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 to investigate if the brief stays unchanged
The shortlist may favour broad vocabulary over demonstrated depth if the screen only checks named domains.
Some specialists may hesitate if it is unclear which domains require deep ownership. Check this against candidate feedback rather than assuming why someone did not apply.
Compare screening criteria with working-session feedback. A mismatch may indicate that the brief rewards breadth of terminology over the required depth.
If interview feedback repeatedly finds different domain gaps, revisit the remit before repeating the same search.
Why candidates disengage
A specialist may question whether the team provides support outside their primary domain. Ask which responsibilities or support gaps concern them.
A broader candidate may want clarity about the balance of design, delivery and leadership work.
If candidates raise concerns about the remit, record their stated reasons and test these possibilities against that feedback. The brief alone cannot establish their motivations.
Signals to check 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.
- Ask for one identity decision they owned end to end, including what they ruled out. This is the domain the brief leans on hardest; the others (detection) can be tested for working knowledge rather than depth.
- Ask what they changed in Splunk and why, rather than whether they have used it. Comparable experience on another platform should count here.
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. On this brief that means the person holding it can point to work they owned in identity and detection, with splunk and sentinel as the environment rather than the qualification.
The brief carries 3 areas that are each normally somebody's whole job: identity, detection, strategy and board-facing work. Read together they leave the primary ownership of the seat unresolved, which is a scoping question rather than a question about how much the brief asks for. Candidates strong in one of these read the rest as work they would carry badly, and the ones who apply anyway tend to be the ones least able to say which part they would own. Screening then turns into a search for someone who has done all of it, and that person is rare enough that the shortlist stalls.
The brief does not settle these. We have not assumed an answer.
- Whether this is an individual contributor seat or a management seat. The brief currently reads as both.
- Which of these is the primary domain, and which are adjacent: identity, detection. The brief currently treats them as equal.
What would change our view
This diagnosis rests on what the brief says, not on how the market has responded to it. Interview and withdrawal data from this round would carry more weight than any of the signals we read (exec reporting, board reporting, or executive stakeholder management; strategy ownership bundled into an architect seat; team building and management bundled with architecture).
Confirmation that the leadership expectation is nominal rather than real, or that the band has been set against the leadership shape rather than the practitioner one.
A brief that names one primary domain and treats the others as adjacent. That single edit removes most of the friction described above.
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.
- The original advert also named identity, detection. Confirm which of these the seat owns outright, which it advises on and which belong to another team, before publication.
- splunk, sentinel, chronicle, terraform appeared in the original advert. State whether each is a requirement on day one or an environment the person will work in, rather than leaving it as an unweighted keyword.