Many years ago, I was a tech lead on a short but intense 3-week project. It was also my first time as a tech lead, and I had to juggle a seemingly endless stream of problems — coordinating with product and design, scrambling to get engineering work lined up for the sprint, and clarifying goals and needs from company leadership.
On top of all that, a big challenge for me was being a tech lead on a team with someone who had over 10 years more engineering experience than I had. I didn't quite know how to interact with him in this new dynamic.
I didn't want to give him menial tasks that he might think were beneath him.
I didn't want to overburden him with a huge critical chunk of work when he was also focused on some other critical engineering-wide changes.
I didn't want to do anything that would make him think, “Who do you think you are, to manage me?”
And so I played it cool, never talking about it explicitly. I'd say, “Work on whatever you want.” I didn't take advantage of his experience as I struggled to reason through major technical decisions. I didn't check in with him as often as I should have because I assumed he had more context than he had. I didn't ask him for help on all the loose ends even as the end of the three-week sprint approached.
We wasted a lot of engineering time, and I ended up picking up all the slack myself.
The nature of engineering ladders, with their many forks, and with people popping in and out of them, makes this a fairly common situation — and one that I've coached many tech leads and engineering managers through.
The first time you're in it, it can feel uncomfortable, as it did for me. But the way to approach it is fairly simple. The foundation of everything is:
Design how you want to work together.
This is the foundation of everything else. If you feel unsure about how to be a tech lead with someone more experienced than you, and you don't acknowledge it, your discomfort will show up in unhelpful ways — avoiding conversations, being less engaged, providing too little guidance, etc.
To begin this design conversation, you'll want to acknowledge the dynamic. This can be as simple as saying:
“Hey, I wanted to have a quick conversation with you about working together. I noticed that I feel unsure about how best to work with you as I tech lead this project, since you have a lot more experience. What's important to you in working together?”
Breaking the ice with this acknowledgment may seem small, but it's a critical step. Essentially, you've created a space in this working relationship and said, “I want this to be a place where we can talk about how we want to work together, not just about the work that needs to get done.”
Once the ice is broken, the conversation may flow naturally to what's important to each of you. For this initial conversation and for subsequent conversations to revisit this topic, here are some ideas for what to design.
What to Design: How you can help them
“What are some ways I can best support you as we work together?”
This industry places so much value on technical expertise that we sometimes undervalue the other things people bring to the table. As a tech lead with less experience than this individual, there are so many ways you could possibly help them in their work.
That might be:
- Taking care of high-level project coordination so that they can focus on execution.
- Coordinating with and being in meetings with product and design.
- Being a sounding board when they get stuck, even if you don't have full context on what they're working on.
- Helping them find opportunities to grow in the ways they want — technical depth or breadth, mentoring, etc.
- Advocating for and sharing the impact of their work broadly across other teams and in status updates.
- Sharing context from product, design, and other teams (without them having to be in all the meetings).
The ways you can help them may also not be entirely visible to you now. But as you continue to work with them, experiment. Even if you feel like you don't know as much as them about something, offer to help: “Are you stuck on that change? Would it be helpful to get another set of eyes on it?”
What to Design: How they can help you
“I'm really excited to work with you because of [reason] and I'd love your help with [something you'd like help with].”
What's important to you in working with this individual? What would you love to learn or gain from working with them? That might be any of the following:
- Having a trusted technical advisor that helps set the team up for success — amount of technical debt to take on, trading off short-term vs long-term impact, what to improve in the existing state of the codebase, etc.
- Sharing the load of code reviews so that the rest of the team stays unblocked.
- Having a strong and reliable engineer you can trust to deliver on substantial features or changes.
Sharing this explicitly with them also makes them feel valued and seen — you're showing them that you appreciate the experience they bring to the team.
What to Design: Delegation and Ownership
“What are some areas or skills you'd like to take on and own?”
With a more senior engineer, you can delegate things that might otherwise fall to you as the tech lead. Continue to have conversations around what you each want. Perhaps there is some area of the codebase they want to dive deep on.
The other part of delegating is getting comfortable with letting go of control. It's easy to fall into the trap of only being a tech lead for things you feasibly do all on your own. It feels safe, because you have yourself as a safety net, but that seriously limits your impact. Figure out what is important for you to know and understand (perhaps the high-level strategy or why one design is better than the other), and let them handle the rest.
Start small, and as you work together over time, and learn each other’s preferences and strengths, you'll be able to delegate more and more.
By effectively leveraging their experience, you can free your time to focus on other parts of your tech lead role. For example, if they want to own a feature or part of the codebase, they may be the one to write a technical spec, and you can review it through a lens of making sure it makes sense with what other teams are working on.
What to Design: Availability
“I know you may have other priorities as well. What does your availability to work on this project look like?”
Generally, more senior engineers, especially if they've been at a company for a few years, have a lot of demands on their time. If they are often pulled into production issues, maintaining a very active legacy codebase, or wrapping up another project, their availability might be limited.
If you feel unsure about their availability or what percentage of their time they can dedicate to the team, figure out together how you'll communicate availability. Maybe that's a weekly check-in where they share what else is on their plate, and how much they can take on.
By explicitly designing how you want to work together, across all these different arenas, you’ll waste less engineering effort and significantly increase your impact as a tech lead.
If you want to learn more actionable tools and frameworks specifically for tech leads, check out our Foundations of Effective Tech Leadership course. It’s a 2-day immersive experience for new and experienced tech leads where we use live demos, hands-on practice, case studies, deep-dive discussions to give you the core foundations to set you up for success.
