Using Well-Placed Friction to Change How Engineers Work
When arguing doesn't change how your engineers work, change the system around them by adding friction to bad behaviors and removing it from good ones.
You've been in that meeting where you know the right answer, you explain it perfectly, and everyone nods... then does something else anyway.
Arguments like that never stick, so put your effort into changing the system your engineers work in.
Engineers are like any other person, and they respond to incentives over arguments. The fastest path from A to B is to make A really annoying.
This is the art of well-placed friction.
What is friction?
Friction is anything that makes a behavior harder, like how mandatory PR reviews prevent deploying straight to prod. That makes the bad behavior impossible, so the next best option is going through PR.
Other examples include:
- Long deploy processes prevent quick iterations thus encouraging mega releases
- "no agenda, no meeting" policies prevent aimless, unprepared meetings thus encouraging canceling or structured meetings
- Password rotations every 30 days prevent remembering passwords thus encouraging them being written on sticky notes
- Demos at the end of every sprint prevent building in isolation thus encouraging earlier stakeholder feedback
How to use this to your advantage
1. Figure out the outcome you want
Start with the outcome, like "fewer bugs in production", and save behaviors like "write more tests" for the next step.
Example: Fewer bugs in production
2. Find what behaviors lead to those outcomes
Work backwards and ask what behaviors cause that outcome. Maybe it's writing more tests, or maybe it's having more time to learn their tools. Treat your answer as a guess until you observe and test it.
Example: Writing high value tests
3. Remove friction from the good behaviors
If the right path feels like a chore, people won't take it, so make the good behavior effortless with auto-generated test boilerplate, one-click deploys when checks pass, templates that pre-fill the boring parts, and CI that runs fast.
Example: Set up the testing libraries and write example tests
4. Add friction to the wrong behaviors
Why aren't people doing the right thing already? Usually it's because the wrong thing is easier. Skipping tests is faster than writing them, mega-PRs avoid multiple review cycles, and copying old code is quicker than refactoring. Find the shortcut people are taking.
Example: Require tests with new code
5. Make a noisy "break glass" path
Allow your system to be broken in cases where it is horribly unfit. This keeps your system from blocking the people fixing an emergency. It also hints to management that something serious needs to be fixed.
Example: Allow admin override with email to director
6. Test and iterate
Listen to reality. What effect are you actually having? Are you achieving the desired outcome? Remember, the dysfunction was originally created from someone having good intentions and not checking in after.
Example: The process itself becoming fair game in retrospectives
Why this works
- No ego battles
- Works while you're in meetings
- Scales across teams and orgs
- People discover the right answer themselves
Pitfalls
- You optimize for the wrong outcome
- Adding friction everywhere
- You treat people like they're dumb
- You make friction for culture
- You forget to remove it when not needed any longer
Closing
You can artfully use a carrot and stick to get people doing the right thing, and design your systems to do the heavy work for you. Maybe taking a closer look will help you realize why everyone habitually does the wrong thing?