One type of question that we get all the time from our readers is about career development. Specifically, they ask about moving up in the ranks of responsibility and compensation. It’s definitely understandable. We know that everyone wants to feel like they’re making personal and professional progress by becoming better, smarter, and more responsible people.
We want more responsibility, more challenging tasks, better opportunities, higher purchasing power, and better provisions for our families. Most importantly, we want to be satisfied and feel like we are fairly rewarded for our efforts.
Often people will describe their situation like so:
I’m a software developer with three years under my belt and still being treated like a junior. How do I make the step up to more senior levels?— Some random developer
Besides the fact that three years isn’t a lot of time in the industry, this developer needs to understand that most businesses don’t promote simply because the employee has reached a time gate. Yes, some larger, more rigidly structured businesses will have a defined process by which they bump people up every X number of years as a matter of company policy, but even in those businesses, it isn’t always the norm.
Instead, leaders and managers will expect employees to actively engage in their career progression by taking the initiative to adopt new responsibilities as evidence of their qualities. This basically means that if you want to move up and acquire more responsibility, you should actively seek to move yourself up into those responsible roles rather than sitting back and waiting for your manager to bestow them upon you.
And while that advice is universally true regardless of your employment, this article isn’t about just any progression, so let’s focus on engineering.
We want to take this time to discuss how people feeling stuck as a Senior Engineer can take that active leap into the first level of leadership: Tech Lead. It’s not easy. It’s not quick. And it certainly requires an abundance of patience. You’ll need to apply yourself in areas that will make you a bit uncomfortable. Most of the changes required during the transition will involve an abundance of non-technical abilities, so hold on for the ride.
In the end, you’ll have more than enough leverage to persuade the powers that be to give you what you crave: Tech Lead.
Senior Engineer versus Tech Lead
Let’s start by establishing the major differences between being a Senior Engineer and taking on the responsibility of a Tech Lead.
How is the Senior Engineer position appointed? That’s a fairly generic job title and doesn’t necessarily mean the same thing across business domains. “Senior” in this context usually means one of three things. First, it implies that you have seniority based on time. That is, you may have reached X number of years of general software experience thus making you a senior by the law of averages. Second, it can apply in cases where you have been with a company for X number of years but haven’t necessarily mastered any specific domain. Third, it can mean that you are an expert in a domain, technology, or subject.
For example, a key engineer with a company for 25 years is probably considered senior by length of employment. Likewise, a newly hired CEO with 25 years of software experience elsewhere may be considered senior by years of time honing their technical acumen. Finally, someone with 25 years of experience using C++ would be considered a senior within that knowledge domain.
What about Tech Lead? Since it’s a relatively new job title in the software world, there’s a lot of discussion about what type of person should fill the role, how many years of experience they should have, what their responsibilities are, and how to hire for the position. In fact, the definition and scope of Tech Lead is likely to vary wildly between companies and individuals. Sometimes it’s considered an architectural role while others might see it as a team lead.
Tech Lead positions can be successfully filled by engineers who have far fewer years of seniority when compared to a Senior Engineer, but that doesn’t make them any less qualified than their Senior Engineer counterparts. Since Senior Engineers will have a fine-grained understanding of a specific problem domain, a Tech Lead will need to know how to work with and guide those Senior Engineers to meet the project requirements.
At first, it might seem counterintuitive to have someone in a leadership position with less experience than those that he or she is leading. But when you consider that most companies will always have someone that has been with the company for a long time, bestowing leadership responsibilities based on years of experience alone is a recipe for disaster. It just isn’t practical to expect people with anyone with X years of experience to magically possess leadership abilities.
Imagine a scenario in which there is a team consisting of three engineers and a Tech Lead:
- Engineer 1 – 30 years of experience. Highly talented. Gets complex work done quickly.
- Engineer 2 – 10 years of experience. Moderately talented. Tends to be a little lazy and forgetful.
- Engineer 3 – 1 year of experience right out of college. Eager to learn and succeed.
- Tech Lead – 5 years of experience. Highly ambitious. Capable of making snap decisions and providing good feedback.
Notice something here? The Tech Lead doesn’t have the most years of experience and possibly isn’t the most productive member of the team. However, where the Tech Lead lacks in time experience and expertise, he or she makes up for in decision-making, assertive confidence, communication, holding people accountable, delegation, and providing good technical feedback. In our experience, we’ve found that years of experience often doesn’t directly correlate with leadership abilities.
Two senior engineers arguing about which approach to take? The Tech Lead makes the decision. Product Owners confused about the technology? The Tech Lead translates to business speak. Application is exploding in production environments? The Tech Lead leads the charge to get a hot fix released.
Let’s take a look at a detailed breakdown of each role’s expectations to further show the differences. What you’ll see is that Senior Engineer responsibilities tend to focus on success personally or within a singular team whereas a Tech Lead has responsibilities that affect multiple people within a team and external to a team.
Senior Engineer Responsibilities
As a Senior Engineer, your typical levels of responsibility fall into the following broad sectors.
Good relationship with team’s tech lead: Engineers with many years of experience are expected to hold detailed and complex technical conversations with their technical leadership. When given technical requirements, they should comprehend, ask questions, provide feedback, and push back when necessary to keep technical leadership honest. An open line of communication with technical leadership is critical.
Expert at tech stack: It’s assumed that Senior Engineers have been using technology for long enough to be considered an expert in that domain. If they are using a new technology, they should be expected to quickly pick up that new technology’s fundamentals and learn to apply it to their business cases. The Tech Lead should ultimately be able to rely on the Senior Engineers to provide technical solutions and implementations.
Competent at updating tickets: One thing that drives us nuts is engineers that do their work but never let anyone else know. Ticketing systems like Jira, Trello, and Azure DevOps exist for good reasons. Product Owners and Project Managers need to be able to accurately follow along with work that’s being assigned, completed, tested, and released to make sure that products are improving and projects are on schedule.
Writes good documentation: A criminally overlooked aspect of the software development lifecycle (SDLC) is documentation. Engineers hate writing it because it’s boring and not related to problem solving. Product Owners hate it because it’s more time spent on tasks that aren’t directly implementing features and fixing bugs. Regardless of personal feelings, it’s still critical to the long term success of a product. Senior Engineers are expected to write good technical documentation meant for consumption by other developers. Note that this is different from user facing documentation or application instructions.
Tech Lead Responsibilities
As a leader, some of these responsibilities may overlap with that of a Software Engineer, but Tech Leads will often have the following extra responsibilities.
Non-technical communication: Product Owners and Project Managers are not technical employees. They aren’t expected to understand the implementation details of the product as they tend to focus instead on the higher level features and bug tracking. Translation between non-technical and technical people is left up to the Tech Lead. Requirements are first written in business language but will need to be translated in a way that makes sense when it comes time to put hands on the keyboard and implement said requirements.
Set and execute technical direction: Tech Leads are expected to work with Engineering Managers to make sure that the technical direction of the team fits in line with the company’s general technical direction. For example, if the rest of the teams in the company have centered around using Angular and ASP.NET, then most likely the Tech Lead will want to set the direction of their team in a way that uses those frameworks. If new frameworks are to be used, the Tech Lead will need to make his or her case, execute on whatever the decision is, and then hold the other engineers accountable to that decision.
Decision-making: There will be times in a project when confusion arises where even the Senior Engineers won’t know the best path forward. Or two engineers may be arguing about which approach is best. In these scenarios, someone has to be a trusted to be a respected tie breaker or the team will remained blocked indefinitely. That person ends up being the Tech Lead when the decision is regarding technical issues.
Accountability and ownership: Nothing is ever perfect and sometimes it feels like that’s doubly true for software. Computers are designed by humans and contain all the flaws that we’ve accidentally built into them, software included. As such, problems will arise, users will be upset, applications will crash, and issues will need to be resolved. When these scenarios occur, business leaders and Engineering Managers tend to come looking for the Tech Lead to lead the charge toward a hot fix release. The technical buck stops with the Tech Lead.
Engaging Product Owners
Software is ultimately a product that should provide some sort of value to the downstream users. While the product is undergoing active development, there is always a person who owns the development of that product. New features need to be dreamed up, bug fixes need to be prioritized, work needs to be scheduled, and Project Managers need to be updated.
In an agile project management style, this person is the Product Owner. The Product Owner is essentially the single point of responsibility for maintaining the product backlog. As long as the software product exists, so too does the backlog and its owner.
Uh huh. OK. Great. We can hear you now, “I’m an engineer, why do I care about that?”
Senior Engineers wanting to make the transition into a Tech Lead role need to know that it will quickly become your responsibility to maintain a relationship with the Product Owners, understand their needs, understand the product’s needs, and actively engage in conversations with the Product Owners about the various products that you support.
Think about that for a second because it’s important. This is arguably the first non-technical responsibility that you will have as an engineer as you work yourself up the ranks. Until this point, you’ve been contributing on an individual basis by writing code, solving problems, committing changes, coordinating with your Tech Lead, and generally isolating yourself to purely technical work. The first steps outside that shell are to engage with Product Owners and take a genuine interest in the health of the product and the business value it provides.
Tech Leads are responsible for setting a direction and guiding the other engineers in that direction to meet the product requirements. If they can’t communicate with or don’t understand the Product Owner, then it will be impossible to successfully implement the required features and fixes.
As a Tech Lead, this ability becomes even more important as it will be on you to translate from non-technical requirements to technical speak for the engineers responsible for doing the development. If things don’t click between you and the Product Owner, more than just the product will suffer; so too will your team.
Tips for working with Product Owners as a Tech Lead:
- Understand the product, its roadmap, its backlog, and the owners of that product
- Keep lines of communication open so that productivity stays flowing
- Raise flags immediately if you or your team doesn’t understand the product requirements
- Contribute openly to requirements gathering and analysis sessions to keep product owners honest
- Direct all backlog modification requests to the product owner to force their accountability
Understanding Project Management
Projects are different from products. For people that aren’t acquainted with the differences, it can be easy to confuse the two. While a product represents a single or set of applications, a project can encompass the scheduling and management of features, changes, and fixes across many products and services.
For example, in the first quarter of 2020, the business executives have decided that they want to sell shoes to customers in addition to the shirts already being sold. To accomplish this, Project Managers are tapped to put together a plan including high level requirements, timelines, estimates, costs, checkpoints, and stakeholders.
But the Project Managers may not necessarily know which specific products and services need to be updated to support this new ask. That’s where collaboration with Product Owners comes into play.
Product Owners receive the high level requirements from the Project Managers, turn those requirements into something that can sit in the product backlog, and work with Tech Leads and teams to understand exactly where and how the necessary changes can be made.
The relationship between Project Managers and Product Owners doesn’t end there. Success requires constant two-way communication between the two.
As a Senior Engineer, your role in the above process is minimal. While you certainly have a part to play during implementation of features and fixes, you are largely absent from the higher level conversations about roadmaps, product decisions, project scheduling, and technical directions. If Senior Engineers were inundated with every minor detail regarding daily requirement changes, timeline shifts, and cost changes, they would never get any of the actual work finished!
But as a Tech Lead your relationship with Project Managers changes. Your responsibilities shift less from day-to-day implementation (though there is some of that) to working directly with Product Owners and indirectly with Project Managers on implementation estimates for the overall project’s tracking and health.
If you’re serious about shifting from a Senior Engineer to a Tech Lead, you’ll have to work to understand why roadmaps are designed the way they are, why your Jira sprint board has fifteen different ways of indicating a blocked story, why Project Managers absolutely do need to know how long something is going to take to build, and why you can’t just write unit tests for the rest of the week.
There’s more to software engineering than building an application. You are providing value to someone even if that someone is yourself. Understanding the project management process and ultimately being held accountable to actually creating the thing in a realistic timeframe is an important part of growing up in ranks.
Establishing Technical Team Norms
Like people, teams don’t function efficiently if they’re disorganized and chaotic. People sometimes need a general direction, a guideline, or a sky full of stars to know where and which direction to go.
It’s not enough to only know where you’re going. How should you behave during the journey, after you’ve arrived, and in the process of settling? In addition to direction, establishing the rules of travel and engagement are equally important. Leaving teams open to an “anything goes” style of development is just an open invitation for chaos and inefficiency.
If you guessed that the person responsible for establishing these rules is the Tech Lead, then you’ve just won a prize. We’ll send it in the mail shortly. But before you open that package, check out this detailed breakdown of Tech Lead responsibilities regarding team rules.
Keep up with the latest frameworks and best practices. Software very rarely exists in complete isolation with no dependencies. Unless you’re a deep down embedded programmer writing assembly language on a completely disconnected device, you’ll most likely be dependent on SDKs that can change rapidly. Depending on your application and your company’s needs, the Tech Lead may be required to regularly check for updates from the developers of those dependencies so that code doesn’t get stale and unsupported. Waiting years to update to new versions can be a huge headache.
Establishing annual review goals. We discuss this in more detail later in this article, but it’s worth introducing the basics here because it’s often overlooked. When consistent annual goals are established for all engineers on a team, everyone knows what the expectations are and what to drive toward throughout the year. For example, you could suggest that 40 hours of every year should be spent on self-improvement or that every developer is required to complete 15 code reviews per month.
Set and execute technology choices. Similar to keeping up with the latest frameworks, simply deciding on what technical stack to work in is a huge help for a team. By knowing the technical boundaries, there won’t be any questions about what tools to use. Angular or React for the frontend? C# or PHP for the backend? C or C++ for the embedded libraries? Which version of a specific framework? Should the team use Visual Studio Code, another editor, or just let people use whatever they want? These are decisions driven by a Tech Lead through discussions with the rest of the team.
Hold team accountable to code reviews, unit tests, and documentation. Some of the most important parts of software engineering have nothing to do with coding. Obviously coding has to get done because that’s how products are actually created. But there are a lot of other ancillary activities that directly support the success of the product and teams. Code reviews, unit tests, and documentation are a few great examples. Without these, the quality, maintainability, and understandability of the code would plummet to the point of uselessness. Tech Leads are responsible for making sure that engineers are following these practices as agreed to during team discussions.
Dipping Into People Management
This one is no fun. One of the worst parts about a job in which you are responsible for the performance of people is managing conflicts and personal problems in those people. And while Tech Leads typically aren’t actively managing people in the sense of approving vacations, providing performance management, and mentoring for career management, they are definitely engaged with their Engineering Manager to provide feedback on the performance of team members.
Most companies engage in an annual employee review process in an attempt to objectively measure the performance of the workforce. The process typically involves goal setting, periodic feedback sessions with managers, mid-year reviews, and end-of-year reviews.
Senior Engineers are probably familiar with this process as they have been participating as an individual contributor for potentially decades. Throughout that process, they’ve focused on only their personal performance, making improvements to their work ethic, and generally only involved in self reflection.
Unfortunately, a Tech Lead doesn’t have that luxury. They are required to look beyond their self during the annual review processes. Think about it this way: a Tech Lead is the leader in the trenches and should know exactly how every immediate team member is performing. Is a developer regularly skimping on code reviews? Does the developer ask for more work or hide until he is assigned work? How good is his documentation? These are just some examples of questions that a good Tech Lead will ask during team feedback gathering sessions.
Engineering Managers will only have a partial view of any given employee’s performance. Usually their view will be limited to a higher level perspective relating to the team’s overall performance, velocity, and overall success rate. This is obviously not an accurate representation of the employee and would be unfair to perform an annual review on that information alone. If Tech Leads and Engineering Managers team up to provide for a combined perspective on an employee’s annual review, there will be a more complete and fair picture for the employee.
Every team has some sort of conflict. Teams do consist of humans, after all. For worldly legal issues, we have arbiters of justice known as judges. Conflicts are hammered out in a courtroom, a resolution is agreed or forced upon those involved, and then everyone goes on with their lives in whatever way is acceptable to the judgement. But taking advantage of the justice system is probably a bit overkill for conflicts between engineering team members.
Software engineering can be a highly opinionated profession. There are endless blogs on the Internet professing the virtues of a million different ways to solve the same problem. Inevitably, people will subscribe to a specific solution and swear that it is the best and only way to move forward even if the benefits are marginal or arguably non-existent. Because many of the solutions are so vastly complex, it’s difficult to come to a consensus between two intelligent and dedicated sides of an argument.
Someone needs to step in before the conflicts escalate. It sounds crazy to think that employees can have personal breakdowns between each other over something as minor as what is and isn’t a bad programming habit. These types of issues happen more frequently than you’d think. The worst part is that these disagreements can escalate beyond a single team and negatively impact multiple teams, products, and projects.
The “someone” that has to step in is the Tech Lead. Even if the Tech Lead doesn’t personally have the years of experience that the Senior Engineers have, he or she still needs to be able to communicate with both sides of the argument, understand at least the basic merits of each side, come to a decision, and confidently execute on that decision without worrying about hurting any feelings. Yes, losing an argument is no fun. But the Tech Lead doesn’t need to coddle Senior Engineers. They’ve been around long enough to know how to behave (hopefully).