Change: Damned if you do, damned more if you don't
This plays out in many ways:
- Customers demand an improved UX, but they don’t want to learn a new UX, and they always complain when it changes.
- Team members want consistency but don’t want policies.
- Developers want to be more efficient but don’t want to change how they work.
- Strategy is ineffective if it’s constantly in flux, but a strategy that remains unchanged in the presence of new information is incorrect.
The right choice is almost always “change.” This is because change is a reaction to uncovering facts, getting smarter, or a shift in the outside environment. Death awaits any organization that chooses the comfort of the familiar over the discomfort of change.
Yet, though inevitable, change is uncomfortable and exhausting. Even we who relish change, who love bragging that “it’s hard but every day is different,” reach a breaking point after years of adaptation and fake-gleefully exclaiming that “failure is how you learn!”
Yeah, but all this learning is fricking tiring.
This is important for leaders to understand, if indeed “change is the only constant” as the insipid cliché goes. Even your most stoic, change-loving mortals sometimes need a break from change. Yes “it’s a marathon” but sometimes you need to walk a mile to catch your breath. Look for signs of burnout or decision-fatigue, and address it proactively.
This is equally important for everyone in a startup, whether you manage others or not. Constant change can feel like management has no plan and no strategy. It takes careful consideration to distinguish between being rudderless and a culture of self-reflection and improvement.
This is exacerbated by the fact that not all change is for the best. Sometimes our attempt to solve a problem makes it worse. Sometimes, when we try to make code faster, we break it. The difference is that we can see slow code objectively in the profiler and couch the code in unit tests and code reviews, and iterate before we ship, and revert to the previous version in the worst case; it’s not so easy when the change is happening to a whole team, or a major product release, or a cross-departmental strategic initiative.
In fact, sometimes it’s objectively impossible to know ahead of time, and you have no choice but to place a bet.
Even deciding what to change is hard. Successful companies can stall out because they lose sight of the fundamental reasons they earned success in the first place—the key insights and UX of the product, or the key culture and values that attracted their first hundred or thousand employees. But successful companies also stall out because they’re so dogmatic about their strategy or “non-consensus but correct” ideas that when the world changes around them, or scale breaks their previously-correct notions, they fail to adapt. It is not generally true that “what got us here will get us there,” and that means deep change is required.
There’s a mindset that everyone can use to address all of these difficulties:
Maybe don’t judge too harshly if your organization tries to improve one thing and ends up breaking another, or where the organization takes too long to implement change. Maybe don’t judge too harshly if the person to your left needs to work on something easy for a few sprints or take a vacation.
Edison had to try thousands of materials before finding the one that make lightbulbs practical. Would you have judged him for “thrashing?” Invention is often frustrating.
You should judge harshly if nobody is thinking about this. If nobody cares whether there’s change or not, if there’s no rhyme or reason to the company strategy, if everyone is expected to act and feel happy and productive all of the time, then you should definitely judge. An organization that isn’t striving to improve, will rot and disintegrate.
There are no straight paths in life or startups. All we can do is keep being introspective, and keep attempting the right sort of change.