By Ryon Riley, Director of Engineering
For the better part of the last four years, the way my team made changes to a client’s environment looked like this: open a browser, log in to a console, click through a few menus, save, and move on. Then do it again in the next client’s tenant. And the next.
There is a name for this now. People in our world have started calling it ClickOps. It is exactly what it sounds like. You manage infrastructure by clicking through a graphical user interface, by hand, one screen at a time. For a long time, it was simply how Mac/PC and identity management were handled, and for a handful of environments, it works fine.
We are not a handful of environments anymore.
The problem with clicking.
Here is what nobody tells you about managing dozens of environments by hand.
First, you lose track. When every change is a manual click, there is no clean record of who changed what, when, or why. We lean on changelog notes and Jira tickets to reconstruct history, but the environment itself quietly becomes the only real source of truth, and it drifts away from what you assume it is. There is even a term for that: configuration drift.
Second, you lose time. A change that needs to land across many clients has to be repeated, tenant by tenant. Every one of those repetitions is engineering time that could have gone toward something that actually moves a client forward.
Third, you lose your evenings to firefighting. When a manual change has an unintended effect, there is no clean undo. Someone has to go back in and reverse it by hand, usually while tickets stack up at the service desk. More time triaging, less time building.
A version of this plays out more often than I would like. A client contact with just enough access and knowledge to change something in Okta, Jamf, or Intune. It breaks things for a chunk of their users. Tickets are starting to flow to our service desk. And the first questions we have to answer are the hardest ones: what changed, when, and how fast can we put it back? With ClickOps, those answers are not a click away. They are an investigation.
Treating infrastructure like code.
The fix is a discipline borrowed from software engineering, and it carries a slightly intimidating name: Infrastructure as Code, usually shortened to IaC.
The idea is straightforward. Instead of clicking through a console to configure a system, you describe what that system should look like in a text file. That description lives in version control, just like software does. When you want to make a change, you update the file, and an automated pipeline reviews, tests, and deploys it. The industry name for that pipeline is CI/CD.
That single shift addresses all three problems at once. Every change is recorded, reviewed, and attributable, because the file is the source of truth and its history shows exactly who changed what and when. A change can be written once and pushed to multiple client environments simultaneously, with built-in testing before anything reaches production. And when a change misbehaves, we roll back to the previously known-good state instead of manually reversing clicks.
It is, in short, change management that enforces itself.
What this actually means for the people we work for.
All of this can sound like internal plumbing, so let me put it in terms that matter to a client.
Faster onboarding. A lot of our projects involve standing up brand-new infrastructure: a fresh Jamf Pro instance, an Okta tenant, an Intune environment. Done by hand, that is hours of careful configuration. Described as code and run through automation, the same buildout can go from nothing to fully configured in minutes. That frees our engineers to focus on the parts that genuinely need a human touch, like testing enrollments, validating results, and getting the client live sooner.
Fewer surprises, faster recovery. Tested changes and a reliable rollback path mean fewer self-inflicted outages, and far shorter ones when something does slip through.
A real audit trail. We operate in a SOC 2-compliant environment, and so do many of our clients. Being able to show exactly what changed, when, by whom, and through what approval is not just convenient. It is the kind of evidence auditors and security teams actually ask for.
Consistency across the board. When we improve how we do something, that improvement can roll out everywhere at once, instead of slowly and unevenly as engineers get to it, tenant by tenant.
We are early, and we are saying so on purpose.
I want to be honest about where we are, because the honesty is part of the point. We are early in this. We are building it deliberately, one platform at a time, starting with our identity layer in Okta and moving into Jamf Pro from there, with automated drift detection so the code and the live environment never quietly disagree.
The longer-term picture is bigger than deployment alone. Picture an engineer typing a command in Slack and getting back device details from our MDM, user details from our identity provider, or the change history behind a ticket, without logging into anything. Picture macOS updates flowing automatically from Apple’s release feed (or SOFA) out to every managed fleet, tested and enforced, as soon as they are vetted. That is the direction. We are walking toward it in phases, rather than promising it all at once.
Where I have landed.
Here is the through line. ClickOps got us to where we are. It will not get us to where we are going. The market we serve is growing, the environments keep getting more complex, and our clients are trusting us with more. You cannot hand-click your way through that and hold the quality bar where it needs to be.
So we are treating infrastructure the way software teams have treated code for years: written down, version-controlled, tested, and automated. It is more work up front. It is a genuinely different way of thinking for a systems team. And it is, I am convinced, the only way to scale without trading away reliability.
If you run IT for a growing company and any of this sounds familiar – the clicking, the drift, the late-night firefighting – I would welcome the conversation. I think it is the one our industry should be having.
