Issue No. 23

This week's newsletter was painful to birth... so painful that it took me two weeks to write it! So much for trying to ship a weekly newsletter.

I went deep, and it wasn't easy to write. I hope you find the lessons valuable.

💬 In this issue, I cover:

• 🛠️ The IKEA Effect - The idea that people like things more when they make them, and how this can help with changes at work.
• 📈 I Screwed Up! - How I messed up by not using the IKEA Effect in a change I was making, which led to a messy situation.
• 📚 Lessons Learned
  • 💬 Communicate 'the why' early - Explaining why you're doing things from the start is important.
  • 🤝 Establish a shared 'why' - How good it is when everyone agrees on the problem so they all want to fix it.
  • 📝 Communicate a 20% draft, not a finished masterpiece - Encourages sharing early, not-done versions to get feedback and work together.
  • 🔑 Our role or position has power, so use it wisely - Remember that what we do affects how much others want to help.
  • 🫴 Involve People and Do Smart Delegation - Getting people involved isn't enough. We need to hand out work in a smart way.
  • 🗣️ Use language to get buy-in - Use words that make it feel like everyone's working together.
  • ⏰ Give time for feedback - Give people enough time to think and share their thoughts.
  • 🐢 Go Slow to Go Fast - Getting people involved from the start might seem slow, but it makes change happen faster overall.

The IKEA Effect and How I Screwed Up!

I recently had an experience where I screwed up in a change I wanted to introduce. I should have followed the advice I often give, but because I didn't, the situation got messy.

When making a change, I firmly believe in doing it with the impacted people. In a recent newsletter called "The Collective Power of Co-Creating Shared Principles", I wrote:

When creating principles, the best approach is to involve everyone, utilising the IKEA effect. This way, instead of leadership deciding the principles, everyone's input through co-creation leads to increased buy-in and adherence.

🛠️ The IKEA Effect

What is the IKEA effect? Wikipedia has a great definition:

The IKEA effect is a cognitive bias in which consumers place a disproportionately high value on products they partially created. The name refers to Swedish manufacturer and furniture retailer IKEA, which sells many items of furniture that require assembly.

A 2011 study found that subjects were willing to pay 63% more for furniture they had assembled themselves than for equivalent pre-assembled items.

We can use this when making changes in an organisation by co-creating the change with those impacted by the change because when people have a part in defining, designing, and refining, they're far more likely to feel ownership.

It creates buy-in, making folks more likely to understand and adopt the changes.

📈 How I Screwed Up!

Unfortunately, in my enthusiasm for implementing some changes with a client, I ignored my advice, and the situation blew up.

By sharing my mistakes, I hope you can learn from them.

Writing this up will help me retrospect the situation and further internalise the lessons I've extracted.

🧩 The Situation

While working with a client, I reviewed the organisation's process and looked for improvement opportunities.

As I got to know the organisation, I realised that things were working well at the team level; however, it soon became apparent that Engineering felt like a black box at the broader organisational level—their higher-level projects and when they were predicted to land needed to be visualised. In addition, I uncovered several other common issues with how the organisation worked, which were typical for their stage and type of business (a B2B SaaS).

I want to refrain from discussing further specifics of their organisation. Still, the traps I fell into were classics, and I fell into ALL of them. So, it's a good case study of how not to make a change.

I soon recognised some issues, and my conversations with the CPO and CTO backed up my observations. The areas to work on were also part of the mandate I received in my mission brief, so I set to work.

I had a good idea of what good looked like in this situation, so I got the CPO and CTO together for a workshop, and we worked through my rough draft of a proposal on a whiteboard. I wanted to get high-level alignment between us before going to the team (partly because I was serving in an interim role, so I needed to ensure that whatever I did had longer-term support). What we shaped made a lot of sense to us.

I took our rough outline and started working on a formal document that took all of our hasty sketches and turned them into a process proposal that the organisation could use as a living document that explained how the organisation worked (with the idea that as the process evolved, the document would evolve, too).

It was a lot of work. The document grew longer as I tried to combine everything into something cohesive and comprehensive. Our proposal didn't represent a considerable change for the organisation; however, there was a change in terminology, many clarifications, and a couple of shifts at the organisational or philosophical level.

I did the big reveal on a Friday before I went on a week's holiday. I wrote up what I thought was a great Slack message. I shared it with everyone, saying they had time to read through it over the next week, that nothing was set in stone, and that this was a proposal, a starting point for us to iterate on. I told them, "You know, this needs to be your process. You are going to live this. So you really need to give feedback on it".

The response was a mixture of a few negative comments and dead silence.

Predictable, I know! It is harder to write about this and to relive these moments with hindsight than it is for you to read about it!

So what happened here?

I had good intentions.

I was trying to solve a problem for the group.

Let's talk about what I did by viewing this through the lens of how I should have done things.

📚 Lessons Learned

I've already shared some of the ideas in this section in previous issues of this newsletter, and I've even gotten them right in the past. Here is what I should have done instead.

💬 Communicate What You Are Doing and, Most Importantly, "The Why" Early!

I worked in the background. Folks knew this work was part of my mission with the organisation (I had shared it with them as a group and in my one-to-ones during my onboarding).

But before I even ran the workshop with the CPO and CTO, I should have told folks that I was starting to tackle this part of my mission and reminded them why it was necessary.

🤝 Establish a Shared "Why" and Define the Problem Together

I should have involved people in defining the problem. When people feel like they're solving a problem together, they have more investment in it. If I wanted input, I should have started at the root cause, not the end. You permit people to give feedback when something needs to be defined and is unfinished.

I'm always amazed at what people and groups come up with that may not have occurred to me.

It's because each of us works differently. It's not because I am deficient that I can't come up with all the ideas. It's that we see things differently. We have different experiences.

So, to harness these differences between us, a wider divergence phase that includes more views around the problem will help us converge on a better problem statement and, by extension, a better solution.

Also, when people are involved in defining processes, methods, or how things should look in a change, they get a broader understanding of their work.

📝 Communicate a 20% Draft, Not a Finished Masterpiece!

I started with the idea that because this was part of my mission to tackle, I had a mandate to change it, and I thought I knew what needed to be changed. Second, I came out with a polished proposal document, which I had put a lot of thought into because I really cared about it. I wanted to solve the problem, but the document was so polished, it looked so complete and so professional, that it didn't really communicate that there was much room for people to get their fingerprints on it or have any input.

Unconsciously, when people are presented with a fully prepared proposal, they don't see an opportunity to contribute to its creation.

Consider being invited to a dinner party where the host has meticulously prepared every dish before you arrive. Your only role is to enjoy the meal, not to influence its flavours or components. This is akin to being shown a completed proposal; you can appreciate it but can't impact its development.

However, imagine a different kind of gathering—a cooking party. Here, you're not just a guest expected to dine; you're invited to select ingredients, taste test as the meal comes together, and offer suggestions for improvement. In this scenario, you're deeply involved in the culinary process, making the final meal partly your creation. This engagement and sense of ownership are what we aim for when involving people from the early stages of a project.

This doesn't mean everyone needs to be in the kitchen for every step, but inviting input and collaboration early on ensures the result is richer and more satisfying for all involved.

I could have asked for input, asked a few volunteers to work with me, or invited a few people to work with me. Even if I didn't include everybody in the group, at least some members could have represented their colleagues by providing their input. I could even have asked those people to gather input from others and ask for reviews from others.

🔑 Our Role or Position Has Power, So Use It Wisely!

I also discounted the impact of my position. I was at the same level as people's bosses. I was presenting something that looked polished and finished—something that a small group of senior leaders (who everyone reported to) had worked on.

Giving feedback to your boss, even when they ask for it, always creates friction. There's also always some perceived risk. It's quite natural to worry that your manager might perceive the feedback as critical and that negative feedback could somehow limit your career.

So, it was predictable that most people would be silent when I asked for input.

I've discussed ways I could have involved people from the start. These would have helped, but they wouldn't have addressed the power that came from my position.

Instead, I should have delegated certain parts of the definition or certain parts of the design to the team members rather than doing it myself.

🫴 Involve People and Do Smart Delegation

As an aside, if I were to delegate parts of the work to the team, I would have to give them a very explicit brief, including how I would have handled the results of their work.

It is not helpful to gather a group and then say, "Okay, you go off, and you come up with three possibilities, and then we will go through a process to figure out which one is going to be the best solution for us at this time or at least the best thing for us to start with as a solution and then we can evolve it as we go along".

How are we going to decide between the options? Will I decide or will we decide together?

What options are off the table? What things are just out of bounds that you wouldn't accept?

We don't want to be in a situation where the team choose a solution that we will definitely be rejected. The disappointment on the delegee's side will be huge after spending a lot of time coming up with a solution, only to have it rejected. On top of the damage that would cause, good luck trying to involve them again in a similar situation! It's a perfect way to destroy trust between the person delegating and the person doing the work.

It helps to think through the worst things that could happen and set some boundaries around what options will be acceptable so you don't end up in a worse situation.

🗣️ Use Language to Get Buy-In

Finally, some subtle things about my language came through in my request for feedback that torpedoed things. I presented this as "this is the process I worked on. I developed"

I used "I" language, which communicates ownership, and I used the past tense, indicating completion.

I should have talked about "we're working on" and "we are developing" so that it's clear that the process is still ongoing.

⏰ Give Time for Feedback

Another thing that I realised as I reflected on this situation was that when I asked for feedback, I had just dumped this big document on very busy people with a very, very broad ask. They had just been exposed to the information and didn't feel they had enough time to absorb it.

I could have started with a more progressive series of questions, starting with an open but not quite as broad question such as "What's your first impression?" or "When you look at the totality of this, what stands out for you?".

Then, I could have asked more specific questions.

Imagine you're taking a survey about your favourite foods. If the first question asks, "What do you like to eat?" you might struggle to give a comprehensive answer on the spot. Your mind might go blank or only remember a few dishes.

However, if the survey starts with a broad category like, "What's your favourite type of cuisine?" and then follows up with more specific questions like, "What's your go-to dish in that cuisine?" or "What ingredients make that dish stand out to you?", you'll likely find it much easier to provide detailed, thoughtful responses. The guided approach helps jog your memory and lets you clearly articulate your preferences.

When asked a super broad question, people often can't come up with a helpful answer. But if you start with a broader question that provides some context and then ask more specific questions, people can often give you much better feedback.

I should have also asked questions like:

• How will this address our problem?
• What do you see needs to be added?
• What is extra?
• What might we add?
• What aspects have we forgotten?

Then, depending on what they said, I could have asked many more specific questions. That would have helped people give more specific responses that would have been much more useful.

🐢 Go Slow to Go Fast

So, involving people has many upsides, from problem definition to shaping how the project is implemented.

Some people feel this will take a long time and that working on it yourself is faster. That might be true.

I did get to a pretty good document quite quickly, much faster than a committee, that is for sure!

But let's look at this in the context of the whole change, from idea to solution to implementation. I wasn't counting the portion of the change that's involved in persuading people to accept the change to get them to understand all the thinking behind it and to have them do whatever the change is with some enthusiasm instead of just mindlessly complying.

It's either you spend it at the front, or you spend it at the end.

And I'm pretty sure which one I should have chosen and will choose again.

I want to highlight a real danger I realised from the feelings I felt inside me during all this. If you do the work without involving folks, you can interpret your team's lack of input as not wanting to take the initiative or take any responsibility.

If you go down the path alone, you might feel burdened, like you have to solve all the problems thrown at your solution. You might start resenting the people who report to you, and you could become much more directive because you figure your team won't take responsibility anyway. So you could end up feeling like you have to tell them what to do, which will likely cause them to resent you, leading to a damaged relationship where the trust that may have been there is completely gone. And that would be a shame because all of us have worthy ideas.

If we can find ways to work together, we can achieve incredible outcomes.

🎬 Summary

To sum it up:

From the start, share what you're doing and why.

Get people involved in figuring out the problem. This helps everyone commit and come up with the best solutions.

Don't show others a finished product. Leave parts incomplete so people can share their ideas.

Know that your role can affect others.

Be smart about involving others and giving them tasks. Point out areas that can be changed for different situations. Make it clear what must stay the same and where people can add their touch while still getting the desired result.

Use words like "we" and the present tense to stress that the process is ongoing and collaborative.

When asking for feedback, make it clear that the work is still a draft and point out areas where individual input is welcome. Give people time to think about the information and ask more focused questions to gain valuable insights.

Take the time to involve others throughout the change process to get better results and maintain trust and relationships.

So that's the IKEA effect and how to use it based on my textbook failures. Create ways for people to shape the change throughout the process, from the definition to bringing it to life.

🔦 Highlight of the Week

This is a good reminder from a genius!

💬 If you had some thoughts while reading this, I would love to hear them in the comments.