Effectively managing your team whilst retaining your technical know-how may seem like an impossible juggling act. But there are some things you can do to polish up your skills.
If you’re worried about becoming hands-off as a manager and losing your technical edge, I feel you. When it happened to me I felt the lack of hands-on, tangible experience with my team’s code very keenly, and went through a year of mourning and regret for the loss.
Now, many years later, I‘ve managed to overcome the fear of losing my edge, and I am confident that I’ve successfully stayed technical through all these years of not writing code. How have I done this?
At the senior management level, “staying technical” is about understanding the technical details of your team well enough to accurately represent them and paint them into the bigger picture strategy. It is about understanding the value of technical investments, whether they are supporting product strategy, scaling, or productivity, and being able to justify these investments to your team and beyond. It’s about being able to show your work, to demonstrate that you understand the underlying technical demands. But to do any of this, you have to be good at knowing what you don’t know so that you can ask the right questions of people who do.
Avoiding the trap of uninformed overconfidence
We’ve all experienced the out-of-touch senior manager. The person who confidently speaks about your team’s work so inaccurately you wonder if they have ever bothered to read the definition of Kubernetes, or built a website in their life. Somehow this person has become successful, but it’s the kind of success that you would rather avoid if it means sounding that clueless.
Fortunately, steering clear of this trap as a manager is easy. You just have to bother to ask questions, listen, and check in with people. Staying technical is a lifelong project, but it doesn’t happen in your spare time by building apps on the side so you can brag to your staff that you are running deep learning algorithms on your kids’ homework. It happens through constant engagement with your team, paying attention to what they’re doing, and listening when they explain their projects. It happens through checking in with engineers often enough that you actually understand their work, at the appropriate level of aggregation. Add in occasionally doing your homework and brushing up on relevant areas, and you’re in good shape.
Technical management in action
What does this look like in practice? Here are two situations that many senior managers have faced, and examples of the ways that two different types of technical managers might approach them.
Situation one: moving to an SRE model
Your staff wants to move to a Google-style Site Reliability Engineering (SRE) model for operations. Do you:
a) Just start hiring Xoogler SREs, throwing them at teams to fix things, all the while talking up your SRE strategy?
b) Skim the Google SRE book to understand how and why Google did SRE in the first place, read a few blog posts, ask colleagues at other companies about their experiences with SRE, talk to your staff about the goals they want to set for this transition, help them to articulate milestones for measuring whether it’s actually making the organization more effective or not, and then strategically hire some experienced SREs to bootstrap the initiative?
Option A is easy to do, and will basically always fail. This problem may not seem particularly technical, but the work required for a successful SRE rollout usually involves both social and technical changes. Without an understanding of the distance your organization will have to travel in order to successfully adopt SRE from both of those perspectives, the new hires are likely to bounce off the existing structure, get frustrated, and leave without delivering much change.
Option B is not that much more work for you as a senior manager. All you’re doing is making sure your staff is being specific about what they want and doing basic research to understand where all this is coming from. You’re making sure that there is some thought and planning for how these new SREs can be successful with the technology and organization you have today. But if you pretend to know what SRE is already, and try to slot it into your org with no thought or planning, you will get the worst of both possible worlds: that sort of arrogance will come off as not technical to your savvy staff, and you are likely to end up with a failed rollout of SRE.
Situation two: moving to a hybrid cloud environment
Your organization wants to move to a hybrid on-prem/public cloud model instead of being entirely in the public cloud or entirely in your own data centers, claiming that this will enable the best of both of these environments. What is your next step?
a) Start hyping that you’re going to build a magical orchestration system to seamlessly and dynamically move all workloads between on-prem and the cloud.
b) Do some research on the basics of cloud-native orchestration and some of the buzzwords your team is using so you have a baseline. Ask your staff: what vendor products are there that do this? What are our goals for this model, and how are we measuring them? What are the critical risks in underlying systems that we will need to manage to make this project happen?
Option A might be a good sales pitch to the senior non-technical leaders of the company, but your engineers are likely to wonder if you have any idea of the real complexity they are facing if you share that vision with no nuance or backing details.
Option B does not require much from you to start, just an understanding that there are moving parts that need to be implemented and coordinated to do something like this. It’s your job, as the leader of this organization, to ask questions that make sure these moving parts have been considered, and that risks are being identified and acknowledged. You may come out of this analysis with an Option A-style pitch, but now you have a more complete understanding and can speak to the nuance when you discuss it with the engineering teams.
There is, of course, one more way for you to come off as non-technical in both of these scenarios: deny both of these projects without trying to understand why the team wants them or what the value might be.
There are plenty of projects you will have to say no to in your time as a manager, but when your team comes to you with the desire to modernize their technology or approaches to work, you owe it to them to be open-minded to the proposal.
No one comes off as technical through bold proclamations or out-of-pocket rejections. They come off as more technical through the successful delivery of projects that people care about, and through asking questions about important details in a way that shows that they appreciate the work at hand.
Your next steps as a technical leader
None of this is going to make you a master of technology, but I promise you that most engineers don’t actually want that from their senior manager. They just want someone who is trying to learn and who is listening when they provide details about why something is hard. Someone who occasionally asks them questions that force them to think about how they are approaching things and whether there is a better way.
So pause. Take the time to ask questions with the goal of creating successful technology. Keep doing that as you manage bigger teams. Don’t pretend you know what you don’t know, and stay curious about the details. That’s the easiest way to be a great manager and a technical leader.
