Category Archives: tech leadership

Recording for Posterity

This is a simple mantra I’ve used in many teams I worked in or led over the years:

Prefer Services to Software
Make services that are robust and functional.
Buy services that other folk do better than we could for the time and/or money.
Prefer Software to People
Automate everything where possible.
Output actionable telemetry for all the things.
Prefer People to Bureaucracy
Trust in the people you’ve employed to do the right thing and do it well. Remove unnecessary paperwork and processes whenever you can.
Prefer ChatOps for Everything
Email is so 1990’s. Put everything on Slack so everyone can see it.
Make command and control of your systems intuitive, accessible and secure.

How to be a Good Tech Lead

Transitioning from engineering to management/leadership is tough unless you understand the sacrifices you have to make. Rarely can you keep your hands in the guts of the engineering you used to know intimately. And you’ll have to do more paperwork. That said it can be just as rewarding to see your team grow in expertise and experience because of your leadership.

Here are a few simple rules to start with:

  1. If there’s an exciting fun task and a messy unpleasant task, assign the fun task to someone else and do the unpleasant task yourself.
  2. If someone on your team wants to ask you a question, always make yourself available and absolutely pretend that you don’t mind being interrupted. But if you need to ask someone on your team a question, always ask first if it is a good time for them to talk and offer to come back later if they are in the middle of something.
  3. If someone wants to try an approach that you think is wrong, say: “I’m not sure that’s the right approach, because of X, Y, and Z. However, I’ve been wrong before, so I might be wrong about this, too. How long will it take you to research this approach and see if it works out?” If you’re working on a tight schedule, this may not be practical, but if you want to develop good engineers in the long run, this can be beneficial for everyone.
  4. Be humble. Redirect upstream praise for your team’s work onto your team directly (away from yourself). Accept criticism for your team’s work directly onto yourself.
  5. Expect to do less actual engineering, but still keep on top of one or two components (DB, CM, CD etc) for up to 1/3 of your time. This helps to maintain an ear-to-the-ground on ongoing work and to communicate intelligently with the technical team.

Another good resource is this article from David Loftesness, formerly Twitters Director of Engineering:

Loftesness’ 90-day framework has three distinct stages: Own Your Education (Days 1-30), Find Your Rhythm (Days 31-60) and Assessing Yourself (Days 61-90). It also helps with the decision to enter management in the first place.