I’ve been an architect for about five months now. Long enough to have opinions, not long enough to think I’ve figured it out.

The thing that surprised me most isn’t the thing I expected. I figured the hard part would be not writing code, or the meetings, or something about the title. It’s the distance between a decision getting made and that decision showing up in a developer’s hands. It is nowhere near as fast as I thought it was from the other side.

As an engineer, I only saw the end of that process. Something showed up, I used it, and if it took too long to get there I assumed somebody was dragging their feet. Now I’m in the middle of it, and I was wrong.

So where does the time actually go? In my experience so far, in this order.

Constraints nobody surfaced early. You’re halfway in and something comes up that changes the shape of the whole thing. A dependency, a limitation, a system that doesn’t work the way everyone assumed it did.

Then the approval process. Which is real work, and mostly good work, but it’s work.

Then getting people to agree on a solution. Usually everybody already agrees on the problem. That part is easy. The disagreement is about what to do about it.

And then roadmaps versus priorities. A team can think your thing is a great idea and still not be able to touch it for two quarters. That’s not resistance. That’s a team with their own commitments.

The hardest habit to break has been the engineering instinct. When I see something stuck, my first reaction is still to go fix it myself. Get out of the way, I’ll build it. That instinct served me for years and it does not translate. Most of what’s blocking a decision now isn’t something I can write.

The bigger shift is how I think about being right.

I used to approach a technical disagreement like something to win. My design versus theirs, and the better one should take it. I don’t think that way anymore. I’m looking for common ground that isn’t my idea or your idea, because whatever we land on, those same people have to build it, support it, and live with it. Winning an argument and then needing that team’s help six months later is a bad trade. I’d rather come out of it with a partner.

The other thing that’s changed is what I’m accounting for when I make a call.

As an engineer, the question was what’s best for my team and the thing we’re building. That’s a reasonable question. It’s just a small one. Now I’m asking how a decision lands on a team that doesn’t want this today but will want it in a year. Maybe because of a project I’m on, or because somebody mentioned something to me in a conversation they don’t know I had.

That’s the real advantage of the role, and I didn’t fully understand it going in. I have context that nobody on any single team has. I’m in enough rooms to see things heading toward each other before either side does. If I only optimize for whoever is loudest right now, I’m wasting the one thing that makes the seat useful.

I’d like to say I’ve got engineers pulling me in early on cross-team work. I don’t yet. That’s still ahead of me. Right now the job is getting teams to know who I am, getting introduced to the right people, and making it clear what I cover so it occurs to somebody to loop me in when something new comes up. You can’t get pulled into a conversation by people who don’t know you exist.

And I’ll be honest about the part that’s hardest for me personally. I barely touch code anymore and it sucks. I’ve always been an engineer first, and that didn’t change just because my title did. I’m trying to build more POC work into the role, actually trying things out before I architect around them, and if I can find a way to sit with a team and write something with them, I’m taking it. I don’t want to become the guy drawing boxes for systems he’s never run.

What makes it worth it is that my voice is in the conversation earlier. I get to raise the angle nobody thought through. The way a decision hits a team that isn’t in the room. And I’m in front of senior leaders far more than I ever was as an engineer, which changes what you can actually get moving.

If you’re an engineer thinking about this move, here’s what I’d tell you. There are a lot more meetings and design sessions than you’re picturing, and most of your day is spent working across the organization instead of inside one team. Your ideas will not always be the right ones, and you have to be genuinely okay with that. Not fake okay. Be true to yourself. And don’t make enemies. You’ll need those people.