Why is it so hard to optimise software delivery under stress?
There's a particular kind of pressure that engineering leaders know well. A deadline is approaching, the team is working hard – everyone can see that – and yet the amount of work left isn't shrinking fast enough. If anything, it's growing. The instinct at this point is to push harder: more people, more meetings, more process. However, this rarely works.
The harder you push, the worse it gets
When a software team is under sustained delivery pressure, the things that would actually improve performance get deprioritised in favour of the things that feel like progress: flaky builds get worked around rather than fixed, test suites get slower and developers start skipping them locally, architectural decisions get deferred, and the pipeline accrues small inefficiencies that nobody has the time to clean up. Each of these is a small daily tax on the efficiency of every developer.
Stress makes this worse. When cognitive load is high, people optimise for the short term. They find workarounds and learn to live with the pain. Over time, the friction becomes background noise, invisible precisely because it's always there. The team isn't slow because people aren't working hard enough, it’s slow because the environment they are working in is generating drag, and nobody has the bandwidth to remove it.
The wrong fix: adding more people
The reflex response to a delivery shortfall is to hire. Brooks identified the flaw in this thinking 50 years ago in The Mythical Man-Month: adding people to a late project actually delays it further. The onboarding cost, the communication overhead, the ramp-up time – all of it creates more drag before it creates any lift.
But there's a subtler version of the same mistake that doesn't get talked about as much. Even experienced new hires, who ramp up quickly and start shipping code, are forced to focus on the features. Instead of fixing the underlying friction, they inherit it: working around the same flaky builds, running the same slow test suite, and operating in the same suboptimal architectural context.
What actually works
The alternative might seem counterintuitive, but the Theory of Constraints, Lean manufacturing and Team Topologies all point to the same insight: in any system under pressure, the constraint is almost always flow, not raw capacity. Adding people doesn't fix a flow problem. Finding what's blocking flow and removing it does – and that's a different kind of work entirely.
Instead of asking "who do we hire?", a better question would be "what would we need to fix to make the people we have much more effective?" The answers tend to be specific and concrete: a flaky test suite that takes 20 minutes to run, a build pipeline that's become a queue, a deployment process full of undocumented manual steps, an architecture that makes every new feature disproportionately expensive.
None of these are critical issues on their own, but in combination, they have a severely negative effect on everything the team does.
Why teams don't fix this themselves
Most teams know what needs doing, they just can't allocate the time to do it. When a team is under delivery pressure, improving the system competes directly with delivering features for time and attention. Feature delivery has visible stakeholders, clear deadlines, and immediate accountability. Friction removal has none of those things. It's important but never urgent, right up until the point where it becomes a crisis.
There's also a skill dimension. Finding and fixing systemic friction requires a specific kind of experience that most delivery teams don't have as a core competency, and under pressure they can't afford to develop it.
So the friction compounds, slowly at first, then faster. And as agentic coding becomes part of the workflow, the problem accelerates: AI-assisted development amplifies whatever environment it operates in, good or bad. That means a high-friction codebase doesn't get better when you add AI to it – it gets worse, faster.
The hidden cost of high friction
There's a reason Forsgren, Humble and Kim used delivery performance as the central metric in Accelerate. Their research showed that deployment frequency, lead time, change failure rate and time to restore predict the organisation’s business performance and employee wellbeing.
Flow isn't just a productivity metric, it's a signal of whether developers are able to do good work in a sustainable way. Teams in high-friction environments don't just ship slower, they also burn out faster, make more mistakes and leave sooner. In this sense, reducing friction is just as important for talent retention, quality and morale as it is for efficiency.
How we can help
Stress is precisely the condition that makes friction removal hardest to prioritise. When a deadline is looming, spending time on systemic improvement rather than features feels like taking your foot off the accelerator at the worst possible moment.
But one week spent halving a 20-minute test suite, for a team of 100 developers running it six times a day, recovers something like 40 hours of productive development time, every single day. It pays back the investment within the first week and keeps paying for months after, and that's just the quantitative part. The qualitative effect – on morale, retention, and the quality of thinking – is probably larger still.
So, how do you find the confidence to act on it when everything feels urgent? In our experience, it’s much easier when you have people alongside you who have done this before, who can show the work and demonstrate the effect – and who aren't themselves experiencing the feature pressure that makes thinking clearly so hard.
At factor10, we call this kind of engagement an Anti-friction Team – a small, focused group of experienced hands-on software architects who work alongside your team to find and remove what's slowing you down. Not to learn your domain or add to your delivery capacity, but to make your existing capacity work the way it should.
Read about our Anti-friction Team offer
/ Raniz, Principal software architect