The Problem

Production deployments were causing unpredictable weekly incident spikes, with volume ranging from 7 to 12 incidents per week. This put sustained strain on on-call teams and made operational load difficult to plan around.

My Approach

Redesigned the change management process for production deployments, introducing a formal go/no-go review gate ahead of every release. Paired this with broader SRE process changes covering release readiness, rollback planning, and pre-deployment risk review, governed through Change Advisory Board (CAB) participation.

The Problem

Several large outages that took down the entire company traced back to deployments made during operational hours, disrupting the business while it was actively running.

My Approach

Conducted objective, unbiased root cause analysis across these outages, consistently identifying daytime deployment timing, not any single team’s execution, as the common factor driving business-hours outages.

Outcome

My findings led leadership to institute a company-wide policy against daytime deployments, shifting release timing to reduce the business’s exposure to deployment-caused outages during operational hours.

The Problem

Two technology teams needed adequate access to QA and developers for testing after major changes, which wasn’t guaranteed unless it was specifically raised before the change went through.

My Approach

Attended Change Advisory Board (CAB) meetings and asked the right questions about changes I knew would have a major effect on our systems, ensuring the two teams had the QA and developer access they needed for testing built into the plan ahead of time.

Outcome

Ensured testing access was in place before major changes went through, rather than teams discovering a gap in access after the change had already landed.

The Problem

Documentation lagged behind engineering and operational needs, slowing onboarding, incident response, and audit readiness across a distributed onshore and offshore Technical Writing team.

My Approach

Introduced AI-assisted authoring workflows using GitHub Copilot and Writer.com, restructuring how content moved from first draft to publish, and standardizing style and content across the team supporting 28 SaaS products.

The Problem

One of the tools my team relied on switched to a token-based pricing model, meaning our actual usage would now directly determine the value we were getting from the tool.

My Approach

Quickly asked the team to use the new tool as much as possible so we could gauge real token usage patterns and determine whether we were getting the best value for our tokens under the new pricing model.

Outcome

Gave leadership real usage data to evaluate the tool’s value under the new pricing structure, rather than making that assessment on assumptions about how the team would use it.

The Problem

My editor was spending manual time tracking which documentation had been published and which was due for updates, pulling that information from tasks on our sprint board by hand.

My Approach

Implemented a Power Automate flow that collected information directly from tasks on our sprint board and populated a list showing when documentation was published and when it would next need to be updated.

Outcome

Reduced my editor’s manual workload by automating status tracking that previously had to be assembled by hand.

The Problem

My team handled recurring cases where someone posed as a known, trusted contact in an attempt to gain unwarranted access or trust. These incidents needed a fast, defensible way to assess credibility before involving Legal.

My Approach

Directed my team to triage each case by verifying whether the impersonated contact’s information actually matched a real, existing relationship in our systems, for example, confirming whether the named individual had genuinely worked with the business before. Cases that passed initial verification were escalated to Legal with supporting findings; cases that didn’t were resolved at the team level.

Outcome

Gave the team a consistent, repeatable process for assessing credibility before escalation, so Legal received cases with verification work already done rather than raw, unqualified reports.

The Problem

When our OAuth vendor experienced an outage, it created IAM issues that affected user access across the business, tied to a dependency we didn’t directly control.

My Approach

Confirmed the issue was widespread rather than isolated to individual or QA accounts, then worked the IAM impact directly, coordinating on the vendor-side dependency rather than treating it as an internal authentication bug.

Outcome

Kept the response focused on the correct root cause, the vendor outage, rather than losing time investigating our own IAM configuration for a problem that originated externally.

The Problem

Domain changes periodically caused login issues for users across the business, breaking authentication for reasons tied to the domain change itself rather than the login system.

My Approach

Verified the login failures were tied to the domain change and were affecting users broadly, not isolated one-off or QA account issues, before escalating to engineering to resolve the underlying configuration.

Outcome

Reduced wasted escalations by confirming scope and root cause before engineering involvement, so engineering time went toward genuine domain-change fallout rather than individual account troubleshooting.

The Problem

A recurring incident type involved information mismatches where data was pulling from a different database than expected, producing inconsistent or conflicting records for the same record or transaction.

My Approach

Directed my team’s investigation process to trace mismatches back to their source, identifying which database was supposed to be the source of truth versus which one the system was actually pulling from, and coordinated with Engineering to correct the routing or sync issue causing the discrepancy.

Outcome

Reduced ambiguity in diagnosing data mismatch incidents by giving the team a consistent starting point: confirm the intended source of truth first, before investigating further.

The Problem

Automated detection would periodically fail to flag impersonation attempts because the system’s criteria hadn’t been configured for a new type of persona being impersonated, allowing cases to slip past automation and requiring manual investigation to determine credibility.

My Approach

Had the triage team manually investigate cases that automation missed, then fed those findings back into refining the detection criteria, closing the specific gap that had let each new persona type slip through, rather than only resolving the individual case.

Outcome

Turned each missed detection into an improvement to the underlying automation criteria, narrowing the gap between what automation caught and what required manual investigation over time.

The Problem

Working across a microservices architecture, my team dealt with bi-sync issues where a service that was supposed to pull data from another service would stop doing so, returning a null value instead, typically caused by a recent deployment or system upgrade.

My Approach

Directed the team’s diagnostic process to start by correlating the failure against recent deployment and upgrade history, rather than treating each null-data incident as an isolated mystery, then coordinated with Engineering on the fix.

Outcome

Shortened time-to-diagnosis on sync failures by making recent deployment history the first place the team looked, instead of the last.

The Problem

Recurring 504 errors were often traced back to vendor mishaps, specifically vendors deploying updates without notifying our team, leaving us unprepared and resulting in broken workflows.

My Approach

Worked closely with the Cloud Architecture team to decipher the cause of each 504 error, tracing failures back to their source and identifying whether a vendor-side deployment was responsible.

Outcome

Improved the team’s ability to correctly attribute 504 errors to vendor-side changes, rather than assuming an internal cause and losing time investigating the wrong system.

The Problem

Sites went down when the Networking team’s workflow mapping missed dependencies, meaning a change in one area had downstream effects that hadn’t been accounted for.

My Approach

Worked with the Networking team on incidents caused by these missed dependencies, helping identify the gaps in the existing workflow maps that had allowed the outage to happen.

Outcome

Contributed to more complete workflow mapping, reducing the risk of the same class of dependency gap causing future outages.

The Problem

The entire company went down during the Cloudflare incident, and again a few weeks later during the Microsoft incident. Neither outage originated inside our own systems, but both took the company down because we didn’t have full visibility into which of our systems depended on those third parties.

My Approach

After the second outage, decided to map all dependencies we could identify across the company, so we would know in advance what would go down if a large third-party outage of that kind happened again.

Outcome

Gave the organization a clearer picture of third-party dependency risk, moving from discovering the impact of a major outage after the fact to knowing it ahead of time.