On the bike at the gym this morning, I thought about increasing my level. When I exercise, more friction is good.
But when you develop or use products, more friction is bad. Brian Marick talks about this when he speaks and writes about “ease” for development teams. If you’ve encountered a web page that made you do 25 different things before you were able to do what you wanted (some conferences want a whole lot of information, even if they’ve requested you send in a proposal), you’ve encountered friction as a user.
Up until this morning, I thought the technical debt and ease metaphors were sufficient to describe the friction that people encounter on projects. However, I also like Keith Ray’s post, “High technical debt = slum.” I feel like a second-class citizen–sometimes a third-class :-)–when I am part of a team or use a product with high friction.
When you hear these statements, you know you have friction:
- We can’t move to shorter iterations because of overhead
- It works on my machine
- Let the testers find the problems
- We can’t finish a feature inside of a week
- It’s just too hard to do <that thing>
And, if you don’t acknowledge technical debt, you can’t do a darn thing about the friction you encounter. It just grows and grows and grows.
If you work on a project, what do you do about the friction? Do you reduce it at all times? Sometimes, that’s the right approach. Sometimes, it’s not. If you are a project or program manager, do you look for friction? If not, start. Friction is often an unknown risk coming true.
Most of the time, friction makes our lives miserable. Unless, we’re in the gym. Then it might make our lives better in the long run. But for work, and for general living, think about reducing friction. Work and life will be much easier.
