Your Senior Engineers Are Trapped in Sprint Tickets — And You Put Them There

It was 2:47 on a Wednesday, and the aircon was losing its war against a meeting room packed three people past comfortable. Somchai had his laptop open but wasn’t typing. He was staring at the sprint board projected on the wall — his name next to four tickets, same as last sprint, same as the sprint before that. A bead of condensation rolled down the side of his Thai iced tea, untouched, the orange slowly separating from the milk the way his attention was separating from the standup happening around him. Someone was talking about acceptance criteria. He was thinking about the authentication service three teams were duplicating because nobody had time to fix it. He’d been thinking about it for six months.

Somchai is a Staff Engineer. His IC level expectations say he should be “leading development of medium to large projects in cross-org environments” and “taking active participation in reviewing architecture solutions of other teams.” His actual calendar says sprint planning, standup, retro, refinement, design review, sprint planning again. You gave him the title. You wrote the expectations. And then you scheduled every hour of his week so that meeting those expectations would require either time travel or a personality disorder.

As the basketball coach John Wooden once said, “Never mistake activity for achievement.” We’ve built entire engineering organisations around this exact mistake — keeping our most capable people perpetually active while structurally preventing them from achieving anything beyond their team’s sprint board.

The Expectation-Infrastructure Gap

Let’s be specific about what you’re asking for. Pull up your IC framework right now. I’ll wait.

Your Staff Engineer expectations probably say something about “cross-org impact” and “technical leadership beyond the team.” Your Tech Lead expectations probably mention “leading mission-critical, long-term projects in multi-team environments” and “impacting org-level initiatives.” These are reasonable expectations. They’re also complete fiction if you haven’t changed anything else about how these people spend their time.

Look at your Tech Lead’s actual calendar for the past two weeks. Sprint ceremonies. Feature work. Code reviews for their team. Maybe a cross-team meeting they were invited to but couldn’t attend because it conflicted with refinement. Now ask yourself: when exactly were they supposed to have that cross-org impact? At 11pm? On the weekend? During that fifteen-minute gap between standup and the design review that always runs over?

The economist Thomas Sowell put it plainly: “It is hard to imagine a more stupid or more dangerous way of making decisions than by putting those decisions in the hands of people who pay no price for being wrong.” You put “cross-org impact” in the expectations. You made it part of performance reviews. But you pay no price when the infrastructure to support it doesn’t exist. Your senior engineers pay that price — in frustration, in stalled careers, in quiet disengagement during standups where they’re thinking about system-wide problems they’ll never get time to solve.

The Title Trap

Here’s what actually happens in most organisations. An engineer is exceptional. They solve hard problems, mentor teammates, write clean code. You promote them to Staff Engineer. You update their expectations to include broader impact. And then… nothing else changes. Same team. Same sprint. Same velocity targets. Same backlog owned by a Product Owner who — reasonably, doing their job correctly — prioritises features over the architectural work that would benefit five teams but belongs to none of them.

You haven’t empowered this person. You’ve given them a fancier title and the same cage. Worse, you’ve created a situation where they’re now evaluated against expectations they have no structural ability to meet. That’s not career development. That’s a setup.

Now, before someone points to their one Staff Engineer who drives cross-org initiatives despite having no protected time — yes, those people exist. Every organisation has a few. They’re the ones who somehow find the gaps, build the relationships, and push through architectural improvements by sheer force of will and a suspicious number of “informal coffee chats.” They’re exceptional, and they’d be exceptional in any system you put them in.

But they’re maybe 10–20% of your senior engineers. The other 80–90% aren’t less talented or less ambitious — they’re just people who need some structure and facilitation. And that’s not a weakness. That’s normal. You wouldn’t design a road system that only works for Formula 1 drivers and then blame everyone else for crashing. The point of organisational design is to make good outcomes the default, not to rely on outliers who succeed despite the system rather than because of it.

I’ve seen the non-outlier version play out dozens of times here at Agoda and in every organisation I’ve worked with before. The engineer starts enthusiastic about their new scope. They try to carve out time for cross-team work. Sprint commitments eat it. They try to raise architectural concerns in planning. The PO nods sympathetically and points to the roadmap. They try to do strategic work in the evenings. That lasts about three months before burnout wins. Eventually, they either leave for a company that actually supports the role, or they quietly retreat back into being a very expensive sprint contributor.

The Fix Is Structural, Not Motivational

You don’t solve this by telling senior engineers to “find time” or “be more strategic.” That’s like telling someone in a traffic jam to “drive faster.” The constraint isn’t their ambition or their skill — it’s the system they operate in.

The fix is embarrassingly concrete: you have to explicitly carve out the time and define the scope.

The guidance I give is simple. IC4 Staff Engineers should be spending roughly 30% of their time off-sprint. IC5 Tech Leads, roughly 50%. It’s not a formal model. It’s not documented in a policy anywhere. It’s guidance — and it’s deliberately loose. Some sprints a Tech Lead might be 80% in the sprint because there’s a critical delivery. Other sprints they might be 80% off-sprint because they’re deep in a cross-team architecture problem. It doesn’t have to be exactly 50% every sprint. It should average out over the quarter, and at the end of the quarter we look at the outcome and decide whether we’ve got the balance right or not.

This isn’t “20% time” in the Google tradition where you work on whatever you want and it quietly withers because sprint commitments mysteriously require 110% of your week. It’s up to them to balance their time — but the expectation that a meaningful chunk of it lives outside the sprint is explicit. And that off-sprint time has direction: cross-team architecture reviews, design system contributions, tooling improvements, mentoring engineers on other teams, investigating systemic problems that no single team owns.

The key insight — and this is what separates this from a management blog platitude — is that this protected time isn’t a perk. It’s the minimum infrastructure required to make your IC framework’s expectations achievable. You can’t expect cross-org impact from someone who’s 100% committed to sprint delivery. The 30% or 50% isn’t generosity; it’s intellectual honesty about what the role actually requires.

And before the Product Owners in the audience start sweating — this works better than you think.

“Can We Free Him Up More for the Sprint?”

I was sitting with a PO a few months back, one of the good ones — sharp, cared about his team, understood velocity wasn’t vanity. We were talking about his Tech Lead, and he leaned forward with that particular look people get when they think they’ve found an inefficiency worth fixing.

“When we do sprint planning, we only allocate for him to have 50% of his time available,” he said, like he was reporting a plumbing leak.

“Yes?” I said. Like there wasn’t a problem there.

“Can we free him up more for the sprint?”

I laid it out for him. If you have a Tech Lead on your team, they aren’t going to be spending 100% of their time on the sprint. They have priorities outside the sprint that are more impactful to the wider organisation. But they should be adding enormous value even at that 50%.

Then I posed a question. “Would you rather I replace him with a senior engineer who has 100% sprint commitment, or keep your Tech Lead at 50%?”

His response was immediate. He didn’t need a second to think about it. “I’ll keep the Tech Lead at 50%.”

That’s the answer every time. Because POs aren’t stupid — they know the difference between someone who completes tickets and someone who makes the whole team better. The Tech Lead at 50% is reviewing designs, catching architectural mistakes before they ship, mentoring mid-levels, and making decisions that save the team weeks of rework. The senior at 100% gives you more throughput on paper and more issues in production in practice.

The Scope Confusion Problem

Protected time without defined scope is just a longer lunch break. We learned this the hard way.

When we first introduced the off-sprint allocation, we saw a predictable failure mode: senior engineers would use the time to “catch up on Slack” or “attend more meetings.” The time was protected but directionless. It’s the same problem we found in our 70/30 survey data at the team level — widespread confusion about what counts as “tech time” when it’s not explicitly defined.

The same confusion happens at the individual level. Without structure, off-sprint time becomes “time not in the sprint” rather than “time dedicated to cross-cutting technical initiatives.” The former is passive. The latter is a mandate.

What works is connecting the time to specific vehicles. Your Staff Engineer’s 30% isn’t free time — it’s time to own a cross-cutting technical initiative, lead an architecture review for another team, or drive a tooling improvement that benefits multiple squads. Your Tech Lead’s 50% includes mentoring across teams, participating in org-level design decisions, and tackling systemic problems that live in the gaps between team boundaries.

Teaching the Skill, Not Just Granting the Time

Here’s something that took me longer than I’d like to admit to figure out: giving senior engineers time for strategic work assumes they already know how to do strategic work. Many don’t. Not because they’re not smart enough — they’re brilliant — but because nothing in their career has required them to find and articulate problems at the organisational level. They’ve been rewarded for solving problems handed to them, not for discovering problems nobody’s named yet.

This is where the Problemathon comes in. It’s a two-week program we built where IC4+ engineers team up to learn problem-finding skills — design thinking, root cause analysis, systems thinking, Jobs to Be Done, first principles reasoning. They’re not building solutions. They’re learning to identify and articulate the right problems. And critically, they’re learning to size the opportunity — because finding a problem is only half the skill. The other half is being able to say “this costs us X hours a week across Y teams” in a way that makes prioritisation obvious. A senior engineer who can walk into a room and quantify the cost of a systemic problem doesn’t need to fight for prioritisation. The numbers do the fighting for them.

The feedback tells the story better than I can. One engineer said they learned “that it’s actually encouraged to be noisy. Before I tried to be more respectful and delicate with it. Now I will be quite ballsy.” Read that again. A senior engineer — someone your organisation depends on to identify and raise technical risks — had been self-censoring because the culture never explicitly told them it was safe to do otherwise. The Problemathon didn’t teach them a new skill so much as give them permission to use a skill they already had.

If you work in Southeast Asia, or any high power-distance culture, this hits differently. Respect for hierarchy runs deep. The instinct to defer, to soften, to wait for permission before pointing out that the architectural direction is wrong — it’s not a bug in your engineers, it’s a feature of the culture they grew up in. Which means the structural permission has to be louder and more explicit than it would be in a Bay Area startup where people interrupt the CEO before breakfast.

Another engineer noted something that should make every engineering leader sit up: “It’s harder to get back to sprint work now. That side of the job seems so much nicer to work in.” That’s not a complaint — it’s a signal. You’ve shown someone what strategic work feels like, and now the contrast with ticket-grinding is sharp enough to cut. If you run a program like this, you need to make sure there’s ongoing space for strategic work afterwards. Light that fire and then smother it, and you’ll lose people faster than if you’d never lit it at all.

The Progression, Not the Program

The Problemathon isn’t the point. The system is the point. These aren’t isolated initiatives — they’re a progression:

First, you set the expectation. Your IC framework says “impact beyond your team.” Fine. That’s step one.

Then you create the space. The 30/50 off-sprint allocation gives senior engineers actual hours in the week to do the work you’re asking for.

Then you build the skill. The Problemathon teaches problem-finding and opportunity sizing — not just “what’s broken” but “how much is it costing us.” Design reviews teach architectural judgment. Mentoring programs teach knowledge transfer.

Then you create the vehicles. Cross-team initiatives, architecture guilds, tooling squads — these give senior engineers missions that match their level.

Then you review against it. Performance conversations that actually ask “what was your cross-org impact this quarter?” and treat the answer as seriously as feature delivery metrics.

Most organisations do step one and skip the rest. They write beautiful IC frameworks with inspiring expectations about broad impact, and then structure every hour of every week around team-level sprint delivery. They’re hoping that “impact beyond the team” happens by magic — that senior engineers will somehow transcend the system you’ve built around them through sheer force of will.

It doesn’t work that way. As the management thinker W. Edwards Deming observed, “A bad system will beat a good person every time.” Your senior engineers aren’t failing to have cross-org impact because they lack ambition. They’re failing because you designed an organisation where 100% of their time is consumed by team-level work, and you’re hoping the rest happens in the margins.

The Uncomfortable Truth

If your Staff and Tech Lead engineers don’t have visible cross-org impact, the problem isn’t them. It’s you. Or more precisely, it’s the system you haven’t built yet.

When we first created the Principal Engineer title at Agoda, I asked Max what a Principal Engineer actually does. His answer was immediate: “He finds me the problem I didn’t know I had and tells me how he’s going to fix it.” That’s the destination. That’s what the top of the IC ladder looks like — someone who doesn’t wait for problems to be assigned, who sees the thing nobody else has named yet, sizes it, and brings the solution. But nobody wakes up one morning able to do that. The off-sprint time and the Problemathon are the tools we give Staff and Tech Lead engineers to start building that skill on the road to Principal. You’re not just giving them time away from the sprint — you’re giving them the runway to develop the instinct that defines the highest levels of individual contribution.

You need to build the space — whether it’s 30% or 50% or something else entirely, the exact split is negotiable, but the principle that senior engineers spend meaningful time outside the sprint is not. You need to build the skills — structured programs that teach problem-finding, opportunity sizing, and the ability to make the case for change in terms leadership can prioritise against. You need to build the vehicles — cross-team initiatives with real scope and real accountability. And then you need to get out of the way.

The alternative is what most companies do: promote talented engineers, write expectations they can’t meet, watch them disengage, and then wonder why your “senior talent pipeline” keeps leaking. You’ll blame the market, compensation, remote work, the new generation’s loyalty problems. It’s none of those things. It’s the cage you built and called a career ladder.

Now, if you’ll excuse me, I need to go check whether my own Tech Leads actually used their off-sprint time this week or got pulled back into refinement. Again. Because this fight? It’s not one you win. It’s one you keep fighting.