Lessons from Leadership is Language on Feedback

That title couldn’t be any more explicit. I spoke with a colleague who shared a challenging situation she’s in. After our talk, I couldn’t help myself from thinking what if I were in that situation and had to be the one to make that difficult conversation. I also took it as an opportunity to revisit what I read about from Leadership is Language by L. David Marquet, and relate aspects or lessons from the book on to the context of giving feedback. Of course, I can’t share the exact examples here, but I tried to give close enough explanations.

Give information, Not instructions

  • Instead of saying “You should do this or that,” try to provide the information that would reasonably lead to that suggestion (or maybe even better suggestions from them).

Focus on behavior, Not characteristics

People will have better control over their behaviors, than on characteristics they have.

  • Instead of saying “You’re an ineffective ______________,” try citing the specific behaviors that led to the idea that they’re an ineffective whatever.
  • Same when it’s positive. Instead of saying “You’re a great team member,” say the behaviors that you’d like to be repeated.

On the process, Not the person

While I think asking one’s self “How can I be a better <insert role here>” is good for introspection, asking that to another person might not always be taken positively. I think we are naturally defensive and we can’t expect everyone to be consciously going against that natural tendency. Asking “How can you be a better leader?” might somehow be misinterpreted as “You’re not a good leader, you suck, you really need to improve…”

  • Instead of asking that, shift focus on certain processes. Say that person’s responsibility includes owning say the peer review process, then instead of asking “How can you be a better peer reviewer,” ask “How can we improve on the peer review process,” “What do you think can we try to better track the peer review comments,” etc.

Observe, Not judge

I think this ties up with the previous items on focusing on behaviors and giving information. By trying to take a non-judgmental stance, ideally we get to show that we are not condemning the person, that we are open to working with the person to address the objective information provided.

  • Instead of (judging the person) “You wrote that report poorly,” or (judging the work) “That report is poorly written,” provide the observations instead “I noticed three spelling errors in the report”.

I just reused the example from the book here. With that example, it feels easier, clearer or more achievable to address the “three spelling errors” compared to a poorly written report.

On achieving excellence, Not avoiding errors

I think asking how to avoid errors is a fair question to ask because that is something you want to achieve. This also works well for me for introspection. But related to what I mentioned previously, asking that can be taken negatively even if you don’t mean it to be. “How can you avoid so-and-so” might come across as rubbing salt to the wound or might feel like the focus is on what the other person is doing wrong.

  • Instead of asking “Why do you keep on missing those bugs” (which also feels accusatory and it’s often not the case that people intentionally try to miss bugs), ask “What do you think can we try to find those bugs sooner?”
  • Instead of asking “How can your outputs be less buggy,” ask “What do you think are we missing in our process so that we can get things right in fewer reviews as possible?”

In writing about this, I have had a little more time to think about it. But the challenge I guess is making these conscious word choices on-the-fly or when the situation unexpectedly calls for it.

Read: Agile Conversations

I’ve previously told myself that I’d ease up on somewhat work-related reading, and shift to something lighter instead. Well, that was a quick break. I came across this newly released book and I ended up checking it out, and finishing both books today. The book is Agile Conversations: Transform Your Conversations, Transform Your Culture by Douglas Squirrel and Jeffrey Fredrick. I feel like I expected too much from the book; maybe it was just too soon for me to read stuff like this again since what I picked up from it are like echoes of recent readings.

It’s not altogether for naught. On the upside, I did pick up the origin story (one sentence, people might expect an elaborate story) of that familiar “Trust but verify” statement.

Anyways, sharing below my summarized bullet points which aren’t really as informative as the actual book or my actual notes, but hopefully, they’d give me a hint on where to find what in case I want to read back on it.

  • Change your conversations, change your culture. It’s like their “Save the cheerleader, save the world” statement.
  • In adopting something codified, there’s the tendency to take in the superficial process changes (e.g., having daily scrum, WIP limits, tool selection, etc). But more than just the processes, it’s the shift in mindset and view towards people as drivers of the success (over processes) that are needed. That Taylorist factory mindset needs to be dropped.
  • There are two theories of action. And we’re unfortunately we’re naturally more inclined towards the counterproductive, defensive behaviors of Model I. But the good news they say is, through regular effort and practice, Model II (behaviors of transparency and curiosity) can be learned.
  • Conversational Analysis can be used to heighten your awareness for where you lack genuine questions (you ask, but not really), when you have unexpressed thoughts/feelings, or when you encounter certain triggers or exhibit tells and twitches.
  • Trust Conversation – Be vulnerable. Be predictable. Use the Ladder of inference in discussions where there’s misalignment (i.e., step back, find safe common ground, before you move deeper into the discussion).
  • Fear Conversation – Watch out for Normalization of Deviance (that process wherein we become somewhat immune to the red flags and fail to raise them). Use coherence busting to step back and refrain from jumping to conclusions or assuming the worst.
  • Why Conversation – Why you don’t start with why is because you need to address Trust and Fear issues first. Distinguish between interests and positions; step back to understand the reasoning and the interests that lead to the possibly conflicting positions. Advocate your position, but be inquisitive on what the other side has to say. Work with a joint design for increased stake of people in the Why.
  • Commitment Conversation – This brings up the “It’s done, but…” example. Agree on meaning. Walking skeleton i.e., strip down to the bare essentials and progressively add in (as the bandwidth would also allow).
  • Accountability Conversation – Adopt Theory Y (or People Positive as mentioned in Brave New Work) mindset. Use Directed Opportunism for communicating plans and intentions up and down the chain of command. Radiate intent and information (e.g., current state, plans and intended outcomes, alert to obstacles) using Agile Radiators (e.g., ceremonies like Planning, retrospectives, demonstrations; and tools like information radiators).

I also had a bunch of knee-jerk reactions to some stuff.

What I’ve been reading, and what to read next

Yesterday, I was shopping in Amazon for the next book to read. I was having a bit of a hard time since I couldn’t really pinpoint what I was looking for. Maybe it’s a mix of quarantine blues, and this feeling that the books I’ve been reading have quite recurrent themes just differently stated.

This 2020, so far, I’ve gone through a few titles. There were topics I read in line with product management:

There were books about leadership, evolutionary organizations, and maybe somewhat about driving change:

  • Brave New Work (2019) by Aaron Dignan – At USD5.99, this feels quite sulit!
  • Reinventing Organizations (Illustrated, 2016) by Frederic Laloux, illustrated by Etienne Appert – This one is available in an option the author calls “pay-what-feels-right.”
  • Going Horizontal (2018) by Samantha Slade – Among the three, I think this is the only one aimed with individuals more than the leaders in mind.

Still on leadership:

  • Essentialism (2014) by Greg McKeown
  • The Culture Code (2018) by Daniel Coyle
  • Fast Times (2020), a perspective from leaders at McKinsey & Company – This one was available at Kindle Unlimited which I had a discounted subscription of $0.99/month but only for a limited period back then.
  • Art of Action (2011) by Stephen Bungay – Not available in Kindle

Then on leadership with focus on communication:

Then there’s this one that’s a bit out of place, but quite relevant in these quarantine times:

  • Remote (2013) by Jason Fried and David Heinemeier Hansson – (but I like their newer book more)

The leadership books and organizational change books especially are really more intended towards leaders (as it should be, I suppose) than individual contributors like me. But that’s not to say I don’t get anything out of them. The insights are very interesting, the anecdotes mostly enjoyable, and the examples give you an idea on how to possibly be better. It just takes a little extra layer of processing of how can this apply to me, or how can I apply this in my own capacity, or how do I get THEM to apply this. So back to my shopping… I guess one other reason why I was stuck was because I felt like reading similar books will only be like the author preaching to the choir, and I’m not really the one who needs convincing.

So I’ve decided on a much lighter reading on a topic that I also enjoy (because of course). Next read is: Dreyer’s English: An Utterly Correct Guide to Clarity and Style.

One link leads to another

Sometimes I come across posts or material in the internet on topics that piques my interest. It could be something I want to know more or understand more about. Or it could be related to a conversation or two I’ve had within the day that makes me question certain things. So sometimes I google, and sometimes I just stumble upon them through various feeds — could be Twitter, email, Medium, IG, and Facebook even. And then one link leads to another and before I know it, it’s 2AM and I should be getting some sleep. So anyways, here’s a dump of some recent links, in no particular order. I hope someone finds them helpful or interesting as I have.

Agile Product Ownership in a Nutshell (15 minute video) – I like how the content was easy to follow. There were a lot of points worth highlighting, but I guess what hits home the most is the mention of three things that need to be balanced:

  • Build the right thing (PO tends to focus here)
  • Build the thing right (dev team)
  • Build it fast (SM or Agile coach)

So you want to be a Scrum Master (book) – This is a Leanpub book which you can get for free, or not if you can afford to make a payment / contribution. It’s written by an Agile community of interest with the intent of sharing what they’ve learned and what they’ve seen to have worked.

The 3 most effective ways to build trust as a leader (post/article) – Got this from Rob Lambert but I can’t remember where exactly — “Three typical management activities that get poor results and three that get good results”. I’m not really a leader by title but the three ways of building trust that the post enumerates are still relevant to me and they emphasize points that I value: Empathy, clarity of intent, and follow through.

DISC Profile Types (personality test) – This is something I picked up from Rob Lambert’s webinar. For each profile type, there are recommended ways on how to better communicate with them, and inversely there are recommended ways on how to encourage others to better communicate with you. Took the test myself and got 48% Compliance, then Dominance, Steadiness, and lastly Influence.

12 common mistakes made when using Story Points (post/article) – This reminded me of something a colleague had shared wherein their Scrum Master wants them to estimate in hours rather than in story points, and also her thinking that story points can be easily translated to hours.

Agile Makes No Sense (post/article) – Let me just quote some lines (actually last 2 paragraphs) that I liked…

What is the smallest thing that could add value (and make sense)? A better standup? A better retrospective? Inviting a customer to a demo? Pairing for a day? Agreeing to get something into product in a couple days? Try that. Make one thing make sense as in “wow, I can see how that created value”.

When you take this humble approach — instead of “installing” a bunch of artifacts, tools, roles, and rituals AKA doing Agile — I think you’re embracing the true spirit of Agile.

Brain dump: How I’d like my Agile testers to be

So I was just thinking about how I need the testers to work in our project (and maybe in any other project). This started as a brain dump and then the next thing I know I’ve got this outline already. So anyways, If I were to outline what I’d look for in testers, I’d look into the following areas:

  • Attitude towards testing
  • Technical competence
  • Being a team player

Attitude towards testing

Working on an Agile, greenfield project really needs to have testers who are quick studies, self-sufficient and proactive. Most of the time we are given just the user story and some mock-ups, so I need the testers who can model the user story in their heads or in their notes, ask the right questions about it, and do it on their own (i.e., not wait to be served the information they need on a silver platter).

I think testing is like problem solving. It’s like: Hey, you’re given this user story. How do you test it to make sure it’ll pass the PO’s review? What exactly do you need to test? What do you need to know to test it? It has a save functionality– what does it save, where does it save it, who’s allowed to save, are there stuff that needs to be derived or transformed, etc. It has a read functionality–read from where, how do I know I’m pulling the right data into the fields I’m checking, how do you get data entered to be read in the first place, do we format certain items differently, etc. Hey, look at this screen, what can I do with the controls in the screen, what can I do that I’m not supposed to, etc. Hey, I found a bug–can I consistently replicate it, can I narrow down the cases when this bug would appear, is this just a symptom of an underlying bug, is this even a valid bug, etc. There’s a fix I need to retest–what could possibly be affected, do I need to retest everything, etc. There’s a lot of figuring out and critical thinking involved.

What I don’t like is to reduce testing to an activity where we just write test cases and execute the test steps without thinking about how our work can provide value to the team, to the product, to the client, and to people who’d end up using our product. I really want the testers go into the project with the desire to make their being in the project really matter.

Technical competence

You can’t just WANT to be a solid contributor to the project, you have to BE one. You can be the most idealistic person but that won’t get you to where you want or need to be, you need to be able to execute.

For testing, I don’t necessarily equate technical competence to being able to automate. Being able to automate tests doesn’t mean so much if your tests can’t find the issues that needs fixing. We have to keep in mind that the product is the actual product — not the test automation scripts.

As I mentioned earlier, testing is like problem solving. Part of this includes modeling the application or feature you need to test — figuring out where there’d be if clauses or doing some decision tables, figuring out the data flows, state transitions, figuring out combination of valid/invalid input, etc. Figuring out what you actually need to test given that the lines defining the scope could sometimes get blurry. Then there’s instances where you have to work with the database, parse some flat files, or with some API. There are also instances when you need to simulate a certain scenario — and you have to figure how to do this right otherwise you might just bring up an invalid test case or bug. There are also instances when looking under the hood allows for more efficient testing; for instance I’ve reviewed database scripts and that reduced the effort as opposed to executing the test cases in fully black box mode.

You’ll also need to collaborate with developers and you need to be able to keep up with the discussions. You can’t rely on the layer of having the test lead interpret stuff for you. And it just saves people time from having to explain things if you can keep up with the technical discussions. When you report bugs, it is also very helpful if you’ve done your own investigation to narrow down the possible causes. When it comes to bug reporting, I always say “A problem well stated is a problem half solved.”

There’s a lot of collaboration within the Agile project. Roles of people you’ll engage with include fellow testers, devs, UX designer, BA, PO, and possibly support. You’ll need to share status updates, raise impediments, raise bugs, raise potential enhancements, raise a lot of clarifications, and possibly conduct demos of the user story. There’s going to be a lot of communication going on so you really need to know what you’re talking about, and you have to know how to talk about it.

Being a good team player

This is good to have in any project or in any team. You want to work with people who are responsible, reliable and who keeps each other informed as needed. You want people to pull their own weight in the project, and to help each other out esp when the load gets heavier for some. And it’s all the more appreciated when people help without having to be asked to help.

Meeting the Sprint goals is the primary focus, and so when needed, the lines defining the roles are blurred and folks try to contribute whenever and wherever they can. For instance, I’ve taken on the BA role while another tester has taken on the PM/scrum master role. We have front end devs who also work on back end tasks. When we needed load testing to be done and we couldn’t get another tester to work on it, one of our devs took on the task. When there were some data update needed, the team split the task among those who can help so as to get the job done faster.

Summing it up

It’s hard to come up with a checklist of traits for what I’d like in the testers in my team. Essentially, I want testers who sincerely want to contribute to the project. I want testers who can actually test, who respect testing per se, and who can build their credibility within the team. And of course, I want team players to help make the not so easy task of building software hopefully less hard. People won’t always fit the bill off the bat, but what’s important is to advance towards improving.

3 stages; shu-ha-ri

Recently, I’ve been putting the waiting time for eclipse/tomcat to start-up and restart to good use by doing some reading (actually, more of skimming).  So far, I’ve been leafing through Alistair Cockburn’s Agile Software Development.  I came across a part of the book on stages of learning that reminded me of the Dreyfus Model which I’ve picked up from Pragmatic Thinking and Learning.

The book describes three stages of behavior of people who are learning or attempting to master new skills:

  • Following – At this level, people simply try to follow and copy whatever works. They only seek out explicit instructions. I suppose the predominant mantra at this stage is: “At least it works.”
  • Detaching – Here, they learn the “limits of the procedure”. They start looking into other ways, and figure out how to make adjustments when things go wrong. I reckon, at this point, they’re no longer bound to explicit instructions and they manage to make workarounds when needed.
  • Fluent – Here, at the third level, they’ve somewhat achieved a zen-like stage wherein they just know the goal and they just know what needs to be done to reach it.

Alternatively, there’s Shu-Ha-Ri, which roughly translates to learn, detach, and transcend.

  • At Shu (godblessme), “the student builds the technical foundation of the art… the student should be working to copy the techniques as taught without modification and without yet attempting to make any effort to understand the rationale of the techniques of the school/teacher.”  Mmm’kay, I do a backswing like so… what do you mean another 30 rounds?!
  • At Ha, “the student must reflect on the meaning and purpose of everything that s/he has learned and thus come to a deeper understanding of the art than pure repetitive practice can allow.”  Oh, right… locking my wrist does make for a better angle upon contact.
  • And lastly, at Ri, “the student is no longer a student in the normal sense, but a practitioner. The practitioner must think originally and develop from background knowledge original thoughts about the art and test them against the reality of his or her background knowledge and conclusions as well as the demands of everyday life.” You want to do some baseline volleys? Sure, no sweat!

Now, what exactly is the relevance of these different stages.  As a learner or a receiver of information, it reflects the type of information that you seek out.  As someone from the other end, it teaches you to be more wary of the needs of someone who’s just learning. As someone who communicates, it teaches you that whatever you said that you think is crystal clear could be any of the following:

  • Unnecessary chatter, esp for someone from a higher level
  • Undecipherable, esp for someone from a lower level
  • Clear enough, but it will never be crystal clear.

One other thing that the chapter expresses is that communication is imperfect.  You can’t do away with its imperfection.  Having an understanding of one of the possible causes of miscommunication (i.e., the different stages) would hopefully at least make you tolerant if not make you strive to bridge the gap.

Collecting quotes (20090124)

Genuine ignorance is profitable because it is likely to be accompanied by humility, curiosity, and open mindedness; whereas ability to repeat catch phrases, cant terms, familiar propositions, gives the conceit of learning and coats the mind with varnish, waterproof to new ideas.
John Dewey

The danger in communication is the illusion that it has been accomplished.
George Bernard Shaw