Isis L. Rose

Trawl through LinkedIn for roles with titles like “Software Engineering Manager” or “Data Science Director”. 90% of them will say they want not just an informed and competent technical team manager but a “player-coach” who can do the jobs of their charges, and sometimes even who is expected to spend a significant percentage of their time directly contributing production code to the company’s products. 

This is a mistake. 

It unnecessarily limits your applicant pool, leaves opportunity on the table, and usually attracts the wrong sort of person to your organization. 

Don’t get me wrong: these unicorns do exist. And occasionally, in exceedingly rare cases, the right person and the right role can come together in a way that works. But trusting lightning to strike isn’t a business strategy, and you don’t actually want most of the people who want that job at your organization. And you definitely don’t want most of them managing your teams of high-performing individual contributors. 

A good technical manager needs to be able to: 

• Speak the language: understand the team’s issues, represent them accurately, communicate with leadership and nontechnical stakeholders about technical topics. 
• Be an effective people manager: support the team, gain their trust, coach them through professional and interpersonal challenges, guide their growth, handle difficult situations with maturity and empathy, set them up for success. 
• Be versatile and always learning: have a strong enough technical background to be able to spin up sufficiently on any new technology or topic that becomes relevant to the team’s work. 
• Remove barriers: handle administrative issues, find resources, and generally be laser-focused on empowering the team to do their best work. 
• Manage risk: flag issues early, communicate effectively about them, and advocate for real solutions. 
• Build roadmaps: synthesize the team’s perspective, the company’s vision and goals, and one’s own expertise into a path forward that everyone can rally behind. 
• Arbitrate: manage disputes and facilitate harmonious, productive relationships on the team. 
• Communicate, communicate, communicate: be the bridge that gives everyone the crystal clarity they need in order to succeed. 

A good technical manager does not need to be able to: 

• Do their employees’ jobs for them. 

Organizations imagine that they’ll find these magical and infinitely flexible managers who will seamlessly switch between wearing a management hat and an IC hat, filling the gap of whatever the team might need at the moment. That they’ll effectively get two employees for the price of one. 

What you usually get in reality is the worst of both worlds. A manager distracted by IC work, who can’t really be there for the team in the way they need. An IC with only one foot in the code, who lacks sufficient context to truly collaborate as a member of the team. So much time lost to task-switching as to make both roles ineffective. And more often than not, the loss of the team’s trust by devaluing their contributions and denying them ownership of their work. 

There’s nothing wrong with having weekend coding projects and keeping one’s technical skills sharp as a hobby, but there should be no more value placed on that than on any other hobby, like music or running. What’s more, I argue that it should be seen as a potential red flag for the type of person who is overly attached to their identity as the IC who saves the day, and who will be incapable of being a truly effective leader. 

A coach’s background and experience as a player is important, but when they transition to the role of “coach” they leave the role of “player” behind. It is no longer relevant what Kevin Cash’s current batting average would be; what matters is how the Rays do on the field, and how Cash facilitates their success. We don’t expect baseball managers to step up to the plate, and we shouldn’t expect engineering managers to write production code. It’s a waste of everyone’s time. 

Managers need to manage

The most critical point in a technical contributor’s shift into management is being willing to let go. To let go of the need to be the rockstar programmer who saves the day. To focus on doing your new job, which is enablement, not execution. To deliberately fade into the background and yield the spotlight to your team. To evolve your definition of success and let go of your identity as a hero. It’s difficult to do, and many fail. Many people get to the juncture of a potential management transition on the strength of their success as a developer, which makes it all the more likely that they will make an incomplete job of it and cling to the desire for the particular praise and accolades they’re accustomed to. 

What you wind up with is a manager who is jealous of their team and neglects the role you hired them for in order to seek their old definition of success. Someone who at best simply doesn’t have the time to be a good manager, or at worst craves the attention that is due to their team and actively (if perhaps unconsciously) undermines any chance of their employees feeling truly supported and appreciated by the organization, driving them away. That’s someone who shouldn’t be a manager in the first place, and it’s precisely the sort of person who is attracted to the ubiquitous “player-coach” roles. 

Managers who want to manage make the best managers. And you do want the best managers for your teams, right?

Developers need to develop

Ask any developer what frustrates them the most about their job, and it will likely be something like: 

• unclear or inconsistent guidance and direction from leadership
• insufficient resources
• administrative overhead
• being expected to do work outside one’s role
• ambiguous, poorly-defined roles
• not enough time to address poor legacy design and tech debt issues

What all of these things have in common is that they take time, energy, and/or focus away from the core function of a developer: to write clean, effective code. People want to do good work, and the purpose of your organization’s management structure is to make that possible. All of the challenges listed above are solved by good management, which means that managers need to focus on clearing obstacles and empowering their team to do amazing things. Managers who are spending their time one-upping their team, stepping on their toes, and wading into the codebase making changes with insufficient context are a drain on the team’s efficacy, not an asset. 

Management is a force multiplier

A skills or capacity gap on the technical side can be readily filled with an additional IC hire or contract support. A top-of-their game technical contributor can step into a scoped role and spin up quickly, if good systems and good management are in place to provide them with the necessary tools, support, and clarity. 

A gap in management, however, is much trickier. An effective manager has to have established, trusted relationships with the team, stakeholders, leadership, operations, and more across the company. They have to maintain context of not just the team’s work but also the longer arc of the company’s goals, current and future challenges, other teams’ roadmaps, staffing, etc. That is an essential, core skillset that needs to be embedded in the company in order to be effective. Treating management as a part-time job cheats the team and the overall organization out of its true potential. Your team’s full capacity deserves to be unlocked, and that can only be done with full-time, effective management. Your team deserves that. 

Do you want a manager who can fill in as around half of a developer on occasion, or one who will build and maintain well-functioning systems and relationships so that you can scale arbitrarily to meet any moment?

Do one thing and do it well

As humans, our biggest strengths are specialization and cooperation. That’s what allowed for the development of agriculture, industry, and essentially every aspect of the modern world. Why would we limit ourselves by throwing away these basic principles when it comes to technical team management?

There is certainly space for advanced technical contributors, in a Principal or “team captain” leader role. Those are essential too, and a senior-level IC track is important to have. But if you’re looking for a manager, someone to handle all the things at the top of this article and unlock the team’s capabilities?

Trust your team to write code. Trust your managers to manage. Let your people do what they’re good at. Build a system that works. Win.