Also available in fr
January 24, 2024
9 min read
Over the past two decades, I've worked on a wide variety of projects. Complete overhauls of information systems for telecoms operators, the construction of massively used financial software, a business travel management application with hotel and airplane searches, the management of communicating electricity meter alerts, a freelance marketplace, among others.
To say that everything has always gone smoothly would be quite wrong. Very wrong.
But in the course of my experiences, I met several Tech Lead/Manager duos who have inspired me in their complementary.
I've met duos, one of them working on the business travel management application, who have multiplied the impact of the projects they've undertaken.
People who were able to pull out all the stops, because they worked well together, much more than each person could have done separately.
And that, as senior ICs (individual contributors), is what you should be striving to create.
I know it's far from simple. Building a duo, a team, is by far one of the biggest challenges for a senior IC, perhaps even ahead of cache invalidation and naming ;)
So let's discuss the importance of this duo and its multiplier effect when it works.
I'm talking about all "manager/player" duos, so I include, non-exhaustive list :
First, I'll remind you of my initial hypothesis. I assume that the two roles are separate.
I know, it's possible to have organizations in which the engineering manager is also the tech lead. This is possible. Inefficient at scale, but possible and I mentioned this in a previous chapter.
It's already very complicated to be good at both disciplines, and when you are, then there's the question of the time available in a day to do both well.
And if you don't trust me, you should listen to what Charity Major has to say on the subject. You can do both well, but not at the same time.
Obviously, not all situations are comparable.
Two people cost more than one. I think that this highly unbelievable assertion can hardly be challenged from a mathematical point of view.
So, at small size, it's quite natural to mix the two roles. And in that case, this chapter will be of little interest.
But if you're not in that situation, then you can carry on reading as normal.
If you want an exhaustive view of the responsibilities of each role, the best thing to do is to visit engineeringladders.com, which gives a list of tasks that can easily be assigned to the tech lead or engineering manager.
the Tech Lead is in charge of the System while the Engineering Manager is in charge of the People.
But I like to sum it up a little differently:
The Engineering manager is responsible for the "who" and the "when".
The Tech Lead is responsible for the "what" and the "how".
And in the vast majority of cases, the "why" is the responsibility of the product manager. I say, in the majority of cases, because in platform teams, the "why" is often the responsibility of the Tech Lead.
Obviously, this definition is "simplistic", and in reality, there are many overlaps, such as the definition of priorities, development processes and the focus on impact. But, it's not an organizational bug. It's a feature.
It's a guarantee that there are, at the very least, two people thinking together. And that's a good thing, because you're never right on your own. The biggest impacts I've been able to achieve in all my experiences have all been built when people forced me to take a step back, and we built multi-brain solutions.
But that's when it's going well, and of course, this duo can come into conflict.
Above, I quote from engineeringladders.com
the Tech Lead is in charge of the System while the Engineering Manager is in charge of the People.
However, it would be an illusion to think that the system, the technology and the people who build it have no connection.
If the tech lead and the engineering manager are each working with a different priority and therefore a different investment allocation wish, this can end up in conflict.
For example, if the engineering manager decides to invest in solving the support problem, while the tech lead thinks it's time to invest in a new technology that may change the future nature of support, there will be a conflict.
These two people may not be in conflict about the end goal, but they may disagree about time scales, and the most effective means of quickly resolving the same issue.
Another type of conflict I've observed is often linked to the very nature of the two people involved.
In one of the first chapters, I mentioned archetypes of Senior IC : the tech lead, the architect, the solver, the right hand, the explorer and the product engineer.
These archetypes can of course be transposed to Engineerings Managers.
If one of the two is an explorer, seeking disruption, and the other an architect, seeking stability, perhaps the alchemy will be explosive. If the two have a totally different approach to risk, one comfortable with error, the other seeking to reduce risk, it's a safe bet that one of them will be uncomfortable.
But should we go back to a situation where the Engineering Manager also has the responsibilities of the Tech Lead?
The key is to agree on the direction you want to take. What's the goal, what's the context? I touched on this point in the chapter Autonomy, alignment and context", because, while we're looking for autonomy for both people, autonomy doesn't mean independence. There is no way out for a duo who decide to avoid all conflict by working separately and limiting interaction.
Always bear in mind that when a duo works together, there's automatically a multiplier effect on the impact produced by the team. But when it doesn't work, the opposite effect occurs.
The reason I'm focusing on this duo is that every chapter of this book aims not only to see how to create impact, but also how to find leverage to increase it. A senior IC depends heavily on the network he or she manages to create. It is this network that will act as a sounding board to amplify the impact produced.
And the first link in this network is the duo formed with the Engineering Manager.
As strong and intelligent as anyone can be, it's extremely rare to achieve a broad impact without another person to constantly drive us forward. It's almost a form of mutual coaching.
Even the greatest have had their coach. For example, do you know Bill Campbell? He's coached a number of people, including Steve Jobs and Larry Page. Yes, even someone like Steve Jobs understood that he couldn't be right on his own.
I'd like to use this example to point out that this type of duo only works when the two people are close in seniority. The two partners in this duo need to be able to answer each other's questions. There can't be any imbalance if you want to create a multiplier effect. It's not possible to create a duo between a Principal Engineer and a Junior Engineering Manager, for example. Otherwise, it's just one-way coaching.
When the duo works, this duality plays the role of catalyst.
For example, if the Engineering Manager works on team topologies, the impact of this organization will be multiplied tenfold if the Tech Lead contributes by helping to define his or her own role and its interactions, by bringing his or her vision of the field and the systems to be built.
If the Tech Lead is working on the introduction of a new technological brick, the impact will be increased tenfold if the Engineering Manager helps to disseminate knowledge, contributes to communications and helps the Tech Lead to highlight the benefits for discussion with the business.
Each can help the other and save time in the ideation phase. He or she can help clarify objectives and ensure that they are well aligned with the company's needs. Each brings a different vision and understanding of the context, which inevitably differs between an IC and a manager.
When a subject concerns human organization and practices, it's up to the Tech Lead to help with the transformation, on the ground, with all team members.
When a subject concerns technology, investments or debt, it's up to the Engineering Manager to help with dissemination, internal marketing and the popularization of impacts so that they are understood by the business.
Finally, both have a custodial role. The comparison with Jiminy Cricket may be totally unfamiliar to many people ^^^.
This character in Pinocchio represents the little voice on your shoulder that makes you wonder. It's an extra person who will make sure that the voice of Engineering is heard, by rephrasing in passing, who will also make sure that the right people, the Tech lead or the Engineering Manager, are present around the table.
A few questions to ask yourself to determine whether your duo is working well.
Do you have regular discussions with your EM that enable you to radically improve your plans? Or do your discussions resemble battlefields? Or worse, do you avoid discussions because you have irreconcilable views on priorities?
By the way, do you talk strategy with each other, or is your relationship purely a "manager/manager" hierarchical one?
Can you think of a moment in the last 6 months when your duo created an impact, and you feel that part of the success was due to your EM acting as a sounding board?
Or do you feel that you've been playing on two different teams, and are frustrated by the fact that you're sharing the benefits with this person?
Do you feel that your duo always ensures that the right people are at the table? For example, does your EM always remember to include you at the right time, in the right place? Or do you feel frustrated that you're getting information too late, and that the Engineering Manager is withholding information or making technical decisions for you in meetings of which you have no knowledge? Do you think that your Engineering Manager doesn't have the same frustrations about you, and that you don't think to include him or her at the right moments?
But above all, if you're not involved in a discussion, but your engineering manager is. How much confidence do you have, between 1 and 5, that the other will make the right decisions?
1 being "if I'm not there, very bad decisions will be made and I'll have to go back and correct them".
5 being "I'm super confident that even if I'm not there, we've already discussed it, he or she will know exactly what to answer, or will temporize the discussions if I'm really needed."
This blog post is part of the book Impactful Software Engineering. Feel free to read the other chapters.