Operational maturity at a lean size

It is Wednesday, and Dana is out sick. Dana is the person who knows how the new hire gets set up: which groups, which apps, the one approval that has to come before the rest, the step that everyone forgets and then spends an hour undoing. None of this is written down anywhere a colleague can find it. It is in Dana's head, and Dana's head is at home with a fever.

So the rest of the team improvises. Someone provisions the new hire by copying an existing account, which quietly grants three things the new person should not have. Someone else skips the approval because they cannot remember whether it was required. The new hire is mostly working by lunch, and it mostly looks fine, and that is the problem. It looks fine right up until an access review six months later asks why a junior analyst can see payroll.

This is what a small company usually means by operational maturity: the hope that the people who know things stay healthy, stay employed, and stay reachable. The instinct, once this scares you enough, is to write everything down in exhaustive detail and call it a process. That instinct produces a binder nobody opens. Maturity is real, and a small team can have it.

The word maturity gets confused with the volume of documentation a company has produced. A two-hundred-page operations manual feels mature. It is usually the opposite: a sign that the work is so tangled it needs two hundred pages to describe, and a guarantee that none of it is current, because nobody has time to maintain two hundred pages.

A useful definition is narrower. An operation is mature when it produces the same correct result regardless of who runs it or whether the usual person is available. That is it. The test is whether the work survives an absence.

By that definition, most small teams are mature at exactly the things they do constantly and immature at the things that matter most when they go wrong. You can reset a password in your sleep. You probably cannot say, without checking, who would revoke a departing engineer's access on a Friday afternoon if the one person who handles offboarding were on a plane. The fragile operations are the rare, high-stakes ones, and those are the ones worth making boring and repeatable first.

Document the handful of operations where improvisation is expensive, and leave the rest to judgment. For most small companies, that short list is recognizable:

• Joiner and leaver access. When someone starts, accounts and group membership should provision from their role, not from a copied colleague. When someone leaves, access should revoke on the effective date whether or not the usual person is watching. Microsoft Entra ID can provision and deprovision accounts in connected apps automatically (Microsoft Entra documentation on automated user provisioning), and its Lifecycle Workflows automate joiner, mover, and leaver tasks with a Microsoft Entra ID Governance or Entra Suite license (Microsoft on Lifecycle Workflows).
• Access changes and approvals. Who can grant what, who signs off, and where that decision is recorded. The record falls out of running the approval through one place rather than a hallway conversation, so it costs no extra work.
• Security findings. Tools like Amazon GuardDuty and Microsoft Defender generate findings around the clock. Having the tool on is the easy half; a mature operation is a named, repeatable path for who reads a finding and what happens next.

Three or four operations like these, made repeatable, move a small company further than a full manual nobody maintains. The rest of the work can stay informal, because the rest of the work is cheap to get wrong.

Writing operations down as a separate project, after the fact, is the thing that drowns small teams, and it is also the thing that goes stale fastest. The way out is to stop treating documentation as a deliverable and start treating it as a byproduct.

When a joiner is provisioned through a defined flow, not a copied account, the flow itself is the documentation: anyone can read what it does. When an access approval runs through one place, the approval and its record are the same act. When a security finding follows a known path, the path leaves a trail of who saw it and what they did. The documentation is produced rather than written, every time the operation runs, because the operation was designed to run that way.

Security is an operational problem before it is a tool problem. What a small team lacks is the few well-run operations that turn scattered knowledge into something repeatable, and the time to keep them running.

This is where running an environment differs from advising on one. A document describing how offboarding should work is a recommendation. An offboarding flow that revokes access on the right day, and records that it did, is an operation. The second one survives Dana being out. Where we fit is running that layer so the operations stay repeatable without a binder. Where we do not fit is replacing the judgment calls that should stay with your team; if your hard problems are mostly novel decisions and not repeatable work, lighter process, not a partner, is the honest answer.

Go back to Dana, home with a fever. In a mature operation, the new hire still gets set up correctly, because provisioning runs from the role and not from Dana's memory. The required approval still happens, because it is built into the path. The junior analyst never gets payroll access, because the operation that would have granted it by accident does not exist anymore.

Maturity, at a small company, looks like an ordinary Wednesday that stays ordinary when the person who usually carries it is gone. The work runs. The record writes itself. Nobody is improvising under pressure on a Friday afternoon.

The honest question is narrower and more uncomfortable than how much process to add: which of your operations would simply stop if one specific person did not come in tomorrow?