Why Clarity is Critical for Accelerated Digital Delivery
True story.
I’m in my office. It’s 10AM Friday, and I’m banging my head against my laptop.
(That’s a metaphor, but it might become true any second now.)
In two days, we’re supposed to push an update live for a major retail client. I’m not running the project, but I’m checking the Kanban board to confirm we’re ready. Go? No go?
And we’re not ready. Not nearly.
The UAT column still has cards on it. Not one, or two, or even ten. Ninety-five unaccepted cards.
I need to talk to the team. Now.
I count to ten… get as far as three… then reach for Slack.
From pictures to processes
In the last article, we looked at how visibility accelerates digital delivery. Here’s the crux of it:
Visibility is about making it easy for others to see where we are—by which I mean our status, our work, and our overall progress. When we do this as a team, a lot of good things happen.
Although visibility is (sorry, I can’t help this) easy to see, it’s only ever a snapshot of a moment in time. It’s a picture of the process, not the process itself.
And herein lies the danger.
In almost every business conversation I have (or article I write), I touch on the importance of process. It’s process that drives work through the system. It’s process that governs how fast, efficiently, and accurately we deliver.
But “process” is not a principle. Every team I’ve worked in, whether world-class or amateur-hour, has followed some form of process. Some were friction-free and wonderful; others were the digital equivalent of working with the Sheriff of Nottingham.
(“Locksley! I'm gonna cut your heart out with a spoon!”)
If great processes drive great results, what drives great processes?
10:17AM
I’m talking to two developers on the project. Their response to the 95 cards is a helpless shrug of their shoulders. They did their job by getting their cards to UAT. What happens next isn’t their responsibility.
They're not wrong, but neither is this helping us get back on track. The guy responsible for UAT isn’t in today, but he knew about the deadline. We need to push the update on Sunday because that’s when our client’s (300) retail stores are actually closed.
If we miss this window, we miss a whole week.
Here’s the thing. I trust the team. It doesn’t make sense that they would leave without mentioning 95 untested cards.
Which means that I no longer trust what I’m seeing on the Kanban board. Should we be testing all of these cards? Some of them? None of them?
We have a huge amount of visibility… but zero clarity.
Clarity (and the three questions that matter)
Clarity is a critical principle in accelerated digital delivery. If you’ve worked in or with an outstanding team, you’ll know that that can always answer three key questions:
What needs to be done next?
How should it be done?
Who is responsible for doing it?
If you think this sounds simple, you’re right, but it’s also rare, especially end-to-end across a process.
That’s why written processes—checklists and Standard Operating Procedures—can be so valuable. They separate the signal from the noise, lessening our reliance on snatched conversations or half-remembered meetings.
Instead, we have clear, functional steps that relentlessly move our project forward.
10:37AM
I’m getting ready to do something I hate—reaching out to people who should be enjoying a day off.
At the moment, I trust each of them far more than I trust the Kanban board. I’m hoping that the cards are actually done, but are sitting in the wrong column.
In other words, I’m hoping that this is a handover problem… a process problem.
And the irony of that hope isn’t lost on me.
None of these people are responsible for our process. I’m the leader. That’s my job.
I send the message.
Focusing clarity where it matters most
World-class businesses are highly functional, creating massive value for their clients or customers.
If your team can answer “the three questions that matter” at every stage, work flows quickly through the system. When they can’t, it stalls, goes missing, gets done twice, or (often worst of all) done poorly. I have a special loathing in my darkest heart for work that needs to be redone. That wrecks project plans, budgets, and confidence in equal measure.
And although the principle of clarity is simple, the reality is that it takes a lot of work—especially if we are talking about complex work like digital development.
In practice, it can help us start if we focus on a few high-risk areas. Here they are:
Meetings
There’s a blizzard of advice on effective meetings, but to my simple mind, it comes down to three things:
Know what you need to resolve.
Get the right people in the “room.”
Document the decisions, actions, and responsibilities.
That’s it.
Handovers
The gap between one person putting a “project” down and another picking it up may be the single biggest risk to accelerated delivery. A customer mindset is critical here. If the UAT Team (to take a random example) is the developer's “customer,” what should the developer provide? What does the UAT team need to successfully execute their work—every single time? Again, this is simple stuff, but standardising how work gets transferred has saved our team thousands of hours.
Feedback
Many of us suck at giving effective feedback. The gold standard is, of course, fast, specific, and honest. Often, though, what we get is slow, vague, and obfuscating.
It should go without saying that brutal or overly personal feedback rarely helps anyone, but neither does sugar-coating the truth. Great people value good feedback because they want to get better. Make feedback sessions into conversations that produce clear, specific, and documented steps forward. That’s the (functional) reason we’re doing it.
Problems
Things go wrong. Mistakes are made. Clients change their minds (then change them back). That’s life. Problems are rarely a disaster in digital development, but our response can often be the difference between starting to fix things right away or spiraling further downhill.
Here’s the critical thing to remember: The moment of guilt, panic, or frustration after you or a teammate makes a mistake is the moment you’re at the greatest risk of making another. One problem is rarely a disaster, but three or four compounded together are what sinks ships, downs planes, and gets contracts cancelled.
Create a clear process for reporting problems, with explicit protections for the team member reporting the issue. We don’t want people hiding mistakes, we want to know about them and get them fixed. Four questions are useful here to get clarity and move forward:
What happened?
Why?
What do we need to do to fix it?
How can we prevent it from happening again?
Also—don’t leave struggling teammates in some asynchronous Slack channel waiting for the occasional sad crumb of advice. Jump on a call and actually help them.
10:47AM
My phone shivers on the desk in front of me.
It’s Slack—one of our UAT team responding to my questions. A quick message, but more than I have any right to expect on their day off.
I read it; then I reread it to ensure I’m getting it correctly. There’s some confusion in the message, a touch of surprise… but fundamentally it sounds like we’re okay.
The client’s UAT team has already signed off on ninety-three of the cards; the other two are last-minute bugs being worked on today.
The code will ship on Sunday.
“Okay”, I think. “Okay, fine.”
But it’s not fine yet. This was forty minutes of raised blood pressure and low productivity. I still don’t know why ninety-three cards were in the wrong place, or why the reason wasn’t captured and communicated.
There’s no clarity yet, but there will be.
And once I understand the issue, I’ll fix it with clear, functional communication because that’s how we roll.
In my head—at this moment—I’m a rock star.
Springsteen at Madison Square Garden.
The Beatles busking on that roof.
And weirdly, because I’m a process nerd, I’m starting to enjoy myself.
Building a culture of clarity
Over the next few weeks and months, I plan to write and record specific articles and videos to demonstrate how we deliver clarity in practice—but mostly, this is simple stuff.
A standard meeting template (with someone responsible for filling it in.)
A Trello card checklist that must be completed before a handover.
A clear process for capturing problems (and their solutions).
Clarity may be simple as a principle, but it’s still work. Not just to create the assets you need, but to use them enough that they become second nature to you and your team.
At first glance, functional communication can feel humourless and restraining, but in my experience the opposite is true. Teams that adopt this principle have more fun, less stress, and do better work.
Clarity makes hard work easier. When we do it right, we learn to trust the system and each other. When we don’t, digital development is like trying to do open-heart surgery… with a spoon.
