Some time ago a friend of mine has asked me to share an opinion on how to be a technical lead. He is a strong developer in another area of influence, who started considering a career growth.

Frankly, trough five years of experience I strive to think that I still don’t have an objective vision. Nonetheless, at least I can share my own humble opinion on how I understand the role and give you advice on what helped me personally (not to fail). All written below is strongly opinionated, so alternative visions are welcomed.

Tech Lead vs Team Lead

It worth mention that being a lead is usually a project role. And depending or your specialization or project needs you can be responsible for different (but usually crucial) parts.

But what is the difference between tech and team leads?

It's hard to answer this question. Usually, it depends on a company scale and a variety of questions to solve. In mid-size and large companies the role of a tech lead will be taken by the most experienced developer in a team, while a team lead is usually a manager’s role.

In our case, as a technical lead, you’re becoming responsible for such aspects of a work as:

• (Technical) solution design and code quality
• Implementation, development plan, and a technical debt
• Uniform work distribution, a bit of risk management
• Governance of development team, ad-hoc questions solving
• Collaboration with the rest of leadership it a team (QA/BA/Design)
• Customer facing, technical consulting

This may sound scary for people without experience, but usually, most of the work is (or can be) distributed in time. It also becomes less stressful with time and pretty similar to micro-tasks you handle during the day.

Scenarios

Albeit is might be not the worst idea to review some projects, in particular, I would want to believe that Customer Name is the last thing that influences a result. Instead, it makes more sense to highlight different inputs that affect scenarios you’ll apply during your work:

• Stage of a project [tension]
• Experience of team members overall [expertise]
• Size of a team [diversity]
• Level of supervision from a customer’s side [control]

Effective work requires to balance all inputs above.

You might be curious why I did not include such a thing as a Scope of Work. The short answer - I consider that amount of work is always bigger than a timeline of a project, whether it a technical debt of features. Like 120%. But we’ll return to this later, to understand why this happens (as it should).

The Flow

Scenario 1: A fresh start

One of the things that might be prioritized in your timeline as soon as you join a team - to build the team’s development core. A Babylon hasn’t built by one person, and this software won’t be too. There are two standard ways to invite people to a team:

• From other’s projects / from the bench;
• By hiring new people.

So be ready, it might take a while. Regarding hiring, there is usually a dedicated person in a company to communicate with developers in a market, so the most important thing that belongs to you is interviews. There is a substantial question though: how many workforces your team would need? In this case, a work with estimations will be involved (whether done by you or an Architect / Manager).

There are other things that should be done before the hiring, such as a proper technology choice. It may significantly affect a number / diversity of people hired.

The good part here is that while you’re setting up a team, already joined members can start working on application setup and prepare an extensible application framework, based on early inputs and your experience.

It is crucial to be in time with stable and reusable solutions, a wrong choice may lead to a massive refactoring of an application.

Over time, your focus on planning and architecture may be shifted to development as well, to help the team to deliver faster, be hands-on and monitor source code (to prevent code smells).

Scenario 2: Active development / Continuous refactoring

In theory, this phase is the most stable one.

• Stable, if the leadership team is same and sticks to the plan;
• Stable, if the customer doesn’t change a plan (by any reason);
• Stable, if no major pitfalls are found between architectural and implementation phases;
• Stable, if code quality is consistently good and the team doesn’t need to re-implement features.

So many if’s. But there is at least one thing among them in common: all points above are increasing your backlog, by adding new features or technical issues to fix.

During this period, you need to balance between code reliability, backlog, and delivery, and the complexity of this activity is dependent on how well you know your team.

• Do you know strengths / weaknesses of each?
• Do team members communicate with you early enough to prevent issues?
• Do you feel when a developer needs help? etc.

Handling a backlog makes a lot of sense during an active development phase. Ideally, backlog should not be items left there for months. In your power to select a proper time and developer to handle the technical debt, even with a standard features first approach.

Scenario 3: Support

In this phase, the application appears to be in production already or going to be soon. It means that stabilization is more important than usual. You behaved during the process rather good if

• Everything works as expected (and fast);
• At least business logic of your application is covered with tests;
• Developers know the structure of the whole application and participated in the implementation of different parts;
• All developers used to write code using the same approach;
• Technical debt is rather small and doesn’t scare you.

However, it’s good to mention about motivation here. Some people lose focus and willing to work once the application leaves development phase. Even leaders. So if a project is your child - don’t leave too fast. You still need to make sure everything works smoothly.

Nonetheless, if you join a team that missed their tech lead recently - you might be in a difficult situation. But there is a thing: there are no bad projects, so keep calm. Next things might help you:

• Meet your team and listen to them. People may have great ideas worth implementation, or issues worth fixing;
• Learn what you can and can’t do. Learn application. Don’t try to change everything;
• Keep people motivated and don’t interfere with business.

Few people think that project in a support phase is a good opportunity to keep skills in a good shape. I am one of those. All you need is to determine what pieces of the application are bad parts and require replacing, and where the application is in good shape.

The Moral

There is no single recipe on how to become an effective technical lead in a short time. You’ll need to try anyway and learn from your mistakes sometimes. At least I can share some Q&A with to support you:

• Delegation is a must-have. Don’t try to solve everything by yourself. All you need is a little confidence regarding who you delegate;
• Having a plan B is always a good idea.
• Validate your ideas with a team. You may be surprised how effective it can be.
• Be a leader, not a boss. In other words, be an example for your team and behave the same way you expect to see from others.

Good luck!