The Myth of "Good" Timing

In a recent 1:1 with a new engineering leader, they brought up some changes they wanted to make to how the team does sprints & tracks stories on Jira. "I've wanted to do it for a while now, but the team is so focused on getting this project done that I'm waiting for the right time". The subsequent conversation triggered my want to share my thoughts on how to pick your spots when it comes to executing on necessary changes. This isn't about change management strategies or what changes you should/should not make - both important topics.

I've had a fair amount of experience at pulling off (and witnessing) all types of changes the last few years. Anyone who has been at a fast-moving company will be familiar with the moniker "change is the only constant" or something similarly trite. Changes to ways we work (processes, stand ups, business review formats, etc) and changes to how we structure our teams are among the most common. Rapid growth, let alone the new normal from Covid, requires you to evaluate these fundamental building blocks frequently.

Leaders frequently approach the decision on "when" with the perspective of "what is a good time to do this?". I want to propose that good timing is a myth that we perpetuate because it gives us an excuse to delay difficult or unpopular actions. There is bad timing, and timing that is just fine.

I tell a story from Gojek whenever this topic comes up. In 2018, two critical orgs were struggling to productively work well together - Team A and Team B. It was a longstanding pain point and well debated internally. A new leader was hired for Team B, and when he joined I said in front of the Team A leader "I don't understand what is so hard about the Team B job". Team A leader replied "You're wrong - there's an impossible choice here. He can either make all the changes we're recommending without fully understanding the problems & risk alienating his org OR he can wait until he understands all the problems & risk being too entrenched to make the magnitude of changes required."

That conversation really stuck with me. Ultimately, the new leader for Team B took the slow route & the outcome was as predicted. People became frustrated at how long the changes took & when they came, the team didn't understand why it was so sudden. Everyone lost.

Back to the conversation with my new engineering leader from this week. I suggested a few steps, after telling him my story from 2018. I've summarized my thinking below. I'd urge you to do the same when you have to think through these topics!

1. Make sure the timing isn't bad. Big changes right before review season can create unintended anxiety. Big changes going into peak sales season can create unnecessary continuity risks. Avoiding bad timing is much simpler than hunting for the mythical good timing.
2. Accept that change is always hard for folks. It doesn't really matter how much change people have been through, the type of change, or really how you package it. Sometimes we trick ourselves into believing the timing will make it better. Ever heard anyone say "I didn't love the change, but the timing was wonderful"? Nope, me neither.
3. If in doubt, announce the change & set an effective date 2-4 weeks in the future. This can simplify the dynamic massively. This isn't my preferred method, but I think it works just fine.

I view my primary responsibility to be to create an environment where teams & individuals can succeed. To that end, I feel that waiting on implementing big changes for some abstract "timing" component is not doing my job. We are responsible for bringing the future forward as much as possible to let our teams tackle the challenges the future holds. Don't fall into the trap of believing in good timing. I'm not sure it exists.