Being a DevOps Redshirt

Many years ago, I was listening to a software engineering podcast when one of the hosts said something that really stuck with me: “The role of the senior developer is to clone themselves because they don’t scale.” I’ve always pushed knowledge outside of myself, so I would be the go-to person to call for an L3 gone wrong or be unable to leave old work behind to go do something new. Becoming “indispensable” by being “the expert” may sound like a good job-security strategy, but it’s death to your growth and a false sense of security anyway. My response to the comment was to be much more deliberate about helping other developers grow. In fact, I still mentor two junior developers from my last company. I still feel very vested in their futures.

The scaling remark is what really hit home. When I approach a problem of how to do something better, my process is to try it out locally, then look for ways to apply it at scale. I always reject solutions that would work for a team or a small group of teams. If they cannot be scaled to an enterprise, it’s not a good pattern. Enterprise solutions scale down. Local improvement doesn’t scale up. For example, we piloted CD with a normal team, not a hand-picked group of senior developers. Therefore, the solutions we came up with were broadly applicable.

When we created the CD Sherpa team at Walmart to help teams learn daily delivery across the enterprise, we had to find a way for six senior engineers to help 20,000 engineers distributed globally learn CD. “No problem, we got this.” When I got my first teammate, I told him how happy I was to only need to help 10,000 people now. Our strategy? Share our knowledge through easy-to-consume documentation, public conversations in our Slack channel, showing what worked with real teams doing real work, and direct mentorship of other tech leads on the engineering methods we used with teams to reengineer everything about how they worked to deliver software.

For years, I’ve struggled to define the job description or even what to call it, especially since it also included executive outreach, internal product marketing, teaching in workshops, and honest conversations with directors, etc. We taught effective, pragmatic agile workflows, but we were not agile coaches. We worked with teams to architect test suites for rapid feedback, but we weren’t SDET. We proposed organizational structure changes, but we weren’t HR. We even acted as counselors and mentors to developers who were being told by their managers to do things they knew were unprofessional by our standards. They wanted us to help escallate. We did whenever possible.

When I first started drafting a job description for hiring for the team, I identified one qualification we needed above all else: a pretty unique skill.

“You must be a wildly optimistic, pragmatic cynic.”

If you think that kind of cognitive dissonance is insane, I don’t disagree. You need to be mildly unhinged to do this work as a software engineer with no direct power, rather than a highly paid hired gun who can fire their customer. As Gene Kim remarked to me one day, “You need to have a certain level of not caring about the consequences.” He called people like us a cross between Hogan’s Heroes and Redshirts. We wore the Redshirt moniker proudly.

Recently, I needed to sit down again and clearly define the role to organize my thoughts about cloning myself and what I needed to share with other senior engineers to do the work I’m accountable for, because I can’t do it by myself. Here’s what I came up with. I’m curious what you think.

Role: Delivery Systems Architect / Value Stream Architect

Mission

Optimize software value streams to accelerate the flow from product idea to user feedback. You will apply systems thinking to diagnose and resolve underlying dysfunctions in application, team, and organizational design, aiming to eliminate entire classes of defects before they are ever authored.

What You’ll Do

You’ll analyze and improve our software delivery systems across the entire lifecycle. This is a deeply technical role requiring expertise in how modern software is built, tested, deployed, and operated.

Your focus areas include:

• Systems Diagnosis: Analyze the interplay between application architecture, team structures, and workflows to identify the root causes of recurring defects and delivery friction.

• Defect Prevention: Design systemic guardrails and architectural patterns that prevent entire categories of errors (e.g., architectural mismatches, environment drift, or communication silos).

• Flow Optimization: Identify and eliminate bottlenecks in our delivery pipeline by making hidden constraints visible.

• Feedback Loop Design: Accelerate both internal quality feedback (testing, CI/CD) and external user feedback.

• Quality Systems: Design testing strategies that balance speed and confidence, focusing on “shifting left” through superior test design and environment parity.

• Developer Experience: Improve tooling and processes that reduce cognitive load and delivery friction.

Required Skills & Experience

Systems Thinking & Problem Solving

• Holistic Diagnosis: Ability to look beyond surface-level symptoms to understand how application design, team topologies, and workflow design converge to create systemic dysfunctions.

• Pattern Recognition: Experience identifying “classes of defects” and re-engineering the system (technical or human) to make those defects impossible to replicate.

• Causal Analysis: Proficiency in using systems thinking tools (e.g., Causal Loop Diagrams, Five Whys) to map the impact of organizational design on code quality.

Technical & Test Architecture

• Application Design: Deep understanding of architectural patterns and how they influence testability and deployability.

• Test Design Mastery: Experience designing test suites that are resilient to change and aligned with system architecture to prevent “flaky” feedback loops.

• Operational Excellence: Ability to assess architectural decisions through the lens of maintainability and long-term stability.

Team Topologies & Organizational Design

• Structural Influence: Understanding of how team boundaries and communication pathways (Conway’s Law) impact the quality of the software produced.

• Workflow Engineering: Experience redesigning handoffs and collaboration patterns to reduce dependencies and “wait time” defects.

• Friction Reduction: Ability to identify organizational friction and recommend structural improvements that empower teams to own their quality.

Leadership & Influence

• Drive Change: Ability to drive organizational behavior and mindset shifts toward continuous improvement without direct authority.

• Lead the Leaders: Coach and motivate engineering leadership to adopt practices that reduce downstream instability.

• Communication: Translate complex technical and systemic concepts for diverse audiences, building compelling cases for change using data and narrative.

Wildly Optimistic Pragmatic Cynic

• Unswerving Belief: An unshakable conviction that you can change the world in the face of overwhelming evidence to the contrary.

• Immediate Value: The ability to accept the improvement that can happen now instead of delaying to get the perfect improvement you want.

• Hard-Fought Wins: Accepting small, hard-fought wins as victories while shooting for the stars.

• Incentive Mapping: The ability to identify and leverage organizational incentive practices to influence behavior changes at every level.

What Success Looks Like

• Systemic Quality: A measurable decrease in “classes of defects” through architectural and process hardening.

• Reduced Cycle Time: Faster flow from commit to production with fewer rollbacks.

• High-Confidence Shipping: Teams shipping with less friction, less drama, and higher psychological safety.

• Sooner, Safer, and Happier: Delivering value to the customer with predictable velocity and excellence.

If you need someone like me, this is the job description you're hiring for. This is what I do.

I should be able to find a few of these with no problem!