Walk into most Salesforce teams and the org chart tells you almost nothing about where the impact is actually coming from. You’ll see an admin, two or three developers, and an architect wheeled in for the bigger projects. Six months later, look at what actually moved the needle: fewer cases reopened, a release that didn’t need a weekend rollback, an integration that kept running when volume tripled at month end. Trace any of those back and the person responsible rarely matches the title on their badge.
I’ve worked across all three roles over the years, often in the same week on the same project. The lines between them get drawn on org charts for hiring and pay bands, not for where the actual work happens. Worth being honest about that, especially if you’re trying to build a team or figure out where you fit in one.
What each title is actually sold as
The admin owns configuration: page layouts, flows, validation rules, reports, user setup. The developer owns code: Apex, Lightning Web Components, integrations, anything that needs a compiler. The architect owns the big picture: data model, sharing design, how the clouds talk to each other, the decisions that are expensive to reverse once twenty people are building on top of them.
That’s the textbook version. It’s clean, it’s teachable, and it’s wrong often enough that I wouldn’t hire against it.
Where the real work actually sits
Admins who quietly run architecture
I’ve seen admins who’ve been inside one org for six or seven years make better data model calls than architects parachuted in for a quarter. They know why that one field got added in 2019, which three automations depend on it, and which “simple” change will break a contact-centre workflow nobody’s touched the Visualforce page for since 2017. That’s architectural knowledge. It just doesn’t come with the title or the pay.
Developers who never touch strategy
Plenty of developers write clean Apex, pass code review, ship on time, and never once ask whether the trigger they’re adding should exist at all. Good hands, no say in the decisions that determine whether those hands are building the right thing. Useful, but not where the leverage sits.
Architects who’ve never run a sandbox refresh
And I’ve met architects who can draw a beautiful diagram of an event-driven integration pattern and have never sat through a deployment that failed at 11pm because a validation rule referenced a field that didn’t exist in the target org yet. Their diagrams are correct. Their diagrams also don’t survive contact with a live org that real people use every day.
Where the leverage actually sits
Not in the title. In the combination of three things, regardless of who holds them: enough technical depth to know what’s actually possible, enough org-specific history to know what’s actually safe, and enough authority (formal or earned) to say no to a bad idea before it ships.
On a team I supported earlier in my career, the person who moved a customer-acquisition journey from 96 clicks down to 17 wasn’t the most senior architect in the room. It was someone who understood the Apex underneath the flow, had sat with the agents using it every day, and had enough credibility to push back on a product owner who wanted to add three more fields “just in case.” Title didn’t matter. Combination did.
That’s the pattern I’d bet on every time: depth plus context plus the standing to act on both. Any one alone gets you competent work. All three together is what actually changes outcomes.
The mistake most teams make when staffing
Teams hire for the title and then wonder why nothing improves. They bring in a senior architect for six months, get a diagram and a data model, and watch it sit unimplemented because nobody closer to the ground had the context to execute it against the mess of automations already in production. Or they load up on developers to “get through the backlog” and end up with a pile of well-tested, individually correct components that collectively make the org harder to reason about than before anyone touched it.
The fix isn’t more senior titles. It’s making sure at least one person on the team has all three things at once, and giving that person room to actually use the authority, not just the knowledge.
What I look for instead of the title
When I’m sizing up a Salesforce team, I ignore the title split for a minute and ask three questions instead. Who in this room actually understands why the data model looks the way it does, not just what it looks like? Who gets pulled into a room when something’s about to go wrong in production, regardless of their pay grade? And who’s allowed to say “we’re not building that” and have it stick?
Sometimes that’s one person. Sometimes it’s split across two or three. Either way, that’s your real leverage point. Everything else on the team is support for that centre of gravity, useful and necessary, but not where the outcome gets decided.
For anyone trying to grow into this
If you’re an admin wondering whether you need a developer title to matter more, or a developer wondering whether you need “architect” on a business card before anyone listens to you, stop waiting for the title. Go get the second and third piece instead. Learn enough of the layer above and below your current work that you can hold a real conversation about trade-offs, not just execute a ticket. Sit in on the production incidents even when nobody asked you to. Earn the standing to say no once in a while, and use it sparingly enough that it means something when you do.
The title catches up eventually. It’s rarely the thing that got the work done in the meantime.
Leave a Reply