In a recent conversation with a Head of Transformation and a GM of IT, we discussed the hiring of a Technical Architect for a significant program of work.
The candidate interviewed well. Strong experience. Clear communication. Deep understanding of architectural principles.
Then the expectation surfaced.
“We’d expect them to get into the code and scripting.”
“If they don’t want to get their hands dirty, how interested can they really be?”
And that’s where it becomes interesting.
Because this isn’t about interest.
It’s about role clarity.
What Is a Technical Architect Actually Responsible For?
In modern Microsoft programs — whether Dynamics 365, Fabric, Azure, or large ERP transformation — a Technical Architect is accountable for:
-
End-to-end solution design
-
Technical governance and standards
-
Non-functional requirements (security, performance, scalability)
-
Integration patterns
-
Environment strategy
-
Data architecture alignment
-
Reviewing and guiding developer output
-
De-risking the program
They are responsible for ensuring the system works, not writing every line of code.
When we ask them to “jump into scripting” or take ownership of build tasks, we’re shifting the role down a level — often unintentionally.
Architect vs Developer: The Strategic Distinction
There is nothing wrong with hands-on capability.
Most great architects were excellent developers earlier in their careers.
But expecting a senior architect to operate at the developer level is like:
`Could they do it?
Probably.
Should they be doing it?
No.
Because while they’re changing tyres, no one is driving the car.
And in transformation programs, that’s when risk creeps in.
The Real Risk to the Program
When architects are forced into build work:
-
Architectural governance weakens
-
Design debt increases
-
Review cycles disappear
-
Long-term scalability suffers
-
Developers lose senior oversight
-
Strategic alignment drifts
And often, the business thinks it’s saving money.
In reality, it’s increasing technical debt.
The Confidence to Say “That’s Not the Role”
The candidate in this conversation handled it well.
They said:
“I can absolutely help — but I would hire someone underneath me to do that work.”
That is not a lack of interest.
That is seniority.
It’s a signal that:
-
They understand program structure
-
They protect governance
-
They know the cost of architectural drift
-
They’ve already done the hands-on build phase in their career
There should be nothing wrong with someone saying:
“That was the role I did five years ago.”
In fact, that clarity is what you want in a senior architect.
How to Pressure-Test Your Own Hiring Brief
Before hiring a Technical Architect, ask:
-
Do we need architecture leadership or additional build capacity?
-
Are we expecting someone to design and deliver simultaneously?
-
Is the program structured with the right layering (Architect → Lead Dev → Dev)?
-
Are we unintentionally compressing roles to reduce cost?
-
Are we clear on the impact of doing so?
If the expectation is heavy scripting and coding ownership, you may be looking for:
-
A Senior Developer
-
A Technical Lead
-
Or a Player-Coach style Lead
Not a true Technical Architect.
The Market Reality
In ANZ, particularly across Microsoft Fabric, Dynamics 365 FinOps, CE and Azure programs, the distinction between:
-
Architect
-
Lead
-
Senior Developer
is becoming increasingly blurred.
That creates:
-
Misaligned interviews
-
Candidate frustration
-
Salary inflation without role clarity
-
Delivery risk
At saas nine, we see this pattern weekly.
The fix isn’t complicated.
It starts with understanding what you’re actually hiring.
Final Thought
Interest isn’t measured by how far down someone is willing to step.
It’s measured by how well they protect your program from failure.
Before asking your architect to “get their hands dirty,”
Make sure someone is still driving the car.