High-performing engineering teams

Teams that trust each other take smarter risks, build better things, and stay.

Hands-on programs that turn talented engineers into high-performing teams.

Experiential. Role plays, game days, design challenges, and honest conversation.
Built on what matters. Trust, connection, ownership, and creative confidence.
Lasting. Teams leave with agreements, playbooks, and a plan to keep it going.

Book a discovery call → See the outcomes

Try it: roll a team challengetap the die

You rolled a 12

A promising design dies in a review nobody enjoyed.

→ Architecture "Yes, And"

The problem

Talented engineers don't automatically add up to a great team.

Ideas stay unspoken because pitching feels risky. Knowledge lives in two people's heads. Hard conversations happen in DMs or not at all. Teams play it safe, ship what's expected, and slowly burn out. None of it shows up on a roadmap until it shows up as missed goals, an outage, or a resignation.

Ideas that never get said

Without trust, people stop taking creative risks. The best idea in the room stays in someone's head, and the team settles for the safe one.

Single points of failure in people

When only one engineer knows how a system works, every vacation and every resignation is a risk to the business.

Burnout and attrition

Teams without connection or joy in the work wear down, and replacing a senior engineer is slow and expensive.

Business outcomes

What changes for your organization.

Each engagement targets outcomes you choose up front. We agree on how to measure them before the first session and review them afterward.

Trust that holds under pressure

People raise problems early, admit what they don't know, and ask for help before it's too late.

MeasureTeam trust and psychological-safety survey scores, issues raised early

More creativity, better decisions

Teams practice building on ideas before tearing them down, so more options get explored and the better ones win.

MeasureIdeas proposed per review, late-stage design changes, decision records

Shared ownership

Clear roles, shared knowledge, and fewer single points of failure, so the team doesn't depend on one hero.

MeasureKnowledge coverage map, documented systems, cross-trained areas

Calm in the hard moments

Incidents and security events are rehearsed, so the team stays coordinated when it counts.

MeasureTime to restore service and change failure rate (two of the Accelerate four key metrics), plan gaps closed

Faster connection for new teams

New hires and reorganized teams learn how each other work in days instead of quarters.

MeasureTime to first meaningful contribution, new-hire sentiment

Engagement, joy, and retention

Teams that enjoy working together do better work, raise problems sooner, and stick around longer.

MeasureEngagement survey scores, regretted attrition

Why it works

Culture predicts delivery. Improv builds culture.

In Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble, and Gene Kim found that a generative, high-trust culture predicts both software delivery performance and organizational performance. They used sociologist Ron Westrum's model of organizational culture to measure it.

Culture is hard to change with a memo. It changes through practice. The core habits of improv map closely onto Westrum's generative traits, and every DevPlayOps exercise is designed to practice one or more of them.

Forsgren, Humble & Kim, Accelerate (IT Revolution, 2018)

Generative cultureImprov habitWhere we practice it
High cooperationMake your partner look goodEscape Room: Incident Command
Messengers are trained, not shotEvery offer is a giftThe Honest Hour
Risks are sharedCommit together, fail togetherGame Day, Breach Tabletop
Bridging is encouragedListen to understand, then connectKnow Your Team
Failure leads to inquiryMistakes are materialPostmortem Theater
Novelty is implementedYes, andThe Pitch Tank, Architecture "Yes, And"

How it works

Practice, document, follow through.

People remember what they did far longer than what they were told. So every session is hands-on, built from your team's real work and challenges, and run with enough energy that people actually want to be there.

The game mechanics are the delivery method. The results show up in how the team works every day.

Scenarios tailored to your systems, not generic case studies
No production access needed, and nothing is shared outside the room
Every session ends with written artifacts your team owns
Follow-up at 30 and 90 days on the agreed measures

Week 0
Discovery
A call with leadership and a short team survey. We pick two or three target outcomes and how to measure them.
Week 1–2
Design
Exercises built from your systems, your team, and your goals. You review them before the session.
Session
Practice
The team works through real challenges together, with a structured debrief after each one.
Within a week
Deliver
Team agreements, playbooks, decision records, and an action list with owners, written up for your repo or wiki.
30 and 90 days
Review
A check-in on the measures and the action list, and a recommendation for what to work on next.

The exercises

Real work, played as games.

Each one builds what great teams share: trust, creativity, ownership, connection, and a healthy relationship with risk. Most engagements combine two or three.

Connection

Know Your Team

A team that knows each other's strengths and uses them.

See who's strong where, where the gaps are, and who to pair with whom.

Creativity

The Pitch Tank

More ideas pitched, and better ones built.

Teams pitch real features to a panel of peers. Critique makes ideas stronger, not smaller.

Creativity

Architecture "Yes, And"

Good ideas that survive long enough to get good.

Borrowed from improv: build on ideas first, critique second, then test against real constraints.

Trust

The Honest Hour

The problems everyone knows about, named and owned.

A facilitated, blameless conversation that ends with owners and first steps.

Ownership

Escape Room: Incident Command

A team that self-organizes when it counts.

A timed puzzle built from your own systems. The only way out is working together.

Risk

Game Day

The confidence to experiment, because you know how things fail.

Controlled failure in a safe environment, then a shared list of what to fix.

Risk

Breach Tabletop

Clear, calm decisions when the stakes are high.

Engineering, legal, comms, and execs play out a security event together.

Trust

Postmortem Theater

Mistakes that become lessons instead of blame.

Re-stage a real incident with roles swapped and see it from another seat.

All of the above

The Long Game

A team that operates like one, and enjoys it.

Exercises combined into a program that ends with a team charter and a 90-day plan.

Engagement formats

Start with an hour. Scale to a retreat.

Best in person. Lunch & learns also run virtually. Every format includes preparation, facilitation, and written deliverables.

1 hour · up to 40 people · in person or virtual

Lunch & Learn

One focused exercise. A low-commitment way for leadership to see the approach and for the team to try it.

Best forPilots, all-hands slots, quarterly kickoffs

~4 hours · 6–30 people

Half Day

Two exercises and a full debrief, such as Know Your Team followed by a Pitch Tank on a real roadmap question.

Best forNew or growing teams, planning seasons

~8 hours · 6–30 people

Full Day

A themed program, such as creativity and design or resilience and risk. Ends with a prioritized backlog the team owns.

Best forReadiness reviews, launches, reorgs

~20 hours · 8–40 people

3-Day Retreat

The full program: simulations, design work, team mapping, and facilitated discussion, with time to recharge.

Best forAnnual off-sites, new leadership, team resets

Bars show approximate contact hours to scale.

Deliverables

Every session ends with something the team keeps.

Your team keeps what it builds. Everything is written for your repo or wiki, not left on a whiteboard.

team/

Working agreements and a strengths map, so everyone knows how the team works best and who to go to.

ideas/

A shortlist of ideas worth building, with the reasoning and owners from design and product sessions.

playbooks/

Playbooks and runbooks for design reviews, decisions, escalations, and incidents, written by the people who use them.

growth/

A skills-gap and growth plan to guide hiring, pairing, and training.

TODO.md

An action list with owners and dates, reviewed at the 30- and 90-day check-ins.

~/platform-team-offsite

platform-team-offsite/
├── team/
│   ├── working-agreements.md
│   ├── strengths-map.md
│   └── how-to-work-with-me.md
├── ideas/
│   └── pitch-tank-shortlist.md  # top 3, owners set
├── playbooks/
│   ├── design-review.md
│   └── incident-command.md
├── growth/
│   └── gaps-and-growth.md
├── outcomes.md              # baseline + 90-day review
└── TODO.md                  # owners + dates

What it isn't

Not team building. Team practice.

Engineers can tell when an activity has nothing to do with their work, and they check out. Every exercise here uses the work your team already does.

Left out

Generic icebreakers and trust falls
Personality quizzes that sort people into colors
Slide decks with no follow-up
Activities unrelated to engineering work

Built in

Scenarios modeled on your own systems
Rotating roles so everyone leads, pitches, and contributes
Structured critique of real decisions
Measured outcomes and written deliverables

About

Teams that play are teams that succeed.

I learned that twice. The first time was in engineering. In a thirty-year career that's taken me through Global Crossing, Level 3 Communications, DivX, Inc., AWS, Comic-Con International, and Robinhood, I've worked everywhere from the call center to SRE and management, on teams that rode out Y2K, live-streamed debates, built CDNs and networks, and made it through SOC 2. The teams that pulled off the hard stuff were the ones that could still laugh together at 2 a.m.

The second time was on stage. I've been doing improv since 2001, training with San Diego Theatre Sports, the National Comedy Theatre, and BATS Improv. Today I teach, perform, and serve on the board with Mockingbird Improv. Improv is a team sport with no script and no undo button, and it only works when everyone has each other's back.

Same lesson both times: play builds trust, trust makes it safe to take risks, and risk is where the good ideas live. DevPlayOps brings that to engineering teams, on purpose.

The best teams I've been on weren't the ones with the most talent. They were the ones that trusted each other enough to try something new and fail together.

Questions

What leaders usually ask.

How do we measure the return?

In discovery we pick two or three outcomes, such as team trust and engagement scores, the Accelerate four key metrics, time to first meaningful contribution, or follow-up actions closed. We record a baseline, and review the same measures at 30 and 90 days. You get those results in writing.

How much of the team's time does it take?

As little as an hour. Most organizations start with a lunch & learn or a half day, then decide whether to go further. Preparation on your side is a one-hour discovery call and a short survey.

Do you need access to our production systems?

No, and we don't want it 🙂 Most exercises run on simulated dashboards, logs, and whiteboards. Game Days can use a staging environment if you want that realism, with your team at the controls.

Is it confidential?

Yes. Scenarios are built from information you choose to share, and what's said in the room stays there. We're happy to sign your NDA.

Does anyone have to perform or act?

No. Role plays mean holding a responsibility, like incident commander, product investor, or customer. Quieter engineers often get the most out of it because the structure gives them a clear place to contribute.

Can you run sessions remotely?

Lunch & learns work well virtually. Half days, full days, and retreats are run in person, because the exercises get their value from people working through a problem in the same room.