We tried mandating AI pairing and it backfired—here's what works instead

General
1

Six months ago, I made a decision I was confident in: we would require pair programming for all AI-assisted code. The hypothesis was sound—it would improve knowledge transfer, code quality, and team collaboration.

The results? Compliance, yes. But also resentment, workarounds, and a palpable decrease in team morale.

Here’s the post-mortem on why mandating collaboration practices fails, and what we’re doing instead.

What We Tried (and Why It Failed)

The Policy: All code written with AI assistance must be pair-programmed. Single exception for exploratory prototypes.

What we expected:

  • Better knowledge sharing
  • Higher quality code
  • Stronger team relationships
  • More intentional AI use

What we got:

  • Engineers gaming the system (claiming code wasn’t AI-assisted when it was)
  • Resentment about “not being trusted” to work independently
  • Productivity theater—people pairing because they had to, not because it helped
  • The most senior engineers found ways to opt out, making it feel like a “junior developer” policy

Why it failed: You cannot mandate culture. You cannot force collaboration. You cannot policy your way to the behaviors you want.

The Shift: From Policy to Culture

After the failed experiment, we completely changed our approach. Instead of requiring specific behaviors, we focused on creating the conditions where those behaviors emerge naturally.

Three Core Strategies

1. Incentives: Career Advancement Tied to Teaching

We changed our promotion criteria to explicitly value knowledge sharing:

  • Senior → Staff requires demonstrable mentorship impact (measured through 360 feedback and mentee survey)
  • Staff → Principal requires building team capability, not just individual output
  • IC performance reviews include “collaboration contributions” weighted at 25%

Result: Senior engineers started volunteering to pair because it directly advanced their careers.

2. Visibility: Showcasing Collaboration Wins

We created regular showcases in all-hands:

  • “Collaboration win of the week” featuring teams who shipped complex work through effective pairing
  • “AI lessons learned” segment where engineers share what they discovered through AI + human collaboration
  • Leadership explicitly praising collaborative approaches, not just shipping speed

Result: Collaboration became high-status, not a chore.

3. Role Modeling: Leadership Pairing Publicly

I (CTO) and our VP Eng now do “public pairing” sessions:

  • Monthly office hours where we pair with any engineer on interesting problems
  • We explicitly use AI tools and talk through our decision-making
  • We share our own “I got this wrong with AI” stories
  • We demonstrate that pairing isn’t about skill level—experts benefit too

Result: Psychological safety around collaboration increased dramatically.

Measuring Cultural Change

We track cultural indicators, not just compliance:

  • Helping behavior: How often do engineers voluntarily offer help? (Measured via Slack thread analysis)
  • Question diversity: Are people asking questions beyond just implementation? (Measured via questions in code reviews, office hours, Slack)
  • Collaboration patterns: Who’s working with whom? (Measured via Git co-authorship, PR reviewers, meeting patterns)
  • Engagement surveys: Do people feel supported? Do they feel they’re learning?

Results After 4 Months

  • 40% increase in voluntary pairing (no mandate)
  • Code quality scores improved (fewer bugs, better test coverage)
  • Engagement scores up 15 points
  • Zero resentment (measured via anonymous feedback)

The Key Insight

Create conditions for collaboration, don’t force it.

When pairing helps people:

  • Advance their careers
  • Get recognized publicly
  • Learn from leaders they respect
  • Solve problems faster
  • Feel less stuck

…they’ll do it without being told.

Questions for the Community

  • What collaboration practices have you tried to mandate vs. cultivate?
  • How do you measure whether collaborative culture is actually taking root?
  • What incentives work in your organization?
  • How do you balance structure (some policies needed) with autonomy?
2

I’ve experienced the exact same failure with mandatory practices! The turning point for me was realizing that “because it’s policy” is the weakest possible motivator for knowledge work.

What’s worked at our EdTech org:

1. Pairing Showcase Program

Every two weeks, one team demos a “collaboration win” at all-hands. Not a technical demo of what they built—a story about how they collaborated and what they learned.

Examples from recent showcases:

  • Mobile team showed how Pair-AI helped junior engineer understand complex state management
  • Platform team demonstrated Team-AI mode for incident response that cut resolution time by 50%
  • Design + eng showed cross-functional pairing on accessibility improvements

The key: these are celebrations, not requirements. Teams volunteer. And it’s become competitive in the best way—teams want to be featured.

2. Recognition Program: Collaboration Champion

Each quarter, teams nominate a “collaboration champion”—someone who made others better through pairing, mentoring, or knowledge sharing. Winner gets:

  • Recognition at all-hands
  • $1000 professional development budget
  • Priority for conference speaking opportunities
  • Explicit note in their performance file

This made collaboration prestigious. Our most senior engineers compete for this award now.

3. Gamification (Yes, Really)

I was skeptical, but we tried it: collaboration badges and pairing streaks in our internal tools.

  • :bullseye: “First Pair” badge for first pairing session
  • :fire: “Pairing Streak” for consecutive weeks of pairing at least once
  • :glowing_star: “Knowledge Multiplier” for pairing with 5+ different people
  • :busts_in_silhouette: “Cross-Functional Connector” for pairing across disciplines

This sounds silly, but it worked, especially with early-career engineers. It created a game-like motivation to try collaboration modes they wouldn’t have otherwise.

4. Onboarding Culture Norming

Every new hire pairs for their entire first two weeks. Not policy for everyone—but standard for onboarding. This creates the cultural expectation from day one that collaboration is normal and valued here.

After two weeks, new hires consistently say: “I want to keep pairing, at least sometimes. Can I?”

Creating that initial experience sets the tone. Collaboration feels like an advantage, not an obligation.

The Shift in Language

We stopped saying “you should pair” and started saying:

  • “This is a great pairing opportunity if you’re interested”
  • “Who wants to pair on this?”
  • “I’m going to pair on X if anyone wants to join”

Making it opt-in transformed the energy completely.

Michelle, your framework about conditions vs. mandates is so right. The question isn’t “how do we make people collaborate?” It’s “how do we make collaboration so valuable that people seek it out?”

3

Adding the diversity and inclusion lens here because mandates can have particularly harmful effects on underrepresented groups.

Why Mandates Can Exclude

Different people have different work styles, and one-size-fits-all policies can unintentionally exclude:

  • Neurodivergent engineers may need solo time to process and recharge
  • Introverted team members may find constant pairing exhausting
  • Engineers with caregiving responsibilities may need schedule flexibility that mandated pairing reduces
  • People with impostor syndrome (disproportionately women and people of color) may experience mandated pairing as performance anxiety

When we mandate collaboration, we’re often optimizing for the work style of extroverted, neurotypical, established engineers. That’s a problem.

Flexible Collaboration Modes

What works better: offering multiple pathways to achieve the same goal.

At our financial services company:

  • Some engineers prefer scheduled pairing sessions
  • Others prefer async code reviews with AI summaries + thoughtful written feedback
  • Some do “office hours” style collaboration where people drop in
  • Some pair in person, others remotely with AI facilitation

All achieve knowledge transfer and quality. None are mandated. All are valued.

Cultural Relationship-Building

I also want to add: as a Latino engineering leader, I’ve seen that mentorship in underrepresented communities is deeply relational, not transactional.

Effective mentorship for diversity and inclusion requires:

  • Trust (built over time, not mandated)
  • Psychological safety (destroyed by forced interaction)
  • Cultural awareness (understanding different communication styles)
  • Sponsorship (advocacy and access, not just information)

I create space for both team pairing AND 1:1 mentoring relationships. Some of my best mentoring happens in informal conversations, not scheduled pair programming sessions.

Measuring Inclusion in Collaboration

We measure collaboration equity:

  • Are all voices heard in Team-AI sessions? (track speaking time distribution)
  • Are underrepresented engineers getting equal access to pairing with senior engineers?
  • Do collaboration patterns reflect diversity of the team, or do people cluster by identity?
  • Do engagement survey scores on “belonging” correlate with collaboration opportunities?

Findings: When we made collaboration opt-in but highly valued, participation from underrepresented groups actually increased. Why? Because people could choose modes that worked for them and felt genuinely supported, not monitored.

The mandate created compliance. The cultural shift created belonging.

The Power of Opt-In

There’s something profound about agency. When I choose to pair because I see the value, I’m engaged. When I’m required to pair, I’m compliant.

Engaged people learn. Compliant people perform.

Culture creates engagement. Policy creates compliance. Choose wisely.

4

Design teams learned this lesson years ago! Forced “design critiques” created defensive designers who presented work as finished rather than in-progress.

What transformed our design culture:

From Mandatory Crits to Opt-In Learning

What didn’t work:

  • Required weekly design critiques where everyone had to present
  • Resulted in: polished presentations, defensive reactions, surface-level feedback
  • Junior designers felt judged, not supported

What works:

  • Office hours: Senior designers hold open office hours, anyone can drop in
  • Show & tell: Opt-in sessions where designers share work-in-progress
  • Design studios: Collaborative problem-solving sessions (opt-in)
  • Async feedback: Loom videos and Figma comments for those who prefer it

AI Twist: Learning from Mistakes

We created something called “AI design reviews” where the team shares what they learned from AI collaboration—especially mistakes.

This creates psychological safety to:

  • Admit when AI generated something wrong
  • Share surprising AI fails
  • Celebrate clever AI uses
  • Learn together about AI limitations

Story: A junior designer shared an AI-generated accessibility fail at show & tell. Instead of shame, it became a teaching moment. Now we have a team doc called “AI Design Lessons Learned” that everyone contributes to.

Current count: 47 lessons about what AI gets right, what it misses, and when to trust humans.

The Cultural Shift

The shift from mandatory to opt-in changed the questions:

  • Before: “Do I have to present at crit?” (resentment)
  • After: “Can I get feedback on this before I go too far?” (eagerness)

Making Collaboration High-Status

What made opt-in work:

  1. Senior designers visibly participate: Our design director attends show & tell and shares her AI experiments
  2. Recognition: Designers who give helpful feedback get shouted out in team meetings
  3. Career growth: Mentorship is part of senior designer expectations
  4. Better work: People see that collaborators produce better outcomes

When collaboration makes you better and gets you recognized, you don’t need a mandate.

Cross-Functional Culture Building

One more thing: this applies to product + design + engineering collaboration.

We tried mandating “design-eng pairing” on every feature. Failed spectacularly.

Now: We showcase great cross-functional collaboration wins. We create opportunities (not requirements) for pairing. We celebrate when product, design, and eng solve hard problems together.

Result: More cross-functional collaboration than when we mandated it. And people actually enjoy it.

The principle: Show the value, create the conditions, get out of the way.

5

Adding the product-engineering collaboration perspective, because mandating cross-functional collaboration is even harder than mandating eng-to-eng collaboration.

The Failed Experiment: Mandatory Product-Eng Pairing

We tried: Every feature requires product manager to pair with engineer during implementation.

Result:

  • Engineers felt micromanaged
  • Product felt like they were “babysitting” engineers
  • Both sides resented the time investment
  • Collaboration became checkbox, not conversation

What Actually Works: Product as Collaboration Participant

Now product managers can opt-in to engineering pairing sessions—and they do, because it’s valuable.

When product joins eng+AI pairing:

  • Product learns what’s technically feasible (AI makes some things way easier than we thought)
  • Engineers learn user context and business constraints
  • AI helps bridge technical-to-business translation
  • Both sides build shared understanding in real-time

Example: Last week I sat in on an eng pair using AI to implement a user analytics feature. The AI suggested an implementation approach that was technically elegant but would miss the specific user behavior we needed to track. Because I was there, we caught it immediately.

Cost of catching it in pairing: 5 minutes of conversation.
Cost if we’d caught it in QA: 2 days of rework.
Cost if users caught it: weeks of wrong data + trust damage.

The Culture Shift

What changed the dynamic:

1. Invitations, Not Requirements

  • Engineers say: “This is a tricky feature, want to pair?”
  • Product says: “I’m curious how you’ll implement this, mind if I join?”
  • Language matters: asking creates collaboration, requiring creates compliance

2. AI as the Great Enabler

  • Product can follow technical discussions because AI explains context
  • Engineers can understand business logic because AI translates product requirements
  • Both sides learn each other’s domain without it feeling like cross-training

3. Showcase Cross-Functional Wins

  • All-hands features stories of product + eng collaboration success
  • We highlight caught issues, prevented problems, creative solutions
  • Makes collaboration aspirational, not obligatory

Measuring Product-Eng Alignment

We track:

  • Feature rework rate: How often do we rebuild features due to misunderstanding?
  • Question timing: Are product-eng questions happening during planning, implementation, or after release?
  • User impact: Do features solve the intended user problems?

Since shifting to opt-in collaboration culture:

  • Rework rate down 35%
  • Questions moved earlier (80% during planning/implementation vs. 40% before)
  • User satisfaction with new features up 28%

The Meta-Point: Collaboration Across Power Dynamics

Product-eng has inherent power dynamics (product often has authority over priorities). When you mandate collaboration across power dynamics, you create:

  • Performance anxiety
  • Surveillance feelings
  • Resentment
  • Defensive behavior

When collaboration is opt-in and valued:

  • Mutual respect
  • Learning orientation
  • Problem-solving mindset
  • Trust

This applies to any cross-functional collaboration: design-eng, eng-ops, eng-business.

Create conditions where collaboration helps both parties succeed. Make it high-status. Show the value. Then get out of the way and watch culture shift.

The best policy is no policy—just clear values and strong cultural signals.