Creating a tech vision and get everyone onboard

We recently finished a tech vision work where we reached a new vision that everyone understands and see the benefits of. The vision is quite different from where we stand today.

When we started this work, reaching a vision that people agreed upon felt almost impossible since we started off having people in different “camps” with completely separate beliefs around how the future should look. We still have some difference in opinions but everyone understands and buys-in to the vision we are going for.

I have been reflecting a bit on things that worked well during this project and the things that could have been better and will in this post invite you to follow my reflection journey.

Learning #1. Starting the change with a vision that is far from where you are today is a bad idea.

First learnings was to not go into solution space too early. All of us have heard that before but still so easy to fall into that trap.

The first start of this project was that I together with my peers created a first draft of a vision on our own. We stated some of the problems, proposed a new vision with some reasoning behind that belief together with a question of what would be needed to get to that vision and would it be a good idea. When we presented that to our leadership team they said – hey, you are moving too fast into solution space, we need to analyze the problem definition better before going for a solution.

That was a good idea. One reason for that was that we could find other solutions than the one we had gone for directly but I think the most important reason was that we were moving too quickly for people to be able to follow. Me and my peers had been thinking about this problem area for a long time on our own, but the problem domain was new for the rest of the leadership team. We needed to take one step back and involve more people in the process to get them onboard and make sure we did not miss any other opportunities.

Learning #2. Starting from a problem statement, having clear decision criteria and a process built on involvement makes all the difference.

The second start of the project was to clearly set the stage for the work that we were going to do together. We started with a clear problem statement, defined what is important for us to achieve, defined a structured approach where we could compare different solutions toward a pre-defined decision criteria and a process that was build on involvement but also clearly stated how decisions would be taken in the end.

I presented all this as the introduction to a workshop where a big group of people worked on analyzing the different paths (vision options) that we could take. They defined what the different alternative would mean and evaluated the strength and weaknesses off the different options based on the decision criteria that was defined. This workshops successfully kicked off the work and we left the workshop with one option already removed and people that had started thinking seriously about this problem with an aligned view of what we wanted to achieve.

Learning #3. Collecting peoples opinions and thoughts is valuable to increase the feeling of involvement.

We had four different options and a clear definition of the criteria that were important for us and quite early we decided to send out a survey to collect the subjective opinions that people had about the different options. We wanted to get a feel for what people were thinking and we also wanted to identify areas of disagreement since that was important data to help us understand which topics we needed to discuss.

What we learned from the survey was that there were no clear “winners” in the game and that there were alignment of opinions in some of the areas and misalignment in others. We were not able to select a winner or exclude any of the options based on the survey result.

But even if the data was diverse and we could not take any clear actions based on the data, I found it valuable for us to have done it. We had given an opportunity for people to voice their opinions and show that we were taking those into account when deciding about how to continue. Doing that we showed that their opinions were important. We also showed that we took an objective approach to finding our answer which I think is important to reduce the risk of our own biases coming in our way when taking a decision. This was especially important in this case since people felt strongly about the topic and knowing that your voice have been heard and taken into account makes it easier to accept a decision even if you disagree.

After doing this survey even more people were engaged in the work that we were doing to find our vision.

Learning #4. Discussions on topics that people feel strongly about requires structure and strict facilitation.

The next step was to dig deeper in each of the options that we had (we were now down to four). We wanted to get a better understanding of each of the options and also identify if we needed to do any tech spikes or other deeper investigations to learn about things that were unknowns and important for our decisions. People had strong opinions that were very different so I was a bit worried about how these discussions were going to develop.

My plan was to set up sessions for each of the options and I started with the one where it was most likely that we needed to do more deeper investigations. If we were going to need that kind of work I wanted to get started with that as soon as possible to not get blocked by waiting for results later in the process.

To enable an objective discussion I worked with the agenda for the session to approach things from an as neutral position as possible focusing on understanding the option and what kind of questions that were unanswered and might need deeper investigations. I consciously avoided questions around if this option was the right one or not since that was not the question we needed to answer now – we needed to get the data needed to look at that bigger question at a later stage.

This structure worked surprisingly well until we ended up in a spontaneous discussion when the meeting was about to end. The discussion got heated and about the beliefs around this option not about the steps we needed to take. And we did not learn anything new from this side step discussion why it would have been better if it had not been happening at all.

The learning I take away from this is, that as I suspected, heated topics need structured facilitation. If you end up in ad hoc discussions around things outside of the target from the meeting it is better to end them as soon as possible since it is very likely you will not reach a conclusion anyway. Getting emotional people, that stand a long way apart and are totally convinced that they are right, to agree by doing a heated discussion is very unlikely to happen. And it is also unlikely that all perspectives will be heard since the arguments that will come through are from the people that are the loudest.

Learning #5. An iterative approach where the next step is defined along the way is efficient but you need a clear goal.

I drove this project in a very agile way. We took one step at a time and decided what we needed to do next depending on the learnings from the last step. To do that successfully we needed to have a clear goal and some structure to create some stability for people to hold on to.

The structure we had:

  • We had a clear goal; to reach a vision in the end of the year. In the end of the year we should have one option left in the race (we started with five)
  • We had a clear decision criteria to evaluate the options against. We knew what was important for us when we started.
  • We knew that we were going to investigate all the options and continuously ask us if the option should be eliminated or stay in the race based on our criteria
  • We knew that we were going to take one step at a time and then decide what is the next best step to take

The things we were agile about:

  • We continuously decided which next step to take by looking at the learnings we have and the most important unknown to figure out
  • We started with an approach to define which tech spikes we needed to set in motion to learn more about the different options but gave up on that approach since we did not find any relevant ones that would help us understand if one of the options should be eliminated from the race or not
  • We had sessions to dig deeper for all the options but set the agenda for those discussions differently based on previous learnings
  • Quite early in the process we discovered that several of the options were having lots of similarities and potentially could be merged into one but to not get attached to a solution too early we continued exploring the different options. The agendas for those explorations were influenced by this why we added perspectives that could help inform if a converging alternative was the right one.

Learning #6. Communication is important, especially around topics that people feel passionate about.

During this project I communicated frequently. I shared the notes from all the sessions together with an update on where we were and the next steps that we were going to take. I invited all teams to the sessions and asked them to send participants to the session which in practice meant that everyone had good insights around what was happening. Many people felt that they had a good picture of what was going on but some people would have wanted more.

I can totally understand that and even if I think that I did do fairly well on the communication side (weighing in things like available time) there are a few things I would do differently.

The first thing is that I would have been communicated on a stricter schedule. I think this would have been valuable to create more stability since the plan was so fluid and got adjusted all the time. I would also have communicated more frequently verbally when we got together all of us (for instance on our group demos). This would have made it easier for people to keep updated and have an easy way to ask questions if they had any.

Another thing that I reflected upon that I don’t think I would change is that we did not have a working group that drove the project but instead staffed the different sessions depending on needs for skills and interest of people. I think this was a great way to get lots of people involved instead of just a few but it also made some people excluded for not being in all sessions. One thing I would do different next time is to make this as part of the structure or ways of working definition for the project.

Learning #7. Driving changes in a way where people are involved and have influence is key to reach a state where people are aligned and ready to execute fast.

In the end of the option evaluations we came to the conclusion that the best way forward was not to choose one of the options but instead to combine them all into one option. We had found that all our options were about sharing code in one way or another and by “picking the cherries” from all the options we created a new one that was better than the initial options.

After reaching this conclusion we moved into doing some tech spikes to verify that this new option worked in practice and not only in theory. One thing that I find amazing is that from this point the teams have been able to execute on the vision on their own. They are aligning within our area on decisions that are needed to be taken (as well as aligning broader when that is needed). I believe that one reason for this to be possible (besides that I am working with great people) are that the learnings from the vision project was so well anchored with everyone that defining the tech spikes, executing on them, gathering new learnings and deciding on how to move forward has been done in our day to day business instead of continued being part of the vision initiative. When everyone knows what we have decided, have a clear picture of why we have taken those decisions and the underlying problems we want to solve they have what they need to take great decisions to move things forward.

The vision that we ended up with was very close to the vision me and my colleagues had proposed to our leadership team to begin with. But even if the end result is not that different from the original proposal I think that doing the vision project in the way we did it was totally worth it. We learned a lot of things during the process and we now know that we have evaluate several different options before coming to the conclusion that that this one is the best one, which make the vision we have today stronger than the one we proposed initially. This tells me that the vision is more robust than it would have been otherwise and the strong alignment around the vision that we have now would not have been possible with another approach.

Conclusion

As I have stated I learned a lot of good things on our journey and I am proud and happy about where we have landed but the learnings that stands out for me are:

  • A structured approach with clear decision criteria is extremely valuable to get people into constructive and objective mindset – putting their feelings aside.
  • Clear problem statements and a clear goal that people can connect to and rally around is extremely valuable to drive change in the right direction

Leave a comment