Nobody will hand you the expensive problems

A while back I worked with a development team that finished about 65% of what it committed to every sprint. Everyone knew it. You could feel it in the dailies, you could see it in the board on the last day of the sprint, and you could hear it in the tone of the retros. And still, nobody owned it. It wasn't a design ticket, a product ticket or an engineering ticket, so it sat in the gap between the three, and gaps don't get assigned to anyone.

I've seen the same pattern in almost every team since. Backlogs are organized by owner, and a problem without an owner never gets a row. It shows up as a mood instead. The sprint went badly again. Someone looks tired again. The estimate was off again. People mention it in the hallway or in a private chat, shake their heads, and go back to their tickets, because their tickets are what they'll be judged on at the end of the quarter.

The funny part is that these are usually the most expensive problems in the building. A team that delivers two thirds of what it promises isn't just slower. Every plan built on top of its estimates is wrong too. Sales promises dates that slip, other teams wait on work that isn't coming, and the people inside the team start padding everything just to protect themselves. One quiet gap ends up costing more than most features ever earn.

Why nobody picks it up

I don't think it's laziness. Picking up a problem nobody asked you to solve is a real risk. If it goes well, it's a nice surprise and maybe someone says thanks. If it goes badly, you spent time on something outside your job and now you have to explain why your own work slipped. Most people do that math and decide it isn't worth it. Honestly, it's a reasonable call.

There's also a quieter reason. Problems that live in the seams are awkward to say out loud. "We commit to too much" sounds like a complaint about the team. "Nobody has a clear view of who's carrying what" sounds like a complaint about whoever runs the planning. Nobody wants to be the person who says it in front of everyone, so the problem stays in the hallway, where it's safe and also completely useless.

And then there's the plain fact that these problems don't look like work. There's no spec, no deadline, no stakeholder waiting for it. It's very hard to prioritize something that doesn't exist in any of the tools you use to decide what matters.

Don't pitch it. Show it.

At that point the company was cutting costs. Proposing a new internal tool would have gone nowhere, and I knew it. A slide deck would have died in the first budget conversation, probably with a polite "great idea, let's revisit next quarter."

So I didn't ask. I built the first module in the evenings, kept it small, and brought it to a daily already working, with the team's real tickets in it. No mockups, no roadmap, no vision document. Just one screen that did one thing.

I started with the question everyone was avoiding: who is carrying what, and is it realistic? Seeing everyone's load side by side changed the conversation almost immediately. Nobody had to defend themselves or point at anyone else, because the screen was making the point for them. Someone had three big tickets and a support rotation. Someone else had almost nothing because their work was blocked. It was obvious, and it had been obvious for months, but nobody had ever looked at it all at once.

Nobody had to approve a tool that already answered the question in the meeting where people were asking it.

From there it grew the way useful things grow. Within a few weeks the dailies, refinements and retros were all running inside it. Each new piece came from something that bothered the team during a real meeting, not from a plan I wrote alone at my desk. When a refinement dragged, we looked at why and built something for that. When the retro kept repeating the same complaints, we made them visible from one sprint to the next so they couldn't quietly come back.

Over the following sprints the team went from about 65% to about 100% of its commitments.

I want to be honest about what the tool actually did, because it's easy to tell this story as if software fixed a team. It didn't. It made the overcommitment visible early enough to do something about it, while there was still time to move work around. The people did the rest. They started saying no earlier, splitting tickets that were clearly too big, and asking for help on day two instead of day nine. The tool just took away the excuse of not knowing.

What I'd tell my younger self

Back then I thought impact came from being handed big, important projects. I spent a lot of energy hoping someone would give me one. In practice, almost nobody gives you the expensive problems, because almost nobody sees them as theirs to give. You have to go and pick them up yourself.

That doesn't mean ignoring your actual job. I did mine during the day and built this at night, and that was a choice with a cost. But a small, working thing built on your own time buys a kind of trust that no proposal can. Once people have used it, the conversation is no longer whether it's worth doing. It's how to make it better.

Where to look

If you want to have real impact, look at the seams. The handoff everyone complains about. The meeting that runs fifteen minutes late every single week. The spreadsheet someone updates by hand on Friday afternoon and nobody else really understands. The question that gets asked in every planning and never gets a straight answer. Those things are rarely anyone's job, which is exactly why they can be yours.

A simple test I still use: if a problem comes up in conversation three times and nobody has written it down, it probably doesn't have an owner. Write it down. Make the smallest version of a fix that you could show in a week. Then bring it to the room where the pain actually happens, not to a meeting about the pain.

Asking for permission works a lot better when there's already something on the table.