Things I've Learned About the Tech Lead Role

At the beginning of the year, I transitioned into the tech lead role on my squad at Ro. Needless to say, I was a bit timid! From what I had heard, a tech lead mixes two opposing sets of skills — manager-esque activities and software engineer expectations — with not exactly enough time to really focus on both.

While there is no shortage of fantastic writing on the tech lead role and its functions, I wanted to contribute my thoughts to the discussion by sharing ten things I have learned about the role since I stepped into it. Hopefully, these reflections will help aspiring tech leads navigate their own transition.

1. Be Patient

Make sure that you are patient with yourself as you transition into the role. You will be departing from a familiar routine you’ve spent your career mastering and picking up an entirely new set of responsibilities. Leaving your comfort zone is scary. No one, including yourself, will expect you to navigate this transition seamlessly. You will have questions. You will be uncertain of yourself. Yes, you might even make mistakes. Just remember, you were given the role for a reason.

2. Lead By Example

A particular challenge of the role is that you must rely on influence, as opposed to authority, to see your vision for the team carried out. The number one strategy here is to be the change you wish to see and lead by example. If you want clear acceptance criteria on tickets, be sure to write clear acceptance criteria for your tickets. If you want the team to share knowledge, publicly offer to pair on a ticket and share your knowledge first.

Another tip: be sure to praise behaviors you wish to see more of publicly. Whether you realize it or not, you are in a position of leadership and the team is looking at you for guidance on how you work together.

3. Strengthen the Team

The team is your number one responsibility as a tech lead. Learn to embrace the role of “multiplier” as your job is to strengthen the skills and confidence of your fellow team members with the end goal being to improve the overall output and quality of work of the team. There are several ways to go about this.

First and foremost, get to know a bit more about each member of your team. Ask them what they are trying to learn and how you can help. For example, is a team member trying to expand their knowledge across the stack? Does a QA engineer want to focus on more product work? Be sure to regularly remind your teammates that you are there to help them grow as it can be difficult to get some people to take you up on this offer.

Once you understand what your teammates are looking to learn, work with your engineering and product managers to identify well-scoped challenges your teammates grow. Make sure you become an advocate for your teammates here. Always be on the lookout for ways they can improve and communicate this with them frequently.

Don’t expect your work to end there: be prepared to spend a lot of your time pair programming. Invest time in learning pair programming strategies and how to do it effectively. You have valuable experience to share, and it is your job to share it! That said, do not be surprised if your teammates do not immediately take you up on your offer to pair. It takes time to build trust to a point where someone might reach out to you for help.

Lastly, your responsibility to the team does not end with your fellow engineers. Be sure you are working to support the designers and product people on your team as well.

4. Promote Ownership

Autonomy as an engineer is important. We want to feel that we have a stake in what we are building and that we are useful to the organization beyond just implementing code. Likewise, we want to work in highly autonomous, empowered teams that often feel more motivated and productive. Be sure to encourage ownership amongst your team members. Get them excited to lead initiatives, no matter the size.

5. Take A Back Seat

Don’t be afraid to let someone else lead. You might feel that because of the “lead” in your title that you alone are responsible for every decision the team makes. This could not be further from the truth. Again, your job is to strengthen your team and what better way to do so than by taking a back seat and encouraging your teammates to lead.

Beyond taking ownership of projects as mentioned above, there are many other ways to promote leadership. It can be as small as asking someone for their opinion during a meeting. If you are discussing a ticket during planning and you have questions about how the ticket will be QA’ed, make sure to publicly ask the QA engineer. Even if you know the answer, giving your teammates center stage and the ability to share their expertise is important.

Another great way to promote leadership, especially among your more junior colleagues, is to get their input on implementations. Better yet, ask to pair with them and have them walk through a problem they are working on or a piece of the system they are familiar with. This has a dual benefit of providing your teammate with confidence in their abilities, and you might even get to learn something new. Search “reverse mentoring” for more details.

6. Code Less

Expect the time you spend coding to decrease. By how much will depend on your firm, the size of your team, and the size of your backlog. I struggled with this point. It was difficult passing on tickets I knew I could rip through to focus on other work. It took a few months to understand that it was perfectly acceptable if I did not commit against the codebase every day.

Of course, you will not be abandoning the codebase entirely either, but expect to work more on architecture and systems design problems and get ready to read and write lots of technical documentation.

If you are still itching to contribute directly to sprint work, remember to look for ways beyond coding to help move your team’s work along: offer to pair with someone on a challenging ticket, help write tests, perform QA, and pick up the work that nobody else wants.

7. Listen More

Expect the time you spend in meetings to increase. You will be getting much more face-time with product managers, designers, and various stakeholders. Spend time preparing for these meetings. While your primary job is to strengthen your immediate team, you should also be working on gaining the trust of stakeholders from across the organization. Listen, take notes, and ask responsible questions. Show these stakeholders that the person charged with delivering their software solution cares deeply about their problem area.

Also, take advantage of these meetings to observe the product development process at your firm and look for small ways to improve upon it. For example, advocate for increased representation from engineering earlier in the product development process.

8. Manage your Time

A great piece of advice my manager gave me when I moved into the role was not to stretch myself thin. I recall laughing inside as I was a master of my time — how wrong I was. It is very easy to overload yourself in this role. Between writing technical design documents, shadowing designers on user interviews, planning the next sprint, and pairing with a team member, and putting out fires the role exposes you to a lot very quickly. Do yourself a favor and take the first few months slower than usual. You don’t want to burn out before you get started.

9. Learn the Business

While you should hopefully be familiar with the business your software supports, take it upon yourself to invest in building a detailed knowledge of your business’s internals. Start with the basics: how the company generates revenue and how your team contributes to the bottom line.

To move beyond the basics, reach out to the leaders of the internal teams your software supports and ask for a question/answer session. One of my most impactful meetings at Ro was with a senior leader on the operations team who took the time to share his vision for the product and what success looked like for his team.

10. Support the Organization

At the end of the day, you and your team are writing code to support the organization. Thus, it only makes sense to get to know members of the organization beyond the engineering and product teams. Start with getting to know the non-technical people your code supports — become a resource to them. If they are relying on your code, be sure to let them know you care. Put on your product manager / design lead hat and set aside time to watch them use it. Ask about their workflows and what could be better. These conversations are invaluable as a tech lead: you become more acquainted with your users and their problems. At the same time, the organization as a whole begins to see you as a relatable engineer who cares about the product.