Teaching Designers Git

The Three Times Rule

DHH described a simple policy: you have to overwrite someone else's work three times before we make you learn Git.

This approach is brilliant for several reasons:

• Pain precedes solution: People don't appreciate tools that solve problems they haven't experienced. Let them feel the pain first.
• Respect autonomy: Adults don't like being forced to learn new tools. This approach lets them come to the realization themselves.
• Clear threshold: Three times isn't arbitrary annoyance—it's a pattern that indicates a systemic problem.

Technical Empathy Across Disciplines

The story also illustrates something deeper: the importance of meeting people where they are. Designers aren't worse at their jobs for not knowing Git. They're experts in a different domain.

Git is notoriously confusing even for developers. Expecting designers to intuit branching, merging, and conflict resolution isn't fair. The goal is competence in their workflow, not Git mastery.

Simplifying Git for Non-Developers

When introducing Git to non-developers, strip it down to the essentials:

# The minimum Git workflow for designers:

# 1. Before starting work
git pull                    # Get latest changes

# 2. After making changes
git add .                   # Stage your changes
git commit -m "Updated homepage design"
git push                    # Share your changes

# That's it. Three commands in, three commands out.
# Branching, merging, rebasing? Worry about those later.

Better yet, use a GUI like GitHub Desktop, Tower, or GitKraken that visualizes what's happening. The command line is powerful but not necessary for basic workflows.

Broader Lessons for Change Management

The Git story is a template for introducing any new tool or process:

1. Pain Before Prescription

Don't solve problems people don't have yet. Let them experience the pain. Then offer the solution. The motivation will be intrinsic, not imposed.

2. Clear Triggers

"Three times" is a clear, unarbitrary threshold. It removes ambiguity about when change is necessary. Find similar clear triggers for your tools and processes.

3. Patient Onboarding

Once someone needs to learn, support them fully. Don't throw documentation at them and expect self-service. Pair with them. Answer questions. Make the transition as smooth as possible.

4. Minimum Viable Workflow

Don't teach everything. Teach the minimum needed to be effective. Advanced features can come later, if ever. Most people only need 10% of a tool's capabilities.

5. Respect Expertise Differences

A designer not knowing Git doesn't make them less competent—they're competent in different things. Technical people sometimes forget that their tools aren't universal knowledge.

When Patience Ends

The three-times rule has a flip side: after three times, learning isn't optional. There's a point where continued resistance to necessary tools becomes a performance issue.

The three-times rule is generous—it gives people multiple chances to adapt. But it also has a clear endpoint. After three incidents, the discussion changes from "would you like to learn this?" to "you need to learn this."

The Art of Gentle Change

DHH's Git story isn't really about Git at all. It's about how to change people's behavior in a way that respects their autonomy while maintaining team effectiveness.

The best tool adoption doesn't feel like imposition—it feels like relief. When someone finally learns Git after overwriting work three times, they're not resentful. They're grateful. Because now they have a solution to a problem they understand viscerally.