I’ve watched the same job title mean completely different things at different companies. At one place an “architect” lives in vendor spec sheets and configuration screens. At another, someone with the same title hasn’t touched a tool in years. And at plenty of places, the “architect” is so buried in day-to-day engineering work that they never actually get the time to architect anything. None of these is automatically wrong — but it tells you that “how deep should I go?” is a question almost nobody answers on purpose.
When I dig into why the depth varies so much, it usually comes down to one of three things: people carry the expectations from their previous company into the new one, someone gets promoted and drags all their old responsibilities up into the new role, or it’s just how that particular company happens to be structured. These are decisions — someone, the person or their boss, made them. But they’re rarely deliberate decisions about what this role should be at this company. They get carried over, or backed into, and then never revisited. And that’s the encouraging part: they’re workable. With the right guidance, a little practice, and some honest conversation, people can grow into the altitude their role actually needs.
So let me try to answer it on purpose — at least for the roles I know best, in solutions and data architecture. A couple of caveats first. Every company is different and every person is different, so none of what follows is meant as a rule to dictate — it’s a starting point for the kind of constructive discussion teams need to figure out what works for them. And all of this assumes an organization established enough to separate these roles in the first place. At a startup or on greenfield work, deliberately blending altitudes — one person wearing four hats — might be the necessary move. The tension I’m describing shows up later: when a company is big enough to draw these lines but hasn’t actually drawn them. If you’re mature enough to dictate who owns a system, you have to act like it. If you’re not, then keep the greenfield mentality and let the people who are passionate about a system run with it. What you can’t do is have it both ways.
The useful way to think about it is altitude: how far down into the detail each role should fly. And most of the dysfunction I’ve seen traces back to one of two things — people flying at the wrong altitude, or no one ever defining the altitudes at all. When roles and responsibilities aren’t documented, the airspace is open, and people fill it however they’re used to filling it.
A typical chain looks like this:
Director → Manager / Enterprise Architect → Technical Architect
Let’s take them from the top.
The Director: vision, not tools
The director owns the long-term vision of a department — think Director of Data Management and Governance, or Director of Business Solutions — and is accountable for making sure the right solutions are in place to meet the business’s needs. They’re usually reporting up to a C-level like the CIO, CDO, or CTO, and their job is to know where the entire department needs to go.
So what does a director actually do? Their core job is to translate the business’s strategy into a roadmap for the technology and capabilities their department is responsible for — and then keep the whole department on track to deliver against it. In practice that means setting priorities across competing initiatives, securing the budget and people to pursue them, clearing the organizational roadblocks their teams can’t clear on their own, and staying aligned with peer departments so the work doesn’t collide. They own the why and the what, by roughly when at a strategic level — and they own the accountability when it doesn’t happen. And there’s one responsibility here that’s easy to overlook but matters enormously for everything else in this post: the director is the natural owner of defining and documenting the roles and responsibilities within their department. If the altitudes are blurry, that’s leadership’s to fix — and it usually has to start right here.
What they don’t do is pick tools or design the architecture. A director sets the destination and makes sure the department is equipped to reach it; figuring out how the systems get there is the enterprise architect’s job. Their altitude is the highest in the chain, and they should stay there — managers and enterprise architects are in constant contact with them to translate that vision into something the teams can actually deliver.
The Manager: involved enough to speak to it, not enough to dictate it
This is where I’ve seen the most confusion, and it runs in two opposite directions.
The manager who dictates the architecture. These are almost always former architects, and it’s worth being honest about why: they got promoted because they were excellent architects, and nobody ever taught them how to let that part go. So they keep doing the job they were great at. The trouble is they now override what the enterprise and technical architects believe is right — and it backfires two ways. Either their solution doesn’t integrate with the rest of the environment, or the architects and engineers don’t agree with it and quietly stop caring. People don’t fight for a solution they didn’t help shape, so it gets less attention and works less well.
The manager who’s checked out of it entirely. The opposite manager delegates the whole solution to the architects. That sounds healthy — it gives the architects purpose and ownership — until that manager walks into a meeting with other managers, directors, or executives and can’t explain what their own team is building. Now one of two things happens: they give wrong information and the team spends days or weeks cleaning up the confusion, or they say nothing at all, which makes the whole team look like it isn’t working, doesn’t understand the ask, or is siloed. Either way, the architects end up in extra meetings calming people down instead of building.
The middle ground isn’t complicated: a manager needs to be involved enough in architecture decisions to discuss them at a managerial or executive level — but not so involved that they’re dictating direction. Give advice, ask the questions that pressure-test whether the technical direction meets the business need, and then trust the team to do the technical work.
There’s one more part of the job that’s easy to miss. When the architects deadlock — and eventually they will — it’s not the manager’s place to break the tie. It’s their place to notice the deadlock is real and bleeding time, route it to the person who should own the call (usually the enterprise architect, or the director if it needs to go higher), and then make sure the whole team respects that decision once it’s made — including the people who lost the argument. The manager owns that a decision gets made and that everyone moves forward; they don’t own what the decision is.
A manager’s real job is keeping the team functioning, informed, and happy. Every hour they spend trying to architect is an hour they’re not doing that.
The Enterprise Architect: 80% horizon, 20% mentor
The enterprise architect flies wide rather than deep. Their job is the whole picture — how all the solutions fit together in business solutions architecture, or how data moves across the company in enterprise data architecture. They take direction from the director and make sure all the different systems can actually work together, then work with the technical architects to make sure each specific area fits the broader stack.
In practice that whole-picture job has real substance behind it. The EA defines the target state — where the architecture needs to be — maps it against where things actually are today, sets the standards and integration patterns that keep new systems compatible, and acts as the gatekeeper when someone wants to bring in a new tool: does it fill a real gap, or is it the third thing that does the same job? They’re also the feasibility check in the other direction — telling the director when part of the vision is going to be harder or costlier than it looks. The catch is that an EA has to do all this while staying credible. Drift too far from the technical reality and you start handing down patterns that don’t survive contact with the real systems, and the technical architects quietly stop trusting you. Close enough to the weeds to be believed; not so close you’re doing the technical architect’s job.
I lean on the 80/20 rule here. At least 80% of an EA’s time should go to making sure the enterprise architecture actually meets the business need. Without that oversight, you end up with a pile of siloed systems, multiple tools trying to do the same job, and expensive platforms nobody uses to their potential. The other 20% is well spent mentoring technical architects — but the horizon work comes first. The moment an EA gets pulled down into the weeds of one system, the whole company loses the only person watching how everything connects.
The Technical Architect: go deep, but on your thing
This is the role that should be in the weeds — with one critical boundary.
A technical architect needs to know how their system interacts with other systems and what happens to their data. But their real value is going deep on their specific area and their specific tools. And by deep I mean deep — not just the high-level design, but the actual code and configuration going into it. They don’t have to dictate every line of logic, but they do need to understand it well enough to be sure it does what the architecture requires, and to roll up their sleeves and help when the team needs it. That’s the entire point of putting an architect in the weeds — it’s the opposite of the ivory tower. An architect who only draws diagrams and never touches the system loses both the credibility and the understanding that made them worth having down there in the first place. And if they’re not constantly looking for ways to push those tools further, the solutions never get used to their full potential. Here’s the trap, though: the fastest way to ruin a good technical architect is to give them too many systems.
I’ve seen architects assigned to several systems at once, and none of those systems delivered what they could — because no one understood any of them deeply enough. Projects stalled because teams were waiting on a decision from an architect who was buried in a different system.
One pattern stuck with me. A company had a platform that paired physical hardware with a software layer, and on paper it could deliver almost everything a business leader envisioned — the research and the vendor conversations all confirmed it. But the vision never got realized. The engineers knew how to install the hardware so it showed up in the software. What was missing was someone who knew the software side well enough to configure it and guide the team. The architect who should have done that was stretched across other domains. The result: projects halted waiting on direction, hardware bought and never used, and business users who had access to a system but no one enforcing how to use it properly.
That raises a question. If you’re the architect for a product, but the product never gets used to its potential because you’re never given the time — are you really its architect? I’d say no. And that’s not necessarily a knock on the person; it’s a knock on what they were asked to carry. The fix is simple: find someone who actually has the capacity and ability to take the helm. In that situation there were willing people — but because management had assigned it to one person, everyone had to wait on them and decisions/direction were significantly delayed or never addressed.
This is the “act like it or don’t” problem from the start of this post, made real. If a company is mature enough to assign who owns a system, it has to act like it — give that person the capacity to actually own the system, or hand it to someone who has both the capacity and the passion to run with it. What you can’t do is claim the authority to assign ownership and then strand that ownership on someone pulled in five directions. The system doesn’t care whose name is on the org chart; it only gets better if someone has the time to make it better.
A quick tell: read the deliverables
| Role | Primary deliverables |
|---|---|
| Director |
|
| Manager |
|
| Enterprise Architect |
|
| Technical Architect |
|
If you want a fast way to spot someone’s altitude, look at what they actually produce. A director is producing roadmaps, priorities, and — ideally — the documented roles and responsibilities for their department. An enterprise architect is producing target-state and reference architectures, the standards everyone builds against, and the high-level diagrams that show how the pieces connect. A technical architect is producing detailed design docs, system and data-flow diagrams, and the configuration standards for their specific area.
When the deliverables don’t match the altitude, that’s usually the first visible symptom that someone’s flying at the wrong height — a director hand-drawing system diagrams, or a “technical architect” whose only artifact is a slide deck. (How much of this should be written down, and who’s allowed to see it, is a whole post of its own — one I’ll come back to.)
The pattern underneath all of it
Almost every architecture problem I’ve described is really one problem wearing different costumes: someone flying at the wrong altitude — or no one ever deciding what the altitudes should be. Directors picking tools. Managers architecting. EAs buried in one system. Technical architects spread so thin they can’t go deep on anything. Get the altitudes right and most of the friction disappears.
| Role | Too high (not involved enough) | Too low (in the weeds) |
|---|---|---|
| Director | Detached from reality. Strategy becomes disconnected. | Gets into tools and solutions. Loses sight of the big picture and priorities. |
| Manager | Checked out. Can’t speak to decisions or defend the team’s work. | Dictates architecture. Overrides experts and creates disengagement. |
| Enterprise Architect | Ivory tower. Creates impractical standards that don’t survive reality. | Lost in one system. Stops seeing how everything connects. |
| Technical Architect | Diagram-only architect. Lacks credibility and misses real-world details. | Spread too thin. No system gets the depth it needs to succeed. |
But “get the altitudes right” doesn’t mean stamping the chart from this post onto your org. Every company is different and every person is different — the point isn’t to dictate where everyone flies, it’s to decide it on purpose and write it down. Most of the dysfunction I’ve seen didn’t come from people being bad at their jobs; it came from roles and responsibilities that were never defined, so everyone defaulted to the altitude they were used to. The fix is rarely a reorg. It’s an honest conversation about who owns what, a little guidance and patience while people grow into it, and the willingness to revisit the whole thing when it isn’t working.
There’s a related question I deliberately left out of this one — who should these roles report to? The reporting lines between architects, managers, and enterprise architects create their own set of problems, and they deserve their own post. That’s coming soon.
What does the right altitude look like at your company — and who’s flying at the wrong one? I’d genuinely like to hear it.