The Modern Leader
Can you run an engineering team if you didn’t come up through code? Yes—with intention about the EM job, how you earn trust, and how you stay technical enough to steer well.
As we said on the podcast:
“I think you can have standards for what it means to stay technical in your organization, but I don't think forcing managers to code is necessarily a good thing.”
What the EM job actually is
Your first responsibility is the system that ships—people, priorities, and clarity.
“Your role as an EM is to make sure your team is delivering what they should be delivering on schedule with a high quality bar.”
Day to day, that means: set goals, remove blockers, create healthy feedback loops, and ensure technical decisions are being made by the right people (often not you).
Where “technical” helps (and where it doesn’t)
You don’t need every framework, but you do need to reason about constraints, trade-offs, and risk.
“You need to be able help your team navigate system design exercises and trade offs. What are the pros and cons? What is the business reason behind using one or the other?”
Stay close enough to speak business and systems, then let your engineers own the how. And if you still like to code:
“My rule is you can code whatever is not critical path.”
Non-technical advantages you bring
- People leadership: coaching, conflict resolution, consistent follow-through.
- Communication: translating between product, design, and engineering; reducing ambiguity.
- Product sense & execution: tying technical choices to outcomes and delivery.
Also, fresh perspective is a feature:
“I think labels can hinder. Like it can be a little gatekeepy.”
Earning respect without being “the most technical”
Start with humility and curiosity.
Pair and shadow to understand, not to steer:
“Make it clear to them that you're doing this because you just want to learn. This is not you critiquing their work.”
And ask the “obvious” questions:
“The best time would have been to ask a while ago. But the second best time to ask is now.”
Guardrails that prevent anti-patterns
- Don’t micromanage architecture or PRs; your voice carries weight.
- Don’t let “non-technical EM = bad” go unchallenged.
- Probe the “why,” then point to outcomes, not origin stories.
- Don’t confuse vibes for rigor (even if you once were).
Staying close to the tech (without grabbing the keyboard)
- Run a tech-map: document critical paths, dependencies, monitoring/alerting, and where risk lives. Keep it current.
- Attend one design review per sprint: listen for assumptions, failure modes, and who owns what.
- Read ADRs (architectural decision records) and post a one-paragraph summary: model crisp reasoning and surface questions.
- Schedule “learning pairs”: 45 minutes where an engineer narrates decisions; you summarize back what you heard.
Handling the respect & timeline trap
Non-technical managers sometimes get sandbagged with “this is just hard.” Avoid it with shared visibility: clear goals, public status, and evidence over ego. If estimates slip, be curious first: scope, unknowns, or external blockers?
What to read
📚 Tiny Experiments — Anne-Laure Le Cunff 🎓 Engineering Leadership in the AI Era (Emma’s pick, I didn't call out my own course!)
Listen to the full episode: Becoming An Engineering Manager Without A Technical Background