The Pressure Is Coming From Inside the House
Or: Why Your Engineers Are Burning Out and Nobody’s Asking Them to
It was 4:47 on a Thursday when Somchai said it. We were in a one-on-one, the kind where you sit in a glass-walled meeting room with floor-to-ceiling windows looking out over an open-plan floor still humming with the afternoon push — engineers leaning into monitors, the soft clatter of mechanical keyboards, someone two desks back laughing at something on Slack. The air conditioning held the room at that slightly-too-cold temperature that makes you wonder if you should have brought a hoodie. I’d asked him a direct question — why wasn’t the team getting on top of refactoring the search card? I knew they had issues with it. The kind of issues that show up as allocation bias in experiments that have to be stopped early, as bug counts that creep upward like humidity in March. He shifted in his chair, the way people do when they’re about to give you an honest answer they haven’t fully thought through yet, and said: “We are just so busy.” I asked him what he was busy with. He paused. “Our product work.”
I leaned forward. “Is your PO pushing you? Are the deadlines unrealistic?”
He shook his head. Not quickly — slowly, like he was checking his own answer before giving it. “No, not like that. Deadline is okay. But… we committed already, so we want to finish what we say we will do.”
“And the tech work?”
“Next sprint we can do.”
I sat with that for a second. Next sprint we can do. The most dangerous sentence in software engineering, because it’s always true and never acted on. And there it was. Not a complaint about a demanding product owner. Not frustration with leadership piling on. Just a quiet realisation, forming in real time across the table from me, that the team had imprisoned themselves inside their own sprint commitments — and nobody had handed them the key because nobody realised they’d locked the door.
As the psychologist Carl Rogers once observed, “The curious paradox is that when I accept myself just as I am, then I can change.” Engineers, it turns out, have an even more curious paradox: they can’t fix the pressure until they realise nobody else is applying it.
Let me tell you how we stumbled onto this. Pete (my old boss) and I kept getting the same complaint bubbling up through our org. Engineers felt under pressure. Too much work, not enough time, quality slipping. The natural assumption was that Product was cracking the whip. So we did what any reasonable leaders would do: we started investigating. We talked to engineers across teams. We talked to product managers. We talked to their managers.
What we found was… nothing. No pressure from Product. No unreasonable demands from leadership. In fact, their managers were actively trying to get them to take work off their plates. The pressure was real — you could see it in the commit patterns, the skipped lunch breaks, the PRs submitted at 11 PM — but it wasn’t coming from anywhere external.
It was coming from inside the house.
The Sprint Trap
Here’s what I think is happening, and I suspect you’ve seen it too.
Scrum gives us this concept of a “sprint commitment.” And the word commitment does something to people. It activates the same part of the brain that makes you feel guilty about cancelling dinner plans. Nobody likes to break a promise, and that’s essentially what a sprint commitment feels like — a promise made in front of your peers, written on a board, tracked in a tool, reviewed in a ceremony.
But it’s not a promise. It’s not even really a commitment. It’s a timebox. That’s what a sprint is. You don’t rush at the end of a sprint to meet a deadline. If you do, your velocity — your subsequent sprint commitments — will be based on that rushing. You’re now committed to sprinting at the speed of panic, permanently. (The Scrum Guide itself replaced “commit” with “forecast” back in 2011 precisely because the word was being weaponised — but somehow, most teams never got the memo.)
The economist Charles Goodhart captured this dynamic decades before Scrum existed: “When a measure becomes a target, it ceases to be a good measure.” Story points were invented to help teams estimate complexity. The moment they became a performance metric — the moment someone put them on a dashboard and started tracking velocity trends — they stopped being about estimation and started being about self-worth. Your velocity went down this sprint? You must be slowing down. You didn’t complete all your committed points? You must not be working hard enough.
Nobody says this out loud, of course. They don’t need to. The board says it for them.
The Invisible Courtroom
There’s a concept in psychology called the imposter cycle. It works like this: you get a task, you over-prepare or procrastinate, you set impossibly high standards, you fear failure, you deny your own competence even when you succeed, and then anxiety and burnout set in. Repeat indefinitely.
Research suggests up to 70% of people experience imposter feelings at some point in their careers. A HubSpot developer survey found that 88% of respondents had experienced imposter syndrome — including those with over a decade of experience. This isn’t a junior engineer problem. It’s an industry condition.
Now layer sprint metrics on top of that. You’ve just given the internal judge a scoreboard. Every sprint is a verdict. Every incomplete story is evidence for the prosecution. Engineers aren’t just afraid of external judgment — they’re running an internal courtroom where they’re permanently on trial, and the Jira board is Exhibit A.
A 2025 meta-analysis on perfectionism and imposter phenomenon found that the need to appear perfect to others had a large positive correlation with imposter feelings. In other words, the engineers most likely to burn themselves out aren’t the ones who don’t care — they’re the ones who care too much. They’re reviewing their PRs four or five times before submitting. They’re staying late not because someone asked them to, but because submitting anything less than perfect feels like a confession.
And here’s the part that should keep engineering leaders up at night: these are your engaged people. The ones who care too much are the ones with potential to be your highest performers. They’re the ones you most want to keep — and they’re the ones most likely to quietly burn out and leave.
The Bystander Effect, Sprint Edition
The self-imposed pressure doesn’t just hurt the individual. It fundamentally changes how teams work together.
An agile coach I work with pointed out something that should have been obvious: the reason people don’t step up to help unblock their teammates is time pressure from sprint deadlines. When you feel like you’re already behind on your own commitments, helping someone else feels like stealing from your own runway. You take the path of least resistance — pick up something else from the backlog, keep your head down, stay in your lane.
This creates a vicious cycle. Work gets broken down into individual tasks. Individual tasks get assigned to individual branches. Individual work means standups become status reports instead of collaboration sessions. “I worked on X yesterday, I’ll work on X today, no blockers” — said while staring at a screen, not at a human. The sprint commitment, designed to foster team accountability, has produced the exact opposite: a collection of individuals working in parallel, each racing their own private deadline.
The team isn’t a team anymore. It’s a co-working space with shared retros.
What We Actually Did
Back to Somchai and the search card. Once I understood what was happening, the fix was almost embarrassingly simple. I set up a meeting with the team and their product owner. I told them the guidance: 70/30 product to tech work. I made it clear I wasn’t going to dictate how they got there — that was up to them. But I added two things.
First, we were going to review the quarter-to-date trend in sprint review. Not as a punishment, but as a mirror. The team would look at their own split and question themselves. Were they spending enough time on the system’s long-term health? Were the signals — the bugs, the stopped experiments, the allocation bias — getting better or worse?
Second, I was going to check in. Engineering leadership would be paying attention.
Within a month, the problem was solved.
Think about what that means. The team had only one source of external pressure — product work. There was no counterbalancing force reminding them that technical health mattered too. The moment we added a second source of pressure — a promise, or perhaps a gentle threat, that engineering leadership was watching the other side of the equation — the system rebalanced itself.
It’s not ideal. I’d rather teams self-regulate. But it was an effective stop-gap, and it revealed something important: the pressure wasn’t malicious. It was structural. The system had a single input, so the output was predictable. Change the inputs, change the output.
The Research Says It’s Not Just Us
The DORA research team — Forsgren, Humble, and Kim in Accelerate — cite Christina Maslach’s six organisational risk factors for burnout: work overload, lack of control, insufficient rewards, breakdown of community, absence of fairness, and value conflicts. The book explicitly states that burnout often arises from issues within the organisation rather than the individual.
Here’s where our finding adds a layer. Maslach’s model, and most burnout research, assumes the pressure is external — bad management, unreasonable deadlines, toxic culture. The standard prescription is to fix the organisation. And that’s usually right.
But what happens when you do fix the organisation, and the pressure doesn’t go away?
The Haystack Analytics 2021 study found that 83% of developers reported work-related burnout. A Team Blind survey put it at 60%. The main contributing factors cited were cumbersome workloads, inefficient processes, and unclear goals. All external.
What nobody talks about is that removing external pressure doesn’t automatically remove the internalised pressure. The system creates the pattern, but once the pattern is in someone’s head, removing the system doesn’t remove the pattern. It’s like removing a dam — the river has already carved a new channel.
This is the under-explored flip side of the DORA findings. The organisation creates the conditions for self-imposed pressure through sprint commitments, velocity tracking, and story point culture. But even when you soften those conditions — even when you tell engineers explicitly that nobody is measuring their story points — they keep measuring themselves.
The Pendulum Swings Both Ways
Before you run off to abolish all estimates and turn every sprint into a meditation retreat, a word of caution: you can go too far in the other direction.
There’s a principle in organisational theory — Parkinson’s Law — that states work expands to fill the time available for its completion. I’ve seen this play out firsthand. Teams where we removed too much structure didn’t suddenly become creative powerhouses. Instead, estimates became insanely large. Simple features took weeks. Engineers spent time over-engineering solutions to fill the gaps, building beautiful architectures that nobody asked for and nobody needed.
The answer, as with most things in engineering leadership, is balance. Not the Instagram-influencer version of balance where everything is zen and harmonious, but the engineering version — a system with the right amount of tension to function without tearing itself apart.
What Actually Helps
If you’re an engineering leader reading this and thinking “this sounds like my team,” here are the things I’ve found actually move the needle.
Change what success looks like. If sprint completion is the only metric your team sees, sprint completion is the only thing they’ll optimise for. Start measuring business impact alongside delivery. Did the feature move a number? Did the refactoring reduce incident count? Make outcomes visible, not just outputs.
Name the invisible pressure. This one sounds soft, but it matters. In workshops with my managers, we’ve started explicitly talking about introjected regulation — the psychological term for external expectations you’ve absorbed so deeply that they feel like your own standards. When a senior engineer stays until 9 PM because “the work needs to get done,” ask them: who told you it needed to be done tonight? Usually, nobody did.
Question the metrics, not just the people. When velocity drops, the instinct is to ask what’s wrong with the team. Try asking what’s wrong with the metric instead. Is the velocity drop actually a problem, or is the team simply building harder things? Are the estimates wrong, or is the estimation process itself generating anxiety?
Provide constant reminders, especially for younger engineers. We found that it genuinely helps people — particularly those earlier in their careers — to have a constant, gentle reminder to think outside their current work stream. Can you question this requirement? Could this be descoped? Is this the simplest way to achieve the outcome? Without these prompts, people fall into a trap of accepting every commitment as immovable.
Press your managers to protect capacity. I have to actively push my managers to make sure their teams don’t over-commit. Engineers left to their own devices will fill every available hour with product work. The instinct to be “productive” — to have a full board, a busy sprint, a complete commitment — is strong. Someone needs to be the adult in the room who says “leave some slack.”
The Bottom Line
As the novelist Anaïs Nin wrote, “We don’t see things as they are, we see them as we are.” Engineers don’t see sprint commitments as timeboxes. They see them as promises. They don’t see velocity as a planning tool. They see it as a performance review. They don’t see estimation as a rough guess. They see it as a contract with their own self-image.
The pressure is real. The burnout is real. The 11 PM commits and the skipped lunches and the “I’ll fix it later” shortcuts that become permanent architecture — all real. But the source isn’t where you think it is. It’s not the product owner with aggressive timelines. It’s not leadership demanding more output. It’s not even the market or the competition.
It’s coming from inside the house. And the first step to fixing it is helping your team see that the door was never locked — they just forgot they could open it.
Now, if you’ll excuse me, I need to go check on my own sprint commitment. I told myself I’d finish this post by Thursday, and it’s now Friday. Nobody set that deadline. Nobody cares that I missed it. And yet, somehow, I still feel like I owe someone an apology.