A little bit about me first. I'm currently the Head of Remote and Support Quality at Klaus, a support quality management platform. Before I moved into this position, I led Klaus’ product organization as we grew from 10 people to 60 people.
There was a lot of change going on during that time, and today I’ll be sharing what I learned about change management through all these sometimes accidental changes.
But first, here are our main talking points:
- The product team is a central node in every organization
- Change management strategies
- Storytime
- A summary for you to ponder
Let's start with the spider's web. Have you ever tried to move a spider's web? I suppose the answer is no.
I haven't tried it either, but I have kids – six-year-old twins – and they love nature, so they know that if you slash a spider's web, the spider loses its house, which is not something that you'd want if you're a six-year-old (and probably not if you're a grown-up personeither!)
To avoid making spiders homeless, my daughter has developed an interest in moving spiderwebs, and we have carried out a lot of experiments on how to do that.
You can try to move the web by yourself, but that usually breaks it, and then the spider needs to invest a lot of time and resources in rebuilding. Or, you can take two kids' hands (four hands in total), and they can push up the spider's web together and move it somewhere less in the way.
Now, to be very honest, I don't think the spider likes this mandatory movement. It's somebody who loves remote work being forced to return to the office, but, well, my kids think it works, so we're going to leave it at that.
Of course, this method is a lot slower. You have to move the web node by node; the structure might get a little compromised, but it doesn't break.
The product team is a central node in every organization
The same is true of change in your company. Your product team, in this case, is the central node in your spider's web. It's the central node in every organization because it sits in the middle of things and works with sales, support, marketing, engineering – everyone!
This means that any change you make to the product team will impact everybody else in the organization, whether you want it or not.
One thing that you could and should do as a product leader, before you make any changes, is to not only strengthen the relationship between your node and other nodes, but also strengthen the relationships between marketing, sales, support, and engineering.
This will ensure that while the product team remains the central node in the organization, it isn't the only node keeping everything together.
In the end, when you change your product node, you want the other nodes to go with it (whether voluntarily or because you’re big enough to drag them onward) without damaging the overall structure of the organization.
Many people are not aware that when they change something within their product team, they accidentally change a lot of things in other teams as well, and that can be disastrous. You need to actively take your central role into account when making changes.
Change management strategies
Now, I'm speaking from the point of view of a remote-first organization. Klaus has been remote since day one, way before the pandemic. If you’re remote-first, you need to invest in documentation and communication and basically over-communicate at all times, otherwise, information gets lost.
However, even if you are in the office or you have a hybrid setup, I think we can all learn a lot about how to make communication work.
Communication plays a vital role in change management. As change moves from mode from node to node within the spider’s web, it has various effects on different nodes that you cannot always foresee.
People are bound to talk about those effects, and you can use that to your advantage. Let’s see how in our two approaches to implementing change.
Option one: from narrative to practice
Step one: Create a strategy and a story
The first approach begins with creating a strategy and a story. You look into what you want to change and why it’s important, you create a strategy, and importantly, you look at what will happen if you don’t make this change.
This is vital because every single person in your product organization wants to know what change means for them, and if you don’t give them a clear answer to that question, they’ll conjure up the worst possible outcomes.
You need to share your strategy and your story with your team. Explain that you are making this change because X happened and you want Y to happen, and if you don’t, Z will happen.
Step two: Explain, promote, and prepare
Once you and your team are clear on this story, you need to promote it among the other teams that the product team works with. Let's say you are changing from one Agile methodology to another – Scrum to Shape Up, for instance. This means there will be changes in how you triage bugs and put teams together.
All of this will impact not only the product team but also the support team. It will also impact the sales team too because you will have a different cadence for new features and a new way to gather feature requests. All of these things need to be explained, promoted, and prepared for.
Step three: Change the thing
Now it’s time to change the thing. That's usually pretty quick.
Step four: Monitor and course correct
You need to continue to monitor the impact of this change so that you can course correct. I have yet to see any change go exactly as expected. It doesn’t happen.
It’s like you finally have the spider web on the kids' hands, and they walk towards the next tree.
But they don't walk exactly parallel (because they're six) so the web stretches, and you have to say, “Hey, move closer together!” so they can get the spiderweb where it needs to go. Maybe you find a different tree on the way and you can shorten the journey by setting up shop there.
Now the thing is, there will always be disruptions. There will always be compromised structures within your spider’s web. That means that you want to invest in making people connect with each other while you're doing the change management.
Pro tip: Use office chat to your advantage
What I’m about to tell you is hearsay because I haven't worked in an office for over 10 years, but what I hear about working in an office is that people build connections not because they work side-by-side, but because they see each other at the coffee machine.
That’s true, as long as you're both at the coffee machine at the same time. If I have my coffee break at 10, and you have your coffee break at 10:30, I guess we'll never meet.
In a remote environment, you have to create “serendipity” for people to run into each other. You can do this by having interest-based channels on Slack, for example. There are a million other ways to do this, but let's say you create a parenting channel, which you and I both join because we both have kids.
Then, even though we have our coffee breaks at different times and in different parts of the world, we end up talking about our problems. We empathize with each other, and boom! I have a friend in marketing!
Now, I can tell my marketing friend about the changes that are happening in product, and they can share that news with their part of the organization. That's how interpersonal connections play a vital part in your change strategy.
Option two: From practice to narrative
Narrative to practice is one option for how to manage change. The other option is to turn that on its head and go from practice to narrative.
Step one: Change the thing
In this approach, you start by changing the thing. This happened, for example, with the pandemic.
Suddenly, everybody was working from home, and not because you did a very in-depth study about what's more productive and how to make people feel connected to their peers in a remote environment. The pandemic happened and you had to go home. That was it.
Step two: Monitor and course correct
Once you’ve made whatever change it is you need to make, it's paramount that you monitor this change so that you can course-correct when things go wrong. Course correction doesn't mean reverting to the way things were.
Course correction means taking the new situation and seeing how you can adapt it so that it works with the reality that you're now living in.
Step three: Create the story
The monitoring you’ve done is going to help you create a story. As humans, we are storytellers. We live through stories (that's why I'm telling you the story of the spiderweb). We learn a lot more from stories than from pure data.
You need to create a story about why this change – let’s say, working from home – is an opportunity or the solution to a problem and talk about how you’re going to carry this change forward into the future.
Step four: Explain, promote, and justify
Next, you explain, promote, and justify your decision to keep the change in place, revert back to the office, or move to a hybrid model.
Of course, the practice-to-narrative approach is like taking one node from the spiderweb and moving it out.
It’s like the product team just deciding to launch product 2.0 without talking to anyone else and saying, “Hey, it's out now! Isn't that great?” Meanwhile, the support team’s like, “Um... Excuse us? Does anyone have any documentation about these changes?”
Nevertheless, it works, especially for small organizations. That’s because while you're still five to 10 people, you do a lot of practice to narrative by default. It comes very naturally to us as humans to come up with a great idea and run with it.
In fact, we think this idea is not only great, it's the logical thing to do – everybody else would surely agree. And so we make the change, and then we create a narrative around it.
However, as they grow, future-looking organizations tend to first create the narrative within their team, and then bring in the change once the narrative is securely in place, and outreach to the other teams has been established.
Storytime
We're going to look at both of our change management strategies in a little bit more detail with an example – an example that is not spider web-related.
Moving to flexible work: From narrative to practice
Let's say you want to move to flexible work – not necessarily remote work, but rather you want to have more flexibility and you've decided that the product team is going to work more asynchronously.
If you go from narrative to practice, you need to first think about what it will mean for the product team’s work with the support team if your work is asynchronous.
Perhaps not everyone will be there during the usual work hours to answer customer questions that the support team might have, and you need to figure out how to mitigate that.
Similarly, sales teams sometimes ask product people to jump on a call with leads. That means you need an on-call calendar for your product managers so that you know that there will always be someone available during core hours.
By really thinking about what it means in practice if the product division moves to flexible work, you can mitigate the pain that this may create for the other parts of the company.
They will have to adapt somehow, and the easier we can make it for them to adapt, the easier it will be to get everybody else in the company to accept the change.
The reason for this move to asynchronous work might be very practical. Perhaps there's an amazing product manager in New Zealand that you want to hire, but because it's a different time zone without much overlap, you need to be more flexible about when work gets done, so you’re going to plan for it.
That's from narrative to practice. We have an idea that we want to change, we think about what impact this will have, and then implement it after we have talked to other people, promoted the change, and explained what this means for everybody who works with us.
We monitor how this is working out because we may need to help people use new documentation tools or explain how to write very succinct notes.
Moving to flexible work: From practice to narrative
Now, let’s look at it the other way around – from practice to narrative. Let's say your co-founder is from Brazil, and their parents get sick, so now, from one day to the next, they have to move to Brazil to take care of them.
Suddenly, you have a six-hour time difference. You have to be more flexible with your work because as Head of Product, you don't have eight hours of overlap every day with your co-founder anymore; you only have a couple of hours.
Now, whenever you want feedback from your co-founder, you need to think about the timing. Do you really need to go on a call? Maybe it would be better in a written format. Can you send them a Google Doc and ask them to respond in that? Much like with the pandemic, you need to build some flexibility into your work.
As more time passes with your co-founder in Brazil, you’ll get a clearer picture of how well this new arrangement is working. If it’s not going great, you’ll have to adjust how you’re working around and with the new situation.
This is probably going to be disruptive. It could work well in a small company with one product manager, one founder, maybe an engineer, and a support person.
However, if this happens when there are a few dozen, a few hundred, or even a few thousand people in the company, it might not go as smoothly as you'd like it to. As I said before, the bigger you are, the better it is to create a narrative before you put it into practice, where possible.
A summary for you to ponder
- Where things change influences how things change, so look at where and how you want to bring in new ideas.
- Awareness is the first step towards a strategy, so don't ignore things that are staring you in the face. It's much easier to run with a change if you recognize that this is happening, be it on the individual level or on an industry level; then you can put a strategy in place
- Stories keep humans aligned. Use them! If you are a horrible storyteller, work on your storytelling skills, and if that doesn't work, find somebody who can be a storyteller for you.
- Coordinate with the other storytellers in your organization because I bet you're not the only one.
