Most advice about growing in consulting is about doing your assigned work faster and cleaner. That’s necessary, and it’s also not what moved me. The things that actually turned a Junior Consultant role into a Solution Architect one were rarely on any job description — and the biggest of them was learning to think in architecture and solutions, not in the boundaries of a single platform. If you’re early in a consulting career, these are the lessons I’d pass on.
1. Become an architect, not just a platform expert
It’s tempting to go deep on one product and stop there — it’s comfortable, and specialists are in demand. But the leap from consultant to Solution Architect happens when you stop thinking “how do I build this in tool X” and start thinking “what’s the right solution across whatever technologies fit.”
In practice that means deliberately working beyond your original specialization. I came up through the Salesforce ecosystem, but the work that changed my trajectory was architecting across the surrounding stack — integrations, cloud, custom components, the systems a platform has to connect to, including non-Salesforce technologies. A platform-agnostic view — designing for the problem rather than around a single tool — is the core of the architect mindset, and it’s what lets a practice broaden beyond a single-vendor comfort zone.
If you take one thing from this: depth in a platform gets you hired; the ability to design a solution across platforms gets you promoted.
2. Own outcomes, not tasks
A consultant is measured on completing what was assigned. An architect is measured on whether the solution was right. The shift is from executing tasks to owning outcomes — noticing the gaps nobody assigned, and stepping into them.
Over time that grew into owning real infrastructure and technical direction that sat well outside my original remit. Nobody hands you that scope; you earn it by reliably handling the scope next to yours until owning more becomes the obvious next step.
3. Learn the commercial side
The change that most affected how the company saw me was moving from “executes technical work” to “understands the business.” I started paying attention to how deals are shaped, what margin means, and why one solution gets proposed over another — which eventually pulled me into technical pre-sales and conversations about our technical direction.
Most technical people treat the commercial side as someone else’s problem. Learning it — pipeline, margin, risk, how a proposal becomes a project — is what earns you a voice where decisions are actually made. You don’t have to become a salesperson; you just have to stop being blind to it.
4. Have an opinion on technology, and back it
There’s a shift from waiting to be told which tools to use to forming — and defending — a point of view on what to propose and where a company should go technically. Arguing to broaden a technology footprint means being wrong sometimes, and being ready to explain the why every time.
That’s the real move from consultant to architect: from how do I build what was decided to what should we decide. You earn it by being right often enough, and by reasoning openly about trade-offs rather than just having preferences.
5. Earn trust in both directions
This one is underrated. Growing into a leadership role isn’t only about impressing management — it’s about being trusted upward and downward at the same time.
- Upward, with leadership and the commercial team: by being reliable, honest about risk, and thinking about the business rather than just the ticket.
- Downward, with the people you work alongside and lead: by having their backs, sharing context, and making the team stronger instead of making yourself look good.
A leader who’s only trusted by management isn’t leading — they’re relaying. And it’s built the same way in both directions: consistency, honesty, and genuinely caring about the outcome for the people involved. Consulting is a team sport; the person who delivers and raises the people around them is the one organizations keep betting on.
What I’d tell my Junior self
The path here wasn’t a stack of exams passed or boxes ticked — the certifications and technical depth were the entry ticket, not the thing that moved me up. What moved me was a steady shift: from executing tasks to owning outcomes, from one platform to whole solutions, from technical execution to business judgment, and from being good at my job to being someone both the company and the team could trust.
So do your technical work well — but don’t stop there. Learn to design across technologies, understand why the business does what it does, form opinions worth defending, and be the person everyone above and below you is glad to have on the project. That’s the version of these four years worth repeating.