Change is hard in business. A few things routinely get messed up:
- Pulling the trigger. Think: “wait, are we still discussing this change or did we just decide to do it.” I can’t tell you the number of times I’ve heard that quote in meetings. I think continuous partial attention is part of the problem. Sometimes, it’s just straight-up confusion as the enthusiasm for a new idea ebbs and flows in a group conversation. It can be hard to tell if we’ve decided to change or if everyone’s just excited about the idea.
- Next-level engagement. Think: “wait, I know we all like this idea on the exec staff, but this decision affects a lot of people at the next level. I need some time to bounce this off my leadership team and get their input before we go ready/fire/aim on this.”
- Communications. Think: “wait, this change is a big deal and I know we just spent every minute of the three-hour meeting deciding to do it, but we need to find another hour to discuss key messaging (5W+2H) for both the internal and external audience.”
- Anticipatory execution. Think: “While we had not yet finally approved the proposal for the new logo, it was doing very well in feedback and I just loathed the idea of making 5000 bags with the old logo on them, so I used the new one even though it wasn’t approved yet.”
When you screw up change a lot of bad things happen.
- Employees get confused about the company’s strategy. “First they said, we were doing X, and then the execs did an about-face. I don’t understand.”
- The external market, including your customers, get confused about what you are doing. This is even worse.
- You can end up with 5,000 bags that have neither your old logo nor your new logo on them.
- You can make your management team look like the Keystone Cops in one of many ways through screwing up sequencing: like dropping off boxes before the big move is announced, or employees finding out they’ve been laid off because their keycards stop working.
In order to avoid confusion about change and the mistakes that come with it, I’ve adopted a principle I call the “sailboat tack principle” which I use whenever we are contemplating major change. (We can define major as any change that if poorly executed will make the management team look like clowns to employees, customers, or other stakeholders.)
If you’ve ever gone sailing you may have noticed there is a strict protocol involved in a tack. When the skipper wants to execute a tack, he or she runs the following protocol.
Skipper: “Ready about”
Each crew member: “Ready”
Last crew member: “Ready”
Skipper: “Helm’s a lee.”
That is, the skipper does not actually begin the maneuver until every involved crew member has indicated they are ready. This prevents partial execution, people getting hit in the head with booms, and people getting knocked off the boat. It also implicitly makes clear when we are discussing a possible course change (e.g., “I think we should set course that direction”) from when we are actually doing it (e.g., “Ready about”).
For those with CS degrees, the sailboat tack principle is a two-phase commit protocol, used commonly in distributed transaction processing systems.
I like the sailboat tack protocol because the extra discipline causes a few things to happen automatically.
- People know implicitly when we’re just talking about course changes. (Because no one is saying “OK, so do we want tack here?”)
- People know explicitly when we are actually making the decision whether to execute change.
- The result of that extra warning — “hey, we are about to do this” triggers numerous very healthy “wait a minute” reactions. Wait a minute: I need to ask my team, I need to make a communications plan, I need to examine the compensation impact, I need to think about what order we roll this out in, etc.