Section 01
The call
The brief bundles architecture responsibilities without making the primary domain and collaboration boundaries clear.
The brief combines broad design scope with operational depth. Clarify which domain needs deep ownership and which require collaboration; an internal or consulting background alone does not establish either.
Role
Senior Security Architect
£110,000 to £125,000
Location
London
2 days per week in office
The shift this report makes
Not the candidates
The brief is the thing being judged.
Section 02
Why TechWaymark made this call
Combining several architecture domains is possible, but the brief needs to distinguish accountable ownership from working knowledge. Without that boundary, candidates and interviewers may interpret the same requirement differently. Ask for a delivered decision in the primary domain and an example of collaborating across a seam. A consultancy candidate may have substantial delivery ownership; establish it from their examples rather than treating their employment background as a proxy.
What in the brief led us to this conclusion
- Exec reporting, board reporting, or executive stakeholder management
- Strategy ownership bundled into an architect seat
- Team building and management bundled with architecture
Section 03
What usually happens if nothing changes
The shortlist may favour broad vocabulary over demonstrated depth if the screen only checks named domains.
Specialists in each domain self-select out before they apply, because they recognise the gap between the brief and their working experience.
Internal feedback after interviews is usually consistent: candidates look impressive on paper and weaker in the working session.
If interview feedback repeatedly finds different domain gaps, revisit the remit before repeating the same search.
Why candidates disengage
Domain specialists know they will be carried by three areas they do not have depth in, and the imposter cost is not worth the compensation on offer.
Generalists know the seat will pull them away from the one area they care about most.
Both groups also know the working session is likely to surface the gaps that the CV review missed.
What you're likely to see in your pipeline
- CVs that list every domain with no operational specifics in any of them.
- Working sessions that go well until the second domain comes up.
- Candidates asking, often in the first interview, who owns the domains the seat does not cover.
Section 04
What should change
- Pick the load-bearing domain and hire to that depth. Treat the other domains as collaboration scope.
- Name the owners of the other domains inside the brief so candidates know where the boundaries sit.
- Decide which domains require ownership and which require collaboration. There is no universal maximum number: the scope, support and depth of each responsibility matter.
Edits that would change this call
Name the primary architecture domain in the brief and treat the others as collaboration scope.
List the named owners of the domains this seat will not own.
Move responsibilities outside the primary remit to named collaborating owners, where the organisation supports that boundary.
What to test for in early screens
- Ask for a recent design decision in the candidate's weakest declared domain.
- Probe the seam between two domains, rather than depth in one.
- Listen for who the candidate has said no to in previous seats, not only what they have said yes to.
The brief picks one of three things to be: senior IC architect, lead architect with delivery responsibility, or head of security with an architect title. It defines the reporting line, the team it owns or doesn't own, and the budget authority. The salary band reflects that choice.
Section 05
Supporting context
What this seat really is
The shape of the work the hire actually carries.The work this seat mostly is
Generalist principal who can pattern-match credibly across domains
The work this seat also carries
Deep specialist in one domain with working knowledge of the others
What this seat isn't, despite the title
Four senior architects compressed into a single salary band
Where the strongest candidates actually sit
Backgrounds that tend to produce people who can do this workPrincipal security engineer with cross-team design experience
Already does the architecture work informally, usually inside the function that owns the engineering decisions. The architect title formalises an existing position rather than asking the seat to earn one from outside.
Cloud or platform staff engineer with strong security instincts
Sits inside the engineering function whose decisions the architect is meant to influence. Brings the credibility that lets standards land rather than being routed around.
Consulting security architect from a delivery-heavy practice
Has lived through influencing engineering decisions without formal authority over the teams making them. Tends to be sharper than expected on the political shape of the seat.
Domain architect (cloud, identity or data) ready to broaden
Has owned the depth in one architecture domain and is ready to take pattern responsibility across more. Brings real production scars rather than framework fluency.
Built on TechWaymark's practitioner-authored assessment framework.
Section 06
Draft for hiring-manager reviewSenior Security Architect
Proposed remit: lead design decisions in one agreed primary domain, working with named owners in adjacent domains. Assess candidates on decisions they can explain and outcomes they helped deliver, whether their experience comes from an internal team or a delivery-focused consultancy. The primary domain and authority need hiring-manager confirmation before this draft is published. The band is £110,000 to £125,000, 2 days per week in office.
Proposed responsibilities
- Document design options, constraints and trade-offs for the agreed primary architecture domain.
- Review high-risk changes with engineering owners and record the decision, implementation owner and review trigger.
- Work with adjacent domain specialists; escalate decisions outside the agreed remit rather than implying ownership of every domain.
Relevant experience to discuss
- Principal security engineer with cross-team design experience. Already does the architecture work informally, usually inside the function that owns the engineering decisions. The architect title formalises an existing position rather than asking the seat to earn one from outside.
- Cloud or platform staff engineer with strong security instincts. Sits inside the engineering function whose decisions the architect is meant to influence. Brings the credibility that lets standards land rather than being routed around.
- Consulting security architect from a delivery-heavy practice. Has lived through influencing engineering decisions without formal authority over the teams making them. Tends to be sharper than expected on the political shape of the seat.
- Closest profile match: Generalist principal who can pattern-match credibly across domains.
Confirm before publishing
- Confirm the reporting line, decision authority and which responsibilities belong to other teams before publication.
- Confirm whether this is an individual contributor or a management role; do not imply funded headcount that has not been agreed.
- Confirm whether on-call is required and publish the working pattern and support arrangements.
What changes vs the original brief
- · Name the primary architecture domain in the brief and treat the others as collaboration scope.
- · List the named owners of the domains this seat will not own.
- · Move responsibilities outside the primary remit to named collaborating owners, where the organisation supports that boundary.