How to Hire Your First Platform Engineer at a Series A SaaS

Your Engineers have started apologising for the deploy process. Someone built the CI pipeline in a fortnight eighteen months ago and nobody has touched it since, staging broke again on Tuesday, and the only person who really understands the Terraform is also your strongest Product Engineer.

That is usually the moment a Founder starts typing “Platform Engineer” into a job board. It is the right instinct, and it is still too early to write the advert, because this hire only works if you have decided what the person is actually there to do.

The signal that says go, and the one that says wait

The honest test is not how much infrastructure you have. It is how much of your engineering team’s week is going into work that nobody chose.

Count it. If two or three engineers are each losing a day a week to builds, environments, access requests, on-call noise and “can you just deploy this for me”, you are already paying for a platform engineer. You are just paying for them in product velocity, spread across people who would rather be doing something else.

What says wait? A team of five or six where one person genuinely enjoys the infrastructure and it takes them a few hours a week. Hiring ahead of that creates a role with no real demand attached to it, and the person you hire will invent work to justify the seat. Usually that means a migration nobody asked for.

The titles are not the job

Platform engineer, DevOps engineer, SRE, infrastructure engineer. Four adverts, four different applicant pools, and at a Series A they often describe the same first hire.

Worth being clear with yourself before you pick one:

• DevOps engineer pulls candidates who expect pipelines, tooling and cloud config. Broad, practical, sometimes light on software engineering depth.
• SRE signals reliability engineering, error budgets and a level of operational maturity you probably do not have yet. Advertise it before you are ready and you will interview people who ask questions you cannot answer.
• Platform engineer implies you are building something your own developers use. That is usually the truest description of the job at this stage.
• Infrastructure engineer reads as cloud and networking first, developer experience second.

Pick the title that matches the first six months, not the org chart you hope to have in two years. You can rename the role later. You cannot un-hire someone who joined expecting a different job.

Write the role around what breaks first

The strongest briefs we take are not lists of tools. They are lists of problems.

Something like: our deploys take forty minutes and fail one time in five, we have no staging environment anyone trusts, engineers wait two days for a database they can test against, and nobody can answer why the bill went up last month. Those four sentences will get you a better shortlist than any stack list, because good platform engineers read them and immediately start thinking about how they would fix it.

The stack matters less than founders expect. Someone who has built developer tooling on AWS will be productive on GCP inside a month. Someone who has only ever maintained infrastructure that someone else designed will struggle on any cloud.

What to screen for

Four things carry most of the signal at this stage.

Do they think of engineers as customers? The whole point of the role is that other people’s work gets easier. Ask what they built that their team actually adopted, and what they built that got ignored. Anyone honest has an example of the second.

Have they made something simpler? Series A infrastructure has a way of accumulating cleverness. The strongest candidates talk about deleting things, consolidating environments and reducing the number of ways to deploy. The weaker ones describe architecture that would need a second platform engineer to run.

Can they carry a decision they disagree with? They will inherit choices made under pressure by people who were shipping features instead of building platforms. The right person is pragmatic about that. The wrong one wants to rewrite it in the first quarter.

Cost instinct. Anyone who has run infrastructure at any scale has a story about a bill. If they have never thought about what their choices cost, they have not owned the outcome.

The interview worth running

Skip the systems design whiteboard. At this stage it tells you very little.

Instead, walk them through your actual setup for thirty minutes. The messy version, not the tidy one. Then ask a simple question: what would you do in your first ninety days, and what would you deliberately leave alone?

The answers separate people quickly. Strong candidates ask about your team before they propose anything, want to know who deploys and how often, and are comfortable saying “I would not touch that yet”. Weaker candidates arrive at a target architecture before they have understood the constraints.

It also respects their time, which matters in a market where good platform engineers are choosing between offers rather than chasing them.

The mistake that costs you the hire

Hiring the person, then giving them no authority.

A first platform engineer who has to negotiate every change with the engineer who originally built it will spend six months being politely blocked and then leave. Before they start, decide who owns the deploy pipeline, who owns cloud spend, and who has the final say on tooling. If the answer is still “we will work it out”, you are not ready to make the hire.

One last thing

Go back to the moment your engineers started apologising for the deploy process. That is not really an infrastructure problem. It is a signal that your team has outgrown the way it was working, and the fix is a deliberate decision about who owns that layer, made before the advert goes out.

Get that decision right and the first platform engineer is one of the highest-leverage hires a Series A ever makes.