Don't promote your most talented technologists into people management. Promote them into technical leadership roles instead. You'll keep happy, engaged leaders and avoid the perils of the Peter Principle.
It's a common policy in hierarchical organizations to promote top performers into people management. Your best programmer comes up with great ideas, the team listens to her, she can fix anything. It's review time and what happens? She's offered a job in management. What are her new responsibilities? Paperwork, reviews, operational alignment summits, budgets. How much code is she writing now? Not much and she's probably miserable.
"I don't want to stop coding." — Almost every good programmer, ever.
There's another alternative. Technical leadership. Here are some common tech leadership roles:
- Lead Engineer
- You're coding everyday and helping others to code better, too. You have deep experience with the tools and technologies, as well as the problem domain, and you use that to inform internal system design. You keep the code healthy.
- Software Architect
- You're designing the story arc of how this software fits into its problem domain. You have visibility into the long-term plans for the software, and strong technical skills to work with engineering to build something that keeps the software focused. You keep the software healthy.
- CTO
- The most senior architect. You know what every product line is aiming for. You know how it fits into the long-term story of the product and the industry. You share this insight with your architects and leads to give them vital context for making great choices. You keep the company healthy.
This is the intersection of technology and people.
People are at the heart of tech leadership roles. It's a socio-technical role, a mix of people and technology. Hacking on one and not the other will cause the performance of both to suffer. This is the critical glue missing from most engineering organizations where engineers are promoted to managers. This is where technical leadership plays its key role. You're not managing people: you're leading them.
Why is there a gap? Because newly-promoted managers now have too many jobs. Promoting a tech lead into a manager forces them into the problem of having too many roles. Their boss is expecting them to be a full-time people manager, but their team depends on their technical leadership. They'll either have to choose one or do both poorly, for lack of time, which will eventually force their hand into choosing people management. Again, because their boss is expecting them to do that role. Now there's a void in technical leadership.
In a healthy organization the tech lead (lets say a Principal Architect) and the people manager are a powerful pair. When they're working together the people on their team are taken care of at every level. The team is comfortable because they know what to build and why, and that they're building on the right path. They're also getting the individual attention of their manager.
Tech leadership is a force multiplier.
As a technical leader you aren't always writing code. If you're a recognized leader chances are you already know that. You spend a lot of time helping others. Teaching, mentoring, reviewing code, standing at the whiteboard and explaining the permissions model for the hundredth time. Or whatever your pet thing is…
You may not always be pressing many keys and causing an implementation to occur, but for the people who are you're a valuable asset. You help them do it better. You help them avoid the pitfalls and mistakes you've already made five times in your career.
This work is vital to the health of an organization. It has a direct impact on productivity and happiness. You are helping each team member avoid pain, and you're helping the organization avoid pain. How is this a force multiplier? The evidence is proven over time.
Applying the skill of technical leadership is a force multiplier in several ways. If any of the following apply to you, you might be a tech lead:
- Your experience helps engineers at all skill levels create solutions that last longer, are easier to maintain, and respond to change better.
- You've thought through integration problems so there are fewer surprises.
- You understand the long-term goals for the software so your short-term solutions don't paint everyone into an architectural corner.
- Your team is constantly learning from you so retention rates are high because everyone is growing.
- When a customer is upset you can code up a solution which keeps the team focused on their planned work.
- You've been planning ahead for the next big development effort — have five prototypes ready for comment by the time the team is ready — so nobody feels lost in the face of a new challenge.
This is how a technical leader is a force multiplier: enhancing the attributes of your organization to make it more effective than others. It's like skill boosts in role-playing games (be honest, if you're reading this you know exactly what I mean).
Lead by example.
Technical leadership is the role best suited for my skill set. I was fortunate enough to have been supported by a fantastic people manager at my current company. With support I used everything in my technical leadership toolbox to build teams of outstanding engineers, create a culture for them to thrive in, write the story of our next great architectural revolution, and lead the team down that path.
I love this work. I'm passionate about it. As a programmer who always wants to code, I don't get to do it as much as I'd like, but when when I do it's usually pairing with someone on my team. As a leader I get to work directly on the problems getting in the way of my team, very real people-problems, and resolve them. I do that with the support of people management.
One of the core values in my team culture is transparency. I'll exercise that by sharing a piece of my self evaluation from last fall. It's the part where I'm supposed to say what I ought to work on for the next year. This is a high-level view of my approach to technical leadership:
What should the focus be for the next review period?
I'd will continue to focus on the areas I feel are the greatest value to WhiteHat. This has been my focus for the last year and will remain so. Specifically:
Empower Others — I will continue to create space and opportunity for the members of my team, my organization, and anyone in the company to contribute at their best level.
Challenge Assumptions — I will continue to challenge the things we do, how we do them, and why we do them in a relentless effort to eliminate waste in our organization.
Eliminate Pain Points — I will continue to learn about others' work in order to find resolution for things that are difficult and painful in their daily work. I will empower my team to find ways to automate most of those pain points away, or challenge assumptions in our process and workflow which may have created them.
Influence Culture — I will continue to be the change I want to see at WhiteHat, and be myself with no bad politics or hidden agendas, in order to help create the culture of trust, learning, productivity, fun, and reward I want to work in; that I want to recruit my friends to work in.
Lead Technology and Architecture — I will continue to be a leader, mentor, and teacher to my team members and organization members. I will take an active role in leading the development and design of our software and operational architectures to ensure we make aggressive strides toward modern, sustainable solutions that meet our customers' needs.
By this time next year I will have been successful if the Engineering organization is delivering high quality software that delights our customers.
I expect my team to have delivered an infrastructure and web application framework that puts us in the position to aggressively compete in our market, to have delivered several key features which empower WhiteHat to make impressive advancements within our industry and in comparison to our key competitors.
We need a tech leadership track.
I'm sure you've heard this before: "we're going to put you on the management track." The management track is a career advancement concept designed to mold high performers into managers. Within engineering we need a new, parallel track. We need a technical leadership track.
Top performers who want to remain technical and advance their career should have the option. Organizations are in desperate need of highly qualified, deeply experienced leaders making strategic decisions for the health of their software. A technical leadership track is the best way to source that talent from within.
If you are a mid to senior level engineer right now, and you don't want to advance to management, I want to encourage you to advance to technical leadership instead. Insist on a promotion to Lead Engineer, then Architect, then Principal Architect.
If you run an engineering department and want to offer career advancement that keeps your top performers engaged and happy, don't force them into management. Create an advancement track designed to build a strong technical leadership pipeline. Your software will be better for it.
Find your best technologist and promote them to Director of Architecture. Your new Director should have people managers in her peer group. This creates space for the tech leaders in your organization to grow. Build your technical leadership team under her in the hierarchy, but let them keep working with the teams their leading in day-to-day work. Let them continue to do what they're great at. This is how you make technical leadership just as important as people management.
