Selected work · Non-proprietary case studies

Private code.
Visible thinking.

The source code belongs to the organizations where it was built. The problems, constraints, engineering decisions, and operational results are mine to explain.

Case study approach

REPEATABLE
01

Establish the operational context

02

Make the constraints visible

03

Explain the engineering decisions

04

Connect the work to its result

The work behind the work

Enterprise impact rarely comes with a public repository.

These stories focus on how I investigated systems, reduced risk, built repeatable automation, and made difficult operations easier to execute—without exposing proprietary code, credentials, or internal architecture.

Four systems made
more repeatable.

Context. Decisions.
Operational results.

01

Ansible · Enterprise patching

Cross-platform JDK upgrades through scheduled runbooks

~46%reduction in monthly vulnerability findings

Situation

M&T Bank patched thousands of virtual servers through monthly ServiceNow runbooks configured by individual application teams. My team owned Oracle JDK maintenance across both Windows and RHEL Linux hosts.

Approach

I built an Ansible playbook that detected installed JDK versions, downloaded the appropriate installer to a temporary directory, removed the existing JDK installation, and performed the upgrade. The workflow was validated in DEV and CERT/UAT before production promotion.

Result

The automation became an “Upgrade JDK version” Step Action that application teams could select in their scheduled runbooks. It standardized a cross-platform security task and reduced monthly vulnerability findings by approximately 46%.

02

PowerShell · Azure DevOps migration

Building the inventory behind a cloud migration

6 mo.activity threshold for archive review

Situation

A migration from Azure DevOps Server to Azure DevOps Services needed more than a list of projects. The program needed reliable ownership, contact, activity, repository, work-item, and platform identifiers before teams could be coordinated safely.

Approach

I developed a PowerShell inventory using Azure DevOps APIs and RSAT directory lookups. It collected team projects, Project Administrators and email addresses, recent Git commits, the five latest work items, project and repository URLs, and IDs needed by downstream scripts. Projects with no recent activity were flagged for archive review.

Result

The searchable, Excel-ready dataset stayed current as migration work progressed. It identified who to contact, distinguished active projects from archive candidates, and gave the team a practical way to track each project through completion.

03

PowerShell · Governance

Automating quarterly audit evidence

Quarterlyrepeatable evidence collection

Situation

Each quarterly audit requested the same set of platform data points. Gathering them manually meant repeating lookups, reconciling formats, and spending engineering time on evidence collection instead of platform work.

Approach

I wrote a PowerShell audit script that retrieved every required data point that could be collected programmatically. The remaining screenshot evidence stayed manual, while the underlying platform data followed one consistent retrieval process.

Result

The quarterly submission became faster, more consistent, and easier to reproduce. The script reduced repetitive collection work and created a dependable baseline for answering the same control questions over time.

04

Elasticsearch · API automation

Expanding a one-off request into an operational toolkit

24 → 72hthe retention change that started it

Situation

The initial request was to extend a Custom Logs integration from its 24-hour default to 72 hours. The expected approach was a manual edit, but similar changes were recurring across integrations, index templates, agents, and Logstash-driven configurations. Granular backups were also limited, making small mistakes expensive to diagnose and recover.

Approach

I created scripts that authenticated through environment variables rather than embedded secrets. The toolkit grew to update retention settings and index-template mappings, discover agent names and ports from Logstash pipelines, create the corresponding indexes and templates, and back up integration and agent configurations before changes.

Result & lesson

The work demonstrated a repeatable, authenticated alternative to manual configuration and offered a much smaller recovery unit than waiting for a full nightly backup. Broader team adoption did not move forward, reinforcing an important lesson: useful automation also needs sponsorship, shared ownership, documentation, and a clear rollout path.

Different systems.
Same engineering instinct.

01

Discover first

Inspect the real state of the platform before deciding what should change.

02

Automate recurrence

Turn repeated operational work into a controlled, reusable workflow.

03

Design for recovery

Back up state, validate through environments, and make reversal practical.

04

Make it usable

Deliver outputs in the runbooks, tables, and tools people already understand.

A smaller example of practical documentation:
A Quick Git Cheat Sheet

I’m happy to walk through the work in conversation.

Get in touch