When an organization’s growth outpaces its systems implementation capabilities for years, big problems are on the horizon.
I have been living in that gap.
My name is Patrick Rivers, and I currently serve as a Cloud & Systems Engineer for a full-service storage, logistics, and transportation enterprise. We operate as a multi-entity organization: several legal entities, multiple operating units, but one shared backbone for IT, HR, Finance, and other back-office functions.
I was initially hired as a Network Administrator with a fairly clear charter: design and implement a full-scale integrated enterprise network that would connect multiple sites across Mobile, AL, Pensacola, FL, and Houston, TX, as well as oversee our Oracle Cloud Infrastructure tenant network. That alone is a meaningful scope.
But once I settled into the role and started planning the basic network infrastructure, it became obvious that the real challenge was bigger than routing tables and VLANs. To support the pace of growth and the expectations of our customers, the organization needed a secure, coherent enterprise systems environment—not just a better network.
In short: we had to modernize while already in motion.
The Starting Point: Target-Rich Technical Debt
When I was onboarded, the leadership team had several core goals:
Deploy internal applications that were in development and testing.
Achieve CMMC Level 1 Self-Attestation, with a clear path toward CMMC Level 2.
Improve internal communication and collaboration.
Bring all systems up to a reasonable operational standard for a mid-sized enterprise.
On paper, that looks like a roadmap. In reality, it felt like a triage list.
Everywhere I looked, I found fragmentation: different departments and sister companies were using different tools, workflows, and platforms. Devices had been purchased ad hoc from consumer retailers. Collaboration happened across a mix of email, texts, and whatever tool a given team preferred.
The conclusion was obvious: we needed a more centralized way of doing business.
After evaluating our options, we decided that a migration to Microsoft 365 would give us the centralized communication, control, and workflow foundation we needed. We did the research, built assumptions around cost and timeline, secured buy-in, and got to work.
That is when another reality surfaced: device management was going to be our first real stress test.
The Device Problem Nobody Wanted
Going into the project, I assumed the device capture phase would be the hardest part.
Over the previous few years, the organization had experienced rapid growth. New hires were brought on quickly, and the priority was understandable: get people working as fast as possible. But as is often the case, systems and controls lagged behind.
By the time I arrived, nearly 100 laptops were already deployed in the field—unmanaged, running Windows 11 Home, and sourced from retail channels that didn’t prioritize business readiness.
That created a two-part problem:
Each of those machines needed to be upgraded from Windows 11 Home to Windows 11 Pro so they could be properly managed as business devices.
Every device had to be captured into our Microsoft 365 tenant using Autopilot, so that future resets, policies, and configurations could be standardized.
And there were two of us in IT.
Touching that many devices manually, in multiple locations, while trying to keep the business running, was a non-starter.
If we were going to hit project deadlines and minimize operational disruption, we needed a different approach.
Strategy: Turn Users Into Partners, Not Obstacles
The only realistic path forward was to involve end users directly in the device capture process.
That sounds risky on the surface—asking non-technical users to run scripts and upgrade their own machines—but the alternative was worse: delays, bottlenecks, and incomplete coverage.
The approach had two pillars:
To that end, I created two PowerShell-based workflows:
One script to upgrade a device from Windows 11 Home to Windows 11 Pro using the generic upgrade key.
A second, secure script to capture the device’s serial number and enroll it into Autopilot in our Microsoft 365 tenant.
I published these scripts as GitHub Gists and wrote corresponding execution commands that users could run directly from their devices. Those commands, along with the supporting documentation, were hosted on a secure internal SharePoint site accessible only to internal users.
The technical side—scripts, keys, tenant integration—was only half the battle. The other half was making sure people would actually run them successfully.
Script Design: Security in a User-Led Workflow
Distributing logic to non-technical users requires a different design mindset than typical internal automation.
I considered using batch scripts but decided against it. Traditional .bat files frequently collide with security controls, and they often require more complicated troubleshooting when something fails. PowerShell provided a more flexible and secure foundation.
To design the scripts, I combined prior experience with fresh research. At a previous organization, we ran a Gist-based Autopilot script on all new machines as part of our provisioning process, which gave me a pattern to work from.
However, this time I had to be even more deliberate about protecting sensitive information.
Because the scripts were exposed through GitHub Gists and general execution commands, I wanted to ensure no tenant IDs, secrets, or credentials were baked into anything users could see or copy.
To solve this, I used Azure Key Vault to store secrets and supply them securely to the scripts at runtime. I also leveraged large language models to help explore secure patterns for key retrieval and to stress-test the approach.
The end result: users could execute a controlled workflow, while the sensitive bits stayed confined to secure infrastructure.
User Experience: Designing for Failure Before It Happens
The second phase of the project was all about distribution and usability.
It is easy to treat internal documentation as an afterthought—a “how-to” page bolted on at the end of a project. That mindset almost guarantees friction, confusion, and support tickets.
I approached the guides the same way I approach system design: assume the failure points up front, then design a path that helps users avoid them.
For the written documentation, I leaned on SharePoint as the central hub:
It was already authenticated.
It was accessible to all internal users.
It provided a single, maintainable source of truth for instructions and links.
From there, I focused on reducing cognitive load:
Visually obvious design over text-heavy pages.
Large, clear “click here” images instead of buried hyperlinks.
Short action verbs and numbered steps that mirrored what users would see on their screens.
Each page had exactly one job.
Segmenting the flows this way meant users weren’t overwhelmed by a long, single “do everything” checklist. It also reduced the risk of someone skipping critical steps because they were scrolling too fast.
For users who preferred visual guidance, I recorded an unlisted video tutorial walking through both processes step-by-step. Between the written guides and the video, most users could choose the medium that suited them best.
But even with text and video, I knew some users would still be uncomfortable running upgrade and enrollment workflows on their own. So I implemented a structured safety net: an appointment-based support option built on top of Calendly.
I created dedicated Calendly event types specifically for “Device Upgrade & Autopilot Capture,” with defined time slots, buffer windows, and clear descriptions of what would happen during the session. Links to those booking pages were embedded directly into the SharePoint guides and included in all related communications, so the call-to-action was always the same: “If you’re not comfortable doing this yourself, click here to schedule time with IT.”
This allowed users to:
Choose a time that worked for them without back-and-forth scheduling.
Get either remote or onsite assistance, depending on their location and role.
Move forward without feeling forced into a self-service path they didn’t trust.
That safety net reduced anxiety, prevented stalled devices, and kept the project moving by ensuring “I’m not comfortable doing this” didn’t quietly turn into “I’m not going to do this.”
Communication: Repetition as a Feature, Not a Bug
The implementation path I chose would not have worked without an intentional, repetitive communication plan.
From the start, I treated communication as part of the architecture, not an afterthought. One email about a critical, multi-step process is basically a suggestion. A structured campaign is a system.
I built out a communication cadence that included:
An initial announcement email explaining the “why” behind the project, the impact on users, and the high-level steps.
Follow-up emails focused on a single call-to-action: either “run the script,” “watch the video,” or “schedule an appointment.”
Targeted reminders to groups that had not yet completed their device work, with clear deadlines and links back to SharePoint and Calendly.
Periodic “status update” messages reinforcing progress (“X% of devices completed”) and re-highlighting the same links and instructions.
The key was repetition with clarity. Every message pointed back to the same simple ingredients:
By reusing the same language, links, and expectations across a thorough email campaign, users always knew where to go and what to do next. It wasn’t glamorous, but it was consistent—and consistency is what made the system actually work in the real world.
Without that detailed and repetitive communication plan, even the best technical solution would have stalled out in pockets of inaction.
Lessons Learned: Small Teams, Big Leverage
This project reinforced a few themes that I keep returning to in my work.
Growth without systems equals operational debt.
The unmanaged devices weren’t just a technical nuisance. They represented exposure—security, compliance, support, and reliability all took a hit.
Standardization is a force multiplier.
Migrating to Microsoft 365 and onboarding devices into Autopilot established a long-term platform for consistency, instead of a patchwork of one-off fixes.
Automation without documentation and communication is just hidden complexity.
Scripts alone would not have delivered the outcome. It was the combination of automation, guides, an appointment-based safety net, and a deliberate email campaign that made the initiative sustainable.
Security and usability can coexist.
With tools like Azure Key Vault, Calendly, and careful script design, it is possible to keep secrets safe while still enabling users to run powerful workflows in ways that feel approachable.
Small IT teams can still drive large transformations.
With only two people in IT, we could have easily defaulted to low ambition. Instead, we treated constraints as a design requirement and built for leverage—through automation, self-service, scheduled support, and consistent communication.
Bits of Progress
The title of this blog—“Bits of Progress”—captures how I think about work like this.
Large-scale change rarely happens in a single, dramatic moment. It happens through a series of small, deliberate decisions:
Choosing to standardize devices rather than tolerate exceptions.
Choosing to centralize communication rather than let every team choose their own tools.
Choosing to empower users with both self-service paths and human support, instead of forcing one or the other.
Choosing to communicate clearly, repeatedly, and consistently until the new path becomes the obvious path.
In this project, the “bit of progress” was simple but powerful: take devices already deployed in production and bring them under a unified, secure, and manageable umbrella—without grinding day-to-day operations to a halt.
It wasn’t glamorous. It didn’t involve a flashy new product. But it materially improved how the organization operates.
Those are the kinds of wins I want to keep capturing and sharing here.
