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.
At the time, it felt like I'd failed. I was supposed to be the architect, and my first proposal barely survived contact with the team. I see that meeting differently now.
As an engineer, I got used to success looking like a solved problem. Take an ambiguous requirement, turn it into clear code, ship it, and move on. Architecture gave me a less comfortable measure of progress.
An architecture has to leave room for problems you haven't discovered yet. You still make the best decisions you can with the information available, but some assumptions will fail. The useful skill is noticing where that uncertainty sits and avoiding choices that make later correction needlessly expensive.
The requirement I missed
I once proposed an event-driven architecture for a payment system. It had clean separation and 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, and I'd missed the requirement entirely. Fortunately, the design had enough room to add a synchronous path for those reports without rewriting everything. I hadn't anticipated that exact need. I had left seams in the areas where my understanding felt weakest.
The junior engineers on that team shipped a better solution than I would have designed alone. They knew edge cases from working in the system every day. My contribution was a structure they could challenge and improve without having to pull the whole thing apart.
Staying close enough to be useful
Architects need enough technical credibility to be useful. Yet the more you zoom out, the further you move from the details that created that credibility.
I've fallen into both sides of that tension. Stay too close to the code and you can become a senior developer with a fancier title, micromanaging decisions because that's where you still feel competent. The team loses room to work, while broader system questions receive less attention.
Zoom out too far and the design can look beautiful on a whiteboard but fall apart when someone asks, "How do we actually deploy this?" The team soon learns how much weight to give the next diagram.
There isn't a fixed distance that works. I need enough contact with the implementation to ask useful questions, and enough restraint to let the people closest to it fill in what I don't know.
I spend a lot of time asking "what if" questions to find weak assumptions. What if this service gets ten times more traffic? What if that team gets reorganized? What if the requirement we think is fixed turns out to be negotiable?
The answers suggest where flexibility may be worth its cost and where a simple decision is safe enough.
I've also learned to say which parts of a proposal are incomplete. That gives the team something concrete to challenge and makes space for them to own the areas they understand better than I do.
Something to push against
Being visibly wrong remains the uncomfortable part, especially in front of people who expect you to have answers.
The oracle version of architecture is tempting. People bring you questions, you dispense answers, and the design moves forward. It also discourages the challenge that might expose a missing reconciliation requirement.
In practice, I propose something, the team pokes at it, and it changes. Sometimes the final result barely resembles the first sketch. I still want that sketch to be thoughtful. I just no longer use how much of it survives as the measure of whether I helped.
Being wrong still stings. The question I care about now is whether the design and the conversation made it easier for the team to discover the mistake and respond to it.