From Wikipedia

Jeff asked this in the comments:

Do you have experiences moving an organization to a culture of “it’ll probably work/we’ll deal with problems as they happen” from “you haven’t convinced me yet/what if it doesn’t work”?

What if you’re trying to effect change in your organization? Where do you start?

Here are five things that can help you implement a fail-fast, fail-often culture:

1. Find out who your supporters are
2. Focus on implementing working solutions to problems
3. Use rough consensus
4. Get management support for implementing solutions
5. Manage the irrational well

I’ll take each of these points:

1. Find out who your supporters are

You do need to assess if you really are alone in wanting this change. Talk with people! Because if you really are completely alone in your opinion, you might want to reconsider whether this is the right time, or place, for the change.

2. Focus on implementing working solutions to problems.

“Working code” is a good metaphor for this. You want to offer possible ways to try out a fail-fast way of working, maybe by focusing on small projects or just your own work first. Prove that your way is better!

Stating your pre- and post-conditions around the change is a powerful tool (see, life is just like code!). But we’re hacking people’s behavior, and the organization’s ability to recover from failures.

And accept that maybe you never get everyone on-board. But at least your own work will benefit from the changes.

You must also make sure your solution solves a relevant problem. Assessing relevancy of problems is a whole other topic. It’s likely the most important question someone working in IT needs to answer before making changes. We’ll talk about that in a future blog post!

3. Use rough consensus

Cultural change affects everyone in an organization. So, to make it happen, you need most, but maybe not all, of the team to support it. Once you propose tests to try things out, or you’re implementing new policies, you’ll need a process for deciding what to do next, when something isn’t working and when you’re done.

In my keynote, I referred to the IETF’s model of rough consensus. They refuse to define a method for determining what exactly this means, to avoid gameifying the decision making process.

Identifying a chair, or project leader who is responsible for articulating the “sense of the group” is critical. This avoids letting a single vocal person paralyze decision making.

Also, there needs to be some kind of back channel that records opinions. Mailing lists with searchable and linkable archives are great for this. Corporate email hidden away in personal inboxes are a waste. Collaboration tools like wikis or other kinds of shared documents on the web can be critical for building consensus. And they are underused.

4. Get management support for implementing solutions

Nothing kills revolutions in business faster than management opposition. If you want something to change, part of your work is convincing your manager or boss that the change is important and necessary.

Present evidence of the problem and clear thinking about the solution you’re proposing. Maybe you come up with test output, customer complaints, or concrete examples of how much better things will be after the change.

If you’re the boss, you need to support the people who are making these changes. Give them room to make some mistakes, and help them out when they face inevitable opposition from their teams.

5. Manage the irrational well

When I listed my first three points to a colleague last week, she pointed out that I’d completely overlooked irrational situations.

Change can inspire fear. When a person is afraid, they can get irrational and oppose anything that might threaten them. Managing irrational people is a skill that you can learn.

There are some books on this, like Crucial Conversations Tools for Talking When Stakes Are High, Second Edition. In the end, you just need to practice talking with people, and talking about difficult subjects.

The first step is recognizing the early signs that a person is feeling afraid, and finding ways to accommodate or work around their feelings. No two people or situations will be exactly alike, but there are recognizable patterns and learnable responses.

Epilogue

While writing this, I enjoyed this brief interview with Steve Jobs about collaboration.

I also enjoyed this article: Design Principal. In it, the firm’s leader talks about when to say no to a client – with a “four Ps checklist”: People, Project, Profit, Plate. Along with prompting questions. Great food for thought when tackling big changes projects.