Congratulations, you’re a tech lead! You are no longer an IC (Individual Contributor). Despite being a role on the “technical track” of most career ladders, it differs from all other technical roles in that your evaluation as a tech lead is based on the team’s ability to deliver consistently, and with technical quality.

In a nutshell, your role is to ensure the team delivers on time with technical quality. If you’re lucky you will help define what “on time” and “quality” means.

The first order of business for any new role is the same. Get to know the expectations from your manager, agree on how you will be evaluated, and set some boundaries for your responsibilities. Boundaries are especially important for the TL role because it can be a catch-all for miscellaneous tasks, and because a tech lead and engineering manager have some overlapping or shared duties.

Remember that becoming a tech lead means you have some level of technical competence. If it helps dispel some imposter syndrome, know that you were hired/promoted because someone believes in your abilities!

However, technical ability alone will not lead you to success in this role. Most of the skills required are non-technical “soft” skills: communication, project management, time management, leadership, and relationship building.

Communication

Tech leads spends more time communicating with people than writing code. Frequently interfacing with Product Owners, but also with all other departments during discovery and planning phases including senior management, legal, finance, customer support, etc. As the most technical representative in cross-functional discussions you become the bridge between business objectives and technical requirements.

You can expect to receive a constant stream of questions and requests from your own team, from other teams since you are now the face of the team externally, from engineering managers, and from other departments since you are the engineering representative for some aspect of the product. The frequent context switching can be challenge, but if you can shield the IC team members from this problem as much as possible then they have more focus to deliver on the team commitments. Consider delegating questions/requests to another team member when it presents an opportunity that fits into their career development plan.

Prioritize Review Time

Most TLs spend hours every day reviewing code in pull requests, product requirements/briefs, architecture diagrams, or just anything in the Review column if your organization uses Kanban boards. You should get in the habit of reviewing work before starting something new. Items in review are, in a way, “blocked” until they are reviewed, so this is always an effective use of your time.

Reviewing code is also a good way to get to know the system. A breadth of knowledge can be helpful in troubleshooting problems, architecture design, and making technical decisions. It is unlikely you know how everything works in your team’s remit when you enter the role. You may not know everything when you exit the role either, but you can aspire to know as much as possible!

Know things

When your responsibilities include technical decision making, planning/prioritizing work, and being a representative for your team, you have to know a breadth of information!

Code. Review PRs to know about all the changes that are being made, and the technical implementation details that are only knowable by reading code. If you have the capacity, try to read every piece of work, even if it has already been merged/completed.

People. Connect with your teammates to get to know them. Build trust. Get to know their goals and aspirations. Find opportunities that fit in with their career development plan. Teammates are more likely to tell you when things are going poorly if they know and trust you.

Projects. Pay attention to all the status updates in stand-ups. Be aware of the status for any in-progress initiatives. Read roadmaps to know what projects are coming soon.

Organization. Keep up with organizational goals, metrics, and values. Help the team understand how their work contributes to business objectives. When done well, this builds a sense of purpose within the team which can be a huge motivational tool.

So many meetings, so many opportunities!

Get accustomed to days full of meetings. Not all days will be like that (hopefully!) but there will be times when you feel there is no time to get work done. Find ways to get fulfillment from meeting packed days. Did you unblock the team by making a key decision? Did you push a project forward by talking through product requirements to identify risks, or the critical path, or break down the work into manageable tasks? Did you review and approve PRs from your team? Did you build relationships with people? Did you learn something? If you really cannot find anything useful from a day full of meetings then consider if those meetings are an effective use of your time. Some organizations have a meeting walkout policy: “if the meeting you are in is not a good use of your time, it is your obligation to walk out”.

In meetings with managers, leaders, and other departments, there are opportunities to advocate for change. Being close to the code while also connected with the organization’s needs is a unique perspective to identify technical/process changes that can benefit the organization. The TL role is afforded a level of trust and credibility to advocate for these changes.

Time management

In a busy team or organization time management will be the most important skill. For me personally this has been my biggest challenge. You are pulled in so many directions it can be difficult to prioritize tasks and to set aside time for the highest priority items. Trying to do everything is a slippery slope towards burnout.

Sensing the signs of burnout in yourself and in your team is a useful ability. Be honest with yourself and with your manager. Internalizing the feelings of being overloaded only further contributes to burnout. A trustworthy engineering manager will assist you with pushing back on team commitments when necessary. If you can identify those signs in others then you can take reactive steps to give them space. There is no better way to gain trust within the team than to push back and provide respite to mentally/emotionally exhausted teammates. This is leadership.

Since you are the person responsible for the technical output of the team, it can be tempting to be the person writing the most important code. However, the best way for your team to be successful is not for you to be writing all the most critical components. When you only have 1-2 hours in a day for coding, consider if you should not commit to working on tasks on the critical path. You can still be available for technical decisions and for code reviews. When that is the extent of your technical contributions in a project, that is a success! Learn to accept this as a team success and get fulfillment from it.

It is when you up-skill your team members, unblock them as quickly as possible, and enable them to do their best work that you multiply your impact towards team success.

---

A big part of being a tech lead is of course the technical leadership, coaching, mentoring, and knowledge sharing. Stay tuned!

Special thanks to Connor Giles for his inspiration providing tech lead tips in this article, and also inspiration as a former peer tech lead in the same organization!