What advice do you have for a new and inexperienced, but ambitious, tech lead?
...
Becoming a tech lead is a tremendous accomplishment, and you should be proud to have been given that responsibility. Technology leadership is a stepping stone into management or architecture, so your career progression is on the right track. Since you are ambitious, you should think about your next career move as that will help guide your day-to-day priorities over the next several years.
When becoming a tech lead, you should always be asking yourself three questions:
What are the upcoming features?
How ready is the codebase for the upcoming features?
Is my team capable of handling the upcoming features?
Know the upcoming features
Knowing what features are coming is imperative for a tech lead to know, and the only way to know is to develop a tight partnership with your business stakeholders. Whatever your team may be working on a few months from now is already being discussed, even though it may not be formally defined. The more you know about what features the business may be asking for, the better you can prepare both the codebase and your team.
Forming fluid, informal, effective working relationships with business stakeholders will make your job as a tech lead much easier. Where this partnership will pay dividends is when you have to negotiate delivery dates and the requirements that need to be done by that date. If you do not have a good relationship with your stakeholders, you will continuously be caught between them and your team, and it will be a nightmare. However, with a good working relationship with your business stakeholders, you will be able to negotiate your team out of bad situations before they arise.
Let's say you are told that you have a week to do a month's worth of work. Instead of getting angry, you can invite your good friends on the business side of the house to lunch. Once there, you talk about the weather, sports, and what's happening in the news. In the last few minutes of lunch, you can then gently transition into a conversation about the gap between what the business wants and what your team is capable of delivering.
Business people are used to negotiations over lunch, so this comes naturally to them. However, to a new tech lead, this type of conversation can be intimidating. Nonetheless, you must persist in forming these relationships and accept that you will be clumsy at first as your communication skills become more polished. Years down the line negotiating with the business on how best to execute on a product opportunity will come naturally and most likely will be the primary reason you get your next promotion.
Understand the state of the codebase
Understanding the state of the codebase is a core responsibility of the tech lead. The only way to get this knowledge is to study every single line of code that makes up the application. Shockingly, few tech leads do this, and instead, complain to their team when the system doesn't work the way they thought it worked. This is very poor leadership. Now that you are a tech lead, you can no longer complain, as it's your codebase now - no matter who originally wrote it.
Feeling ownership over the codebase is a core aspect of being the technical lead. You are now both the custodian and guardian of the codebase. You are the first and last line of defense of code quality and design. Regardless of the state of the code was in when you inherited it, it's now your responsibility to prepare it for whatever the business might need it to do in the near future. Note also that this is the main difference between a tech lead and a lead architect - the architect is concerned about what the business might need in the distant future.
Depending on the codebase you inherit, you may feel like you won the lottery or have been cursed with misfortune. Unfortunately, as proper system architecture and code quality are no longer emphasised in the software industry, you may feel more of the latter. This is to be expected, but your feeling of dread will subside as you learn more about the entire codebase and how precisely it works. It may be a mess, but it will be your mess, and like a wounded animal, it will be your job to nurse it back to health.
As the technical lead, it will be assumed you are the most capable software developer on the team - as well you should be. Being the best software developer on the team is a responsibility that carries with it the obligation to take on the toughest tasks. Perhaps no task is more onerous than refactoring a legacy codebase to use new paradigms, frameworks, and technologies. You should never ask your team to do something you are not willing to do, so when the time comes for a big steaming pile of refactoring, you should be the one to take it. Refactoring the codebase is a thankless exercise to everyone outside of your team, but your team will greatly appreciate and respect your effort - especially if you are good at refactoring.
Ensure your team can handle upcoming features
Concerning the capabilities of your team, this is where things can become quite a challenge for a new technical lead. There are two situations you will face, both of which can present problems:
You have been promoted above your peers, which inevitably causes interpersonal issues.
You were hired into the role of a tech lead and are inheriting a team you do not know.
Most tech leads get their start by being a senior engineer and getting promoted at their current company. Assuming you were very well-liked by everyone, then people may be happy to take direction from you. After all, you were peers yesterday, but today you are in charge. Everyone likes to be reminded daily that they were not good enough to be promoted to tech lead, but you were. I am, of course, kidding. This is the dark secret of being a new tech lead - you often are now in charge of your friends. It is tough to give direction to people you used to socialise with, and when you do, feelings of resentment are common. The good news about being promoted above your peers, however, is at least you know their capabilities. Not so if you are inheriting a new team.
Inheriting a team means you have no clue of their capabilities, but you must know what they can do to be an effective leader. Unfortunately, the only way you truly understand this is through trial and error on a real project, as you only learn what people cannot do when they fail. If software developers were self-aware and honest about their own capabilities, they could tell you, but most often they are neither.
Being a new tech lead with a new team will push you to the limits of your leadership capability. The issues you will face may be so vast that even after reading a hundred books related to leadership, you still may not have all the knowledge you need. It is genuinely challenging, and there is no way around this fact. The best advice I can offer is a few principles you should always do your best to follow:
Always try to do the right thing.
Always act with integrity.
Always treat people fairly.
Always be honest.
Always be respectful.
Never ask your team to do something you are not willing to do.
Never take credit for your team's accomplishments.
Never blame anyone but yourself for your team's failure.
Never miss an opportunity to learn from failure.
Never let your team dwell on their failures.
Keep in mind...
Your first few years as a tech lead will be your hardest, but that time will pass. The more mistakes you make, the more you will learn, and that will form the foundation of your experience. From experience will come wisdom, and then expertise. It may be many years before you consider yourself a wise and expert technical leader. Still, you are starting at the only place you can: at the beginning.
...
Neil writes a lot more about the softer side of software development over at neilonsoftware.com. Check it out!
