Episode 23: The IKEA Effect and How I Screwed Up!

This is a project by Jeremy Brown.

I'm a journeyman sharing insights on leading product and engineering teams.

Building products and exploring technology.

As I build this newsletter and a podcast and a YouTube channel in the

open you'll get updates occasionally.

Issue number 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.

We're making a change.

I firmly believe in doing it with 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

utilizing the Ikea effect.

This way, instead of leadership, deciding the principles.

Everyone's input through co-creation leads to increase 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 then for equivalent preassembled items.

And we can use this when making changes in an organization 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 the clients, I ignored my own advice and the situation blew up.

By sharing my mistakes.

I hope you can learn from them.

And writing this up will help me retrospect the situation.

And further internalize the lessons I've extracted.

🧩 The Situation

While working with the clients I reviewed the organization's processes.

And looked for improvement opportunities.

As I got to know the organization, I realized that many things were

working well at the team level.

However it soon became apparent.

That engineering felt like a black box at the broader organizational level.

They're higher level projects.

And when they were predicted to land needed to be visualized.

In addition, I uncovered several other common issues with

how the organization worked.

Which were typical for their stage and type of business.

A B2B SAS.

I want to refrain from discussing further specifics of their organization.

Still the traps I fell into where classics.

And I fell into all of them.

So it's a good case study of how not to make a change.

I soon recognized 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 sat 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 a 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.

So 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 organization could use as a living document.

That explained how the organization worked.

With the idea that as the process evolved, the document would evolve to.

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 organization.

However, there was a change in terminology, many clarification's

and a couple of shifts at the organizational 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 it through 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's 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.

So 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's 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 organization.

I'd shared it with them as a group and in my one-on-ones during my onboarding.

But before I even ran the workshop with the CPO and the 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.

And it's because each of us works differently.

It's not because I'm deficient that I can't come up with all the ideas.

Is that we see things differently.

We have different experiences.

So to harness these differences between us.

A wider divergent 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.

📝 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 looks 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 flavors or components.

This is akin to being shown a completed proposal.

You can appreciate it.

But can impact his 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 to for improvement

in this scenario, you're deeply involved in a 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.

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 even

invited a few people to work with me.

Even if I didn't include everyone.

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.

And some side notes on this point.

Obviously, we want to create psychological safety in an organization

and generally you need that in place before you can truly harness the team.

In any change you're making.

And how you give feedback is crucially important.

Techies often need help with this.

And they can be perceived as negative due to bad communication.

I wrote some thoughts about this in a recent LinkedIn post and my friend,

Péter Szász wrote an article for managers and how to deal with negative

behavior that is also well worth a read.

And I'll put the links to those in the show notes.

So it was predictable that most people would be silent

when I asked for their 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's not helpful to gather a group and then say, okay, you go off and you come

up with three possibilities and then we'll 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.

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 seminar situation.

It's a perfect way to destroy trust.

Between the person delegating and a person doing the work.

It helps to think through the worst things that could happen and set some boundaries.

Around what options.

We'll be acceptable.

So you don't end up in a worst situation.

🗣️ Use Language to Get Buy-In

Finally, some subtle things about my language came through in my request

for feedback, that torpedo things.

I presented this as this is the process I worked on I developed.

I used I language.

Which communicates ownership.

And I use the past tense indicating completion.

I should have talked about, were 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 realized 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 favorite 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 favorite 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 asked questions, like how will this address our problem?

What do you see needs to be added?

What is extra.

What did we add?

Or what made me 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.

And that might be true.

I did get to pretty good document quite quickly.

Much faster than a committee that's for sure.

But let's look at this in a 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 complaining.

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 we'll choose a game.

I want to highlight a real danger.

I realized from the feelings I felt inside me during all of 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 of all of us have worthy ideas.

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

🎬 Summary

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 the 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 distress.

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 as 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.

We cannot solve our problems with the same thinking we used when we created them.

Albert Einstein.

That's all for this week.

Folks have a great week,

Jeremy.

Don't ignore your dreams.

Don't work too much.

Say what you think.

Cultivate friendships and be happy.

PS, I'm doing a small experiment.

You're listening to this newsletter in podcast format, both in audio, only

format here and on most platforms and available in video format on YouTube.

💬 Please do take a second to like 👍 subscribe or give me some quick

feedback on this issue in the comments.