Writing narratives and technical documents becomes a more and more relevant skill to have when navigating today’s organizations. Often times successful alignment between teams or even departments rely on this form of communication. Personally I have seen how I was unable to convey my thoughts and ideas to a wider audience simply because I was not able to write them down. Later I learned that only writing them down is not enough to form an alignment.

There are a number of different ways this writing and alignment can happen. Some organizations rely heavily on writing even for the product development process (PDP). Shipping Greatness describes Amazon’s process in detail. Before anything is being built a set of written specifications are produced that are used for aligning beginning with the executive board down to the teams.

Only writing is not enough Link to heading

The first time I was involved in trying to align teams with a written narrative was a total disaster. Not because we as the authors were cruel or not well intended. We created a four page document about how we want to change our system’s architecture. This change would also have an impact on another team that would have had to change some of their architecture. After we shared this paper however it was not unfolding the way we were hoping. A lot of push back was given to our ideas and weeks of follow-up meetings followed. We were not able to reach consensus and eventually the idea and the paper ended up in the virtual drawer under our desks.

So what happened? I later realized that the working backwards PDP contains multiple steps. You begin with writing a high level press release about the work you will just have shipped. This artifact does not contain too much detail and mostly only the value added for the customer. But it also contains a FAQ that collects the most frequent questions and provides answers to them.

Once this is aligned, the design document is a more detailed description of the product. What will change in the UI, how will customers experience the new product. The purpose of this artifact is to align other product teams and designers on the solution. Finally the technical solution document describes the way the technical teams will build the product.

By now the informed reader might have realized that this is basically Simon Sinek’s Start with Why. By first articulating WHY you want to do that piece of work this important question can be answered and not debated anymore. This has also been one of the main issues with our paper. It was clear for us why we wanted to build this, but it was not clear to the other teams. Once this is out of the way you can continue to talk about the WHAT and HOW.

Writing is a process of alignment Link to heading

In another instant and without the strict product development process in place we worked on a paper for a strategic initiative in my area of work. This time there was support by a very senior leader with a lot of experience in this field. The way he coached us to deliver this paper was very insightful in combination with my observations from before.

Instead of writing the paper and sharing it, he created a process around writing the paper itself. We first started with writing down the status quo, talking to teams on how specifics are implemented and how they work today. This was then shared with the involved teams and the relevant (S)VPs, executive rounds and heads of engineering. The goal was to find blind spots that we as the authors might have and at the same time get a shared understanding of the status quo.

We then formulated a set of goals and principles for the way we wanted to work on the problem going forward. This also contained a definition of what success looks like for the new product. Again at this point we held meetings with key executives and key stakeholders to align on this definition of success. Finally, we wrote down the list of actions we would want to pursue in order to reach the goals, guided by the principles defined earlier. Similarly to any other step in this process we held another round of alignment meetings in which the new updates were shared.

The result of this process was then provided to the management board. At this point all stakeholders and key decision makers had already been on board. No details were left open and no questions came up that we had not heard before. A completely different experience than the paper before.

Again one might have noticed the Good Strategy/Bad Strategy background in the way the paper was written. A very insightful book about why most strategies are not ones and why they fail. The execution of the strategy has not been a complete success but that is a different story.

Takeaways Link to heading

After working with written documents for the last two years my main takeaway is that finishing the document is not the important step in the process. Writing all of the content alone or in a one team and then sharing it with other involved teams will not lead to buy in.

The important thing is how one ends up with the document. The path a team or multiple teams take to get a shared understanding and a shared solution finding is the important part of this process. Once the document is finished, the whole process should be finished. Changing the document’s status from in progress to closed marks the end and not the start of the alignment.