Making the shift from engineering manager

You’re not starting from zero

Engineering managers make better enterprise architects than people often expect. A lot of EA work is about people, organizations, and getting change done, and you’ve been doing that for years. The hard parts of the transition are more about mindset than knowledge.

What transfers directly

EM strength	How it shows up in EA
Stakeholder management	You already manage up, across, and down. EA does the same with more senior and more varied stakeholders.
Delivery realism	You know what change actually costs: estimates, capacity, migration pain. That keeps your roadmaps credible, a common weakness of architects who have never delivered.
Organizational awareness	You’ve seen Conway’s Law in action. Team boundaries and system boundaries are tied together, and EA has to work with both.
Hard conversations	Telling a team their pet project is being deprioritized is a skill you’ve practiced.
Growing people	Coaching engineers becomes coaching a federated community of architects and tech leads.
Prioritization under constraint	You trade off scope, quality, and time every quarter. EA does the same across a portfolio.

What changes

From authority to influence

As a manager you had positional authority: you could assign work, set priorities, and make final calls for your team. As an EA you usually have none of that. Nobody reports to you, and teams don’t have to follow your advice.

Your influence now comes from:

• Credibility: being right often, and honest when you’re not
• Usefulness: solving problems people actually have, early
• Context: knowing things others don’t, because you see across the organization
• Relationships: trust built before you need it
• Sponsorship: executive backing, used sparingly

From delivery to direction

Your old success metric was visible and frequent: the team shipped. EA outcomes take quarters or years to show up, and other people’s teams deliver them. That can feel unrewarding at first.

What helps: set yourself near-term, visible milestones (a published capability map, the first ten ADRs, one decision that saved real money) and keep a log of decisions you influenced.

From your team’s interests to the enterprise’s

You’ll sometimes argue against your former team or your former peers, for example by recommending that their service be consolidated into another team’s platform. This is where perceived neutrality is won or lost. Be explicit about the enterprise trade-off and acknowledge what the team gives up.

From quarters to years

EM work is mostly this quarter and next. EA work is mostly a 1–3 year horizon, connected back to decisions being made today. You’ll need to get comfortable with more ambiguity and with plans that will change.

From “how” to “what” and “why”

You’re no longer the person who decides how a system is built. You make sure the right things are being built, for the right reasons, in a way that fits together. Resist the urge to design the solution yourself. Set the constraints and outcomes, then let solution architects and teams do the design.

Common failure modes

Failure mode	What it looks like	The antidote
Staying in delivery	You still join your old team’s stand-ups, debug their incidents, and review their PRs.	Hand over deliberately. Agree an end date with your successor.
The ivory tower	You overcorrect into theory: frameworks, metamodels, diagrams nobody reads. Engineers stop listening.	Tie every artifact to a decision someone needs to make.
The bottleneck	You try to review every design, and teams wait for you.	Set principles and guardrails; review only what’s hard to reverse.
Framework-first	You open with “we’re adopting TOGAF” instead of “here’s a problem I can help with.”	Lead with problems. Use frameworks quietly as a toolkit.
Solution-jumping	You go straight to a technical answer before understanding the business problem.	Ask “what outcome does the business need?” before “what should we build?”
Trying to boil the ocean	You attempt a complete current-state model before doing anything useful.	Model just enough to support the next decision.

Your development plan

Use the skills self-rating to find your largest gaps. Most engineering managers find theirs cluster in:

• Business architecture (capability modeling, strategy translation)
• EA frameworks (TOGAF), which you’re addressing with the certification
• Building an EA practice, which is new to almost everyone

For each of your top three gaps, plan one learning activity (a module here, a book, a course) and one stretch assignment where you apply it for real. Review the plan with your manager at 30, 90, and 180 days.

At Quillfeather

You’ve just moved from managing two core platform teams into the EA role. Some early tests:

• Week 1: Your old team’s tech lead asks you to approve a database migration “because you know the context.” Handing it to the new EM is the right move, even though it would be faster to do it yourself.
• Week 3: The Head of Payments assumes you’ll push to absorb PayNest into the core platform, because that’s what your old team always wanted. Your job now is to weigh that option fairly against keeping PayNest separate, and to be seen doing so.
• Week 5: The CTO asks for “an architecture framework.” Find out what problem they want solved (likely the board’s technology plan, and decisions being made inconsistently) before mentioning TOGAF.

Reflection

• Which “what changes” shift will be hardest for you personally? Why?
• Which failure mode are you most at risk of? What early warning sign would tell you it’s happening?
• Who could you ask to give you honest feedback in your first six months as an EA?