How to 10x Developer productivity — without AI
I didn’t go to university when I was 18. I decided to have an existential crisis instead and went at 21. At the time, it felt like a big deal. So, when I finally started my career, my toxic masculinity implored me to accelerate and outpace my peers as quickly as possible.
By the time I became a manager at the ripe old age of 30, I’d read countless engineering books, worked endless hours of overtime, and nailed down more cloud certifications than I care to admit. I thought I was ready.
But nothing could have prepared me for the sheer chaos and inefficiency companies seem to accept on a day to day basis.
My gut told me inefficiency isn’t just about bad code or poor tooling — it’s a people problem. Feeling lost, I did the only thing I knew. I returned to reading books and blogs, listening to podcasts and looking for inspiration.
I found myself becoming obsessed with one concept above all.
The cost of fixing a bug.
While the numbers shouldn’t be taken at face value, the diagram shows that the cost of fixing a bug increases exponentially the further you get in your development lifecycle.
The core concept is beautifully simple.
Identify problems before committing resources to them.
This is Everywhere
Like a multi headed hydra, I saw this cited in many forms and many places.
First cited by IBM in their research paper on the relative costs of fixing defects.
A white paper from Deloitte states that “64% of defects originated from the requirements and design phases. The vast majority — of problems are not fixed for 10 pounds, but 1000–10,000 pounds.
In a recent Lex Friedman Podcast with Guido Van Rossum — inventor of Python — they talk at length about how 75% of programming is fixing bugs.
Elon Musk even has a famous adage of ‘Making your requirements less dumb.’
While the cost of fixing a bug is a clearly a well cited idea, I believe that this is enormously undervalued and understated.
How to make 10 developers do the work of 25 should be on the front page of every textbook, the first lesson in every computer science course and opening statement of every company’s mission.
This isn’t a tech problem, or a coding problem, or an idiot problem, it’s a Process problem.
My hope for this blog series is to convince readers that the shape of their nebulous inefficiencies can be modelled by this concept.
How poor communication, impatience and, ironically, a sense of urgency drags us to the right hand side of this exponential cost scale. And how to fix it.
For that reason, I’m going to do something quite unusual for a technical blog. I’m not going to talk about tech. I’ll talk about catching problems as early as possible by building strong barriers at each stage of the development lifecycle.
Barriers come in several varieties. Including but not limited to
- Communicating effectively
- Designing good solutions
- Enabling autonomy
- Outcome based mentality
- Making good ideas go viral
And importantly - how to measure success.
Links to be updated on release.
Communicating Effectively
Communicating Effectively I — Acceptance Criteria
Communicating Effectively II — Sequence Diagrams
Communicating Effectively III — How to Run a planning Meeting
Communicating Effectively VI — The Planning board
Communicating Effectively V — The Dumbest Phrase in Engineering
Enabling Autonomy
Enabling Autonomy I — Everyones a product manager
Enabling Autonomy II – Consultancy based model.
Measuring Success
Measuring Success I — Bugs, ‘Bugs’ and Yo-yo jiras
Measuring Planning Misc — Story points are dumb.
How to make your design less dumb
Non Functional requirements checklist.
Own your own Infrastructure.
Flood with use cases.
Good ideas go viral
Good ideas go viral I — Architectural Design Records
Good ideas go viral II — Ew — Another Company OKRs blog
How to make your coding less dumb
Optimize for cycle time.
Coding standard design records.
Putting it together
Sprint 0
Making your team Happy
If you enjoyed this post…
Give it a clap (or 50 — they’re free)! 👏
Follow me for more.
Share this post with your team.
Got thoughts, ideas, or questions? Drop a comment below.
