The improvement killer: why your team isn't getting better

Imagine two kitchens. In the first, a short-order cook stands over a hot grill. Tickets stream in: "Two eggs over easy!" "Burger, no onions!" "Pancakes, side of bacon!" The cook's entire world is the next ticket. Success is measured in seconds: how fast can an order be flipped, plated, and sent out? There's no time to think about a better way to organize the station, a more efficient way to prep ingredients, or a new recipe. The goal isn't to become a better cook, it's just to survive the lunch rush.

In the second kitchen, a chef and her team are responsible for a seasonal menu. They have a clear objective: create an amazing dining experience. While they handle orders every night, they also spend time discussing what worked and what didn't. They experiment with new techniques, source better ingredients, and refine their plating. They own the entire process, from concept to execution. Their goal isn't just to get food out; it's to master their craft.

Many software delivery teams today are stuck in the first kitchen. They're caught in a transactional loop, and it's killing their ability to improve.

The transaction trap

When work is purely transactional, it's perceived as an endless series of disconnected tasks. A ticket comes in, the team works on it, closes it, and immediately picks up the next one. The primary, and often only, metric for success is speed: How many tickets did you close this week? How quickly did you respond to that request?

This mindset creates a system where continuous improvement is seen as a distraction, not an investment. Why would a team spend half a day refactoring a messy piece of code when they're being judged on closing five tickets by lunchtime? Why invest in automating a manual process when that investment takes time away from their real work?

In this environment, there's simply no incentive to think beyond the immediate task. The team doesn't own a product or a service; they just process tasks. Their job isn't to make the system better, it's to clear the backlog. This is the difference between ownership and dependence. Transactional work nurtures dependence on the next instruction, while ownership nurtures autonomy and initiative.

Sure, you might find a few passionate individuals who try to make improvements on their own time. They're the exception, not the rule. They are fighting against a system that rewards speed above all else, and eventually, even the most dedicated person gets tired of swimming against the current. You can't build a culture of improvement on the heroic efforts of a few.

Is this not just the nature of the work?

When you have been stuck in a transactional system for a while, it is hard to see a way out. It feels like the work itself is driving the transactional nature of the system. This is not the case for software delivery teams. With the right mindset and a clear focus, we can stop chasing the backlog and take ownership of the process.

More about that in the next blog.