The architect's job is to be wrong first
A few years ago, I proposed a design that my team immediately improved. Not tweaked. Rebuilt from scratch. They took my rough sketch and made something cleaner, more elegant, actually suited for the problem we had.
I used to think that was failure. Now I think that's the job.
The shift nobody warns you about
When you're an engineer, success means solving the problem. You take ambiguous requirements, turn them into clear code, ship it, move on. The compiler doesn't care about your feelings. Either it works or it doesn't.
Architecture is different. You're not solving problems anymore. You're designing for problems you don't know about yet. And this took me years to understand: that means you're going to be wrong. A lot.
The skill isn't predicting the future. It's knowing where to leave room for when your predictions fail.
Flexibility is the actual deliverable
I proposed an event-driven architecture for a payment system once. Clean separation, loose coupling. The team looked at it and immediately asked: "What about the reconciliation reports? Finance needs those in real-time, not eventually consistent."
They were right. I'd missed it entirely.
But the design had enough flexibility that we could add a synchronous path for those specific reports without rewriting everything. Not because I'd anticipated that exact requirement. I hadn't. But because I'd left seams in places where I knew I didn't know enough.
The junior engineers on that team shipped a better solution than I would have alone. They understood the edge cases from actually working in the system. My job was giving them a structure that could absorb their improvements without collapsing.
The credibility trap
There's a real tension here. Architects need technical credibility to be taken seriously. But the more you zoom out, the further you get from the details that gave you that credibility in the first place.
I've watched architects fall into two traps. Some stay too close to the code. They become senior developers with fancier titles, micromanaging technical decisions because that's where they feel competent. The team resents it. The broader system design suffers.
Others zoom out so far they lose touch entirely. They propose designs that look beautiful on a whiteboard but fall apart when someone asks "how do we actually deploy this?" The team stops taking them seriously. I've been in both of these traps at various points. Neither is comfortable in hindsight.
The path between them is narrow. You have to know enough to be dangerous, but also know when to shut up and let the people closer to the problem fill in the blanks.
What I actually do now
I spend a lot of time asking "what if" questions. Not to prove I'm smart, but to find out where my assumptions are weakest. What if this service gets 10x more traffic? What if that team gets reorganized? What if the requirement we think is fixed turns out to be negotiable?
The answers tell me where to add flexibility and where simplicity matters more.
And I've learned to propose designs that are explicitly incomplete. Not because I'm lazy, but because I want the team to own the parts they understand better than I do. When they improve my design, that's not failure. That's the system working.
The hardest part
The hardest part isn't being wrong. It's being visibly wrong, in front of people who expect you to have answers.
There's a version of architecture where you're the oracle. People come to you with questions, you dispense wisdom, they go away enlightened. That version is comfortable. It's also a lie.
Real architecture is messier. You propose something, it gets poked at, it changes. Sometimes it changes so much that the final result barely resembles what you started with. That's fine. The goal was never to be right. The goal was to give the team something to push against.
Have you made this shift? From solving problems to designing for uncertainty? What surprised you most about the transition?