Leverage is an important concept for an engineering organisation. When we are debating whether to standardise and on what, which technology tools and stacks to use, whether to add new technology, replace an old system with a new one, which programming languages to use and how many, under the surface we are ultimately talking about or around, the topic of leverage of technology.
Having leverage is having means to optimise the impact and performance of you and your colleagues’ work relative to effort invested.
“A manager’s output is the output of his or her organization plus the output of the neighboring organizations under his influence.”Andy Grove (High-output management)
“To be effective engineers, we need to be able to identify which activities produce more impact with smaller time investments. Not all work is created equal.”Edmond Lau (The Effective Engineer)
A valuable activity then is identifying and creating ways and means to increase leverage. You might also have come across the term force multiplier—it’s a complementary idea, in that a force multiplier is something that gives us increased leverage.
Using a technology or service should provide some benefit in kind to its users. We’ll call that benefit lift. Why introduce a second concept and not just talk about leverage in itself? It’s because we want a way to frame and identify the benefit not just the activity.
For example, if we write a tool that 50 engineers use, instead of having each engineer write their own tool, that tool is being leveraged via re-use, but we haven’t identified the benefit. What if the tool slowed those 50 engineers down, or slowed down 20 of them? One reason lift is worth calling out is because we can have negative lift, where a technology or choice is hampering the organisation.
Points of Leverage
There are a number of strategies we can use to obtain technical leverage. We can build and create tools and services. We can buy or rent those tools and services.
When it comes to introducing technology, two things need to happen. First we want to establish there will be some kind of lift, and do so in the context of our organisation. What works elsewhere may not work here. At the most simplistic level—is there expertise in-house or, will we have train up or hire in? Second, we want to look at classes of technology and not assess something in isolation.
This is particularly important for programming language and database technologies as they tend to be foundational engineering choices that exhibit diminishing returns. The 5th programming language an organisation uses is not going to provide the same level of differentiated impact as the 2nd did. As expertise gets spread across ever smaller silos, it’s easy to get to a point where the engineering organisation itself starts to struggle under the burden of variation.
On the other hand, highly restricting choice has its own constraints. For example it can require dedicated investment to enter new problem domains, especially if the technology does not have a broad industry backing or ecosystem.
Standardisation is another common approach to leverage. This can be anything from internal guidelines, to de jure/de facto industry standards, to an all-in strategy on a vendor. The key to standardization is adoption. A standard used by 80% of the engineering org has more opportunity for lift than one adopted by 20%. The author’s own bias on this is local options are preferable unless the standard can be clearly demonstrated to provide benefit or quantified in some way, even if the collective of local approaches seems wasteful, or inefficient.
Efficiency in the sense of resource utilisation is worth touching on, as it’s a common concern for engineers and those that fund engineering organisations. The most important thing to note is efficiency by itself does not provide leverage. It may allow other things to happen, notably reduced expenditure allowing capital to be redirected to other efforts, or margin improvements.
Aspects and Consequences of Leverage
Let’s look at three general aspects of technical leverage: indirectness, dependencies, and shelf-life.
One point about leverage is that it’s indirect. It impacts how we solve a problem but does not directly solve a problem . Because it’s indirect, there can be a tendency to undervalue the impact of working on things that don’t have an immediate and obvious first order benefit, and defer or miss out on the compounding effects.
We want to be sure to have enough problems to justify indirect investment, and lift is a useful way to frame that analysis.
Renting a service from AWS or Azure is a dependency. Using tools from the tools team is a dependency. Adding a library for circuit breaking is a dependency. There are real risks to dependency introduction but the upsides are just as real. In particular it can help to assess lift in terms of what we’re not doing as well as the perceived gain—it’s quite normal to not measure what isn’t happening.
What offered leverage in the past might not in the future. In particular an engineering organisation will want to be able to replace internal software builds with open source or services as they reach maturity and commoditise. We can think of this as an un-platforming exercise that allows the engineering team to redirect its focus on more differentiating problems and technologies.
The exception is moving things back in house—typically this is done on the basis of unit economics, where the organisation is at sufficient scale to build for itself. Less common is to want strategic ownership of technology or a vertical integration. In either case, using the idea of lift helps with understanding the internal investment, commitment needed to succeed, as well as timing.
Regardless of how we choose to frame things, I think what’s important is to think about technical investment beyond individual or per team preferences, and in terms optimal overall outcomes for engineering organisation itself.