Heroes and Juniors: Increasing Engineering Team Velocity

Or why organizational science is a powerful tool for building better software

Technology vector created by slidesgo

The Plight of the Most Junior Senior Engineer

Sometime ago I was looking at a system with one of my engineering teams. This system had been built to support three different templating languages, which sounds useful until you consider that Twig, Liquid, and Jinja 2 have limited differences in functionality. Supporting them all means supporting the libraries necessary to compile them and all their dependencies, which was quickly becoming unsustainable. It seemed clear that we needed to consolidate templates to one templating language. The problem? Roughly 60 million customer templates would need to be migrated.

On-Call for Life

The other big impact this had was that engineering was having trouble maintaining efficient on-call rotations. A good on-call rotation needs six people. You want to run two tracks: a primary on-call person who gets the pages and a secondary on-call person who gets paged if the primary fails to respond. But you also want to space things out so that people are not on-call too often. Six people on two tracks means that engineers spend about 30% of their year on-call, with only one week approximately every two months where they are primary. This allows for long rest periods from the psychological stress of being on-call and deters burnout.

Going Faster by Going Slower

Look, no matter how brilliant they are or how thoroughly you screen for “culture fit” you can’t have a team full of tech leads. If you do nothing but hire senior engineers the only way to maximize the output of those engineers is to allow them to continue building new things. In any given software project there are different levels of tasks to be completed. Obviously in the beginning there’s a lot of architectural decisions to be made, a lot of unknowns, and a lot of requirements to be discovered, but as the project continues the team will start to pull off well-scoped items of work that need to be done in order for things to continue. These include:

  • Well scoped implementation work that adds one more of the same kind of pattern already implemented in the project.
  • Tweaks to existing code after user feedback

Transferring Knowledge

It can be scary to hire a junior person. In technology, situations can change fast. An open role where it felt safe to add someone with great growth potential can shift to a critical hire that you need to step up to complex challenges in a matter of weeks. I’ve definitely had situations where we chose the more senior of two mid-career candidates and were grateful for that when priorities changed unexpectedly two months later.

Author of Kill It with Fire Manage Aging Computer Systems (and Future Proof Modern Ones)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store