One of the hardest transitions for someone stepping into engineering management, especially from a senior engineer or architect role, is learning how to let go of direct control over architecture, which fundamentally changes what being technical looks like in the role, a theme I expand on in Staying Technical as an Engineering Manager. This challenge is not limited to first time managers. Even seasoned engineering managers who have spent years as architects or lead engineers often feel a strong pull to own technical decisions. That instinct comes from a good place, especially for managers whose earlier impact came from designing systems directly rather than enabling others to do so, a broader leadership shift I explore in System Design Through a Leadership Lens. You have built systems before, you know what good looks like, and you want to protect the team and the product from bad decisions. But the reality is that this transition is not easy, and it is not supposed to be. Letting go of certain controls is necessary for the long term growth of the team and the systems they build.

This post shares my perspective on what the role of an engineering manager really is when it comes to shaping software architecture, without becoming the architect yourself.

The Reality of Letting Go

When I transitioned from an IC architect role into engineering management, my first instinct was to dive deep into architecture. I wanted to understand every nuance so that I could make the best possible decisions later. What I quickly learned is that the scope of responsibility for an engineering manager is much broader than that of an architect. Your time is split across people management, delivery management, strategic planning, and a calendar full of meetings. The deep focus time that architects rely on is simply not available anymore.

Every decision becomes a return on investment question. How much time should you invest in a particular area, and how much does the outcome actually matter. If you have architects or senior engineers on the team, they are the ones best positioned to dive into the details. I learned this the hard way by spending too much time going deep, only to realize I could not sustain that level of involvement. That experience is common for many engineering managers.

Letting Go Does Not Mean Walking Away

There is an important caveat here. Letting go does not mean fully relinquishing responsibility. Architects will bring you designs, but it is still your job to extract the right design with the right tradeoffs. You need to understand enough to challenge decisions, ask for alternatives, and question whether something is too complex or too expensive for the business value it delivers.

This is where the engineering manager role intersects with delivery leadership. You are accountable for outcomes, both short term and long term. That accountability requires informed judgment, not blind trust.

Create the Right Environment

Your primary lever is not the architecture diagram. It is the environment in which architectural decisions are made. That starts with providing context. Whether you are working with a group of architects or a single senior engineer, they need to understand where a system fits in the broader landscape. Sharing goals, boundaries, and constraints clearly gives the team the foundation they need to make good decisions.

Your role is to guide questions, not to answer them. Architecture thrives on exploration, especially in a technology landscape that changes rapidly. What was right a year ago may no longer be the best choice today. Encouraging exploration and critical thinking is far more valuable than prescribing solutions. You are not solving the problem for the team, but you are shaping how they approach solving it.

Apply Principles, Not Details

As a manager, you will never know the full depth of every architectural decision. Time will not allow it, and that is fine. What you should always apply are guiding principles. Does this design make sense given the constraints. Are the tradeoffs explicit. Does the complexity match the problem being solved.

Your job is to use those principles to extract the right architecture from the team, even if you are not immersed in the details.

Start With the Business View

When onboarding a new product or inheriting a system, the instinct is often to look at detailed diagrams. Instead, your focus should be on understanding the business context first. You should know how systems interact, which teams you depend on, what tooling is involved, and how value flows through the system. This may be formal or informal depending on the company, but that high level understanding is critical.

You do not need to know every contract detail or authentication nuance. It is great if you do, but it is not realistic. You should be comfortable relying on your team and architects when deeper questions come up.

Reinforce the Right Architectural Behaviors

Over time, you should actively reinforce certain principles. Encourage questioning assumptions, especially when those assumptions may be based on outdated or incomplete information. Favor simplicity over cleverness. Most real world problems do not require complex solutions, and simpler systems are easier to maintain and evolve.

Be cautious about designing for hypothetical future scale without a clear business case. Generalizing too early often leads to unnecessary complexity. At the same time, prioritize speed to market. Time to launch matters, and shipping a focused MVP is often far more valuable than spending years building a perfect system that may be obsolete by the time it is ready. Architecture only matters if it serves the business.

Build This Muscle Gradually

This kind of thinking does not appear overnight, especially in newer teams. You have to introduce it gradually and reinforce it consistently. You cannot control every decision forever. You do not have the time, and doing so prevents the team from growing.

As the team internalizes these principles, it frees you up to focus on forward looking work and higher leverage decisions, while the team continues to make sound architectural choices on its own.

Stay Technical Without Overreaching

Letting go of architectural ownership does not mean you stop being technical. If you stop engaging with technology entirely, you are no longer acting as an engineering manager. Staying current with industry trends, understanding your tech stack at a high level, and knowing what is possible within your constraints allows you to spot risks early and bring useful ideas into the team.

Curiosity is a core part of the role, even if you are no longer opening the hood on every system.

Know When to Step In

There are situations where you must step in more directly. If you do not have architects or senior engineers, you may need to design the initial systems yourself to get an MVP off the ground. I have been in that position while building a team from scratch.

You should also step in when designs are clearly misaligned with long term strategy or when architectural choices are creating unsustainable technical debt. You own delivery, both today and in the future, and those tradeoffs ultimately sit with you. Stepping in should be intentional and transparent, with a clear plan to step back once the team is ready.

Final Thoughts

Guiding architecture as an engineering manager is about balance. You set direction without dictating, challenge without micromanaging, and stay technical without becoming the bottleneck. The goal is not to be the architect. The goal is to build a team that consistently produces good architecture, supported by the right context, principles, and leadership.

---

Have thoughts on how managers can stay technical without overreaching? Please share your thoughts in the comments below. I would love to hear your perspective.