I recently had the opportunity to present at the Enterprise IT Strategy Forum on the subject of maximising software development productivity. There was a typo on my opening slide, but we pushed on regardless.
“Productivity” is a word that makes a lot of software people uncomfortable, and with good reason. It’s been used as a stick to beat engineers, to justify surveillance tooling, and to reduce complex creative work to lines of code or story points. None of that is what I’m talking about here.
Genuine productivity is about building the right things, in the right way, and minimising the constraints that slow you down. Here are the areas I think matter most.
Team Happiness
Happy teams ship better software. Not happy because of ping pong tables and free fruit — happy because they feel psychological safety, they have real ownership over their work, and they’re empowered to solve problems rather than just implement predetermined solutions.
Engineers who are trusted to define the how — not just execute the what — are more engaged, more creative, and more productive. It’s not complicated, but it is hard to sustain under pressure.
Problem, Team, and Architecture Sizing
Smaller units consistently outperform larger ones. Jeff Bezos’s “two pizza teams” principle holds up — cross-functional groups of five to ten people move faster, communicate better, and make decisions without the overhead of a committee.
The same logic applies to architecture. Monoliths that have outgrown their usefulness should decompose into microservices and micro-frontends. Not because microservices are fashionable, but because they let teams own and deploy their own components without stepping on each other.
Experimentation
The ability to experiment safely is one of the most underrated productivity multipliers. Feature flags are the mechanism — they separate software releases from feature rollouts, allowing you to deploy continuously while controlling what users actually see.
This reduces risk, shortens feedback loops, and means you’re not staging big risky releases. Done well, it changes the relationship between engineering and the business entirely.
Measurement
Measure the right things. Vanity metrics — velocity, story points, lines of code — are easy to game and tell you almost nothing useful. DORA metrics are better: deployment frequency, lead time for changes, mean time to recovery, and change failure rate.
These four measures correlate with high-performing engineering organisations and, crucially, they’re hard to manipulate without actually improving. They give you a genuine signal on how your delivery pipeline is performing.
Reusability
Every time a team builds something that already exists elsewhere in the organisation, you’ve lost. APIs and design systems prevent this reinvention. A well-maintained internal API platform means teams can build on each other’s work rather than starting from scratch — and improvements propagate across the organisation automatically.
Reusability isn’t glamorous, but it compounds. The investment in shared infrastructure pays back every time someone doesn’t have to rebuild something from scratch.
The productivity conversation in software is worth having — it just needs to start from the right place. It’s not about doing more for less. It’s about removing the things that stop good engineers from doing their best work.