Building Technical Leverage

software-engineering (15), architecture (32)

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.