Synonymous with British cycling, from the Olympic games through to the Tour de France, and widely associated with leader and brainchild Dave Brailsford, marginal gains became the “go-to” strategy for elite performance across sports, business, and technology. It’s a very impressive approach. However, in technology, there is often an easier place to start.
How do marginal gains work?
Marginal gains is an approach to performance improvement that aims to affect many aspects by a small amount rather than a single aspect by a large amount. It focuses on widespread finetuning rather than hunting for a silver bullet.
In cycling, this ranged from the simple (athletes using their own pillows to get a comfier sleep, getting the bus to the destination slightly faster to increase recuperation time) to the complex (chemical improvements to tyre grip, performance sensor gadgets, analysis of workout effectiveness). In technology, this may mean optimising CI/CD tooling to take seconds out of release times, rescheduling tasks to maximise compute efficiency or even moving the Kanban board a little closer so that developers don’t have to walk as far.
So what’s wrong with marginal gains?
Nothing. However, I’ve found that the way people approach it puts too much focus on niche innovations rather than dealing with obvious issues. Perhaps it’s because the most striking examples tend to be those that are impressive for out-of-the-box thinking. As a parody of the concept, Dave Brailsford told a journalist that creating a perfectly round wheel was one of the measures taken. Whilst that was a joke, it’s easy to see marginal gains being about levels of precision beyond normal working environments, professionals and budgets.
There is also a question of value. Taking minutes out of the deployment process may be worth the effort, but when you’re into improvements that can be measured in seconds, then the benefits may no longer outweigh the costs. Perhaps the effort to further refine an already very good process could yield a better return if refocused on a different challenge.
Furthermore, marginal gains often require a degree of stability which is often absent in highly successful organisations where the pace of change and progress outstrips the technology team’s ability to achieve a high level of refinement. High levels of tech debt and messy processes are often the product of an organisation delivering a lot, quickly, in a rapidly evolving business context. If you’re in a successful business and this sounds familiar, it is likely you’ll lack the space, time and stability to get to the point where you’re finetuning for marginal gains. But that doesn’t mean you give up on performance improvement, it just means that they can usually be found hidden in plain sight.
Enter, the marginal loss.
What is a marginal loss?
To be clear; I have never set out on a strategy of implementing either marginal gains or marginal losses. However, when I’ve thought back about many of the places I’ve improved the performance of technology teams, most of the low-hanging fruit comes through stopping (or at least refining) processes, approvals, reviews, constraints, and checkpoints, which cost more than the value they add.
Let’s consider some typical examples from technology:
- Code reviews can only be done by person X or role Y
- Tech debt has to be approved by the PO before it can be worked on
- For every deliverable, both a business and an IT tracking tool get updated
- Team leads have to get approval before taking the team for celebratory drinks
- Timesheets that don’t match Jira logged time get reviewed
I’m not saying that any of these steps are unequivocally wrong – but usually there are approaches that compromise a little rigour for more trust and result in huge upticks in performance, engagement and morale.
A trust-by-default approach
How might these be approached?
Pair programming vastly increases cross-pollination of perspectives. Whilst the odd ticket may slip through the net by not being reviewed by the most capable person, the removal of a bottleneck along with levelling up the whole team vastly outweighs the cost pretty quickly.
Perhaps some threshold needs to be put in place e.g. 20% story points for tech debt per sprint. However, in most squads a PO review of tech debt is relatively pointless unless there is an associated risk that they need to sign off. The tech team ought to be able to do their housekeeping without navigating a challenging justification. We all know the long term costs of technical debt building up, so they might as well just get on it.
This covers all cases where one change results in several tools being updated because the cost of consolidation is never tackled. Perhaps that is justified – it may be a particularly daunting project which would get in the way of some critical milestones – but I’ve often seen low hanging fruit here. Often getting rid of one tool and forcing use of the other causes a few ripples but is quickly outweighed by reducing duplicated effort.
Celebrating successes should be part of the basic package of running a team; I’d rather challenge a team if they don’t have something worth celebrating in a given 3-4 month period. Set some budgets and let them spend freely within those guardrails.
Everyone in tech knows that the two things rarely equate; teams inevitably lose some time between tickets. This could probably be extended to most aspects of time monitoring, even when not reconciling between systems. Ultimately, judging a team on their output is a far more effective way of measuring performance and reviewing time only costs more of the very thing it is there to safeguard – time.
Marginal gains the easy way is simply the practice of stopping all those things that are actively harmful to your own end goals
These are the sorts of practices that I see time and again in underperforming technology teams. Marginal gains the easy way is simply the act of stopping all those things that are actively harmful to your own end goals. Whilst thinking about marginal gains in the traditional way often puts emphasis on creativity and innovation to finetune by small degrees, it is only worth doing once you can confidently say you’ve eliminated all of the marginal losses. Can you say that about your team?
