A fistful of radishes

comments 2
Growth

The man pulling radishes

pointed my way

with a radish.

Kobayashi Issa

I first came across this haiku when I was reading Jon Kabat-Zinn’s Wherever You Go, There You Are. Something about it really captivated me. 

What was it about? 

An image comes to mind of walking through fields, lost, trying to navigate to the nearest road. Upon noticing that a man is bent over working the ground, the traveller shouts out the name of the destination that she is trying to find, seeing the farmer pop up with a fist full of radishes. He waves one in the general direction.

I researched this poem further, and I found some exploration of the theme on the Poetry London website. Here, it is interpreted through the lens of teaching poetry: the farmer pulling the radishes is the poet, and the traveller is the student learning the way.

When learning poetry, we can only see a poem through the lens that we have inherited: the context of our own lives. In the case of the farmer, the embodiment of the practitioner and the teacher of poetry, his bias is clear: he grows and harvests radishes, and uses them to instruct; he teaches what he knows. There are many things that he does not know that he does not teach. But is he aware of this?

Photo by Daiga Ellaby on Unsplash.


When thinking about this haiku, it made me consider my own role as a manager, and even though it still feels uncomfortable to say so at times, a leader. When I am asked for my opinion, I am aware that it carries weight. But am I also always aware of my own inherent biases? 

I carry a number of biases, without malice. These are biases that I must work at keeping in check. Here are some that come to my mind.

  • By trade I am a backend engineer, with a PhD in compilers. My view on solving technology problems often steers from this skillset first, and not necessarily from other methodologies and technologies that may be better suited. What am I missing out on when I think of the solutions to problems, or give my advice to others?
  • I am quite confident in front of groups of people, but others may not be. Am I preventing others from talking?
  • I like to be decisive and tend to think fast without necessarily knowing all of the details. Others are slower, more analytical thinkers. Do I drown them out?
  • I am a white male in technology. I am inherently part of the gender and diversity problem in our industry. Do I have any biases that I don’t even know about that prevents people that aren’t like me progressing? How will I even know?

I struggle with these kinds of “checking myself” issues daily. There are ways, however, that we can combat our own biases. The best way is by surrounding yourself purposefully with others that are not like you.

Some of the most productive and effective relationships that I’ve had with my staff are when they are totally unlike me. Even abrasively so.

Slower thinkers challenge my expediency. 

JavaScript engineers, data scientists, delivery managers and QA engineers all force me to think about problems from different angles, in the best interests of different groups of people. 

The opinions of the most reserved staff often reveal the best and most cerebral parts of a discussion. 

Ensuring that we have excellent female managers, technical leads and interviewers has made our culture more inclusive.

The only way I’ve found to tackle your own biases, which are rarely malicious, but always apparent, is to surround yourself with people that are different, able to challenge you, and are equally aware of their own biases. 

The conflict and debate force better outcomes.

If you surround yourself with others who are just like you, then you’re stuck with a fistful of radishes.

Ownership

Leave a comment
Growth
Photo by Agê Barros on Unsplash.

Tick tock

How much time is wasted in the cracks between phases of work?

A feature is code complete, but the pull request is waiting on review. 

Stalled

The feature branch is deployed, but it needs QA. 

Stalled

Everything is finished, but it needs deployed to live. 

Stalled.

As a phase winds down before it becomes the next one, either due to needing internal input from the same team, or due to needing external input from another team, the person doing the work has to stop and wait.

That individual may naturally turn their attention to another task so that they can remain productive, such as starting on the next ticket.

However, an individual’s focus on individual productivity can often cause the total productivity of the group to suffer.


“Oh yeah, that’s just waiting for QA. It’s been like that for a while now.”

“Did you let them know it was ready?”

“Nah, the ticket’s been moved into the right column, so they’ll pick it up.”

Well, maybe they’ll notice that it’s there, and maybe they won’t, because they’re busy with something else.

Even highly productive individuals can demonstrate a lack of ownership over the overall goal of shipping software. Instead the individual is only focussing on their part of the task. The other parts are on the other side of the fence, and that’s somebody else’s problem.


“That one’s waiting on the other team to push their changes upstream.”

“OK, did they know that you’re waiting for them?”

“They looked pretty busy, so I thought I’d let them get on with their stuff for now.”

Sometimes work can take hours, or even days, longer than it needs to because an individual only pushes forward the part that they can control. A particular process doesn’t guarantee that complex work being done by lots of people will be completed. The people themselves make it happen by doing whatever is required to see the whole task through.

When individuals embrace total ownership of their collective output, things get done faster. This is predominantly a change in mindset, not a change in process. 

But before we explore that mindset more, what if people don’t understand their responsibilities in the first place?

RACIs

Often when roles aren’t clear, the natural thing to do is to collectively spend time defining them. A tool that many find useful is the Responsibility Assignment Matrix, commonly referred to as a RACI

Within teams, departments, or even whole companies, you can draw up a RACI to better understand the different roles that individuals take for particular tasks.

These roles are, for a given task:

  • Responsible: Those that do the work to complete the task.
  • Accountable: The person ultimately responsible for delivery of the task. They approve the work that the responsible person does.
  • Consulted: Those that have their opinion sought through two-way communication.
  • Informed: Those that are updated on progress via one-way communication.

Hopefully you can see where the acronym comes from now.

Here’s an example of what part of a RACI might look like. The uppercase letters in each box correspond to the role definitions above.

CTOVP EngineeringTeam leadDevelopersQAScrum Master
Develop softwareIIARCI
Remove blockersIIRRRA
Ensure quality of softwareCRRAI

If a team is finding that tasks keep dropping through the cracks, then taking that team through a RACI exercise can often uncover all sorts of incorrect perceptions about how things get done. Give it a go and see what happens. I guarantee you’ll have some interesting debates.

Yet, remember what we said before: people make things happen, not processes. The RACI will not solve your ownership problems, but it will stimulate interesting discussion.

People solve ownership problems by realizing that they need to take total ownership of their collective output. You may have the most detailed RACI filled in, but without a mindset of ownership, little will change.

Hiding in definitions and process

Processes and definitions create places to hide within them. If you know you’re responsible for X, why should you care about Y? After all, the RACI says so, right?

“Oh, that’s her remit.”

“Nothing to do with me.

“Yeah, the other team should probably look at that.”

“Not my responsibility. I’m busy enough as it is.”

We could imagine a situation where a RACI could be abused to encourage a “not my problem” mindset.

After all, if the QA is ultimately accountable for ensuring the quality of the software being released, should the developers care less about it? 

Of course not.


When technology companies are start-ups, there is no choice for staff but to care about everything, because there simply is no other way. Start-ups embrace total ownership through lack of resources.

But success breeds growth, causing expansion of people and divisions of responsibilities and roles. The more you divide and spread that ownership, the more gaps and barriers that form between those subdivisions. Individual remits become narrower and deeper. 

You work in your box, and they work in theirs.

Instead of the founder selling, building and fixing, you now have developers on specific teams, numerous specialties of salespeople for diverse regions and products, and multiple roles for keeping customers happy and engaged. 

The risk of this scale is the collapse of total ownership.

When the remit focussed on is a tiny part of the whole, the individual optimizes for individual performance. This can easily be at conflict with the overall goal of being a successful company. 

Your lead generation machine could hit target, but those leads could be junk. Your engineers could ship to a deadline, but the quality could be awful. Your marketing event could have record attendance, but none of the attendees convert to sales. 

Overly local focus creates local maxima, and people across the company could be kings and queens of the minor mountains without conquering anything of worth.

And, of course, fingers will point: sales can’t convert those leads because they’re junk. They think it’s the fault of marketing. But marketing thinks that better salespeople could convert them. Engineering get accused of shipping a bad product, but they blame the deadline that was set by others. 

When you only care about your little patch, you’ll dump the rubbish over the fence to keep it looking pristine.

Owning it all

Instead of hiding behind processes, or driving relentlessly towards individual KPIs, truly excellent staff take ownership of the entire thing

It wasn’t your fault, it was mine. 

Leaders take ownership for their teams, and for their departments, even if it hurts and it bruises their ego when things go wrong that were out of their control.

Ownership as a mindset spreads. It builds respect. It causes different questions to be asked.

“Oh yeah, that’s waiting for QA, but I totally forgot to ask them. I’ll do that now and pair with them on it.”

Much better.

“This is waiting for the other team to push their changes upstream. I’ll ask if they can do that now as it’s blocking us.”

Excellent.

“That pull request is still waiting for review. I’ll go ask a couple of people if they can review it now.”

Perfect.