Friction isn't velocity.
When you’re driving a car down a road, you might get a bit stuffy and decide to roll your windows down. The air will flow in, the wind will get louder, and the sensation of moving will intensify. Your engine will start working a bit harder–and louder–to maintain the same speed. Every sensation will tell you that you’re moving faster, but lowering the window has increased your car’s air resistance, and you’re actually going slower. Or at minimum you’re using more fuel to maintain the same speed.
There’s nothing that you didn’t already know in the first paragraph, but it remains the most common category of reasoning error that I see stressed executives make. If you’re not sure how to make progress, then emotionally it feels a lot better to substitute motion for lack of progress, but in practice you’re worse off.
Grounding this in a few examples:
Many companies realize that their monolithic codebase is slowing them down. It’s easy to decide to migrate from your monolith to services to “solve” this problem, but without a clear service architecture, most attempts take a long time without improving on the underlying issues. That’s because an effective service migration requires the same skill to operate an effective monolith: good technical design.
However, the microservice migration itself provides a reassuring sensation of progress, delaying for a year or two the realization that you’re in roughly the same place that you started in.
When your engineering organization doesn’t seem to be shipping enough software, an easy solution is to rollout a new development process. For example, you might say that an ineffective team needs to start following the scrum development technique.
In rare case that the team has never considered any approach to organize their work, then this might well help. In most cases, this will just paper over whatever problem is causing the slow down, creating an appearance of progress that’ll quickly fade away.
It’s common for new executives to rollout their preferrenced knowledge base, e.g. Notion or Confluence or whatnot, operating from the belief that the tool itself is the fundamental driver of an effective knowledge base.
This will create months of work to move to a new knowledge base, but generally does not improve the underlying knowledge being managed. Poorly managed knowledge bases are always related to incentives and culture, not checkbox ready feature lists like “effective search.”
The pattern here is generally an intuition-driven decision driven by a senior leader, unclear criteria for success, an orientation towards motion as an effective proxy for progress, and being too busy to reflect on whether prior actions accomplished their intended goals. This recipe passes as leadership, and does share some of the characteristics from leading from conviction, but is always an inferior tactic to another available option.
If you see someone following this tactic, it’s a genuine kindness to point it out to them. If they’re not interested in that feedback, you’ve learned something important: they’re more focused on the performance act of leadership than in the impact of their work.
To provide one caveat, in cases where you’re wholly stuck, then minimizing friction doesn’t matter so much. In that case, Travis Kalanick’s classic quote is appropriate, “Fear is the disease. Hustle is the antidote.” Frenetic motion is worse than thoughtful pursuit, but some frenzy is preferable to going quietly into that good night.