You’re Not Architect Material

My performance review lasted three minutes, and at the end of it my manager told me I was not architect material. I had the experience, the impact, the intent. What I did not have was his permission, and for a while I mistook that for not being ready.

I had spent years moving through the ranks, junior to senior to principal engineer. I had written more lines of code than I could count, led projects, and sat through the kind of production fires that teach you who you are at two in the morning. Somewhere in all of it I had earned the thing that matters more than any title: the respect of my peers and the cross-functional teams I worked with. So when I looked toward what felt like the natural next step, a Software Architect role, I walked into that review without a flicker of doubt. I thought it was a formality.

Then he left. I stayed in that room for another thirty minutes, alone, unable to make it fit. I was the same engineer who had been delivering, solving, and unblocking people the week before. Nothing about my work had changed in three minutes. What had changed was that my growth was now blocked, not by anything I lacked, but by one person’s opinion of me.

The questions came fast, and they were not kind. What am I missing? Should I give up on the architect path and just keep coding quietly? Is the door simply closed? I sat with all of it long enough to feel the disappointment fully, and not one minute longer than that. By the time I stood up, I had found two principles I have not let go of since.

Nobody Has the Right to Hijack Your Aspirations

Corporate life has its dynamics. Politics, power plays, personality clashes, the manager who decides your ceiling before you have finished your sentence. Those forces are real, and pretending otherwise is naive. But I refuse to let any of them define who I become. Progress was never the same thing as obedience. It is intent, action, and growth, and not one of those three requires someone else’s signature.

That distinction is easy to write down and brutally hard to live, because the person telling you no is also the person who signs your review. I had to separate the verdict from the truth. The verdict was his to give. The truth, whether I could think and design and lead like an architect, was mine to build, and he had no vote in it. I had once written that fear and doubt compound silently in a career, the way unspoken hesitation hardens into a kind of technical debt you carry for years. This was the moment I had to take my own advice.

Take Back Control of Your Learning

If you attach your entire growth to your nine-to-five, you hand your future to whoever happens to manage you. I had done exactly that. My development had quietly become a function of my job description, and that same job description was now being used to fence me in. So I stopped waiting for permission to grow. I started investing in my own development outside of titles and beyond anything a role officially asked of me.

In the beginning I had a shallow idea of what that even meant. I assumed becoming an architect was about drawing the right boxes, choosing the right frameworks, and guaranteeing scalability, security, and uptime. Those things matter. But they are the surface. The real work of an architect turned out to be quieter, and far more human, than any diagram I had been picturing.

Architecture Is a Mindset, Not a Job Title

Architects do not just design software. They design focus.

That single line reorganised how I work. An architect’s job is not to know the most in the room; it is to create clarity where there is noise. Most of my day now goes into resolving a small, recurring set of questions, and almost none of them are really about technology. What should we not build yet? Which tradeoffs are genuinely worth it? Where does simplicity beat cleverness? How do I unblock a team without over-engineering the very thing meant to unblock them? The restraint living inside those questions is its own discipline. I have written separately about the two sentences, “not now” and “yes, properly”, that an architect has to learn to say at exactly the right moment.

Look closely at most engineering problems and you find they are not really about skill. The team is capable. The tools are fine. What is missing is clarity, about what matters most, and about who is supposed to define the basic things in the first place: the what, the why, the how, and the when. An architect who supplies that clarity is worth more than one who supplies another framework.

I had learned a smaller version of this once before, and it had stung. The first architecture document I ever produced was rejected in about fifteen minutes by a chief architect who was entirely right to reject it. That day taught me I was not ready. The three-minute review taught me something harder: being ready is not the same as being allowed, and only one of those two is ever in your control.

Clarity Is Not Built Alone

The other thing nobody warns you about is that an architect creates almost nothing in isolation. The clarity I am describing is negotiated, out in the open, with the people who hold the other pieces: the product manager, the engineering manager, the product owner, the tech lead. They are not obstacles standing between the architect and a clean design. They are the allies who make the design real, the ones who help you agree on what the focus even is before a single box gets drawn.

With them, the work becomes three things at once. Designing pragmatically for a focus everyone has actually agreed on, rather than the one living in your head. Helping the team ask sharper questions instead of just handing them answers. And keeping enough humility to design for people, not only for systems. That is the exact point where architecture stops being a technical problem and becomes a leadership one.

I have carried this across search platforms and checkout systems, payments and banking, through teams on three continents and systems at very different stages of growth and decay. The domains changed every time. The constraints changed. What never changed was the lesson that a design ends as a document or a diagram, but it only succeeds when the teams understand it, the engineers own it, and everyone knows why it matters. A diagram nobody believes in is just decoration.

Years later, the title found me anyway. Senior Cloud Architect, the role a three-minute review had once declared impossible. But the title was never the achievement. The achievement was refusing to let someone else’s sentence become my ceiling, and doing the quiet, unglamorous work to outgrow it regardless.

So if you are growing toward an architecture role of any kind, cloud, solution, application, software, or enterprise, here is what I wish someone had told me in that room. A good architect does not dictate; they collaborate, persuade, and lead by merit. They think without flattering their own biases. They bring a real understanding of the problem before they bring a proposal, and they back that proposal with insight, attention to detail, and the right context. None of that requires a title. All of it requires that you decide, today, to begin.