For the last 14 months I’ve had management responsibilities slowly added to my day-to-day. This has involved weekly 1-1 meetings, performance reviews, and some backlog management. Today my role is as a team lead rather than an individual contributor. This post is my attempt to collect the most salient take-aways from the experience, with the understanding that I still have a lot to learn.

Effectiveness Through Enabling Others

A year ago a number of factors had left me as the team member with the most knowledge of how our system’s production environment worked. We didn’t have a full-time Linux Engineer. Whenever a production outage happened I would be the one diagnosing and resolving it. Luckily for me, our alert list was usually quiet, but crises (and their very possibility) put a lot of stress onto me. This wasn’t a situation we wanted to continue for very long.

Worse, the production environment would soon need to be expanded to support deployments in multiple datacenters. We could roughly see the changes necessary to support a larger deployment; they would be massive. There would have been a time when I would have attempted to do them myself through heroic effort, but that wouldn’t fix our root problems.

Today we have a dedicated development team assigned to our operational infrastructure and while I’m still involved, my team handles most of the work necessary for the day-to-day maintenance and development of the production environment. For our multi-datacenter deployment project I did a lot of work in the beginning, but near the end almost everything was owned by other team members. This transition showed me how I could be more effective in an enabling role than as a pure individual contributor.

Performance Management: Being Intentional

As an individual contributor, employee engagement wasn’t on my radar. It wasn’t part of my day-to-day to tell people when they were doing a good job or when they should use a different approach.

Prior to the last year most of my performance management experience was as a teaching assistant, where you operate in 15 minute increments, are very focused on specific problems, and can be very prescriptive in your advice (“No, don’t do X. Do Y instead.”). This isn’t to say that teaching assistants should operate this way – but these are the patterns I found defining my initial approach as a team lead.

However, the situation in the workplace is very different. The conversations I have with team members are spread out over weeks and months. They can be about almost any topic and aren’t limited to problems that we’ve identified; we could be equally talking about the work for the day or our plans for the next year. Because of the expansion of scope, the advice I give has to be more tied to business outcomes (“When you do X, Y is the result”) than suggesting specific steps.

With more experience it’s easy for me to see how I was limiting myself by using my teaching assistant experience as a model. I’ve switched my thought process to treat employee engagement through feedback and recognition as an intentional result of my everyday work. I think of this example as an instance of a general principle: if you consistently want a result you can’t just expect it to happen – you have to plan for it and act on behaviors that encourage it.

Staying Busy as a Technical Janitor

As my management responsibilities have increased I’ve coded less. Last November I was coding every day and still doing seriously complicated widget design. Nowadays I’m hardly on my team’s taskboard, meaning that whatever code work I’m doing is probably not important for the business priorities that my team’s responsible for. On Github, I’ve gone from 15 pull requests a week to 2 or 3. My contribution graph has cratered.

Contributions over time

The above paragraph would make some of my friends shudder, but I’ve never felt like I’ve been less effective (despite writing less code). However, it’s important that I stay technical enough to contribute to the conversations that my team has. Right now we’re doing some work to add Cassandra as a data store used by our production infrastructure. While I have no direct experience with this data store I can’t afford to “turn off” when the team gets into these details.

To stay current on the code I generally scratch my own itches: working on experimental ideas (statsd integration), fixing small defects, or reducing software entropy by rewriting hairier sections of our code. Last week I removed the node_modules/ directory from our project’s repository and updated our deployment process to npm install required dependencies instead. When I get involved in the code it is more as a technical janitor than a technical leader.

To some extent I’m still responsible for a lot of the project’s long-term technical vision. My goal is to offload this to other team members. The less you’re involved in the details of the system the less you have the context to know whether an approach is correct or not.

Resources

I’ve leaned on on a lot of great resources to help make this transition, including relying on the advice of some great people at my job. Initially management resources were pretty overwhelming because I wasn’t able to connect the advice to relevant personal experiences. After a year of new responsibilities advice “lands” better and it’s easier to fit it into my thinking.