The Tech Time Tightrope: Why Scrum Has No Handle for Technical Health

Kyle hadn’t raised his voice. That was the thing. He didn’t need to. It was 9:20 on a Wednesday morning, and the team had gathered around the whiteboard the way they always did — post-it notes in neat columns across the board, cards migrating left to right through the swim lanes, a couple of yellow ones stubbornly stuck in “In Progress” since last week. The air smelled like dry-erase markers and the particular instant coffee that comes from the machine near the kitchen that nobody loves but everybody drinks. Somchai was tapping one of the cards in the “Done” column, walking through his progress, and the three engineers had just finished — ahead of schedule, for once. He peeled a blank post-it from the stack, smoothed it against the board next to the pricing backend column. “We’ve got capacity left,” he said, leaning back slightly, the way people do when they think they’re about to deliver good news. “We’d like to pull in some cleanup on the pricing service — it’s getting brittle and we’ll need to touch it next quarter anyway.” Nobody moved. The small cluster of people standing around that whiteboard went quiet in that particular way — not hostile, not awkward, just the held-breath stillness of people waiting for someone else to speak first. Kyle, our Product Owner — former Amazon, recently relocated from Seattle, the kind of guy other dev managers had pulled me aside to warn me about — shifted his weight and set down his coffee on the narrow shelf beneath the board. “Can you explain to me why? What’s the value here?”

Nobody moved. The engineers hadn’t prepared for that question. Most engineers don’t. The silence had that specific weight to it — the kind where you become suddenly aware of the office humming around you, keyboards clacking at nearby desks, someone’s Slack notification chiming two rows over, the faint sticky sound of a post-it losing its grip on the board. I’d been through this exact moment before, on the other side of it, and I knew what was happening in their heads: the quiet scramble to translate something they felt in their bones into language that sounds like a business case.

So I jumped in. Not because I had a polished pitch ready — I didn’t — but because I’d learned the hard way that this gap between “we know this matters” and “here’s why it matters to you” is where technical health goes to die. I fumbled through an explanation about the upcoming pricing changes, the coupling risk, the cost of working around the mess later versus cleaning it now. Kyle listened. Then he nodded. “That sounds reasonable. How about we bring this small product experiment onto the sprint with the leftover capacity, and we’ll put that cleanup top of sprint priority for next week.”

That was it. No fight. No political manoeuvring. No passive-aggressive Jira comments. Kyle was a reasonable guy. He just wanted someone to connect the dots for him — the same way any sensible person would before committing resources to something they don’t fully understand.

So why all the warnings from the other managers? Because Kyle asked that question — “what’s the value here?” — every single time. And most engineers, and frankly a lot of their managers too, couldn’t answer it. Not because the value wasn’t there. Because nobody had taught them to articulate it. This created a pattern that looked, from the outside, like an aggressive PO blocking technical work. In reality, it was a communication failure dressed up as a process problem.

And here’s the thing: Kyle wasn’t wrong to ask. As the economist Thomas Sowell put it, “There are no solutions, only trade-offs.” Every hour your team spends on technical work is an hour not spent on product delivery. Pretending otherwise is dishonest. The question isn’t whether there’s a trade-off — it’s whether you’re making that trade-off consciously or just letting it happen by default.

The Structural Hole in Scrum

Let’s name the elephant: Scrum has no mechanism for managing technical health.

Go ahead, read the Scrum Guide. You’ll find roles, ceremonies, artifacts. You’ll find sprint planning, daily standups, retrospectives. What you won’t find is any structured conversation about the balance between product delivery and the technical foundation that makes delivery possible. The closest Scrum gets is a vague notion that the development team is “self-organising” — which in practice means “figure it out yourselves while the PO controls the backlog.”

This creates a predictable dynamic. The Product Owner — who is almost always the least technical person in the room — holds the keys to prioritisation. Engineers who want to do technical work need to pitch it through a product lens, competing directly with features that have obvious, measurable business value. A/B test results, revenue projections, priors — these things have numbers attached. “We should refactor the notification service before it collapses” does not have a number attached, at least not until it actually collapses.

As Kareem Abdul-Jabbar put it, “One man can be a crucial ingredient on a team, but one man cannot make a team.” The same principle applies to your product and technical work. Product delivery is a crucial ingredient — but it can’t make a functioning engineering organisation on its own. Neither can technical excellence in isolation. You need both halves, and they’re not competing priorities — they’re interdependent ones. But Scrum treats them as though they live in separate backlogs of the mind.

I’ve watched this play out in dozens of teams across my years here in Bangkok. The pattern is remarkably consistent with newly formed teams. Everything looks brilliant for the first few months. Velocity is high. Features ship fast. The team demos look impressive. Then the trade-offs start accumulating. A shortcut here, a workaround there, all perfectly rational decisions made under the pressure of sprint commitments. Six months later, everything takes longer than it used to and nobody can articulate exactly why. Twelve months later, someone says the words every engineering leader dreads: “We need to stop the business and do a rewrite.”

Which also generally fails. But that’s a topic for another post.

The Death by a Thousand Cuts Problem

There’s a specific flavour of technical debt that’s particularly insidious: the kind that’s too small to pitch but too numerous to ignore.

You know exactly what I’m talking about. Thirty cleanup tasks, each one or two days of work. Individually, none of them moves the needle enough to justify pulling engineers off product work. You can’t measure the impact of renaming a confusing service, or fixing that one test that’s been flaky for six months, or consolidating those three slightly different implementations of the same business rule.

But collectively? Collectively, they’re the difference between a team that moves confidently and one that’s wading through treacle. Skip them for six months, twelve months, and you’ll watch velocity degrade in ways that are maddeningly hard to attribute to any single cause. Your sprint retrospectives will keep surfacing the same vague complaints — “things take longer than they should” — without anyone being able to point to one thing and say “fix this.”

It’s the compounding problem. Each individual shortcut, each deferred cleanup, each “we’ll get to it later” adds a thin layer of friction. Like cholesterol in an artery, no single deposit is the problem. The blockage is the accumulation. And by the time you notice the symptoms, the surgery is far more invasive than the prevention would have been.

The industrial quality pioneer W. Edwards Deming said it well: “It is not enough to do your best; you must know what to do, and then do your best.” Just telling teams to “balance technical and product work” is not a strategy. You need a mechanism. A handle. Something structural that creates space for this work without requiring engineers to win a debate every time they want to fix something.

How the Industry Actually Handles This

I’ve been talking to colleagues across several companies about how they solve this problem, because pretending any one organisation has figured it out completely would be dishonest. But the patterns are instructive.

Atlassian runs a well-known 20% time model — one day a week where engineers can work on whatever they think is right. It grants genuine autonomy, and for small, individually-driven improvements it works well. The limitation I see is scale: if you need five engineers for two sprints to tackle a meaningful architectural problem, 20% time doesn’t facilitate that. You end up with a lot of individually useful micro-improvements but struggle to move mountains.

Booking.com takes a different approach. A colleague who came from there described a concept of buffer time — roughly 20–30% baked into sprint capacity. Teams use it for cleaning up what they’re working on, sometimes things adjacent to their current work, and also to absorb overrun from product delivery. Here’s the interesting structural insight: anything that exceeds this buffer needs to be pitched as a formal project. The logic is elegant — if you’re going to take more than buffer time, you’re probably doing something significant enough to be measurable, and if it’s not measurable, why are you putting dedicated resource on it?

Amazon operates similarly, according to a former colleague now on my team. Buffer time exists primarily for cleaning up systems you’re actively working in. Larger efforts require a formal pitch with clear business justification. He made one observation that stuck with me: “Sometimes this means we leave legacy systems alone for a long time. We don’t touch them until they’re basically on the verge of falling down. But it kind of works, because by that point it’s genuinely the highest-value thing to fix.” There’s an uncomfortable pragmatism in that — not everything that’s imperfect needs immediate attention, and sometimes the market reveals what’s truly important by threatening to break.

At Agoda, where I lead teams, we’ve landed on something we call Tech Time. The guidance is roughly 30%, but the real principle is flexibility and responsible decision-making. If you’re building something greenfield, your tech time is probably near zero — you’re making the choices right now, there’s nothing to clean up yet. If you’re working on a sprawling legacy system, maybe it’s 50% or more. Whatever the number, we treat it as a dial, not a switch.

This flexibility opens up creative approaches. Sometimes we’ll have three teams each contribute one or two engineers for a quarter, forming a temporary fourth team that runs at 100% technical work while the originating teams absorb a slightly higher product load (a word of caution here — temporary teams come with their own set of risks around dynamics, ownership, and cohesion; I’ve written about this separately). I’ve had one team move to a model of fixed technical work items per quarter. Another runs 60% technical work every second sprint to get more focused blocks of time. The most recent large-scale example was our cross-platform web and app initiative — a multi-year project that required dedicated teams and formal investment pitches far beyond what any buffer system could accommodate.

The point isn’t that one model is correct. It’s that every one of these companies has recognised that Scrum alone is insufficient and built something on top of it to manage the balance.

Building the Bridge Between Engineering and Product

Let’s go back to Kyle and that Wednesday morning standup. The dry-erase markers, the faint adhesive smell of fresh post-it notes curling at the edges, engineers shuffling into position around the whiteboard with coffees still too hot to drink properly. The reason things worked wasn’t because Kyle was unusually reasonable — though he was. It was because someone in the room could translate between engineering concern and business impact. That translation layer is everything.

Here’s what I’ve learned about making it work.

Engineers need to speak value, not just technical truth. “This code is messy” is not a business case. “If we don’t address this coupling now, the pricing changes planned for Q3 will take three times as long and carry a significant risk of production incidents” is a business case. The technical truth hasn’t changed — only the framing. And yes, this is a skill that needs to be taught and practised, not just assumed.

Product Owners need to learn the basics of technical consequence. Not enough to write code — enough to understand that when an engineer says “we’re accumulating risk,” it’s not an abstract philosophical concern. Invite them to architecture discussions. Walk them through what happens when a deployment goes wrong. Make the invisible costs visible. When both sides develop what we might call T-shaped understanding — deep in their own domain but broad enough to speak each other’s language — the “us versus them” dynamic dissolves.

Managers need to be the bridge, not the bottleneck. That morning with Kyle, I jumped in because I could see the gap between what the engineers knew and what Kyle needed to hear. That’s not a permanent solution — ideally, the engineers build this skill themselves — but in the moment, it was the right thing to do. If you’re an engineering manager who can’t articulate the business value of technical work, you’re failing at a core part of your job. Full stop.

As Aristotle observed, “We are what we repeatedly do. Excellence, then, is not an act, but a habit.” If you repeatedly treat technical health and product delivery as separate conversations — one owned by engineering, the other by product — that separation becomes your culture. Not by design, but by repetition. And then you’ll wonder why those concerns are perpetually in conflict.

Practical Handles for Teams That Don’t Have Them Yet

If you’re reading this and thinking “great, but we don’t have any of these structures,” here’s where to start.

Start with buffer time, not permission time. Instead of asking the PO to approve each piece of technical work, build it into capacity planning. If your team runs two-week sprints, plan for 70% product capacity and 30% buffer. The buffer gets used for technical improvements, absorbing product overrun, and the kind of small cleanups that never survive a prioritisation meeting. This requires trust — and I won’t pretend that trust is always warranted. But the alternative is never addressing technical health at all, which is how codebases become unmaintainable.

Separate the small from the large. Those thirty one-to-two-day cleanups? They live in the buffer. They don’t need individual justification. They’re the cost of operating a production system, the same way oil changes are the cost of owning a car. Larger efforts — the kind that need multiple engineers for multiple sprints — those need a pitch. If you can’t articulate the business impact of a large technical initiative, either the impact isn’t there or you haven’t done the work to understand it. Both are problems worth solving before you commit the resources.

Make technical health visible in terms POs understand. Deployment frequency trending down? That’s a number. Mean time to recovery going up? That’s a number. Bug rate per feature increasing? That’s a number. These aren’t vanity metrics — they’re the vital signs of your engineering organisation’s health. When you can show a PO that deployment frequency dropped 30% over six months and correlate it with velocity degradation, suddenly “we need to do some technical work” becomes a data-driven conversation instead of an emotional one.

Play with the dial. Don’t treat your tech-to-product ratio as a fixed policy. Treat it as a lever you adjust based on context. New product? Dial it down. Post-migration legacy cleanup? Dial it up. Quarterly planning is a natural checkpoint for these adjustments. The discipline isn’t in picking the right number — it’s in consciously choosing a number at all, instead of letting it default to zero.

The Bottom Line

As the architect Buckminster Fuller once said, “You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.” Complaining about Scrum’s blind spot for technical health won’t fix it. Building a structure that fills the gap will.

The companies that sustain high velocity over years aren’t the ones that picked the right Agile framework. They’re the ones that acknowledged the framework’s limitations and built practical mechanisms to compensate. Whether that’s Atlassian’s autonomy-first model, Booking.com’s elegant buffer system, Amazon’s pragmatic triage, or Agoda’s flexible dial — the specifics matter less than the principle: you need a handle for technical work, and Scrum doesn’t give you one.

The conversation between Kyle and my team that Wednesday morning worked because the structure was already there. Not in the Scrum Guide — in the habits, the shared language, and the willingness to have an honest conversation about trade-offs. Build that structure in your team, and the Kyles of the world become your strongest allies instead of your biggest obstacles.

Now, if you’ll excuse me, I need to go prepare a pitch for a cleanup initiative that’s been “on the backlog” for eight months. I’m told the pricing service we discussed cleaning up that morning still has most of those workarounds in it. Turns out “top of sprint priority next week” was optimistic. But at least Kyle approved it.