One of the most fascinating things about software engineering is that the more you develop your technical skills, the easier it becomes to shift to a new paradigm, pattern, or language.
As you develop your technical skills, you get to a point where you develop incredible confidence about your ability to deliver irrespective of any technical challenge thrown at you.
But the moment you take a leap into a leadership role, moving beyond leading oneself to lead others, you start to realize that succeeding in this new venture takes more than being technically sound. Suddenly, there are non-technical skills that seem to matter.
Unfortunately, most people don’t get a manual handed over to them to help with the transition. In this post, we will look at five valuable lessons for a new tech lead. Whether you’re an individual contributor who is thinking (or in the process) of stepping into a tech leadership role, or a manager who is overseeing such transitions, this article is for you.
1. Your output is measured differently than you’re used to
Moving to a tech leadership role implies that you’ve done excellently well as an IC. You’ve earned your way to be a rockstar individual contributor, churning out features in the blink of an eye. But in this new role, what made you a good IC is now slightly different from what will make you a good tech lead. Realizing and adjusting to this new reality may feel strange at first. After a few weeks, or months especially, you may start feeling you’re not as productive as you were. This is because as an IC, you derived a sense of accomplishment from purely technical work such as writing code, refactoring an existing codebase, or optimizing an existing feature.
But as you step into your new role, your responsibilities diversify. You now have a responsibility to carve a technical path for your team. Your responsibilities now include having an overview of the entire system your team is building, establishing technical visions, and driving alignment.
Your role has changed, and how your output is (or will be) measured has changed too. It no longer depends on how much you can single-handedly deliver. Instead, it depends partly on what you do and partly on what you enable others (your team) to do. The quicker you’re able to tune your mind to this new reality, the greater your impact will be.
2. Aligning priorities is now part of your job
Aligning priorities means helping your team to focus on what’s most important and impactful. It means making sure your team’s efforts are all in sync with one another, supporting and reinforcing each other on the right thing.
As an IC, you were part of a team; you adopted the team’s goals and priorities. But as you become a tech lead, you start to take an active role in helping to shape your team’s priorities. You start to develop a wider understanding of your team’s goal and use that to decide what’s most urgent and important in terms of collaborating with other stakeholders.
There are always hundreds of tasks to be done, hundreds of features to build, experiments to run, and ideas to test. Being effective in this new journey requires a focus on value and impact and knowing how to choose which results to deliver.
You have to train yourself to look at every project or idea through this lens: how can we use 20% of our efforts to unlock 80% of our business goals, and how can I convince others and get them on board?
There won’t be enough time to build every idea. And there won’t be enough resources to create the ideal, ultra-polished product. The three variables you must now constantly play with are time, resources, and scope:
Figure 1: The triple constraints
Scope measures the work to be done. Resources include budget, team members, and everything at your disposal to execute the work to be done. Time refers to deadlines and how long you have to deliver on the work. You need to learn how to negotiate project scopes and requirements based on available time and resources.
3. How you communicate matters more
One of the most important skills to master is communicating effectively. Not all tech leads are good communicators, but all good tech leads communicate well.
Building software is a complicated process with numerous options and trade-offs that can easily be overlooked when communication is poor. As you step into a tech lead role, the way you communicate begins to have greater consequences and impact. Rather than simply making information available for people, you need to think carefully about what and how you communicate to people in order to achieve the desired outcome.
Sometimes, the curse of knowledge (where you develop a cognitive bias that makes it difficult to remember what it was like to be a novice) might kick in as you have access to broader information. You might think your team knows everything that you do or has the same context that you have on a project, when they don’t.
The effect of miscommunication could lead your team to veer away from building the right thing or making technical decisions that don’t align with the project’s direction, which can be expensive to fix later on.
You have to communicate and overcommunicate. Be creative about it at times; this could be as simple as creating a diagram or mock-up screen to pass the information across. When expressing complex ideas, it’s important to take a couple of minutes to think about how you can make it easy for your audience to understand. The worst mistake you can make is to assume people already know. Sometimes people forget things or are lost in other thoughts. So don’t be afraid to repeat yourself to get information to stick.
4. You should avoid premature fixes
As you step into your new role, you have to learn to wait for things to unfold in order to have a clear picture of what is going on before implementing a fix.
This can be very hard to grasp because it goes against our very instincts as engineers. As makers, we know what it means when we didn’t build to counter various edge cases that could make our application behave in unexpected ways. We know users of software can’t be trusted, so we have to think and anticipate problems in advance and put constraints to guard against them.
As you step from coding software for people to use, to leading people that code software for people to use, rushing to implement constraints to prevent or guard against problems you anticipate can sometimes have unintended consequences.
You can think of constraints as processes, practices, or guidelines enforced and intended to prevent certain problems or lead to certain outcomes.
While a lack of processes can affect your team’s performance and ultimately lead to the development of low-quality products, on other hand, too many processes created in anticipation of problems that are not yet clear can slow and hamper your team’s productivity.
‘The Master allows things to happen. She shapes events as they come. She steps out of the way and lets the Tao speak for itself.’ – The Daodejing, Lao Tzu
Instead of rushing in to create tons of processes right away, wait for problems to surface due to a lack of a process that fixes that problem. You’ll not only be able to craft a more appropriate solution, but you will also easily get your team’s buy-in, and collectively and collaboratively you will be able to define a better approach to fixing the problem.
Not only will your team see the need for it, but they will also understand why it is important. Since they’re involved in providing a solution, they will feel a sense of accountability.
5. You need to learn to manage projects
One important skill that feels very different from your previous role is dipping your feet into a bit of product management.
The Project Management Institute (PMI) defines project management as the ’use of specific knowledge, skills, tools, and techniques to deliver something of value to people.’ Because you and your team are responsible for delivering something of value (software) to users and stakeholders, you have an obligation towards your users as well as your stakeholders, which means you need to make sure work gets done.
There will be non-engineering bottlenecks that raise their heads to prevent you from delivering on time or block your team’s progress. These could include dependencies on people, corporate processes, or mismanaged expectations. Now it’s on you to identify and tackle these problems.
Now you need to think about planning and breaking tasks down. You need to inform stakeholders outside your team of what is going on in engineering and, likewise, inform your team of what is going on in other teams.
Management is now a part of your job. Rather than simply handing off anything that has to do with project management to project managers, you now need to work with them and compliment their efforts.
Reflections
The transition from IC to tech lead is never easy, and every journey is unique. There’s no manual and you’ll need to figure things out as you go. Take time to read, experiment, learn, and reflect. You will make mistakes, but what matters most is learning from them. That’s how you’ll grow as a leader.
