The Yahaba Technique

Introduction

How are our future concerns represented in the decisions we make today? How can the people who will inherit our world influence actions we are taking and the policies we put in place? How shall we balance the needs of today with the needs of tomorrow?

In 2015, representatives of residents of Yahaba, a small town in northeastern Japan, went to their town hall to take part in a unique experiment. Their aim was to develop policies that would influence the future of Yahaba. But this time, there was a twist. Before debating municipal policy, half the participants were asked to put on ceremonial robes and imagine they were from the future, representing the interests of the current citizens' grandchildren. Specifically, they were told to imagine they were from the year 2060 and therefore representing the interests of a future generation. The results were very encouraging. Not only did researchers observe a "stark contrast in deliberation styles and priorities between the groups," the concern for future generations was infectious — among the measures on which consensus could be achieved, more than half were proposed by the imaginary ‘grandchildren’.

Organisations have a similar challenge. Like councils and governments, businesses need to think very carefully about the long-term. This is not only because most businesses hope to be successful not only today but also tomorrow, next year and in five years’ time and thus create a long-term value for shareholders but also because some policies, strategies and investments take many months if not years to yield results.

Concerns of tomorrow are therefore very relevant today. And whilst the time horizon most organisations today consider is typically in years rather than decades, the challenge remains the same: How do we practically bring considerations and perspectives of the future people into our conversations? How do we ensure our decisions reflect and take into account the viewpoint of people who may be in our roles in one, five or even ten years’ time? As I wrote elsewhere, long term success is very closely linked to the organisation’s ability to grow its overall maturity and that often involves making difficult trade-offs between the short-term and the long-term. Only organisations that get this balance right can hope to remain viable in the long-run.

What is the Yahaba technique?

In business and especially in tech there’s very often a tension between things we absolutely must complete here and now (e.g. because our commercial success directly depends on it) and things that we have to focus on in parallel so that we can continue to grow, remain adaptive, scale our operation without impeding agility and be able to innovate also in the medium and long-term.

To turn this tension into an advantage, to make more informed decisions and to properly examine what really matters to us and why, I propose the Yahaba technique.

Here’s how to use the Yahaba technique in practice:

  1. When considering a strategic, organisational, structural, technical or other significant decision, bring together a small group of people whose input is relevant for the decision. In practice these could be experts in the field, senior leaders and managers who will need to lead the implementation of the decision, people who will be impacted by the change the most, customers, stakeholders etc. Keep the group small, ideally between three and eight.

  2. Designate up to a half of the group participants (i.e. typically 1-5 people) to be the Shōrai (将来, Japanese for ‘future’). The rest of the participants stay in their ‘normal’ roles i.e. represent their perspective on the matter as they would normally do.

  3. The role of the Shōrai is to put themselves in the shoes of the people who will have to live with the decision being discussed and to represent the view of these future people during the discussion. The Shōrai are expected to come up with arguments, ideas, challenges and proposals to shape the decision being discussed in a way that they believe would be most favourable from the perspective of people who will be leading the business, enhancing and operating the platform or running a business process in a few years’ time.

  4. The group as a whole explores the decision in question from various perspectives and aim to reach a consensus about a set of specific proposals, actions, ideas and approaches that, in their view, best represents the varied views in the room and balance the different outcomes and concerns voiced during the conversation.

A few things to keep in mind

Running a good Yahaba session is not difficult, but there is a number of considerations you should keep in mind when using this technique:

  • Avoid making the group too large. My strong recommendation would be to limit the participants to the maximum of ten people, ideally less.

  • How do you decide who will play the role of a Shōrai? It is best to start with asking people to volunteer. Typically, people who are most concerned about the future implications of the decision(s) in question will happily put their hand up. At the same time, it is also insightful (both for the group and for the individual) to invite someone who typically tends to favour short-term concerns over the long-term ones to be one of the Shōrai. It not only forces them to think differently, but it also makes it possible for the rest of the group to obtain a new perspective on the matter in question.

  • If are a Shōrai, your job is to be a passionate but considerate and reasonable advocate of the concerns of future people (colleagues, customers, leaders, stakeholders etc). Your task is not to overwhelm the rest of the group with a set of purely ‘self-serving’ demands or to dismiss other people’s concerns for the urgent issues of ‘today’. Also, consider that too much emphasis on the long-run may result in failing in the tasks of here and now. This in turn may mean there will be no ‘long-term’ anymore and thus taking a position that’s too biased towards the future may be self-defeating.

  • It is a good practice to rotate the role of a Shōrai to different people. This can be done for every decisions/session or even once or twice during the same session. The aim is to come up with the best possible argument from both short and long-term perspective and allow the group to discuss these fully.

  • It helps to have a facilitator who will ensure the discussion is kept focused, that arguments are presented clearly and that people stick to their roles. The facilitator should also help capture different arguments being presented so that the group can explore them properly as well as actions agreed and decisions made.

  • Yahaba sessions could be as short or as long as you see fit — it all depends on the number of participants, nature of the decision being discussed and complexity of perspectives. As a rule of thumb though, my recommendation is to keep the session between 30 and 120 minutes. A shorter session is unlikely to enable all perspectives to be meaningfully considered. On the other hand, sessions longer than two hours tend to gradually lose focus and you may find yourselves going in circles.

  • It may not be practical or desirable to run a full-fledged Yahaba session for every decision. Consider the significance of the decision you are making and the risks involved. Based on that you can determine if and how the session should be run, who should be invited, how long it should be etc.

  • When running the meeting remotely (e.g. via Teams, Zoom etc) you may find it helpful for the Shōrai to temporarily add the word ‘Shōrai’ to their name. Alternatively, the facilitator may post who the Shōrai are into the meeting chat.

A Yahaba session in practice

Here’s a simple made-up example of how a team-level Yahaba session may look like in practice. In this example session, taking place at a on-line clothing retailer Peak Cloud Ltd., we are observing one of the teams trying to decide about the best approach when implementing a new major capability. At a senior level, the nature of the discussion, the time horizon people are concerned with and the trade-offs involved would, of course, be different. But the example below should illustrate how a simplified Yahaba session may look like and how people in the Shōrai role can play a vital role in illuminating the consequences of decisions being taken.

The participants in this session are:

  • John — Scrum Master and session facilitator

  • Claire — Solution Architect

  • Sandra — Lead Developer

  • Marcus — Product Owner

  • Tom — Senior Developer

  • Anthony — SRE

John: Hi all and welcome to our Yahaba session! Today, we will be talking about a rather significant decision we need to make. As you know, over the next few sprints Marcus would like us to develop a new multi-level filtering capability for customers who are looking to buy one of our products and want to filter based on a range of criteria. We have an existing solution in place and can look to enhance it to support the new requirements but Sandra raised a concern about that due to the complexity of the code in that area. We all know there’s a deadline we are working towards and there’s a lot to do. To make sure we are making an eyes wide open decision about the implementation approach, we decided to run this Yahaba session. We have about 45 minutes so let’s get started. Is everyone ready?

(people nod)

John: Great, thanks! So, first things first, I am happy to be the facilitator today. Is everyone happy with that? Awesome. Next, we need to appoint our Shōrai for today. Any volunteers?

Sandra: Yes, happy to be one of the Shōrai today.

John: Thanks Sandra.

Anthony: Me too.

John: Thanks Anthony! Anyone else? No? Ok, fine, let’s do this. Marcus, do you want to set the context please?

Marcus: Sure. As you know, we have a set of major new product product launched coming up in July and that will significantly increase the number of products and their variants on our website. Having a really good filtering capability is essential and we need to have it on day one to maximise the conversion from the outset. I appreciate there are challenges in implementation of the filtering logic, but we just need to get it done.

Sandra (Shōrai): Thanks, and I get that Marcus. As a Shōrai though, I am now thinking how this will feel like in 6-9 months’ time. Because of the decision being discussed today to simply bolt on a lot of additional logic on top of an already complex filtering mechanism, I am now stuck with a massive amount of complexity in this area of code, it keeps constantly breaking and filtering is now very slow. Our customers complain about it and it is affecting our conversation significantly. The team is now spending a huge amount of time just fire-fighting issues with this logic and we can’t support any more enhancements.

Anthony (Shōrai): I agree Sandra. Operationally, this is nightmare. Because the filter logic is tightly coupled with the rest of our system, any deployment is now very slow and error-prone and we tend to introduce defects which are hard to detect and even harder to fix. The amount of testing we now need to do is huge even for basic changes which have nothing to do with filters!

Claire: Hang on. It can’t be that bad! Yes, things are coupled but it’s working fine now and it’s not causing us that much trouble, is it!

Marcus: Exactly! Plus, as I said, we really can’t afford to delay this — it has to be done by July!

Tom: I agree with Claire that this is not causing issues now, but I want to hear more from Anthony as one of the Shōrai, about the operational issues. Can you please elaborate?

Anthony (Shōrai): Of course. What I am seeing now, speaking as a Shōrai about nine months in the future from the rest of you, is that the code is now so complex that none of the teams are prepared to touch it and the we struggle to test it effectively. Our deployment cycles have increased because of the constant back and forth around broken filtering functionality which nobody can fix. And when John asked us how long it would take to refactor it, the answer was at least three months!

John (facilitator): OK, thanks everyone. Sandra, Anthony, what are you proposing we do?

Sandra (Shōrai): As I said, I now see major issues with the way filtering works because we took the shortcut nine months ago to meet the July deadline…

(Marcus interrupts…)

Marcus: Well, Sandra, if we don’t get this done by July, your concern about complexity etc. will be irrelevant as we will miss our yearly targets, so…

John (facilitator): Hang on, Marcus, let our Shōrai speak please. Sandra, you were saying?

(Sandra explains her concerns from a perspective of someone working on the code in the future and together with Anthony adds a number of examples about things that are causing problems)

Sandra (Shōrai): …and to avoid this scenario, I propose to split our work over the coming weeks into two streams. Stream one will be about separating the existing filtering logic from the rest of the system which will alleviate a significant part of the operational pain Anthony is talking about as we will remove all the coupling. The second stream will be focused on building the new requirements Marcus mentioned.

Claire: Yes, but that does not solve the code and logic complexity issues you called out Sandra.

Sandra (Shōrai): No, it doesn’t, but it does significantly reduce the operational impact AND means we can still get close to July with the new functionality.

Tom: I am ok with that, but when will we refactor the rest of it? I mean, we will still have a hugely complex code in this area!

Marcus: If it helps, I am fine with blocking up to two months of our roadmap from August to allow for a proper refactoring of this.

John (facilitator): Would that work Sandra? Anthony, Claire — what are your thoughts?

Sandra (Shōrai): Yes, with encapsulation done I think two months works.

Anthony (Shōrai): Works for me. As long as we have an independently deployable and encapsulated module I am happy to go ahead.

Claire: Fine with me too. But I will need time over the next few weeks to work with Tom and Sandra to shape how the design for the new filter will look like so that we can hit the ground running in August. Can we put some stories in for that John?

John (facilitator): Sure. You happy with that Marcus?

Marcus: Yep, I am fine. Thank you.

John (facilitator): OK, great. Seems like we have a way forward. I will capture the actions and the summary of our conversation and share it with you. Thanks all for this session!

Conclusion

As you can see, this technique can be used at various levels of the organisation (from the exec board, to teams and down to individuals) and in many different contexts and to varying degrees. My recommendation is to try to include an element of Yahaba in any decision you are making. After all, considering future concerns is a healthy habit to develop and it will also help you hone your systems thinking skills. I hope I managed to make a good case for the Yahaba technique and encourage you to try it and make it part of your toolkit when trying to make important decisions.

The Yahaba technique is, of course, not a panacea and it will not magically enable you to solve all your problems. For it to work, people need to be engaged, argue in good spirit, be prepared to listen to each other and consider a range of competing perspectives. Having said all that, just the act of giving a ‘voice’ to the future people can be immensely valuable and is very likely going to help you and your team or organisation to make much better decisions and achieve better outcomes. And in my mind, that’s well worth it!

Previous
Previous

Empiricism makes everything better

Next
Next

How I think about: Organisational Maturity