Last year, my colleague Mark Baum and I worked on a project together for the first time in six years. The experience was unusual for both of us because we both work as technical leads and have each spent the last few years leading our own project teams. This meant that we needed to sort out our respective roles on this project. As two technical leads, how would we collaborate where one was the tech lead and the other, the senior developer? Once the project was complete, we met to debrief and talk about the experience. The detailed conversation can be found here. Here are some recommendations we came up with, based on our chat.
1. Focus on Mutual Challenges & Growth Opportunities
Explore the challenges and opportunities for growth for both of you, focusing on your respective strengths.
Just because you’re the designated tech lead, you still might not be the most technical person on the team. Fight the desire to demonstrate that you “know what you’re doing.” Instead, ask what you can contribute rather than trying to figure everything out on your own.
And as the senior developer with a tech lead title, lean into being the ideal follower. When you are enthusiastic about taking direction, you set an example for the rest of the team on how to be a good team member. That said, don’t be shy about sharing your expertise and making contributions, but talk to the tech lead about your own leadership impulses and how to make best use of them.
2. Prioritize the Simplest Solution
Look for the simplest solution by keeping a beginner’s mind. Question your impulses towards complexity and doing fancy things just because they make you feel smart.
3. Stay Attentive to Your Developers’ Needs
Adjust your ticket writing to how they think (as well as to the client’s needs during UAT). And if, in fact, you don’t understand the resulting code, one strategy for leading code reviews is to ask the developer to tell the story of the code and have them add comments whenever they need to explain something to you.
4. Keep Your Architectural Vision in Mind
Review previous work with an eye to consistency of approach, at least on the first MVP build. Stay vigilant about regression risks, which can become more difficult to identify after the initial deployment.
5. Maintain Team Morale
Bear in mind that some senior developers might not want to spend time accommodating different approaches or looking for the “best” approach. Find ways to counteract dismissiveness, saying “Yes, and” like an improviser.
6. Lead with Curiosity
Coordinate team dynamics by listening more than you speak and making sure everyone is heard to help build morale. Know when to lead and when to get out of the way and let your team members do what they do best.
7. Share Leadership within the Group
Strive for consensus and team building, but make the hard calls when needed. As often as possible, look for ways to adopt team members’ practices you agree with, want to try, and/or want to learn from.
8. Keep Client Communication Flowing
The tech lead must be the intermediary between the client and the development team. Make sure information passes through you. If you start to hear about side conversations between developers and the client, ask yourself whether you are sufficiently available to everyone. Speak out when things are going in a direction you aren’t comfortable with or that doesn’t serve the client, while being judicious about when you take a stand.
Focus on Leadership That Improves, Not Confuses
Ultimately, keep in mind that when we appoint a tech lead, we are often naming a leader among peers. Having multiple technical leads on a project can raise the level of the product you produce, but it presents its own challenges. Remaining humble, curious, and present are the keys to making this arrangement work. Focus on your strengths and make space for everyone else on the team to do the same.
At Soliant Consulting, we think carefully about team assignments, as we always want to do what’s best for each client. The choice to put Mark and me together on the same project wasn’t random. We knew we’d have to make adjustments for each other, but we also knew our different strengths could create something excellent for the client. In fact, we’ve heard that they may adopt our application worldwide.
This experience gave us new insights into collaboration, and we now use what we learned on other projects. Some projects are straightforward, while others are complex and benefit from a team of senior staff. We look at each situation and decide what makes the most sense.
Our consultants bring years of experience to custom software development. We’ve learned that the right team structure matters as much as technical skills. Contact us to talk about your project, and we’ll figure out the best way to help you succeed.
Transcript
The following is a conversation between Michael Havis and Mark Baum, who both work as technical leads but were staffed as technical lead and senior developer on a client project. They discuss the challenges and opportunities of collaborating under this structure, especially when the senior developer has more technical inclination and expertise than the tech lead.
Michael: I’m excited that we’re talking today about technical leadership and what it’s like to work with a team of experts. There’s so much to explore here.
Mark: Me too! When we worked together on a big project last year, I started out worrying that you were a stronger developer than me and had more experience in the tech lead role. In this case, I was the tech lead and you were the senior developer, and I had to be OK with those insecurities.
Which raises the question: how do you respond to the title “Technical Lead”? The word “technical” makes me feel like I’m supposed to be the most technical person on the team, and sometimes that’s not the case. Now I’ve started focusing on the word “lead” instead.
Michael: That works for me. It’s a learning opportunity when you’re tech leading people who are more technical than you are and who have more experience. It’s easy to let it intimidate you.
Mark: Or to worry about how it will expose your ignorance. I address that by exposing my ignorance on purpose.
Michael: Yeah, I’ve done that too. Often I didn’t feel like I had any other choice.
Mark: But it still takes courage. Right? Do you relax into not knowing everything and allow things to happen, or do you seize up and get controlling and directive?
Michael: That’s a good skill to have as a tech lead – knowing when you should just get out of the way. The project can suffer from a tech lead trying to insert themselves too much. Like you said, it takes courage not to prove yourself and show everyone that you know what you’re doing.
Mark: It’s an improvisation, really. Like they say in jazz: “When in doubt, lay out.”
Michael: That’s how I approached my first project. I did almost no development, which was pretty disorienting. The main developer was a Javascript expert, and I wasn’t familiar with Javascript back then.
I tried to steer us toward conversations where I could offer the most value. I gave feedback about the user experience, I didn’t attempt any code reviews, and I did a lot of mediation between the developer and the client.
Mark: It sounds like you were leaning in the business analyst direction – getting requirements from the client and later testing the developer’s work at high level.
Michael: Exactly, getting client requirements and finding the best way to present those requirements to the developer. So really, being a translator.
This was a very specific and detailed client. I let them flood me with all of the information that they wanted to get out and then took time to be thoughtful about how I wrote each development ticket, adjusting my approach along the way by observing the developer’s reaction to the tickets as he worked them.
Maybe he needed to see an example JSON object, maybe he needed a table that presented all the permutations of what might happen – in each case, I tried to be intentional about the ways that I translated the information to him.
I also helped us maintain best practices, even when I couldn’t understand the code itself. I asked him about his approach, learned from his responses, and helped him stay accountable to himself. Of course, that works best when your team members want to maintain standards and just need some encouragement.
But finally, every project is different because every team is different. I’m always learning what my developers need from me and adjusting my approach to make sure they get it: being thoughtful, responsive and adaptable.
Mark: I start out each engagement by asking, “What am I doing here? With all these talented people, what can I contribute?” Maybe that reflects my insecurity, but those are still really good questions to ask.
Like what you said before, I’m most comfortable being the liaison with the client and helping the group work together: listening to everyone and encouraging them to do their best work and learn from one another. When in doubt, I generally assume that other people know more than me, and by exposing my ignorance, I keep things grounded and make the work less intimidating for more junior developers. It also helps us talk about sophisticated approaches in the simplest possible way – often finding a more direct approach than we might otherwise have been inclined to take.
Back when I was an actor, I worked with a director who said, “The fundamental problem is that actors like to Act. That’s why we have directors.” It’s the same in our industry: designers like to Design and developers like to Develop. There’s a tendency to find satisfaction and even self-worth in complexity even when it’s not necessary. And that’s why we have tech leads.
Michael: The tech lead has the vision in mind at all times. One thing I found valuable on the project we did together was the constant reviewing of previous work so that when we make a change in our approach, the previous work is updated to maintain those standards.
Mark: It introduces a regression risk but whenever we can maintain a consistent approach, it lightens our cognitive load for the future. And if the changes genuinely improve things, why not make those improvements everywhere it’s feasible?
It’s much easier with a new build that hasn’t been released yet. After that, it gets increasingly more complicated. But at that point, we can hope that we have found a solid approach that has internal consistency.
But that’s what I admire about you – your commitment to refactoring your code with regression risks in mind. When there is a change in requirements, you don’t just make the easiest adjustment that gives the necessary result, but you make several passes to ensure that the code remains rock-solid. You ask, “We’ve got this requirement: what does that mean for the integrity of what we’re doing?”
Michael: Honestly, it’s just the way my brain works. If we have a new requirement, or we find a better way to do something, the first question on my mind is, “How could this change break what we’ve done? Do we still have a closed loop the way we did before?”
Mark: What were the things that were challenging for you on our project?
Michael: It was challenging to step back into the developer role and not be in the lead role, but you giving me the space to express my preferences up front and throughout the project helped me do some of my best work.
You get used to being the leader, so it was a very deliberate thing for me to say, okay, you’re not the tech lead right now. You said how you feel. Now let’s move on.
Mark: I tried to say yes at every opportunity I could, to say: “I’m not sure about that, but let’s give it a try.”
It was easy with our team because we had a lot of respect and affection for one another, and a deep commitment to meeting the client’s needs.
Michael: That commitment made it a lot easier to step back when I had to. Once we’d talked things though, if the thing that we decided on wasn’t what I wanted, I still knew that we’d gone through the process. I didn’t ever feel shut down.
I felt a lot of times like you let me go in a way that you weren’t sure about just to find out how things would look at the end.
The more generous you can be with everyone else having a chance to speak and share their experience and the more space you make for people who don’t talk much, the more likely the morale is going to be high.
Mark: Some of the directions you wanted to pursue weren’t familiar to me, and that wasn’t always comfortable, but I trust you. How else am I going to learn from you unless I respect your experience and challenge my assumptions?
But the trickiest part is when it feels like the group is going in the wrong direction. That’s when you make the call, take the responsibility and risk, and say, “Hey team, you haven’t been in the meetings with the client. I’ve learned what the client’s values are, and this approach isn’t supporting them.”
But there should be a clear reason for intervening. And it’s important to be judicious about the moments you take a stand.
Michael: If you’ve been generous with me most of the time, I’ll find those moments easier to accept.
Mark: Morale is so important. It’s natural for me to act as the teams’ cheerleader and maintain enthusiasm for the work when we get stuck. It can be so discouraging when things don’t test well, or when we see a bunch of deficiencies, or when the client pivots in a dramatic way.
Then I’m like, “Oh no, do we really have to do this over?” It’s crucial to shift that attitude and find pleasure and satisfaction in getting the application closer to what the client needs.
Michael: That cheerleading feels even more important to me with a skilled team than with a team of newer people in their roles.
I enjoy our conversations where the team is just hammering at the problem until something great comes out of it. But it also can be draining to do that every week.
Some people who’ve been doing this for a long time, and have been successful at it, don’t react well to that kind of constant scrutiny and introspection. They just want to do their thing. It’s important to counteract the dismissiveness that can emerge from that.
Mark: The goal is to stay curious about what we’re doing and what it can teach us, and how that can lift up the team and help everyone to grow.
Michael: Yeah, it was so fun to do that together.
Mark: So when do you feel really good about the job you’re doing as a tech lead?
Michael: I feel good when I have the client’s goals in mind, when I have a clear vision of how we will get there, and when I’m confident that the things we’re doing are serving that vision. And when the team is engaged and excited about their work.
Mark: Could you give me an example of a project that went really well for you?
Michael: I began a project that was all about creating data reusable imports for large data sets. Part of that included undoing a previous developer’s limitedly successful way of creating these imports. I started as the developer but had to move to tech lead as other projects were added to my schedule. Because I started as the developer, I already had a vision in mind about how to accomplish what the client needed, and now an experienced developer was stepping in to do the work. We quickly found a rhythm of high-level technical discussion, testing, and client interaction that felt seamless. Given all the risk factors involved, fairly opaque legacy code, large data sets, multi-step imports with custom validations, the handoff and my role change from developer to tech lead worked out great.
Mark: Can you remember a project where where things got difficult?
Michael: There have been times in the past where things come up in client meetings that I didn’t know were happening. Or a ticket gets created or moved, and I don’t have a good idea of how it fits in. If that happens, I get everybody together so that I can get my head around what’s going on. I feel frazzled when things are happening and I don’t know why, or where they came from.
About a year ago I had a bunch of projects on my plate and was serving different roles on each of them. As a result, one or two of those projects, let’s say, got a little less attention. The stand ups fell off the calendar, and nobody noticed, and the only time we all met was with the client.
At those client meetings, issues came up that I hadn’t heard anything about. One of the users emailed a developer directly, and they dealt with the issue independently of the team. It made me so uncomfortable to be completely out of the loop.
But that was motivating: I thought, “I’m not doing a good job tech leading this project right now. Let’s get back on track!”
Mark: The most difficult thing for me is when the client goes dark. I have to remember not to take it personally, and to manage my tendency to give my attention to the loudest / most fun / easiest to support clients and lose track of the those that have disappeared from view. It’s especially challenging when I’ve worked passionately on something complicated that requires me to hold a lot in my head, and then not get any feedback for months. It’s so much effort to reload the mental model and get back in gear.
Michael: In my case, the key stakeholder was the only person that we talked to in our client meetings, and we didn’t realize that they had moved to a different department and weren’t using the database anymore.
Then the department lead started reaching out for feature requests directly to the developers. We thought we had a reliable direct connection to the lead stakeholder, but that line got broken up, and I didn’t realize that was happening.
Mark: In contrast, on our project last year, the primary stakeholder was incredibly engaged and had an extensive mental model of what we were building. How often does that happen?
Michael: And we could dedicate a significant portion of our schedules to doing it so that there wasn’t a lot of competition from other work. It didn’t feel like I was working ten projects, and this was just a slice.
Mark: He and the BA had a great relationship and they would just charge ahead with working out complex requirements. Sometimes I felt like a third wheel, but I figured my role was to ask questions and slow them down a bit. That’s not always the most fun job to have – to interrupt the flow with concerns – but I know that we benefited from a third point of view.
I did the same thing with all the BA’s meticulous documentation. I’d go in as an editor and look for gaps or inconsistencies in the process.
If there’s one thing I know how to do, it’s edit, so I would just go to town on that, and along the way I’d internalize anything I might have missed.
Despite all our best efforts, we ended up with evolving requirements and had to pivot a number of times, and that’s always hard for me. After investing a bunch of effort, it’s like, do we really have to blow this up and try again? Also, it can be difficult to decide which new requirements really matter, and which we can defer.
When these changes come along, my job as the tech lead is to bring it to the team with curiosity and enthusiasm: “How are we going to rework this?” And: “This is a big improvement for the client, so let’s go do it!”
Michael: There’s a feeling of whiplash that can come with rapidly changing requirements. It’s the tech lead’s job to shield the team from that feeling.
Mark: Right – the tech lead disciplines their own feelings about what’s happening so they don’t carry it over to the team.
Michael: That’s part of what I meant by translation earlier, managing your own frustrations either with the client or with the dev team – so that you can give everyone what they need to do their best work.
Mark: To shift the energy and say, “OK, so we’ve got this gorgeous work of art we’ve been building, we’ve done the best we can to make something consistent and elegant, and now we have this new requirement. But we don’t have to tear everything down. Let’s find a satisfying way to incorporate it into what we’ve done.”
Michael: Yeah, there is this protectiveness you feel about the work when you’ve spent a lot of time thinking about how all the pieces fit.
Mark: My impulse in that moment might be controlling, to hold everything tight and solve the problem on my own, but it’s good to open it up to the team and solve it together so that everyone feels authorship around the necessary changes. They’re not being handed down from above.
Looking back at our project, I’m so grateful you were part of it. It was a big endeavor, and you were right there, so interested in doing it well, and wanting to work together rather than saying, “Who is this person to tell me what to do?”
Thank you for helping me not need to be right, not need to be an expert, and to share moments of insecurity. It’s so special when we can trust one another with that, with the willingness to be vulnerable in our work.
Michael: Yeah, I felt really comfortable working with you too. At no point did I feel like, “If I don’t take control, this project’s gonna go off the rails.”
Sometimes when I’m not the lead, I have this feeling that if I don’t take control, this thing is gonna spin out, and we’re all gonna be pissed off because of how bad it went.
Mark: The plane’s going down! We’re all gonna die! (laughter)
How about this as a description? When we appoint a tech lead, we are naming a leader among peers. The process should be collaborative, with as much consensus as is possible and practical, but finally it’s necessary for someone to be tasked with talking to the client and making key decisions.
Michael: Yeah, that’s a really powerful thing and a big responsibility. It’s a great thing for me when I can take that role and and live up to it. I’m grateful that our big project never went off the rails or got stressful. That’s the way to do it.Mark: I hope that soon we’ll get a chance to work together again, but with the roles switched. Then we can have another conversation from the other point of view!
