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.
| CTO | VP Engineering | Team lead | Developers | QA | Scrum Master | |
| Develop software | I | I | A | R | C | I |
| Remove blockers | I | I | R | R | R | A |
| Ensure quality of software | C | R | R | A | I |
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.
