• Abstract
• My journey
• Defining the role
• Project management: planning
• Tech
• Delivery
• Defining success
• Execution
• Write code
• Delegation
• Defining success
• Project management: tracking
• Defining success
• Tech lead: per project vs persistent
• Sounds like a lot
• Conclusion

Abstract

In this reflection, I’ll be focusing on what the tech lead role is and why I think it exists. For reflections on how to be a tech lead, take a look at

My journey

Years ago, when my manager at the time asked me to take on the role of tech lead for my team, I was hesitant. In fact, I may have flat out rejected the offer, saying that, "l don't want to tell anyone what to do." He responded to the effect of, "Good, because that's not what I'm asking you to do." He also suggested that I pick up a copy of Becoming a Technical Leader by Gerald Weinberg, which remains on of my favorite books on the subject of leadership to date.

This became one of the most influential conversations in my career, as the ensuing discussions caused a paradigm shift in what I understand leadership to be.

Like Camille Fournier, the author of The Manager's Path (TMP), I was the least senior (but not junior) member of my (very senior) team at the time that I stepped into a tech leading role. If I am permitted to speculate, I think my teammates all saw what my manager did - that if I took this role, I could grow my leadership skills (and confidence) while also ideally freeing up focus and capacity for them to dive deeper on coding and other areas of project success. I would do so by assumed more of the project management responsibilities. This also gave my manager my capacity to focus on people management.

Defining the role

So, what does a tech lead do? In TMP, Fournier states that a tech lead is an engineer who may, "continue to write code but with the added responsibilities of represent the group to managed, vetting our plans for future delivery, and dealing with a lot of the details of the project management process".

Tech leading involves being in sync with the shifting phases of project lifecycles. The phases and associated responsibility that I’ve identified are:

• Project management: planning
• Execution
• Project management: tracking

Project management: planning

Tech

• Drive the process of identifying potential approaches
• A given task is almost always going to have multiple valid solutions. If the best approach isn’t immediately obvious, it’s on the tech lead to help identify a feasible set of options.
• Select the approach with the best set of trade offs for the given context
• Consider the goals of the project.
• For example, optimize for speed if your goal is to learn or prototype, optimize for stability if your goal is to scale or productionize. Those optimization may lead you to pick very different tech setups
• Consider the available / allotted time and other resources (such as staffing)
• Understanding and, if possible, minimizing dependencies
• Fewer dependencies → fewer potential blockers → more predictable planning

Delivery

• Break project into milestones, milestones into tasks
• Note that I am not advocating for waterfall/big up front planning. This exercise is about identifying uncertainty and assumptions.
• This will likely need to be revised throughout the life of a project but you do need a starting point
• Delegate those milestones and/or tasks (more on this in the Execution section)

Defining success

• You know how to get started and it is clear what your selected technical approach is optimizing for
• Teams that you depend and teams that you depend on are aware of your work and are prepared to support as needed.
• Surprises are avoided by getting stakeholders on the same page before coding begins.

Execution

Write code

The amount of focus time for coding can be highly variable, and tends to shift throughout a project's lifecycle. For example, there'll likely be less ability to focus on code in the beginning of a project, when there is a lot of communication overhead involved in defining tech requirements and approach. Once things are concrete and ownership is clear, more bandwidth is freed up for programming. Towards the end of a project, coding bandwidth may become constrained again as you begin to coordinate launches, communications about those launches, etc.

Delegation

Unless you are on a team where you are the only engineer, you probably aren’t going to do all of the implementation yourself. As a tech lead, your are at least partly responsibilities to

• Help identify opportunities for work to be done in parallel
• Help Break tasks down to level appropriate for each teammate
• For example, maybe a Junior engineer needs help to define very granular tasks while a Senior engineer may be able to take charge of entire subsections of a project, navigating through uncertainty on their own.
• Make sure teammates know what they are accountable for

Related reading:

Defining success

Delegation is successful when

• Folks, including yourself, know what they are accountable for

Successful execution of a project means that it

• Meets at least the minimum requirements in terms of functionality and usability
• The code base incurs no more tech debt than is appropriate.
• For example, if you are running an experiment to validate a hypothesis, it’s probably OK to cut a few corners in order to more quickly find out if a feature/product/etc is worthy of further investment. If those shortcuts don’t impact confidence in the experiment, then it very well may be pragmatic to incur that tech debt.

Project management: tracking

• Hold folks, including yourself, accountable for deliverables
• Communication of project status
• Flag risks, provide options or inputs for options on paths forward
• This could mean asking for decreased scope, more time, or more people. Or simply raising the concern that velocity is lagging behind projections in a way that may affect project success, even if you don't know for sure what to do about it.

Defining success

• Partners, especially in product, have relevant information.
• Especially if they don't have to ask you for it because they know where to look for it themselves
• Engineers and other functions know what to be working on.

Tech lead: per project vs persistent

In my first foray into Tech Leading, I was assigned a persistent role and title. I've subsequently been on teams where Tech Lead is determined on a per project basis. Either model works, so long as the expectations are clear and consistent.

Sounds like a lot

It is a lot. But like any other competency, proficiency is acquired with intentional application over time - ideally with guidance (from a mentor or manager) and support (from your team). Also, the distribution of a tech lead’s time will vary greatly based on their team or project’s needs. For instance, I’ve been on teams where, as tech lead, I was a contributor to but not the primary driver of project management conversations. Conversely, I’ve been on teams/projects where I was accountable for keeping delivery on track.

Conclusion

And so, things have come full circle. As a manager, I now find myself recommending Becoming A Technical Leader to my reports and mentees interested in technical leadership. I now also see how truly valuable of a role a tech lead is to a team. If, for example, a tech lead is taking care of the important-and-urgent quadrant of the Eisenhower Matrix, e.g. a project that needs to be scoped out for work to begin, that allows me to pay attention to the important-but-not-urgent quadrant of the matrix, e.g. thinking about when and how to grow the team.

It can be a demanding but rewarding role. A tech lead role embodies the principle that engineering is not just about programming, it is about building the right solutions to the right problems. A tech lead contributes to the success of projects by doing - and being recognized for - glue work. It is a role for those who enjoy succeeding by equipping others for success.