Forty Top Priorities
From the lens of the team everyone called a blocker, and what changed once someone counted the work and made it visible.
THE STORY, IN SHORT A large company blamed its digital team for everything being late. The cause was somewhere else. The team had forty "top" priorities, no way to compare them, and was spending its working time estimating jobs it had no time to do. I couldn't change that from where I sat. Putting it all on one page changed every conversation that followed.
Five minutes.
I was warned before I walked into the room.
Around fifteen years ago I'd just taken over running planning for the digital team of a big consumer business with tens of thousands of staff. My first annual planning meeting was coming up, and people told me to brace myself. Marketing and sales both saw the digital team as the thing slowing them down.
So I asked what felt like the obvious question. Which items on the long list mattered most?
The answer was all forty of them, in no particular order, with plenty more requests queuing up behind.
Where I started
Everyone wanted to know why the team was so slow. On day one, I didn't know either. They were good at their jobs and they were working hard, and they were getting far less done than all that effort should have produced.
So before I tried to fix anything, I counted.
What I found when I counted
Forty top priorities meant nobody had actually chosen. Everything was the most important thing at once. When two jobs clashed, the team had no way of knowing which came first, because nobody above them had ever decided. So whoever pushed hardest went first, and people who learn that pushing works soon push harder.
Each department could put its own requests in order. Nobody could compare them across departments. Marketing knew what mattered most to marketing. Nobody ever weighed a marketing request against a sales one, so that decision never got made.
The team's own work never made the list. Keeping the old systems running and upgrading them had to compete with shiny new features, and it lost every time. A new feature has someone senior asking for it. An upgrade only has the mess that arrives later if you skip it.
Even the time they did have was being wasted. Requests ran at about double what the team could handle. When a slot opened up, the request often hadn't been properly thought through, so work stopped while everyone figured out what had actually been asked for.
Every one of those requests made sense on its own. Nobody had ever put them side by side and asked whether one team could do all of it.
The estimating trap
The business kept asking the team for estimates. How big is this job, how long will it take, when can we have it. Fair questions. The people answering them were the same people who would do the work, and nobody counted the time the estimating took.
So the company was using up the team's working time to ask how much working time the team had. Every estimate slowed them down, and the slower they got, the more estimates they were asked for.
What it felt like inside
I'll keep this short, because the people involved deserve accuracy more than drama.
This was a skilled team that had to ask permission to look after the systems they were responsible for. They were working flat out while the rest of the business called them the reason everything was late, and they had nothing to show anyone to explain why. Overload that nobody can see looks exactly like doing a bad job.
The blame landed wherever the lateness showed up. The people waiting looked at the team in front of them and stopped there. It was nobody's job to look further back, at where all the requests were coming from in the first place.
Putting it all on one page
I couldn't change the list. It was decided above me, in meetings I wasn't in. What I could change was whether anyone could see what the list was doing to the team.
So I put everything in one place: every job underway or waiting, set against how much the team could really do, across all the different systems the business ran on.
That picture gave us the moments I remember best. Once the systems sat side by side, you could see how big a job really was. A small change that needed work on every system before it could go live turned out to be much harder than something that sounded huge but only touched one. People had been judging jobs by how they sounded. Now they could see what each one would really take.
A few practical changes followed. We limited how many estimates people could ask for, and built a simple automatic check that gave a rough ballpark early on, so nobody had to stop real work to look at a request that might never happen. It wasn't precise, and it didn't need to be. For planning, a rough idea of size was worth far more than a perfect number.
I also negotiated a fixed share of the team's time for fixing and upgrading the old systems. That took real negotiation, because the business got a little less new stuff now so the team could go faster later. It was the one change that could break the cycle.
What changed, and what didn't
The conversations changed first. Departments started talking to each other about whose work should go first, because for the first time they could see what they were up against. People were grateful, which surprised me. They still wanted more from the team, and the honest answer was that the team was too small for what was being asked. The difference was that late work and nasty surprises gave way to something people could plan around. They could see why their request had to wait, and roughly when it would get picked up.
The bigger problem stayed where it was. The forty priorities came from decisions made above the team, and the question of team size belonged to whoever held the budget. From where I sat, I could make sure nobody blamed the wrong thing again. Fixing it properly was someone else's decision.
After I left
The team kept up the repair work on the old systems, and things got faster and smoother. Once people understood how estimating worked, they started breaking requests into smaller pieces. Small changes went out quickly, and bigger projects got the time they genuinely needed. People stopped cramming in everything they could think of when their turn finally came, and got much sharper about what would actually pay off. Once everyone could see what each request cost, pet projects got much harder to sneak through.
The same team did all of that without working any harder. The people creating the work could finally see it.
What I'd say now
Fifteen years and a lot of organisations later, I read this as a story about where people look when things are slow.
Everyone looked at the digital team, because that's where the lateness showed up. The cause was in how the requests were created and never compared, and that happened elsewhere. Inside each department, the requests made perfect sense. The problem only showed where the departments met, in one team's to-do list, which was the one place nobody thought to look.
If your team is the one being called the blocker, the most useful thing you can do is show the people creating the work what it all adds up to. Then ask the question that picture always raises. Which decisions, made above your team, filled up its time in the first place?
The simplest version of what I did is a tool called 100 Figs. It takes ten minutes and shows, in one picture, the gap between what a team is being asked to carry and what it can actually carry. Find it in The Toolkit →
There's a name for what was slowing this team down. Read Drag in the Pattern Library →
If this sounded like your organisation, that's worth an honest conversation with someone outside it. Here is how I work →
Blood Sweat and Business publishes one theme a month, examined from three angles. Subscribe to The Log for each edition, and the thinking behind why I chose it.
