Improve your delivery performance under pressure
Why? A deadline is approaching, the team is working flat out, and delivery performance is getting worse. It's tempting to hire your way out of it, but in our experience, capacity is rarely the actual problem. It’s friction: slow builds, patchy pipelines, architectural decisions that never quite got made. And new people don't arrive and fix that, they learn to live with it, just like everyone else.
What? The solution is a focused, time-limited intervention that makes your existing team faster, not bigger. We send in a small team of two experienced and skilled, hands-on software architects. They’re not there to learn your domain or take on feature work. Their job is to identify the bottlenecks limiting your flow, and remove them, one by one, with clear before-and-after visibility at every step.
We call this an Anti-friction Team, you may also know it as an enabling team (from Team Topologies). The idea is the same: your team keeps shipping while we make the rails smoother.
How? A typical starting point is two factor10 consultants, part-time, working in or alongside one of your delivery teams. Where possible, we like to include at least one person from your organisation working at the same pace – it builds internal capability and makes the improvements stick.
We're flexible on format. We can embed in an existing team, work as a separate enabling team, or structure the engagement differently depending on what your situation calls for. We'll figure that out together.
For whom? This offer works best when:
you're under real delivery pressure and can't afford to pause to improve the system.
you've tried adding people and it hasn't moved the needle.
you suspect your team's environment is limiting them more than their capabilities.
you want the improvements to be visible and quantifiable, not just felt.
Why this works when other approaches don't
Organisations don't fail to fix friction because they don't know what's wrong. They fail because under delivery pressure, improvement work can never compete with feature work for time and attention. It's always important, never urgent – until it becomes a crisis.
An external Anti-friction Team changes that equation. We have the specific experience to find and fix systemic friction fast. We're not caught in your delivery pressure. And, because we're explicit about the intention and expected effect of every change we make, the business case for the work is visible to stakeholders throughout, not just at the end.
There's also a compounding risk in doing nothing. Friction doesn't stay constant, it grows. And as agentic coding becomes part of your workflow, a high-friction environment gets worse faster. AI-assisted development amplifies whatever it operates in, good or bad.
What we actually fix
Every team and codebase is different, but in our experience friction tends to hide in the same places:
Build and test pipelines – slow, flaky, or skipped tests kill feedback loops and create queues. We cut execution time, fix flaky builds, and balance the test suite so the right tests run in the right context.
Deployment and release processes – manual steps, undocumented dependencies, and inconsistent environments create drag and risk. We reduce the distance between writing code and getting it to users.
Architecture and design decisions – when the architecture makes every new feature disproportionately expensive, the problem compounds. We provide hands-on support for tricky decisions and help establish lightweight processes for architectural choices.
Developer experience – context-switching and unclear workflows slow teams down in ways that don't show up cleanly in metrics. We look at collaboration patterns and tooling to optimise for flow.
Coaching – sometimes the friction is in how the team works rather than what they're working with. We coach on TDD flow, Ship-Show-Ask, DDD approaches, continuous delivery practices, and anything else that improves the day-to-day experience of shipping code.
Measurements and visualisations – established to keep track of progress as well as answer questions that crop up during the work. We're happy to leave the setup behind when we leave.
Continuous improvement – we introduce and demonstrate approaches for fixing problems that have happened once, so they don't repeat and disturb your flow again.
In short, we come with hypotheses based on experience, we validate them by looking at your specific situation, and then we fix things.
A concrete example
A team of 100 developers. A test suite that takes 20 minutes to run. On average, each developer runs it six times a day.
That's 2,000 minutes of developer wait time, per day – before you account for context-switching, flow interruption, and the tests that quietly stopped being run at all.
In one week, we reduce execution time to 10 minutes. Conservatively assuming 40% of the recovered wait time translates to productive work, each developer gains around 24 minutes a day. Across the team, that's roughly 40 developer-hours recovered – every single day – from one week of work.
Let’s talk!
The first step is a two-hour workshop – remote or in person – to look at your current situation, identify where the biggest sources of friction are likely to be, and work out whether an Anti-friction Team engagement makes sense for you.
No commitment required, just a conversation.
PS. If you only want help identifying what to fix – and want to handle the fixing yourselves – take a look at this offer instead: Proven results: Cut your lead times and track the effect.
