Why visibility is crucial to efficient digital delivery
There’s a secret to accelerated digital delivery that I haven’t discussed much… mostly because it feels too dumb to say out loud.
Here it is: Avoid making big mistakes.
As I said, it sounds dumb… but hear me out. In software development—as in anything—there are two ways to solve problems. As a kid, I learned the “fix it” mindset. When something goes wrong, you do something to solve it—a post-problem remedy of some kind.
I think of post-problem fixes as an old-style manufacturing solution. If a car leaving the production line fails its final inspection, it gets shunted into the “finishing shop”. It may need something as simple as a respray, or it may need stripping back down to the engine.
Either way, there’s going to be a delay, and other “mistakes” are piled up ahead and behind it.
Does any of this sound familiar?
Speaking as someone who witnessed (and caused) a decent number of mistakes in the early part of my career, I believe that struggling projects often replicate this sad story:
A mistake is caught late, delays production, and must be rectified as quickly as possible because it’s causing knock-on issues with other work.
As I said, avoiding big mistakes is a huge part of bringing your project in on time and budget.
The question is… how?
In the last article, I wrote about accelerators—reusable components we deploy with 100% confidence. They are a huge help in avoiding mistakes.
But accelerators can’t do it all. Every project involves bespoke thinking, unique design, and custom code. That’s how we solve our clients’ problems. And I love it. Solving unique problems is just about my favourite thing.
But it’s also where we are most at risk of making a costly mistake, hitting a brick wall, or heading off on a wild goose chase.
To mitigate those risks, we need a different tool from the toolkit. We need to build Visibility into every part of our process.
What is visibility in digital development?
Visibility is about making it easy for everyone to see the wood for the trees. 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.
Status: Is a teammate “at work,” either remotely or at their desk? Are they available, in a meeting, or “asking” not to be disturbed?
Work: What are they focused on right now?
Progress: Is their work on schedule, ahead, or falling behind?
Later in the article, I’ll discuss practical ways to ensure visibility, but for now, let’s just focus on the practical benefits.
Visibility Benefit 1:
Mistakes surface early
The earlier we can see a problem, the less chance it has to derail us.
This is not a new idea. The aging car lines mentioned above have long since been replaced by lean manufacturing processes. When a modern Toyota worker spots a problem there’s no waiting or shunting the car off the line, they pull a cord that lights up a big board and gets people moving.
If the problem isn’t resolved within a short time, the whole production line stops. You can see this concept—Jidoka—in the following video:
Problems are resolved right on the line—before they infect multiple vehicles.
Digital development isn’t manufacturing, but we can still benefit from fast problem resolution. But we can’t solve them unless we can see them.
Visibility Benefit 2:
Course corrections happen faster
How often have you done a ton of work only to find that it wasn’t what the client wanted? Like, at all?
I’ve seen this happen with design work, feature development, and even proposal writing. Somewhere between you and the client, the brief got garbled (I’m being kind) and the wrong end of the stick was grabbed and run with.
And it’s not just with clients. As a young project leader, I had team members cheerfully nod at my requests and disappear to do the work. Later on—sometimes days or weeks later on—I’d check on their progress only to discover that they’d completely misunderstood.
(Or had they? As we know… clarity is now one of my key principles for accelerated digital delivery. Perhaps there’s a good reason for that!)
In any case, working on a tangent is another reason why keeping work visible—whether for ourselves or our clients—can save a lot of pain.
If we can check in with each other easily and often, course correction becomes a lot easier.
Visibility Benefit 3:
Smoother resource allocation
If one of the team is struggling with a piece of work, either its scope or its volume, I want to know as soon as possible.
If they need advice, we can give it. If they need support, they can have it. If the piece of work needs more bodies, we can get them.
Visibility Benefit 4:
Consistency increases
I’ve known people who deny it, but I believe that visibility taps into a basic truth of human psychology: We behave differently when other people are watching.
The degree of difference may vary from person to person, but broadly speaking, we are designed to care about the opinions of those around us.
This can be extremely useful when we are running a team.
In the Accelerators article, I talked about the huge practical value of checklists and processes. I stand by that, but I also know how many development teams have tried to create standard operating procedures, only to find their use degrade over time… and lead to mistakes and delays.
I feel your pain, so let me suggest that making everyone’s work visible is a big step in the right direction.
When our work is truly available to those around us, when we are working on shared documents (or even shared code), we are far more likely to follow a standard.
And—providing the standard is genuinely good—everyone benefits.
How to make your work visible
As you’ll have noticed, we’re really talking about three directions of visibility here:
Our teammates need to know who’s working, and on what.
Leaders need to track project progress so that they can deliver support when it’s needed.
Clients need to see that the project is delivering. Regular updates reduce surprises and keep them feeling included in the project’s journey.
The way we deliver visibility will change depending on the audience, but building visibility doesn’t have to be complicated. Here are a few tools and setups that make a difference:
Availability indicators: Simple tools like Slack status lights signal availability. Remote teams don’t have the benefit of in-office cues, so setting statuses to show availability is essential.
Scheduled rituals: Remote or not, structured visibility practices like daily standups, weekly updates, project demos, or “show and tell” sessions with stakeholders go a long way to keeping everyone informed.
For clients, weekly sessions to share what’s been achieved and what’s planned help clients feel engaged without micromanaging every step.Shared Tools: Tools like Figma for design or shared project boards in Trello allow the whole team to see and comment on work in real time.
Although some might hesitate, giving clients access to tools like Figma or Miro can streamline feedback and keep alignment on track. Yes, there’s a chance of over-commenting, but more often than not, this access just encourages valuable feedback early on.Detailed project tracking on Kanban Boards: Forget the Backlog/Doing/Done approach, use systems like Trello or Monday.com to represent each stage of development.
Makes it easy for anyone to see where each task stands. Moving a card along the board is simpler and clearer than updating each card’s status individually.Use progress indicators: Many of the tools we use can send out automatic updates when work progresses to the next stages. For example, switching design screens to dev mode in Figma can alert the dev team in Slack, or build processes can send status emails.
All of these ideas can be useful, but—as with any technology—leaders must find the balance between what helps… and what hurts…
Side note: Too much visibility leads to obscurity
We all know the frustration of being copied into endless emails, invited to pointless meetings, or becoming blind to apps that notify us about every little thing.
Sometimes this is because the defaults are just wrong, sometimes it’s about people covering their posteriors… and sometimes it's a sign that our teams lack the confidence (or autonomy) to make their own decisions.
These are all good topics for future articles, but the result is the same.
Too much visibility creates noise.
In my last article, I mentioned the value of setting “smart defaults.” The keyword here is “smart.” Getting visibility right is not about blindly following my advice—or anyone's—it’s about doing what works for your team.
If in doubt, start slow and ask for feedback. It’s okay not to know everything, which leads me to…
The biggest benefit of visibility
As I type these words, I’m feeling on edge.
Soon, I’ll share the first draft of this article with smart people I trust… people who know me well enough not to spare my feelings. So naturally, I’m filled with doubt. Not about the ideas, about the way I’m expressing them. Is the article poorly written? Is it obvious? Is it boring?
Visibility requires vulnerability. Putting your work out there, whether it’s an article, a design, or a piece of code, can feel exposing, especially if things aren’t going well. But if you and your team can learn to live with vulnerability, there’s a huge prize to be won.
When we are open and transparent, others find it easier to be the same with you. The best teams I’ve worked with all share this trait—everyone cares more about being good than being “right.”
There’s a ton of power in saying simple things like “I don’t know,” “What do you think?” or “I need help.” Once you get comfortable with vulnerability, you create a virtuous circle:
Team mates are more likely to raise issues early, which means…
Problems and challenges surface sooner, which means…
Mentors and peers have more time to help, which means…
Issues get fixed faster, which means…
There’s less stress (and more progress) within the project, which means…
Team mates are more likely to raise issues early…
And so on.
We’ve all seen the alternatives: Some teams snipe or bicker. Others—and this is often worse—barely talk at all.
If you can see it, you can solve it
Once you’ve seen the value of working with the door open, it’s hard to unsee. Visibility isn’t just about knowing who’s available or what’s been done. It’s about creating an environment where everyone—from team members to clients—feels informed, aligned, and trusted.
By contrast, low-visibility projects often generate unforced errors, distrust, misunderstandings, wild tangents, and blame (as things go off the rails).
If you’ve spent any time working in digital development, you’ll have likely witnessed some or each of these things.
None of them are fun or productive.
So let’s stand out. By committing to make our work visible, we build a foundation of trust, a currency that keeps projects moving, builds client confidence, and ultimately leads to more successful and stress-free digital delivery.
Start with your own work, then push out from there.
