Normalizing change
I always liked to work on new problems, but earlier in my career, I didn’t get why things changed suddenly, and I often had no say. I’d get a new boss; my project would get canceled; I’d have to rewrite my code because a new software version came out. Change loomed like a specter: a hair-raising, yet thrilling mystery.
When I became a people manager, suddenly I was the person my team looked to with their “Why?” when change came. At first I gave the most naive response: “don’t worry, that change is no big deal”. It didn’t work: dismissing concerns didn’t ease people’s fears and anxieties. Then I tried to shield them from change so they can focus on doing their best work. But I often couldn’t, not even a CEO can.
Change happens because we learn new information: business strategy changes, our competitors are catching up; economy changes, investors no longer throw money at startups outside a zero interest rate environment; technology changes, AI with large language models today is not the same as AI 2 year ago. We don’t control our environments, but we can control ourselves to adapt. Instead of dismissing or hiding change, I can build a culture where change is normal, easy and rewarding.
It is not the most intellectual of the species that survives; it is not the strongest that survives; but the species that survives is the one that is able best to adapt and adjust to the changing environment.
― Leon Megginson on Darwin’s Origin of Species
So how do you normalize change? Here are some ways I found useful:
Reframe change as experiments and learnings: Turning ambiguous ideas into great products is hard. As an engineer, I honed the skill of making an idea real. Billion-dollar productivity tool? I can build it too! But most of my ideas didn’t turn into great products. Surely if I come up with better ideas I’d have more success, I thought. But even successful startups pivot from their founding idea before they hit a home run. Famously, Instagram pivoted from a social check-in app to a photo-sharing app, and Slack pivoted from a game to a group messaging app. When I worked in Data Science at Shutterfly, we ran so many growth experiments before making a dent in our revenue.
Startups that win are the ones that learn the fastest. For them, everything is an experiment: a product idea, an org design, or even a new hire. They take a portfolio approach like Venture Capitalists: bet on 10 ideas, expect 1 ~ 2 home runs that return 10x their investment, a few break evens, and the rest written off. We can do the same by reframing our day-to-day work:
- Bad: we built a simpler onboarding funnel and it isn’t working
- Good: we ran an experiment to test if simplifying our onboarding will increase account creation. Account creation is up by x% but 7-day retention is down by y%. We learned that users liked entering less data upfront but aren’t as invested to use our product. This trade-off hurts long-term engagement so we’re pivoting.
Silicon Valley births innovation because it celebrates failure. I have plenty of practice and I still get to build! Failure means we learned that our hypothesis was wrong, but there are always others to test. I believe we should reward teams for learnings. For example, I measure Product Manager performance by not just the business impact they create, but also the volume and velocity of experiments they run.
Set expectation early: tell your team that changes are coming, and give them some examples of what changed before. Ideally founders set this expectation from day 0. Psychologists call this technique “priming”. It works because hearing an idea early influences how we see the world, how we behave, and even how well we learn. For example, as part of Product Manager hiring and onboarding, I tell a new team member that we rethink org design at least once a year. Meta’s Year of Efficiency is another example. The company messaged the vision and the why early before making a few rounds of org changes.
Give people a say: as humans, we want to feel a sense of control over our lives. Change at work often comes from the top. Mix it up with bottom-up change by involving people to imagine new ideas, give feedback and help in carrying out the change. Ask them: How efficient is our process? Are we happy with this tool? How can Product better partner with Sales? And a more specific example: I guide teams to define success as a crisp quantitive number or a yes/no:
- Bad: customers like new feature X
- Good: 4 out of 5 customers buy new feature X
By defining their own success, teams feel agency in their work, and we debate less on whether what we learned is good or bad. People clearly see if change is needed.
Find your cadence: companies and teams operate on a cadence: annual kickoffs, quarterly planning, weekly experiment reviews, etc. Piggyback on these events to make changes and ask for feedback. Simply hearing about change regularly, people start to react differently: “oh we’ve been talking about that, and it’s happening now.” Linear has a unique resource allocation cadence that rotates people across projects. It doesn’t need big reorgs, and there’s no drama when people and projects come and go.
Time-box experiments: when experiments drag on without conclusive results, people linger and tech debt piles. At LTSE, we planned every 6 weeks in what we called Pivot vs. Persevere (PvP) cycles. We broke big problems down into smaller experiments that fit within the cycle, then build, ship and collect data at the end. Based on what we learned, we pivot to work on another problem, or persevere by running more and bigger experiments on the same problem. The time-boxed experiments make change easy and normal.
I'd love to hear what you think about this essay. Your feedback makes my work better. You can chat with me on Twitter and Hacker News .