Leverage
Software development is fundamentally a game of leverage1. While we often focus on writing more code faster, the real power comes from finding points where minimal input creates disproportionate output.
Leverage multiplies your input to create a higher output. The higher your leverage factor, the more impact each unit of effort creates. As an engineering leader, you should be focusing efforts on high-leverage opportunities.
In this post, I’ll explore six ways to dramatically increase your leverage factor in software development.
1. Automation - Question the Why
Automation is where engineers often rush. Through code we have the power to automate just about anything!
The XKCD comic helps you understand whether automating a process is worth it, but before you rush in and automate a process, you should question the “why”.
At a previous employer, we compiled code on an Itanium. We spent disproportionate effort automating the build system to support HP-UX. We never had a customer use it. Automating the build process for this was a waste of time.
Organizations develop byzantine processes as they grow and often the reasons for doing so aren’t clear to the current generation of employees.
Automating a process is good, but eliminating a process entirely yields much greater leverage.
2. Bottlenecks - Use Data, not Intuition.
Fixing bottlenecks is a worthy goal, but the problem is that the bottlenecks are often non-intuitive.
In the technical world it’s easy to assume that the “ugly” code is the problem, but unless you’ve got the data to support it, you’re probably wrong. In the process world, the same applies.
Those “bottleneck” planning meetings that feel like they are taking forever? Perhaps that’s really masking the true bottleneck of an unclear product strategy?
Always gather data first to accurately pinpoint bottlenecks and apply effort effectively.
3. Build over Buy: Understand Your Trade-offs
Instead of solving a problem yourself, give a company some money (or find an open-source library). There are some devilish trade-offs here, particularly if you engage with a vendor. What if the price rises? What if the cost model changes? What if they encroach on your core business? The risk increases as you move from library to framework to platform.
To navigate this:
Use Wardley Maps to analyse your value chain, distinguishing commodities (good candidates for buying) from differentiators (strategic elements you should build).
Apply Domain-Driven Design (DDD) core domain charts to clarify which parts of your system provide unique competitive advantage.
Buy commodity solution; build differentiation. Understand exactly what you gain and what you sacrifice with each choice.
4. Asymmetric Opportunities: Spike Radical Ideas
Companies often default to "safe" choices, inadvertently creating risk by suppressing innovation. However, radical options, though riskier, offer asymmetrical payoffs—they can dramatically advance your organization.
The trick is mitigating risk while exploring radical options. Quick experiments or "spikes" let you test radical ideas rapidly with minimal downside.
Frequently explore radical ideas through low-risk experiments. Ignoring these opportunities is a direct path to stagnation.
5. Points of Influence: Target Network Nodes
Systems, whether technical or organizational, function as networks. Some nodes within these networks exert disproportionate influence.
As an example, introducing a single interface for database interactions can centralize control, enabling significant performance improvements with minimal effort. As a human level example, recognizing where decisions bottleneck (e.g., micromanagement) provides opportunities to restructure or redistribute influence.
Identify influential nodes within your systems and strategically amplify or reduce their impact.
6. Network Effects - Aim for Compounding Returns
Network effects compound value exponentially with growth. Metcalfe's law illustrates this: the value of a network increases with the number of users. Slack exemplifies this—the more users, the greater the value.
Similarly, internal APIs or shared services can yield network effects. Platforms grow more valuable as more teams integrate them. Likewise, documenting architecture decisions over time compounds into a valuable asset, facilitating better future choices.
Network effects can be slow burn. About a decade ago, my current company put in place architecture intent checks (see How do we make architecture decisions? for more information). What’s the network effect here? As we’ve made more of them, the repository has started to become incredibly valuable. The history of decisions has helped the company make better engineering decisions the more we’ve got in place.
Design internal platforms and documentation systems that naturally compound in value as usage increases.
Conclusion
Leverage is your ultimate tool for exponential impact in software development. Embrace systems thinking and these six core principles:
Eliminate unnecessary processes before automating.
Use data-driven methods to accurately identify bottlenecks.
Buy commodity solutions and strategically build differentiators.
Experiment safely to uncover radical innovations.
Identify and strategically manage your system’s influence points.
Create compounding systems with network effects.
Focusing on leverage transforms your impact from incremental to exponential, delivering more bang for your buck.
Where are your leverage points?
It may also be a game of queues https://fffej.substack.com/p/four-things-queueing-theory-can-teach