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.

Architecture is designing for problems you don't know about yet

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. You still try to get it right. You just stop expecting to.

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.

Zooming out costs you the credibility you need to be heard

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.

Propose designs that are explicitly incomplete

I spend a lot of time asking "what if" questions 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 oracle version of architecture is a lie

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 on the first pass. The goal was to give the team something to push against.

The shift from solving problems to designing for uncertainty took me years. Being wrong still stings. It just stopped meaning failure. That's the job.