Fifteen minutes. That is how long my chief architect spent reviewing the first design document I had ever produced as an architect. Then he rejected it. Not unkindly — he did not send me back to my desk and say go and try again. Instead he walked me to a whiteboard and spent thirty minutes showing me exactly what I had missed. That session did not just reject a design. It rejected the version of me that had walked in thinking like an engineer.
At the time I was a team lead managing a team of twelve to fifteen people, contributing to a mission-critical payments system, and holding personal ownership of the most technically demanding components in our codebase. By any reasonable measure I was doing well. The quality bar was high, the domain was complex, and the standards for performance, security, and scalability were uncompromising. I had earned my place.
Then I was given a six-month window to prove I could be a software architect. And that is when everything unravelled — in the best possible way.
The Card Number Problem
The first real design task I was given was to architect an automatic card number generation system for our online transaction processing platform. In the payments ecosystem, the card number is one of the most sensitive assets that exists — a secret that enables everything from authorisation to fraud detection. Our system ran card programmes for various business lines, and each programme needed a ready inventory of pre-generated card numbers. When new cardholders enrolled, those numbers had to be available instantly, assigned cleanly, and protected absolutely.
I worked on the design. I documented it carefully, at least by my own standards. Then I walked into the review with quiet confidence.
My chief architect read for fifteen minutes, then looked up and said: this is not an architecture. This is a description of code.
The entire design was rejected. But what happened next is the part of this story that still matters to me. He did not dismiss me. He sat down and gave me six to seven specific areas — questions I had not even thought to ask. What were the fraud parameters that would govern card validation? How would card inventory scale across programmes with different issuance rates? What were the data classification requirements for numbers at rest and in transit? How would the system behave under peak load during a new cardholder onboarding surge? What was the operational model for replenishment? How would expiry and recycling be handled across cohorts?
I had answered none of these. I had been writing code structure in a design document. I had been thinking in classes and components, not in consequences and constraints. And in that moment I knew — with complete clarity — that my mind was not yet ready to think like an architect.
The Full World View
As a developer, I had always owned my piece. I wrote clean code, I delivered on time, I maintained the hardest components in the system. And when my code was deployed — when it was built, tested, monitored by others — I considered my job done. That was not arrogance. That was how the work was structured. Each person owned their layer.
But an architect does not own a layer. An architect owns the whole picture. How the feature will be built. How it will be tested. How it will be deployed and operated. How it will degrade under failure. How it will change two years from now when requirements shift. How every decision made today will constrain or enable every decision made later.
That was my first real lesson. And it came not from a textbook but from a rejection.
What followed that conversation was a period of deliberate learning. I realised there was a large room I had never walked into — and I needed a map. Over time I developed a set of questions I now ask any engineer who is beginning this transition. Not as a test. As an honest mirror.
Five Questions Before You Make the Leap
I will walk through these in reverse — starting from the foundation and working toward the expectations at the surface, because the surface questions only make sense once the foundation is solid.
Have You Brought Your Learning Outside of Office Hours?
Your skill spectrum is the most significant asset of your career. As a software architect, the job has no fixed right answers — only better and worse trade-offs. If you are not learning as a lifelong discipline, this is the moment to start. At the beginning, concentrate on three areas: Mindset (your values and beliefs), Skillset (the technical spectrum you can draw upon), and Valueset (your human and collaborative skills). Growth in all three must happen continuously — not only during business hours.
Do You Understand the Difference Between Perception and Perspective?
This is one of the most important distinctions in the architect's toolkit — and almost nobody makes it explicitly.
Perception is the reality you have built over time through your working environment, your mentors, your successes and your failures. It is entirely yours. It is formed from real experience, and you should be proud of it. But when people argue with you, they are almost always arguing with your perception — not your perspective. If your perception is wrong, admit it and correct it immediately. Defending a wrong perception is the most expensive thing an architect can do.
Perspective is the reality you are being asked to understand and act upon. It is your customer's requirements, your stakeholder's constraints, your team lead's expectations, the problem space seen from every angle that is not your own. Learning to understand and genuinely adopt the perspective of others — not merely acknowledge it, but internalise it — is how good architects make decisions that last.
People argue with your perception. Your job is to act on perspective.
Do You Understand What Your Real Deliverable Is?
Your primary deliverable as an architect is not a document. It is not a diagram. It is your decisions — and the long-term impact those decisions carry. Your decisions will shape the fate of a system for years. You have to learn to leave room for decisions you did not make. You have to resist building a design that only works if every future choice also goes your way.
The single greatest threat to sound architectural decisions is cognitive bias. When someone on your team has a favourite tool, a preferred language, a familiar pattern, they will unconsciously frame every problem as one that requires exactly that solution. Your job is to keep your own biases in check — and to protect the decision process from everyone else's too. Make decisions on merit. Use fact-driven, scenario-driven, use-case-driven analysis. Most architectural blunders are not caused by ignorance. They are caused by prejudice.
Time is your judge. The turnaround time of your decisions is determined by their purity. A decision made without ego clears quickly. A decision made from bias costs years.
Are You Ready for a Paradigm Shift in How You Work?
Becoming productive as an architect requires change across all three dimensions — mindset, skillset, and valueset — simultaneously.
Mindset: This is about breaking your shell. You must learn to accept critical feedback without defensiveness. You must learn to "agree to disagree" — to hold your position with integrity while genuinely respecting dissent. You are no longer a solo decision maker. The impact radius of your decisions is enormous, and you cannot afford to work in isolation or from ego.
Skillset: Expect a sustained learning curve of roughly thirty percent new material at all times. Every day will bring questions you have no answer to yet. Acquiring new skills at pace is not optional — it is the core competency of the role. The architect who stops learning becomes the bottleneck.
Valueset: You have to become a people's person. You have to be a good listener, a genuine collaborator, and a careful communicator. Introverts — and I say this with full respect, because I understand this challenge — have to break certain shells to succeed in this role. Reach out for feedback. Reach out for collaboration. And if your environment is filled with smart, opinionated people, develop your ability to convince — not with authority but with clarity and evidence.
Do You Truly Understand What Is Expected of You?
This transition is neither easy nor straightforward. Your first challenge will be the hardest to articulate: the shift from coding to architecting. Coding was your character. You owned it fully. As an engineer you knew exactly how much you knew and exactly where your code lived. Now you are being asked to have a view of something far larger — and to own that view even when you cannot write a single line to prove it.
There is also a social dimension that is easy to underestimate. The people around you must be convinced of your technical credibility. That trust is not automatic. It is earned through consistent, clear thinking over time.
Be deliberate about your milestones. Break the expectation down: what does success look like at one month? At three months? At six months? At a year? Each phase requires different things — the first month is about listening and understanding, the third is about forming a point of view, the sixth is about delivering on it, and the year marker is about demonstrating impact. If you are not thinking in these terms, the transition will feel like it is happening to you instead of through you.
Not Ready — and That Is Exactly Where to Begin
When I walked out of that thirty-minute session with my chief architect, I was humbled. Not humiliated — there is an important difference. Humiliation closes you. Humility opens you. I walked out knowing the size of what I did not know, and that is the most useful thing an aspiring architect can possess.
The transition from engineer to architect is not a promotion. It is a transformation. You are not doing more of the same thing at a higher level. You are learning to think in a fundamentally different register — from code to consequences, from components to systems, from tasks to decisions.
My chief architect did not give me the answers that day. He gave me the questions. That, I now understand, is precisely what an architect does.
The question is not whether you are ready. The question is whether you are honest enough to see what you are missing — and disciplined enough to close the gap, one decision at a time.