Engineering Lead


An Engineering Lead is often also known as the Tech Lead in some companies. An Engineering Lead is usually the final position before an engineer decides whether to invest 100% into the Manager Track or the Individual Contributor Track. It is common to find Engineering Leads owning all the delivery within a team, managing the engineers in their team and also act as their Software Architect.

As you might imagine, being an Engineering Lead is actually quite difficult because you wear both the hats of a manager and an individual contributor. Very often, a manager and an individual contributor have conflicting needs.

As a Manager

Being a manager is more of a career change than a promotion. Why? A lot of the skills you acquired as a software engineer are not relevant as a manager. You transition from managing technology to leading people.

For the first time, you will have other engineers reporting to you. Like it or not, you are in control of their career. What this means is there will always be a power difference, despite your attempt to keep things light. Acknowledge that as a manager, you will have to:

  • Protect your engineers from burnout and keep them motivated
  • Identify low performers and high performers
  • Make unpleasant decisions, which includes firing low-performers. Your first time firing someone will be hard, but it gets easier over time. You will see that it's often emotionally lifting for both parties if they part ways.
  • Set up processes, tools and culture so that your team can Accelerate their development.

Here are some anti-patterns of a manager:

  • Being friends with your reports: Be friendly and professional so that you can elicit trust and transparency within your team. Being friends will get you into trouble especially when there's a conflict. Would you be ready to fire your friend if he or she is not performing? Probably not, unless both of you are emotionally mature. More about this in the article - Can Bosses And Employees Be Friends Outside Of Work?.

  • Absentee leadership: Such a manager display a lack of interest in their reports. They often do not know what their reports are doing. Most people wish to grow, and a good way for them to grow is to have a mentor who looks out for them. Be that mentor.

  • Paying attention only to your low-performers: You were probably a high performer and thats why you were selected to be a leader. Would you feel motivated if your manager only pays attention to the low-performers?

There are a lot of other good advice in this book: The Manager's Path.

As an Individual Contributor

You will notice that your schedule as a manager has changed drastically compared to the days when you were an engineer. Suddenly, you will have to be involved and chair meetings like:

  • Product planning
  • API integration meeting with other teams
  • Meetings with external vendors
  • Scrum meetings
  • Incident & Post-mortem meetings
  • War room meetings for major company events
  • ... etc.

You will feel extremely frustrated that you no longer can code like you did in the past. That is normal. A manager needs to be accountable for many things and as a result, coding is only one of the things you need to care about. Nonetheless, you should have a strategy to stay hands-on enough so you can make decisions.

Read this article about How should managers code. TLDR;

  1. Intrinsic - feature work
  2. Instructive - documentation, demo
  3. Investigative - POCs

Lean towards #2 and #3. Completely avoid #1, that's the work for your team.

Software Design

At this level, you should be very confident in designing systems within your team's domain. You will be relied on frequently by your team members to make decisions about:

Communication skills

The Problem with Tech Leads is they forget they are no longer just engineers in a team. As a lead, you have to make decisions. Sometimes, you need more information before you can make a decision whether its a people issue or a technical issue. You need to work with and influence others.

Build your network of engineering managers and architects so that you can consult these people when you need help.

Sometimes, you will find yourself working with difficult people. Perhaps they are having a bad day, or you have not understood the picture in their heads. This book about Getting past NO should help you find some ideas.

If you haven't already done so, I recommend getting a copy of Team Geek as you are now leading the team. You will need to build a strong engineers that play well with each other.

Your Reading List for this page