The First Hire Is the Expensive One

I was called a bottleneck and asked to hire urgently in the same week.

Both came from the same leadership team, and both were, in their own way, correct. At a security company I work with, I lead the platform and security layer: cloud, SRE, NOC, IT operations, the works. The team is small enough that “the team” is mostly a polite way of saying “me.” When you are the platform, every access request, every deploy approval, every incident flows through you. From the outside, that looks like a bottleneck. From the inside, it feels like ownership. The uncomfortable truth is that it is both.

So leadership did the reasonable thing: they pushed me to hire an SRE. Immediately.

And I did the thing that surprised them: I pushed back. Not on the hire, on the immediately.

Table of contents

The short version

• A lean, high-trust platform team is different: the blast radius of a bad hire is the whole company, not a sprint.
• When your IAM is immature, trust quietly becomes your real access control. That is a bus factor, not a security model.
• The first hire is the most expensive: you vet, mentor and review alone. Every hire after gets cheaper.
• Your access model is only as strong as your tooling tier. Free tiers assume trust, and least privilege is often a paid feature.
• Access should not be “earned” by one person’s judgment. Scope it by role, gate it by milestones, and audit it, including yourself.

The trap of lean, high-ownership teams

There is a category of team that every scaling company has and almost no one designs deliberately: small, senior-heavy, holding the keys to everything. Platform teams. Security teams. The two-person group that owns the cloud account, the identity provider, the CI/CD credentials, and the DNS.

These teams have a property that makes them fundamentally different from a product squad: the blast radius of a bad hire is not a sprint. It is the company. A mediocre backend developer costs you some velocity and a few code reviews. A mediocre, or worse, a malicious, platform engineer with production access costs you an incident, an audit finding, or a headline.

Everyone nods at this in the abstract. The uncomfortable consequence: the standard hiring playbook does not work here. You cannot onboard a platform engineer the way you onboard a developer, hand over a repo, point at the backlog, and let them ship. Day one for this role traditionally means credentials. And credentials are exactly the thing you cannot hand to someone you met three weeks ago in an interview loop.

The confession: trust was my access control

Here is the part I would rather skip, and the reason this post exists.

The honest answer to “why can’t you just apply least privilege and onboard them safely?” was uncomfortable but ordinary: the IAM had not been hardened yet. Security is real work and real cost, and under delivery pressure it is usually the first thing deferred, which is how IAM ends up growing organically, with broad roles created during incidents and never narrowed afterward. It was functional, and we were steadily fixing it. But at that moment, the real access control protecting production was not a policy engine.

It was me knowing exactly who had access to what, because the list was short enough to fit in my head.

That is not a security model. That is a bus factor wearing a security model’s clothes. That is why I hesitated. Not because I did not want help. Because I knew what “help” would be plugged into.

I used to compress all of this into a phrase I was fond of: access is not granted, it is earned. I still believe the instinct behind it. But I have had to unlearn the phrase. More on that below.

The bootstrap problem

There is a second structural issue that leadership rarely sees: in a high-trust team, the first hire is the most expensive one, and every subsequent hire gets cheaper.

The first person, you vet alone. You mentor alone. You review every change alone, while still running everything you were running before. There is no second opinion on whether they are ready for the next level of access, because you are the second opinion. It is a trust bootstrap problem: trust is built through supervised work, and supervision capacity is exactly what a one-person platform team does not have.

But once that first engineer is ramped and holding real ownership, the economics flip. Hire number two gets mentored by two people. Vetting becomes a conversation instead of a solo judgment call. The ramp that took months for the first hire takes weeks for the third. This is why “hire three people this quarter” is the wrong ask for a team like this, and “hire one senior person now, then scale” is the right one, not because of budget, but because of trust throughput.

Two practical corollaries. First: for that critical first hire, your professional network is a legitimate shortcut. Someone you have worked with before arrives with trust pre-built by history, months of ramp-up you do not have to fund. Second: hire senior. A senior engineer needs context, not supervision, and context is the one thing you can give while drowning.

The plan that almost worked

My answer to the access problem was, I thought, elegant: let the pipeline hold the credentials.

Our infrastructure is fully Terraform, GitOps-driven. So the ramp-up design was straightforward: the new engineer delivers value from week one without any direct access at all. They write infrastructure code, open a pull request, the pipeline runs the plan, I review, and the merge triggers the apply. The pipeline has the credentials, the person has a Git account. The trust boundary moves from the cloud console to branch protection, which is free, granular, and audited by default. Direct access comes later, in stages, for incident response only.

Contribution is not credentials. Someone can deliver real value long before they should hold the keys, and treating the two as the same thing is what makes this hire feel impossible.

Deliver from day one, hold credentials from day ninety. Separate contributing from having access. I was genuinely pleased with this.

Then I looked at our Terraform Cloud plan.

Like a lot of small teams, we were on the free tier. And on the free tier, there is no granular RBAC: no scoped teams, no per-workspace permissions. Giving the new engineer a seat at the table meant giving them, effectively, admin. The entire graduated-access model I had designed collapsed into a binary: admin or nothing.

I would love to tell you this was an exotic edge case. It is not.

Free tiers are optimized for individuals and tiny teams that run on, you guessed it, implicit trust. The moment you try to engineer trust instead of assuming it, you hit the paywall.

The fix was not abandoning the model. It was recognizing the constraint and choosing: keep contributors out of the tool entirely and anchor everything on the VCS workflow, self-host the PR-automation layer, or pay for the tier that matches your security posture. Any of the three works. What does not work is designing a beautiful ramp-up on a whiteboard without checking whether your tools can express it.

And if you need budget approval for that upgrade, you now have the cleanest business case in the company: “our current plan forces me to choose between blocking a hire you asked for and handing out admin access.” That sentence funds itself.

What I unlearned about “earned”

Back to my favorite phrase. “Access is not granted, it is earned” sounds principled, and the instinct is right: access should be demonstrated, not bundled with the badge. But said that way, it has two failure modes I only saw once I was on the receiving end of a bottleneck narrative.

First, it makes me the unit of measurement. Who decides what “earned” means? I do. Subjectively. Which means access to production is gated on one person’s personal comfort, and that is indistinguishable, from the outside, from a fiefdom. If you are already being called a bottleneck, “access is earned” translates to “access is granted to people I deem worthy,” and you have just confirmed the accusation.

Second, it points at the person when it should point at the system. In a mature setup, access is not a merit badge. It is a function of role, scoped to least privilege, logged, and revocable. The version I use now:

Access is not granted. It is scoped, audited, and expanded by milestones. Merit sets the speed. Engineering sets the blast radius.

Same instinct, different center of gravity. A milestone ramp says the same thing my old phrase did:

• Day 1: read-only, plus staging
• Day 30: infrastructure as code through reviewed pull requests
• Day 60: scoped production access
• Day 90: on-call, with elevated access

But it is a contract anyone can verify, instead of a feeling only I can have. And it protects one more person the old phrase never did: me. As long as access is a matter of personal trust, the person nobody audits is the one holding all of it. Mutual auditability is not distrust of your platform lead. It is what lets your platform lead take a vacation.

The translation for leadership

If you run a company with a lean platform or security team, here is the version of this post that fits in a hallway conversation.

When your platform lead hesitates on an urgent infra hire, you are probably not hearing resistance. You are hearing someone who knows exactly how unready the access layer is, and cannot say so in a status meeting. The productive response is not pressure, it is a question: “what has to be true for this hire to get access safely, and what is the date?” That turns a veto into a plan: IAM cleanup with a deadline, a milestone-based ramp, maybe a tooling upgrade with a number attached.

And the trade you are actually weighing is this: the cost of a bad platform hire is an incident. The cost of not hiring is that your entire cloud keeps a bus factor of one. Waiting is not the safe choice, it is just a quieter form of the same risk. Both are unacceptable, and the milestone ramp is the only option that shrinks both at once.

Final takeaway

The first hire is the expensive one. Pay for it properly, once, and every hire after gets cheaper.