Software development happens in teams. That means every idea or change affects many people. So everyone involved – including technical staff – must contribute their ideas to the organization. Fearless Change and Fearless Journey offer the tools to do just that.

If you work in IT projects, sooner or later you’ll realize that many problems can be solved informally – just like in other areas of life. If you ask nicely, people will help you. It’s not uncommon for someone to solve a critical project issue while chatting at the coffee machine. When things are unclear, people tend to talk directly – in person, via video call, or on the phone – rather than writing an email and risking misunderstandings. And a private one-on-one conversation often helps when someone’s behavior in a large meeting is hard to understand. As helpful as these informal approaches are, they’re not enough to systematically introduce an idea into a company – that requires more than just one successful conversation.

In a previous post, we discussed how formal decisions can be undermined. We also know many ways how this happens. This leads to two consequences:

Decisions, Ideas, and Architecture

For technical staff, understanding how an organization makes decisions is essential – because software architecture involves decisions about technologies and code structure. These decisions involve developers, architects, and management alike. Being able to contribute to these processes helps increase your own effectiveness. These decisions especially impact developers and architects, who must live with them and may later be held accountable for the success or failure of a project that depended on them. That’s another strong reason to influence those decisions.

So the ability to moderate or influence decisions is key for technical staff. It’s not enough to recognize the best option – you have to make it happen. And informal approaches are especially valuable in that effort.

Fearless Change: Structuring Informal Action

What’s needed is a structured approach to using informal mechanisms to bring ideas into an organization. One-on-one conversations and chats at the coffee machine are certainly useful, but they’re not a complete solution.

Fearless Change offers a collection of patterns for exactly this. It’s based on two books by Mary Lynn Manns and Linda Rising: “Fearless Change – Patterns for Introducing Ideas” and “More Fearless Change – Strategies for Making Your Ideas Happen”.

One such pattern is “Token”: “To keep a new idea alive in a person’s memory, hand out tokens that can be identified with the topic being introduced.” I believe Linda Rising once used this pattern on me. Over fifteen years ago, I attended a Fearless Change workshop with her, where she handed out index cards with the patterns on them. I still have those cards – sometimes I see them lying around and they remind me of the patterns. Someone else once gave me wooden chips labeled “Innovation Tokens”. I still remember that idea too. Clearly, the “Token” pattern helps anchor an idea – and it’s a completely different approach than chatting by the coffee machine.

Another pattern is “Study Group”: “Form a small group of colleagues who are interested in exploring or continuing to learn about a specific topic.” This can be useful for introducing techniques like Domain-driven Design or Microservices. Beyond learning the content itself, you also form a group with a shared interest – people who care enough to engage with the idea. That group can be helpful for future initiatives too.

Following the pattern “Step by Step,” a Study Group might be a first (or second?) step, which could then lead to a prototype implementation and eventually a “Hometown Story” – a story about an internal success with the idea, which can help spread it to other teams.

There are also communication patterns:

Fearless Journey: A Game for Innovation

You could just buy the books, study the patterns, and create a plan for applying them to your situation. But there’s a playful alternative: Fearless Journey, a card game that helps a group plan Fearless Change together.

First, you define a goal – like introducing Domain-driven Design in your organization. The goal should be a real challenge. Then, players collect the obstacles and blockers standing in the way. Each player receives a set of strategy cards from Fearless Change. During the game, players solve the gathered problems using these strategy cards. One or more players can play one or several strategies to solve each problem – unless someone vetoes the solution, arguing the strategies are unsuitable.

The result of the game is a plan for solving the problems involved in introducing the idea – using Fearless Change patterns. These patterns can be used by anyone in the organization. In other words: you don’t need to rely on management – you can drive change yourself. Of course, management can also use the game to develop strategies with others.

Even more important is the social outcome: a group has formed and already started working together on introducing the idea. That group will likely remain engaged in the initiative. The game fosters cooperation – everyone solves problems with their strategies, which emphasizes collaboration. Because problems are only unresolved if someone vetoes the proposed solution, vetoes are rare – this leads to a constructive and positive atmosphere. By the end, most problems have a solution, making it easier to take the next steps. If some problems remain, that’s also useful – because it makes clear which issues still need attention.

Politics doesn’t have to be boring – it can be fun and useful. Interested in the game? You can download it for free or order it from the website, a card game that helps a group plan Fearless Change together.

First, you define a goal – like introducing Domain-driven Design in your organization. The goal should be a real challenge. Then, players collect the obstacles and blockers standing in the way. Each player receives a set of strategy cards from Fearless Change. During the game, players solve the gathered problems using these strategy cards. One or more players can play one or several strategies to solve each problem – unless someone vetoes the solution, arguing the strategies are unsuitable.

The result of the game is a plan for solving the problems involved in introducing the idea – using Fearless Change patterns. These patterns can be used by anyone in the organization. In other words: you don’t need to rely on management – you can drive change yourself. Of course, management can also use the game to develop strategies with others.

Even more important is the social outcome: a group has formed and already started working together on introducing the idea. That group will likely remain engaged in the initiative. The game fosters cooperation – everyone solves problems with their strategies, which emphasizes collaboration. Because problems are only unresolved if someone vetoes the proposed solution, vetoes are rare – this leads to a constructive and positive atmosphere. By the end, most problems have a solution, making it easier to take the next steps. If some problems remain, that’s also useful – because it makes clear which issues still need attention.

Politics doesn’t have to be boring – it can be fun and useful. Interested in the game? You can download it for free or order it from the website. And you can watch Software Architektur im Stream to see how Tanja Friedel, Ralf D. Müller, and I play Fearless Journey and reflect on the experience (only in German, sorry!).

Conclusion

The Fearless Change patterns give technical staff a toolkit to influence decisions – such as software architecture – through informal means, without needing formal authority. That can make their work easier. But it also means that you don’t have to passively accept decisions just because someone higher up made them. You can – and should – advocate for your ideas, especially if you believe that bad decisions could cause serious harm. In that case, technical staff can’t just hide behind management. They must actively work to implement better ideas within the organization.

This is a translation of my German article at Java Magazin.