The domains inside a single engineering role, coding, testing, infrastructure, observability, security, and increasingly AI orchestration, are converging faster than headcount is shrinking. The open question for hiring is whether that combined role is still something one person can be hired for and sustain.
Is AI shrinking your engineering team, or redefining what each role covers?
For most hiring managers, it’s the second: roles are broadening faster than teams are shrinking.
Across a lot of organisations, tooling, platform engineering and automation have made individual engineers more capable, and the same number of people are increasingly being asked to own a wider slice of the system.
Coding, testing, infrastructure, observability and security, which used to sit with different specialists or at least different areas of focus, are converging onto fewer heads. That convergence changes what a job description needs to say and what a team structure needs to support.
A role that used to be “backend engineer” might now implicitly include infrastructure awareness, security judgement and the ability to direct AI tools across several of those domains at once.
If the job ad hasn’t caught up to that reality, you risk two outcomes. You either hire someone underprepared for the actual scope of the role, or you lose a strong candidate who senses the scope creep and applies somewhere clearer about what the job involves.
How do you decide what one engineer should realistically own?
Beyond auditing one role before you add to it, these habits help once convergence is already shaping how the team works.
- Map domain coverage across the team. List coding, testing, infrastructure, observability, security and AI orchestration against each role, and note who covers each one day to day. A gap means a domain is being neglected; an overlap on one person means risk is concentrated there.
- Separate the headcount conversation from the scope conversation. “Can we run this with one fewer person” and “has this role expanded beyond what one person can reasonably cover” are different questions. Conflating them tends to produce decisions that look efficient on a spreadsheet but aren’t sustainable on the ground.
- Pilot broader roles with your most experienced people first. Someone with deep context across a system can often absorb breadth that a newer engineer, still building fluency in any one domain, cannot.
- Check in on the load as well as the output. A broader role can look like it’s working because things are still shipping, while the person carrying it is one more responsibility away from burning out or leaving. Ask directly in one-on-ones whether the scope feels sustainable.
- Revisit role definitions every time a role is backfilled. A role that has absorbed three extra domains since it was last advertised needs a rewritten brief, not the old one copied across.
What should you look for in a candidate who can own a broader role?
On a CV, look for genuine breadth across the domains that matter for the role, beyond a long list of tools.
Someone who has owned a service end to end, from code through to the infrastructure it runs on and the security considerations around it, is showing real convergence experience. That’s different from someone who has brushed against each area briefly on separate projects.
Where candidates have public code, a portfolio or GitHub history that shows the same breadth, commits touching infrastructure or security as well as application code, is a stronger signal than a CV claim on its own.
In an interview, ask:
- “Describe everything you were responsible for in your last role.” Compare the answer against what your job ad lists; a mismatch either way is worth discussing before an offer goes out.
- “How do you decide what to prioritise when two domains, say a security issue and an infrastructure problem, compete for your attention at the same time?” The answer shows whether they can function across breadth or default to whichever area they’re most comfortable in.
- “If the team grew by one person, what part of this role would you want to hand off first?” A thoughtful answer suggests someone who understands their own limits.
- “Has a previous role ever grown beyond what you felt you could do well? What happened next?” How they describe that moment, and whether they raised it, says a lot about what will happen on your team.
When does combining engineering responsibilities stop working?
Broader roles work well in some contexts, including smaller organisations, early-stage products, and teams where the domains in question are naturally related. Coding and testing, for instance, sit close enough together that combining them is often a sound decision rather than a stretch.
But breadth has a ceiling, and it’s not the same ceiling for every person or every combination of domains.
Security and deep infrastructure work, in particular, often need the kind of sustained focus that’s hard to maintain alongside four other responsibilities, no matter how capable the individual engineer is.
Not every efficiency gained by converging roles is real either. If a smaller team with broader roles is shipping the same output but with more incidents, more burnout, or more single points of failure, the saving on paper is being paid for somewhere else.
That cost often surfaces later than the headcount decision does, in a resignation that catches you off guard, a slow recovery from an incident because only one person understood the whole system, or small quality slips that are hard to trace back to the restructure that caused them.
It’s worth finding out where before calling the change a win.
Ready to talk about your next engineering hire? Get in touch.
Liam
Technology & Software Engineering Recruitment
Last updated: October 2026
