Leadership & Technical Communication

• Led a distributed team of 4-7 engineers through an 18-month FedRAMP authorization while maintaining platform stability and team morale
• Built structured knowledge-sharing sessions that brought engineers from zero cloud security experience to independently deploying regulated infrastructure
• Wrote 2,500+ lines of multi-audience ELI5 documentation for a single architectural change, with persona-specific reading paths and analogy-first explanations
• Practice radical transparency and pragmatic decision-making to maintain trust through organizational restructurings and layoffs
• Developed personalized mentorship approaches focused on individual growth, advocating upward for compensation, tooling, and workload adjustments

Context

Running the DevOps team as a sole infrastructure person who grew into a people manager means wearing both hats simultaneously: designing complex systems and making sure a team of engineers can understand, operate, and extend those systems without a bus factor of one. The work below spans 18+ months of managing a distributed team through a FedRAMP authorization, multiple organizational restructurings, and the daily challenge of keeping a regulated platform running while growing people's capabilities.

Technical Teaching & Knowledge Transfer

I run structured knowledge-sharing sessions for my team on topics that are genuinely difficult to learn from documentation alone. The approach is always the same: start with an analogy to ground the concept, build from fundamentals to complexity, and stop at each layer to check understanding.

Examples of sessions I've led:

• Security compliance frameworks (SOC 2, HIPAA, FedRAMP) - opened with a fire safety analogy: "every room needs a smoke detector" maps to requirements, "photoelectric/hardwired" maps to policy, "installation schedule" maps to procedure, "inspection photos" maps to evidence. Made an abstract compliance structure immediately tangible for engineers who'd never worked in regulated environments.

• Cloud network architecture - walked the team through the full platform topology layer by layer (VPCs as "virtual data centers," public subnets as "a DMZ," Fargate Spot as "renting slack capacity"), pausing between each layer for questions.

• AI coding tools and agentic workflows - synthesized six weeks of personal research into a structured primer using a progressive taxonomy (inline chat, CLI-based, autonomous agents) before explaining the underlying context management that makes each approach work differently.

• Monitoring infrastructure - demonstrated the full observability stack from architecture through data flow to alerting, finishing with a decision framework for when to use embedded checks vs. embedded scripts vs. external scripts rather than just presenting information.

The ELI5 documentation approach:

When I built the single-image multi-brand deployment system, I wrote 2,346 lines of staged architecture documentation specifically designed for different audiences. Frontend developers read stages 1/2/4/7. IT leadership reads stages 1/3/5/6/8. Every stage opens with an analogy ("Imagine you're baking cookies for 4 different friends...") and includes Mermaid diagrams, before/after comparisons, and persona-specific impact tables. The accompanying troubleshooting guide catalogs exact error messages with causes and fixes rather than just pointing people at logs.

Mentorship & People Development

I manage through personalized support rather than one-size-fits-all processes. Each team member gets a different version of me based on what they need:

• For a senior engineer who tends to over-engineer solutions, I provide feedback through personal examples: "Something to try next time is a proof-of-concept install first - I do the same thing where I'll spin up a quick docker compose prototype before committing to the full architecture."

• For a team member who disclosed high anxiety that causes occasional freezing, I offered to serve as a triage layer: "If too many requests are coming your way, throw me in the middle and I'll prioritize them for you." I also advocated upward for a compensation adjustment.

• For a junior engineer ready to grow, I expanded their ownership scope (logging front-end, server migration) while identifying a specific growth area: identifying process holes and proposing solutions to the team rather than waiting for direction.

• When someone's certification aspirations don't align with company budget norms, I build the business case and offer reimbursement on completion.

Consistent patterns across reviews:

• I write specific commendations and read them aloud - people deserve to hear exactly what they did well
• I share my own shortcomings first ("I'm just as guilty of that too") rather than positioning feedback as one-directional
• I ask what people want to learn and then create concrete paths toward it
• I advocate upward for compensation, tooling, and workload adjustments

Pragmatic Decision-Making

The teams I manage ship complex infrastructure under regulatory pressure. My decision-making philosophy is transparent and pragmatic:

"Ship functional, polish later" - When deploying the platform infrastructure to a new FedRAMP test environment, I explicitly separated must-haves from nice-to-haves with the team. Getting a working environment for red team testing was the priority. Making the deployment process elegant could come after, especially since the red team would likely generate a hundred change requests anyway.

Explain the "why" - When I moved the team from sticky notes and Google Sheets to structured project tracking, I explained the reasoning: "It's not me anymore. We're going to start branching out into things where it can't be me. If it's not just one person, we need centralized documentation and workflow." People adopt process changes faster when they understand the driver.

Transparent disagreement - When development teams make architecture decisions I disagree with, I tell my team honestly ("I told them that's not ideal, but they decided that's the way they wanted to go") without undermining the decision. My team deserves context, not a sanitized corporate version of events.

Honest about unknowns - "I'm trying to think of a fast solution to this and I cannot come up with one" is something I say out loud. When I'm stuck, I schedule a follow-up for the next day rather than thrashing or pretending I have all the answers.

Team Facilitation

I run weekly team meetings with a consistent structure:

• Open with genuine personal check-ins (not performative)
• Round-robin status from each team member
• Explicitly dismiss people not needed for subset discussions ("Everyone else, feel free to drop")
• Park tangents for later with clear "let's circle back" commitments
• Time-box collaborative work ("Let's test at 12:30 - does that sound fair?")
• End with clear handoffs: who does what next

This structure keeps a 7-person meeting under 30 minutes while still leaving space for people to raise issues.

Problem-Solving Under Pressure

When things break in production, my approach is consistent:

1. Diagnose before acting - identify the root cause rather than shotgunning fixes
2. Make pragmatic calls to unblock - "kill the health checks on anything that doesn't work, we'll worry about it later" when the goal is to get a test environment up
3. Be honest when stuck - if I can't solve something quickly, I say so and schedule focused time rather than context-switching endlessly
4. Keep the team calm - production issues are normal development challenges, not emergencies. Treating them that way helps people think clearly

This applies across the platform migration work, supply chain security pipeline issues, and general platform infrastructure incidents.

Transparency & Trust

I lead through radical transparency because I've seen the alternative erode teams:

• When organizational restructuring happens, I share what I know and clearly separate facts from speculation
• When timelines slip, I acknowledge my own role rather than deflecting blame downward
• When difficult decisions are coming from leadership, I give my team advance context so nothing blindsides them
• I explicitly create space for difficult conversations: "If you have anything you want to talk about, don't sit on it. Things always get worse when you keep it in your own mind."

Planning & Prioritization

Managing a small team on a complex platform means saying "not now" as often as "yes":

• I maintain explicit priority hierarchies and communicate them: the identity architecture SSM-only access path was prioritized over service mesh improvements because it was critical for the first customer
• I protect the team from scope creep by managing expectations upward - communicating to leadership when competing priorities are consuming all available capacity
• I plan for what work will look like after the current crunch: thinking about team growth, skill development, and what to tackle once the pressure lifts
• I connect deadlines to their reasoning ("We need artifact collection starting August 1st because the assessor needs three months of evidence to review") so the team understands urgency isn't arbitrary

Impact

• Led a distributed team of 4-7 engineers through an 18-month FedRAMP authorization process while maintaining platform stability
• Developed structured knowledge-sharing sessions that brought engineers from zero cloud security experience to independently deploying regulated infrastructure
• Created 2,500+ lines of multi-audience technical documentation for a single architectural change, reducing onboarding time for the development team
• Conducted performance reviews, managed through organizational restructurings and layoffs, and maintained team morale through extended periods of uncertainty
• Built hiring processes (technical interviews, practical assessments) focused on observing problem-solving rather than testing memorization