5 Tips to Stay Technical as a Manager
A good coach is a also a master of the game
A good coach needs to understand the game. A good manager needs to be technically competent. We can't get technical excellence from people if we don't know what that looks like–we won't be able to set clear expectations, continually coach, or hold people accountable for it.
Knowing this and fearing that management abdicates their responsibilities, some companies swing too far to the other side and have managers do part of the technical work themselves as a way to force them to stay technical and set an example. I've already discussed in depth why I think that's a bad idea. Still, the TL;DR is:
- Managers will steal opportunities to grow from the team.
- Technical work will pull them away from the work that only they can do.
- They will grow slower in management and leadership, which are the core competencies of their role.
So the question remains, how do we stay technical? I've assembled five tips that have worked for me this far. Before we go on, though, make sure you want to remain technical for the right reasons–"I want to make my people awesome ✨"–and not the wrong ones–"I miss code 😢." If the former is your reason, go on to the tips ⏭. However, if the latter is your reason to stay technical, I urge you to ask yourself this: Have you internalized the idea that management is not a job?
Becoming a great manager requires you to focus on management skills, which requires giving up some technical focus. Although working with people is not full of quick wins, like coding is, it can be incredibly gratifying once you own your work and stop avoiding it. Your work is building a solid, effective, and able team. Valuing only technical work will pull you away from it. If you can't appreciate working through other people, you definitely shouldn't be a manager, and you'll probably have a hard time being a leader of any kind.
Disclaimer: These tips assume you have relevant technical knowledge in your area and want to learn new things, sharpen your skills, not start from scratch. If you moved too early into management and lack a solid foundation, this is not the way to go. Instead, you'll need more profound and time-intensive work. My main advice here would be to migrate back to a technical position and move back once you're comfortable.
Check Your Ego and Use Curiosity To Learn
The key to remaining a technical expert while not stealing opportunities is curiosity. Even if you have relevant experience with what the team is doing, assuming you always have the correct answer will eventually hurt you.
When people rely on management to be the one to make the decisions and to have the right answers, the "thinking for myself" muscle starts to atrophy, and people will stop growing. Hiring competent people to have them work in this setting is sad.
So I'm not arguing for "fake curiosity," where you assume you have the correct answers and ask questions to ensure people get there. I'm arguing for genuine curiosity. Where you trust people are competent and have done the work and ask questions focused on learning what they've learned. A common pushback here is: "But the team is still learning." Autonomy and trust do mandate more technical competence everywhere. If you have a team that's not competent and can't be trusted to make decisions, then that's the issue you should solve first.
So model genuine curiosity and see people grow as a result of it. Whenever you don't understand some area of the team's work, ask one of your directs to take the time to explain it to you and do some pair programming. In 45 minutes to 1 hour, you can learn a lot, and teaching you will also consolidate that knowledge for your directs. When you do understand it, and someone brings something that is not "correct" in your experience, assume they know something you don't and ask!
Review the team's work
Reviewing work is a great way to learn and to teach. If you have formal reviews or critiques for the team's work, they're an excellent opportunity to both be closer to what people are doing and give impersonal feedback on it. In Engineering, there are some great opportunities for this:
- Code Reviews
- Architecture Critiques
- Architecture Discussions
If you don't have formal reviews, consider adding opportunities for them. Especially when working remotely, making them async is a great way to invite collaboration. My favorite way to do this is through RFC (Requests for Comments). Instead of going into the work directly, creating a document explaining what you want to do and having people give you feedback on it.
Remember, whenever we're reviewing, we need to model curiosity. So we focus on making questions and not assumptions. We need to respect that people had the time to work on what they're submitting to review and to study it, and we didn't, and our experience may be outdated.
A great way to extract the most out of a review is to set a personal goal to understand and articulate every impactful decision the person made and its implications. We don't need to review every piece of work. Instead, we can focus on going deep on what's more impactful or riskier.
Go broad frequently, go deep when you have to
For most managers, having deep knowledge of a subject will not pay off as much as having a broad understanding of several areas. Therefore, instead of focusing on mastering all topics, we should master only those we have to. We should dedicate most of our technical studying time to learning the basics of many different ones.
To broaden our knowledge, we need to learn constantly:
- Studying frequently: I dedicate at least one day of my week to broadening my knowledge. Some sources I like are on this Twitter thread.
- Jumping in on Events: Meetups, tech talks, and events are great ways to expose ourselves to different approaches and subjects.
- Face every project as a learning opportunity: Everything the team does is a learning opportunity. We can explore topics related to what we're building and take the time to reflect and learn based on how the projects are going. Participate in what the team is doing, attend postmortems, be there for technical discussions, comment on documents.
Foster a network of technical people
Having technical people around us and discussing experiences broadens our knowledge and gets live feedback on what we do. Creating a network is all about helping people. I promise you. You will get way more than you give if you dedicate yourself to supporting others, not expecting them to help you back–especially when you connect two people who can help each other.
Participating in communities is a great way to foster this network. Sharing your experience, learning from other people's experiences, and discussing ideas are rewarding and help build connections. So, whenever you can, ask for the authentic experiences behind blog posts and tech talks. Listen and learn from people who have done similar things. Ask for feedback on tools, frameworks, or processes you want to use. But remember to filter out and understand that each context is different.
In conclusion
We need to stay technical without having our hands all over what people are building. Our work is still the team, and the reason we stay technical is the same we should be doing any other thing with our time: To Make The Team Awesome. That's where our focus should be. Use these tips to stay up-to-date and technical and don't abdicate your responsibility. A good coach needs to understand the game.