What’s Next After Team Lead in Engineering?
Many software developers will arrive to team lead role in about 6–8 years of working in the industry. Some will take slighter longer or shorter tenure, while some are called team lead or tech lead. Let’s not nitpick the specifics and let’s talk about the more important topic, what’s next?
The 2 most common paths are moving to management role and go further in-depth into technical role.
Management
For first time manager, a manager will often be involved with project management, people management (team of 2–7 direct reports), handling organizational wide (both technical and non-technical) initiatives, executing organizational changes according to directions set by senior leadership team and the list goes on. In senior management level, the manager will be exposed to program management, designing organizational structure based on business needs, stakeholders management, managing different levels of manager, setting strategic technical and business directions, providing leadership, defining and optimizing processes, looking after the welfare of the functional division and department. Different organizations have different weightage on each category of responsibility mentioned above but the ways of working in fairly predictable.
One of the common mistakes I observe organizations committed is promoting very effective technical people into management role. It is a mistake because the aptitude of being a good manager is rather different from being a technical expertise. In smaller organization, a manager is sometimes the super tech lead where the person covers both management and technical responsibilities. Such arrangement works well until the cognitive load becomes too heavy for the manager. When it happens, it usually signals the organization has grown into a stage where new structure needs to be put in place. For more matured organizations, management role focuses lesser on technical implementation, although the manager is still expected to have fairly good technical context on what is happening in the team(s) else the manager will not be able to manage effectively.
Sometimes, manager can be a misleading title. In the context of this article, the term manager refers to a person who has people management responsibility. In simpler terms, the person who makes a decision on the direct report’s salary. Roles such as Project Manager, Product Manager, Release Manager, etc are not within the context of this discussion.
Technical
This path is often represented by title such as Staff, Principle, Architect, Specialist, Technical [x-functional-domain] Manager, etc. Such roles usually represent technical superiority that many developers lookup to. Sometimes, being recognized as guru or master in specific technology and known for technical problem solving ability. They are usually the wizards who solve complex technical problems with a simple (or sometimes complex) solution that others might not be aware or even heard of. Many developers aspired to be in such role at some point in their Engineering career. Some stick to this aspiration while some changed their mind later in their career when they discovered more options.
Such roles usually have very few direct reports or sometimes no direct report reporting into them. People management responsibilities do take up time and that is not the most efficient way of spending time for them. They will be spending time to research on various technologies and tools, setting technical directions, working across multiple project teams on relatively complex implementation, designing architecture, implementing POC, up-skilling peers, being called into solving tricky technical problems, providing technical consultation, breaking large technical initiatives into bitesize scope for project teams, bridging the gaps between business and technical communication and so on. Usually they are known as IC (individual contributor) where their individual contribution to the organization has a larger impact and they bring greater value in doing so. However, being a good team player is still an expected trait for such roles.
Management or Technical?
Management or technical path? This is the most common question someone at lead level asks when considering the next step for their Engineering career. If you are a lead and you are wondering what’s next, the first person for you to discuss with is your manager. Base on your day-to-day work and interaction, your manager usually has a good sense of what your strengths are and what aptitude you possess that will allow you to excel in either of the path. If for whatever reason your manager is not able to provide that feedback to you or you do not trust your manager enough to have that conversation, the following offer some insights to help you to decide.
In management path, you need to know a little about a lot; in technical path, you need to know a lot about a little. For example, being a manager need to be good at managing people (building trust, motivation, performance management, engagement, etc), product (functionality, roadmap, dependencies, business matrixes, etc), processes (project management, promotion cycle, budgeting, HR, etc) and technology (UX, codes, databases, SRE, etc). Being in technical path requires deep diving into very focused functional area. For example, an architect need to be familiar with multiple programming paradigms, multiple storage types (SQL and NoSQL), various cloud services and sometimes even different cloud providers. Understanding the pros and cons of each selection in depth is essential for someone at technical path to be effective at the job. In other words, if you enjoy overcoming challenges in broad perspective with different contexts, you should choose management path. If you enjoy deep diving into specific technology and study them at great depth, you should choose technical path.
In management path, you need to have a genuine interest in collaborating with and helping people while being a good communicator; in technical path, you need to have a genuine interest in solving problems using technology and overcoming technical problems. Examples of the day-to-day activity for a manager include attending to interviews, coaching a team member on how to do better estimation following Agile principles, explaining organizational changes to direct reports, discussing team level OKRs, etc. Note that the mentioned activities involve high level of engagement with people. On the other hand, in technical path you will be spending a lot of time behind the screen for example evaluating different container orchestration tools, implementing the skeleton of a complex architecture, studying the execution plan for performance impact on different approaches writing SQL statement, etc. Note that the mentioned activities involve high level of individual focus time to work. In other words, if you have a genuine interest collaborating with people, you should choose management path; if you have a genuine interest in playing with technology, you should choose technical path.
Personally, I faced the same choices a few years ago. I was given a choice to be an architect or to be a manager in one of my previous organizations I was serving. I had to reject the offer from the head of architect although another architect in the organization recommended me multiple times to take this option. While I enjoyed many aspects of technical work, I knew it early on that I will do better at management path. For example, I can clearly remember what I discussed with a developer 2 years ago during an interview, I have an interest on refining Scrum ceremonies to have predictable deliverables, I have genuine interest in coaching and mentoring in Engineering career development, etc. Action speaks louder than words. All these point to the direction that I can be more effective in management over technical path.
While majority of team lead or tech lead end up in either management or technical path, there are also other less common options. Let’s unpack some of them.
Product Manager
Strictly speaking Product Manager does not fall under Engineering. Many organizations have Product and Engineering separated as different departments to provide the balanced of priority between feature delivery and technical excellence. However, Product Manager typically work very closely with developers and QAs to the point that Product Manager is perceived as part of Engineering team.
The most common routes lead to being a product manager is first, someone with a strong business background in specific domain (for example, Marketing) to lead a product development team. Second, UX designer who has a good intuition of how a product should be designed and work. Third, a technical person (developer or QA) who can break complex functionality into smaller scope that the other developers can implement them with clarity.
Being technical provide some level of advantage although not always required. Sometimes being too technical can be a handicap because the focus turned to the “how” instead of the “what”. A good Product Manager should focus on the “what” and allow the team to figure out the “how”. This is an area to watch out for tech lead turn Product Manager. The tech lead who turns Product Manager need to have a genuine interest in understanding how the business works in order to translate business context into actionable scope for development team to work on.
Stay on as developer
Many people think that we need to constantly climb the career ladder into higher role with a bigger title. It does not have to be that way. No one says we MUST either go to management path, further into technical path, be a Product Manager, or be a Project Manager.
I have seen software developers who have been happily coding for 20 years (some even longer) and are still coding. These grad-master developers usually deliver very high quality codes and solve problem in innovative, clean and pragmatic manner. They are often treated as Principle or Architect although they don’t officially hold the title. They become the go-to person for consultation when there are complex technical challenges.
But what about salary growth? Compensation package often adjust according to productivity and impact someone makes at the organization. While it is undeniable that there is usually a cap for individual developer, the upper limit is usually high enough for most people to get a comfortable financial package. Also, a very senior (and good) developer who had hit the salary band ceiling sometimes might not receive an annual increment but will receive a retention bonus instead. Organizations are creative enough to retain talents that they wish to retain. The key here is providing value and making an impact. As long as the developer is making a big enough impact, they will be taken care of.
However, if a 20-year experience developer is still coding at 5-year developer quality, please do not be surprised that the developer is being paid at 5-year developer salary. Year of experience is a predictor of technical maturity but not always a strong predictor.
Summary
The typical career progression after being a lead is to either go to management path or further into the technical path. It is important for us to do some soul searching to identify which direction we can excel at. Every organization requires different roles and diversity to operate. There is no right or wrong, better or worse. It is about what suits you the most. Apart from management and technical path, you should also consider the less typical options such as being a Product Manager, Project Manager, Release Manager, Delivery Manager, or maybe try other technical roles such as AI engineer, data scientist, etc as long as you explore and understand the role well enough before committing to it. Finally, it is totally acceptable for a software developer to stay on as software developer for decades if that’s what the person truly find joy in doing.
