Jan 8, 2025

The Manager's Path: Chapter 3 - Tech Lead

The third chapter of The Manager’s Path addresses the tech lead role and its overlap with management. This chapter raised a lot of red flags for me, so I want to start by recognizing that this book is eight years old and thinking on the tech lead role and engineering management has evolved a lot since it was written.

You must read this chapter carefully and selectively as it conflates the tech lead role with engineering management. I oppose the idea of the “tech lead/manager” (TLM). You’re unlikely to receive the external resources to be successful in either aspect of the role, making it more likely you’ll flame out or delay your career progression.

Still, this chapter provides a lot of value when read as a “new technical skills for new managers,” especially around planning and product management. It offers much to consider when contemplating a shift from the individual contributor (IC) track to the management track.

Key takeaways

Planning and project management

“Project management … is not what most people consider fun… [but] the alternative is the project failing slower, not faster.”

This is probably the most applicable part of this chapter for managers. I’d even suggest it would be better titled “Project Management 101.” There’s not a lot of specific direction here; most attention is paid instead to the benefits of project management. That makes sense with a target audience of engineers considered a transition.

Still, the general guidance around breaking down large work early and iterating with stakeholders in all directions is sound. I also agree with the handoff to owners of workstreams for a final breakdown of milestones into task-sized tickets.

Don’t be a process czar

“The process czar believes that there is one true process that, if implemented correctly and followed as designed, will solve all of the team’s biggest problems.”

I aim for not quite enough process. Never create a process from scratch. If you haven’t felt the pain of a missing process, or have only felt it once or twice, don’t create one. Keep getting stuff done instead. When you find yourself repeatedly thinking, “we should really formalize how we do this,” then it’s time to capture, document, and follow the process that evolved naturally while you weren’t looking.

This is the technical equivalent of the Mario Andretti quote, “if everything seems under control, you’re just not going fast enough.”¹

Shifting responsibilities

“In your position as tech lead, you should continue writing code, but not too much.”

I enjoyed the section on your career decision point and real versus imagined daily lives of senior ICs and managers. If only life for either role was as imagined!

The broader takeaway though is directed at tech leads who are still firmly on the IC track, so I won’t belabor the point too much. I will add that if tech leads should be writing less code, engineering managers should aim to contribute none of the core functionality their products. Maintain your familiarity with the codebase by contributing adjacent functionality such as deployment and operations changes. Dig in more deeply when debugging issues. Take on small bug fixes - but be clear-eyed about the definition of “small” here.

Assessing your own experience

Just a reminder that I occasionally answer from the point of view of the manager in order to protect the privacy of my past and current management.

Does your organization have tech leads? Is there a written job description for this role? If so, what does it say? If not, how would you define the role in your organization? How would a tech lead define the role?

We do have the concept of a tech lead, but it is more cultural than formal. It is associated with a specific role as laid out in this chapter, not an engineering level.

Tech leads are the ultimate owners of the service-wide “how” in the planning triad with product managers owning the “what” and engineering managers owning the “who and on what timeline.” They’re expected to be aware of all concurrent workstreams across the service and are responsible for ensuring they work together to make the service as a whole successful. They are not responsible for defining the “how” of individual workstreams unless they are the primary owner. That is left to the workstream owners.

In many ways this means each engineer on our team is the tech lead of the workstreams that they own - and this is intentional. This way engineers of all levels are gaining experience and developing skills for more senior levels. The major difference across levels is the amount of oversight and assistance they receive.

If you are considering becoming a tech lead, are you ready to push yourself? Are you comfortable spending some of your time outside of the code? Do you feel like enough of an expert in your code base to successfully lead others as they work in it?

Out of scope question for me as a manager, but it’s interesting to reflect on. I am probably on the opposite side - I would have a difficult time going directly back to being a tech lead at this point, despite remaining closely engaged with our service. Maybe after spending some time ramping back up my coding skills.

Have you asked your manager what he or she expects from the tech lead?

As a manager, I have had this conversation explicitly with my tech leads when they move into the role. We address how their contributions will change and that their main purpose now is ensuring the success of the team, not coding on their own.

Who is the best tech lead you ever worked with? What are some things that person did that made him or her great?

I’ve been lucky to work with some great ones across several teams here at Cloudflare. Two common characteristic they share are never leaving a colleague behind and working across teams and organizations to push the most complex workstreams to completion.

In performance review language, that’s “teamwork,” “developing a shared understanding,” and “cross-functional collaboration.”

Have you worked with a frustrating tech lead? What did he or she do that frustrated you?

More than one. The common characteristic there was a “go it alone” attitude that left team members and management in the dark. Lots of exceptionalism (derogatory) and disdain for even communicating updates. See also 10x engineer’s aren’t from yesterday’s post.