How can engineer leaders stay technical?
Various ways and actionable tips to keep your technical axe sharp and stay relevant
I reached out with this question to one of my friends who is the CTO at a mid-size company (500-1000 employees).
Below is his response:
I believe staying technical has been key to my success as a CTO and also past roles that led to this position. I feel that I have a big role to play in setting engineering culture.
It lets me:
Grasp what is the level quality
Champion a strategy to improve quality
Solve problems without needing a tech translator
Be the voice of my team in C-suit room
Understand the nuances of the decisions I take
Connect to my people—uniting us in our craft
Executives love to simplify everything into bullets. But often the bullets hide the context and complexity.
Nuances are key. Devil is in detail. As a CTO you cannot afford to abstract yourself from the technical aspects.
Without technical depth:
My understanding will be reduced to bullet points! That is a nightmare!
I lose the ability to drive practical aspects of innovation.
How do I keep up with technology?
I learn directly from my team
I remain relentlessly curious, and I'm constantly reading
I am a generalist these days and know enough about enough, to know that I should not get into details
I learn by reading RFCs, ADRs, etc. and participating in architecture reviews and forums
I sometimes discuss technical challenges in 1:1s and skip-levels (when an executive talks face to face with people who aren’t in their immediate line of report)
I follow conversations on Slack
I occasionally drop by engineers’ table and have a casual conversation to understand their challenges and world while updating them
etc.
To what extent? I know enough about our technology to:
make or support decisions
connect technical work to business objectives
understand my team's challenges and strengths first hand without them having to dumb it down
It might be tempting to hire a Staff Engineer to cover that gap. Please don’t go there for the reasons described here:
Engineer-ication
who has a CTO background and these days coaches other CTOs, has written about “Engineer-ication”:During a few days you block your calendar and agenda rejecting meeting invites and delegating certain tasks to other people, as if you were to go on vacations.
You join one of your engineering team as Individual Contributor, and work on one or more software engineering tasks. — Sergio Visinoni
He also followed up with some best practices in another post.
Sergio formulated his thoughts about this topic at Should Engineering Managers Code?
You should prioritize the well-functioning of your team over any coding work.
You should be able to drop any ongoing coding work at the first sign of stress on the system.
Your team should not make assumptions on your contributions, and […] capacity
Don't [take] tasks or features that are in the critical path for delivery.
Hobby Projects
Another idea is to have hobby projects. Some of the engineering leaders I respect a lot have their own hobby projects to improve their engineering skills and catch up with technology evolution.
It doesn’t matter if it’s tinkering with Raspberry Pi or setting up a new Kubernetes cluster, as long as it allows you to live the life of an engineer and gain fresh insight, it’s good enough.
Power Asymmetry
How technical is technical enough?
Engineering Managers have an say in the team. After all, they hold the levers on everyone’s salary, performance review, vacations, etc.
It is rare that the engineers challenge an engineering manager without the fear of repercussions.
There’s a risk that a bad idea from engineering manager stays unchallenged and goes all the way to production. And when things break, it’s ultimately the engineering manager’s accountability. The engineers are merely responsible for what they’re tasked to do.
It is best to say within a safe distance and let the engineers run the show as much as possible.
It is also very important to build the psychological safety in the team for the engineers to call out bad ideas even if it comes from the leadership.
An EM friend put it in terms of PR (pull requests):
How does a developer feel when the leaders send in a PR? How about comments on a PR review? What if the feedback is actually not a good solution? Does the developer feel forced to implement the feedback due to the manager telling him/her?
What about a technical EM sending in a PR, will the developer feel forced to approve it to not get into "trouble" on performance ratings or salary reviews?
Those are two aspects i have seen that can create a worse technical solution than not having a technical EM. However, i also see your points as well.
I’ve had my share of “micro-managers” who hurt the team culture (with good intentions). Getting too close to code requires a level of trust, openness, and humility that takes time to establish.
So please don’t jump on code after reading this post (easy). Instead spend your time and energy on building an environment that makes the best ideas win regardless of where they came from (much harder).
My monetization strategy is to give away most content for free. However, these posts take anywhere from a few hours to a few days to draft, edit, research, illustrate, and publish. I pull these hours from my private time, vacation days and weekends.
You can support me by sparing a few bucks for a paid subscription. As a token of appreciation, you get access to the Pro-Tips sections as well as my online book Reliability Engineering Mindset. Right now, you can get 20% off via this link. You can also invite your friends to gain free access.
when I became the team manager, I developed an even greater hunger to stay up to date with trends - in my case of MS stack/C#, I dived into the areas of compilers and assembler - something I had never paid attention to before. I believe that the manager of the production team must be up to date with technology even if it is not hands on - and maybe even more if it is not hands on