Last year I had the opportunity to speak briefly with Kevin Scott,
SVP of Engineering of LinkedIn, and he mentioned building technical leverage
as one of his engineering organization’s primary goals.
Many months later, the phrase still echoes inside my head.
Generally, you might say the aim of your development team is to build business value (whether that value
is producing widgets or revolutionizing health care). You can grow a team’s delivered business value
over time by:
training: investing in the team’s people,
process: investing in shaping behavior and communication,
technical leverage: investing in technology.
Examples of technical leverage abound.
At Yahoo! BOSS we offered structured search results
as a service, which made it possible to build a search results page without first building your own search engine.
At Digg, we deployed Hive to speed up writing queries against our HDFS cluster (as opposed to writing
map-reduce by hand). If your coworker is arguing you should switch over to Erlang
because writing in blub is a waste of time, their argument is built
around building technical leverage.
At SocialCode, building technical leverage has been an explicitly stated goal of ours.
Rather than having projects whose only goal is introducing/creating new technology, we’re ensuring each
project has at least one potentially novel or innovative aspect. This has created a framework of low-cost experimentation
with different approaches and designs, where successful ideas are incorporated into subsequent projects,
and where less successful ideas don’t cause entire projects to be thrown away.
It’s a logical next step to pick out your best engineers and then create a dedicated infrastructure or tools team,
who devote all their time to creating technical leverage, sending your company’s overall productivity through
the roof. That idea makes me anxious on the same grounds that I’m distrustful of drawing a line between
software engineers and architects: it not only undermines the feedback loop between decision makers and
the consequences of their decisions, but it also creates a class system where product focused teams are
framed as inferior to
the infrastructure teams.