Deployments are slow, developers repeat infrastructure work and senior engineers spend their mornings unblocking access. These are reasons to investigate platform needs, but they do not automatically justify a new hire. Start by understanding the work that is consuming time and whether a dedicated owner can improve it sustainably.
Map repeated friction
Collect concrete examples from the product teams: setting up environments, releasing changes, diagnosing failures or obtaining usable data. Record who does the work, why it recurs and what happens when it is delayed. Avoid beginning with a preferred platform tool and searching for problems to justify it.
Google’s SRE guidance discusses eliminating repetitive operational toil. That is a useful lens for your investigation, not a staffing formula: your organisation still needs to decide which problems deserve dedicated engineering capacity.
Identify the internal customer
A platform engineer needs people to serve. Name the teams, their workflows and the outcomes that would make their work easier. “Build a platform” is too broad. “Provide a dependable path for service teams to test and release changes” is a more useful conversation.
Talk to those teams before deciding the solution. A new self-service interface will not help much if the underlying approval process remains unclear. Sometimes documentation, ownership or a small change to an existing system is the right first step.
Check that the role has room to succeed
Will the engineer have authority to improve shared infrastructure? Who owns reliability and incident response? Can product teams adopt the changes, and who will prioritise competing requests? Without those answers, the new hire can become a permanent queue of unrelated support tickets.
Be explicit about operational duties. If on-call work is part of the role, explain its scope and support arrangements. Do not advertise a platform-building role while quietly expecting one person to absorb every infrastructure problem.
Assess product thinking as well as technical depth
Give candidates a collection of hypothetical developer complaints. Ask how they would investigate the problems, choose a first improvement and learn whether it worked. Look for prioritisation, a manageable scope and a willingness to talk to users.
Explore a past change they introduced to a shared system. How did they handle migration, documentation and ongoing ownership? A sound technical design still needs an adoption path.
Further reading: Google SRE: Eliminating Toil and Mind the platform execution gap. The hiring framework here is an editorial recommendation, not a headcount rule from either source.