Simple Barriers to Technical Delivery

When organisations call us in, it’s often because of the damage that’s already been done: missed deadlines, frustrated teams, unhappy stakeholders.

But while the impact can be dramatic, the causes rarely are. More often, it’s like a dripping tap. Small, simple and easy to miss against a backdrop of complex issues, and quietly building up every single day.

Delivery is complex, and that complexity hides the simple things that are easy to assume are fine. Here are five we find again and again.

1. Not making decisions, especially about priority

Everything is urgent. Everything is equally important. Or the decision gets handed to the technical team, who answer the questions they can: how clear is it, how complex, how big? Sensible answers, but answers to a different question. None of them tells you what matters most to the business.

One team we worked with kept receiving more and more urgent new work before the last job was finished. Asked to choose, the business happily pushed a new minor issue ahead of a major one, but still expected the major issue to be fixed. We helped them balance business outcomes and priorities with the technical challenges to build a deliverable roadmap.

You are always prioritising. The only question is whether you passively hope that priorities will arrange themselves, or you do it deliberately against the outcomes.

2. Too much work in progress

Busy teams often have far too much work in progress. Every piece of started work costs something, even when nobody’s touching it. It has to be tracked, reported, chased, and re-learned every time someone picks it up again. Beyond the work that really matters, it’s noise.

And “parked” doesn’t mean stopped. Parked work keeps all the cost of being alive, and delivers none of the benefit. Creating work in progress is a negative action: pushing more in doesn’t make anything come out faster.

Sometimes, someone has to be brutally honest and make the decision to de-prioritise, to allow focus. Some work is an easy yes, and some an easy no. The real debate is often between the maybes, and it can be easy to spend time on that debate rather than actively prioritising the yeses and dropping the noes.

3. Creating heroes and villains

Most organisations have heroes: the people who are called first when something’s urgent. They deliver, they’re praised, and the next urgent job goes straight to them. Meanwhile the rest of the team stands in the shadow, without guidance, judged on whatever’s left.

We worked with a company whose development team was seen as lazy. The development manager was fixing everything himself: days, evenings, weekends. The team wasn’t lazy. It was adrift. When we shifted him from solving the problems to explaining them, the team began working as a team, and the pace of delivery massively improved, along with team motivation and the wider perception of the team.

Some teams become villains simply because they’re blocked, with no one to speak up for them. A track record doesn’t always show what people are capable of.

4. Optimism built on assumptions

Assumptions aren’t random. They lean towards the comfortable answer: it’s done, it’s on track, it’s fine.

We’ve seen managers assume testing was being done, while the team assumed they weren’t allowed time to test and that it was done elsewhere. Both were wrong. Neither asked, and one simple question, from either side, would have fixed it. We’ve seen project plans where every task was assumed to finish on time despite already running late.

Why does nobody ask? Because a simple question can feel like distrust, or like admitting you don’t know.

An assumption is just a question you decided not to ask.

5. Silos without open, honest communication

We see teams making assumptions about each other, where the barriers could be dropped by something as simple as co-location and informal lines of communication. We see one group making decisions on another’s behalf without knowing the implications. We also see messages sent with no one checking they arrived.

“I sent the email” isn’t communication. Equally, processes with no acknowledgement loops, and work thrown over the fence, just pass the problem down the chain without any feedback coming back up.

The org chart shows the boxes. The work happens on the lines between them. Too often, nobody owns the lines, and that makes it a job for senior leadership to encourage and demonstrate the behaviours.

Five issues, none of them dramatic

None of these is dramatic or unusual. All of them are easy to miss when you’re in the middle of delivery. And they rarely turn up alone: pull on one, and you’ll usually find another feeding it.

Every organisation is different, so this isn’t a list of fixes. But we’ve seen these patterns many times, and we’ve found the causes behind them.

Sometimes it takes a fresh set of eyes to see the obvious. To ask the simple questions, without judgement. And to bring to the surface the issues you may already know are there.