Becoming a Tech Lead: How I've Balanced Coding with Coaching

In an engineering organization with many small teams, it’s important to develop technical leaders who can be both successful engineers and effective mentors. Depending on the company, team, or person, there’s a lot of variation in what that looks like in practice. At HubSpot, our definition of a tech lead (TL) clearly states: They should spend most of their time on the product, not on people.

TLs are responsible for onboarding new engineers and helping them excel in their roles. But this alone shouldn’t be a TL’s full-time responsibility. Why, then, is it a common gripe from new TLs that they no longer have enough time to code?

It can be hard to strike a balance between servant leadership and remaining a productive individual contributor. It’s taken me time to get comfortable with it. What’s helped during my first year as a TL is this guiding mantra I learned from my manager: Strive to be a force multiplier for others. This means finding ways to dramatically increase your peers’ effectiveness to pay off in dividends over time. When you empower your team, not only do you reclaim your time as an individual contributor, but your teammates will do amazing things all on their own. (Tweet this).

There’s no silver bullet for any team’s situation. These are some learnings that have worked for me that might help you get back on the path to being an successful individual contributor and an effective leader.

Teaching Your Team to Fish

Shortly after becoming a TL, I realized that I was approaching every question from my team as if it were my sole responsibility to find the answer for them. I had embraced the idea of servant leadership a little too tightly. As you might imagine, being this involved in every non-trivial question consumed a lot of time.

Why would you default to taking your own time to investigate something that you can teach your bright teammates to do for themselves?

Nowadays, I try to be the street map rather than offering to be the chauffeur. I’m quick to admit when I don’t know something off the top of my head--which is usually--but I’ll describe what I would do next to find out, or who else in the organization would be able to help. I’ll likely make an introduction between those two people or give an impromptu crash course in a new tool to help them solve the problem.

I’m a fan of this strategy because it keeps ownership of the problem and solution with the person who asked the question. It also has exponential benefits over time for people on your team:

1. They learn how to use tools to answer their own questions (metrics, monitoring, debugging, internal tools, etc.)
2. They learn how to consult new resources where there are answers to many other future questions (code search, internal wiki, knowledge base, external documentation, etc.)
3. They meet new people in the company and create new relationships

At this point, my teammates have a variety of skills and knowledge that I don’t have. Given the time it would take me to learn all those things on my own, the team and our product is far better off because I didn’t insist on absorbing the same knowledge before they did. Teaching the team to fish and empowering them to use the tools at their disposal to solve problems is essential to helping the team scale and achieve greater results.

Forgetting the Role of Atlas

In Greek mythology, Atlas was the god who was condemned to hold the Earth apart from the heavens. On a much smaller scale, I see some similarities between Atlas and the role of the TL on a team like mine.

As a TL, I feel joy watching my team become invested in exciting new features, fun technical challenges and their expressed career interests. It’s a thrill for me when we demo new features or score big performance wins and my teammates were responsible for 100% of the code. (Those are the heavens that I wish upon my team.)

In reality, the area of the product I work on has its fair share of interrupting tasks on a weekly basis. They’re unplanned, could be time-sensitive, and often don’t have a clear solution. These may be support issues reported by customers, reliability concerns or internal requests from other teams in the company. (That’s the Earth from which I feel compelled to protect my team.)

An engineer on my team recently told me how much she had enjoyed having the opportunity to be heads-down on learning to use a new framework and applying it to a major redesign effort. This should sound familiar to anyone who’s heard the productivity rule du jour that makers need long spans of uninterrupted time to be most effective.

Hearing that, who would ever want to interrupt this person with a bug? The eventual downside to this approach is that taking on all of the grunt work yourself work can quickly devolve into an endless game of catch-up. You may provide your team with the cone of silence they need to focus on bigger problems, but how will you be able to make time to tackle your own projects, think strategically, and help your teammates grow?

It’s something I’m still figuring out, but I’ve found that it helps to match each incoming issue to each team member’s skills and expertise. If they’re already familiar with the relevant code, it should be a much easier context switch for them to set aside their main project at a convenient time. If time and bandwidth allow it, I’ll even pass along issues to an engineer unfamiliar with the problem as an opportunity for them to branch out.

If I’m ever in doubt, before clicking “Assign” in JIRA, I’ll plainly ask, “Hey, do you have time to look at this support issue in the next 1-2 days?” The goal here is to start a transparent and collaborative discussion about priority, urgency, and to set expectations about what should be done next.

My main goal is to keep the pain of maintenance aligned with each team member’s responsibility to ship high-quality work. The team will come to expect that they’re on the hook for changes that they made. They’ll also be consulted for help on things they’ve worked with before, so it’s in everyone’s interest to take the time to really understand the code rather than shipping drive-by bug fixes.

Finally, I would also argue that it’s in the team’s best interest to feel these types of pressures occasionally. When there are a lot of bugs or a backlog of technical debt, having everyone on the team own these things will also give them the satisfaction and feeling of ownership that comes with cleaning up old messes.

It takes time for a team to build up the skills and confidence to collectively handle any interruptions that may come up. It’ll be a hard-learned lesson for the TL, however, if engineers on their team are never asked to own their work, switch contexts, or solve something outside of their comfort zone. Trying to serve the role of Atlas, in the long run, is a load that’s not worth bearing. It’s much better to share it with the team.

Sharing Your Pet Rocks

As engineers, we like solving puzzles. It can be tempting to call shotgun on a new problem and spend time secretly thinking about how to solve it. Although intellectually gratifying, it’s not the way to get things done well or quickly. The following example shows just how motivating an interesting puzzle can be to others.

Over the past few months, we noticed that our Java project took longer and longer to build. Even after we moved our project’s build from Jenkins to Blazar, which should have given us a nice boost, something was still wrong in our project. In the situations where the long wait mattered the most, though, the issue at hand took priority over digging into build times, so it ironically didn’t get the attention it needed.

Not having the time for this at the moment, but wishing the build were faster, I took all the details I had and dropped them into an issue in our team’s GitHub repository. I went back to what I was doing and thought I would get back to it on a rainy day.

That day never came because an engineer on my team quietly took notice. Two weeks later, he took the time to debug the problem without being prompted to do so and shaved a full 10 minutes off our build time. This earned him the gratitude of his team and the speed boost made us all more productive.

It might not have happened this naturally if I had hoarded my knowledge of the problem. In this case, passively detailing a high-impact problem was all that was needed to motivate this person to solve the issue. Best of all, the problem was solved a lot sooner than if I had decided to keep it to myself.

I make sure to file details for problems like this in a place where the team can see them, like in GitHub or in our Trello board. In my latest effort to communicate with the team, I’ve started sending the team a brief quarterly recap and preview of our biggest projects and why we care about them. Whenever it comes time to give a new task to someone on my team, I usually find that it’s already familiar and they may already have thoughts on how to approach it.

Freely and openly sharing knowledge about the team’s challenges has helped the team’s overall readiness and to get things done in a more timely manner. And, you know what? I don’t miss those pet rocks one bit.

Coding More, Worrying Less

Balancing TL responsibilities with effective individual contribution can be overwhelming at first. Most importantly, consider what you can do to invest your time in a way that will lead to force multiplication. By focusing your effort upfront on autonomy, ownership, and communication on your team, I hope you’ll find over time that you spend more hours coding and fewer on day-to-day team overhead.