How Can Engineer Leaders Stay Technical?

Alex Ewerlöf put the question to a friend who is CTO at a mid-size company (500-1000 employees): how do you stay technical without writing code full time? The answer treats technical depth as what makes the rest of the job possible, letting him grasp real quality levels, solve problems without a translator, and speak for his team in the C-suite without losing the nuance that gets flattened into executive bullet points.

The piece then complicates its own premise. A second voice, an engineering manager, raises the risk that comes with a technical leader having a strong opinion: engineers may implement a manager’s bad idea, or approve their pull request, out of fear for their performance review rather than conviction that it’s right.

Fichamento

#

• The CTO keeps current by learning directly from his team, reading RFCs and ADRs, joining architecture reviews and forums, following Slack conversations, and having casual conversations at engineers’ desks, rather than writing production code.
• He frames the goal as knowing enough to make or support decisions, connect technical work to business objectives, and understand his team’s challenges firsthand, not the same depth a full-time engineer holds.
• He specifically warns against hiring a Staff Engineer to substitute for a leader’s own technical depth, linking to Ewerlöf’s separate piece on Staff Engineer as an anti-pattern.
• Sergio Visinoni’s “Engineer-ication” is cited as one concrete technique: blocking a few days, delegating meetings, and working as an individual contributor on an engineering team, paired with his own rule that any such coding work should be dropped immediately at the first sign of system stress and should never sit on the delivery critical path.
• Hobby projects (tinkering with a Raspberry Pi, standing up a Kubernetes cluster) are offered as a lower-stakes way for leaders to keep engineering instincts fresh.
• The power-asymmetry section argues managers control salary, reviews, and vacations, so engineers rarely challenge a manager’s technical opinion without fear of consequences, and a bad idea from a manager can reach production unchallenged while the manager still holds ultimate accountability for the outcome.
• The closing recommendation isn’t to avoid writing code, but to spend the effort on building psychological safety so the best idea wins regardless of who proposed it.