As a founder or startup leader, you will often need to drive big changes which affect your organization structure (like introducing a new team), your tool or technical stack (like changing the tool you use for performance reviews), or just the way you do things (like introducing new policies around leave).
If you want to implement change successfully, you need to build a narrative – a story, a justification, for why these changes are happening, and why they’re happening now. You need your team to buy into, or at least, understand the reasoning behind your decisions and sell them like they are their own.
The best leaders and founders I have worked with have mastered the art of storytelling.
It may sound obvious, but it's worth re-iterating: the most successful org changes are those which have 100% buy-in from all team members.
Over the years, I tried to understand the actions behind some of Hotjar's most successful changes – both my own and those made by others. It was no surprise: good planning and great communication with the rest of the team were often key to success.
The best way to let your team know about a change is to build a narrative – a story that explains where you're coming from, the journey that led you to this particular change, and what the future holds.
I also learned that it's critical to look at a change through the lens of others in your team. There's nothing worse than hearing about a change and realizing the person behind that change has completely ignored the impact it will have on you.
Based on my own experience, here are the 2 simple steps you can take when planning a change:
Step 1:
Write down everything you know about the change in a document and get feedback from your manager/s and a few stakeholders.
Over the years, most of the changes I implemented started their life in a simple Google doc which took the following format:
- Explanation of the problem & the history behind it: What issue are you solving with this change? What's the background here? Give the context needed to justify the efforts required to implement the change.
- The solution and the way forward: What's the solution you've come up with? How did you come up with it? Give some information on the process you took to decide. Did you consider different options? Did you consult others?
- Implementation plan: On a very tactical level, how will you be implementing this change? Who will be involved? When? How will it affect their day-to-day work?
- Answers to potential questions: Prepare, in advance, a list of questions you think you'll receive and answer them. This will save you so much time later on, and you'll also come across as better prepared when you're presenting your idea to the team.
This process is useful not just for your team but also for yourself. You will likely discover a number of edge cases that you hadn't yet thought about.
As you're building this doc, you will want to share it with a few of the major stakeholders and get their feedback. Note that I said a few – at this stage, your goal is not to get buy-in from everyone. Your goal is to hear different concerns and make sure that you're either tackling them by changing the plan or explaining why they're not show-stoppers in your QnA section.
The stakeholders you invite to review your doc need to represent the group of team members you will later be sharing the change with. Your goal is to make sure that you know, in advance, most of the concerns your team is likely to raise.
Step 2:
Once you've finalized the plan, convert the raw information above into an engaging and compelling story that convinces your team this is a great change.
To build a narrative, you need to get your facts straight, think about the impact on others, and then share the change with others in a compelling and engaging format.
At this stage, you need to start thinking about how you intend to share the information above with your team. You have several options – for example slides, AMA sessions, emails, company blog posts, or a combination of the above. The format you end up using will largely depend on the significance of the change you're implementing.
Big changes should always be communicated in person (or over a team call) with a presentation to visually explain the story you're trying to communicate. If the change is going to impact several team members, an AMA session might be necessary. On the other hand, for smaller, insignificant changes, a blog post will likely suffice.
The success of your change depends on how well your audience relates to and understands your story. You will need to explain why you feel the problem you're trying to solve is one worth solving. Do this by taking your audience on a journey and explaining how this particular problem has evolved and been tackled over the years.
Take the time to speak directly to the team members who will be most likely affected by your change.
Depending on how big your team is, you may need to build different narratives for different audiences.
For example: say you’ve decided to split one team into two – how do you announce the news to the team that will be affected?
The key here is to put yourself in their shoes. If you were part of that team yourself, how would you like to receive the news? Would you be OK if you heard it for the first time in a company-wide announcement? Likely not.
Similarly, you may have team members who, although not directly impacted, are very opinionated and may have big concerns about the change. In this case, you should also think about taking one-on-one calls with them beforehand.
Don't feel bad if your change is not universally loved. As your startup grows, this will start to happen more often and will become a necessary evil.
What's important is that you put in the effort to help your team understand why the decision is being taken, and ensure their concerns and questions are being listened to and acknowledged, even if the outcome is ultimately not to their liking.