The Importance of Communicating Rationale for Decisions
For the past several years, I've been in positions where I spend a lot of my work time trying to align engineering, UX, and product teams. I have the combined responsibility of supporting business goals, considering the developer experience, and advocating for customers. In order to support these goals, I regularly make decisions that impact the tools and processes followed by various teams and hundreds of individuals and that ultimately, impact millions of customers.
I don't take any of this responsibility lightly, so every decisions is carefully considered1 and I do my best to weigh out the long-term implications to everybody impacted, as well as how one decision will change the available options for future decisions.
None of these decisions are made in a vacuum. My decisions are informed by having visibility into many initiatives and the long-term vision for the products, this includes awareness of constraints that might not be obvious to everybody impacted by the decisions. There are other key decisions to consider, historical reasons we need to support situations that may be less than ideal, financial limitations, market forces, time pressures, etc.
Sometimes it's like playing a game of chess where you can't see the entire board, but you influence the future layout of the board. I try to make the best decision I can with the information I have. I recognize that plans may need to change and that even in the present, every decision comes with trade-offs. The decisions made are informed, not perfect.
All this to say, when you are making big decisions with a large blast radius, it's incredibly important to make sure you understand your own decision and have the ability to help others understand as well.
When I do make a decision, I document it. I document the what and the how, because that needs to exist for organizations to effectively execute. But I also document the why. This helps in a few key areas.
Deciding things that affect the day-to-day work of many people means disappointing at least some of those people. When a decision runs counter to someone's prior understanding, or their personal preferences, or creates more work in the short term it can come across as "you need to do it my way now". Rather than being received as a deliberate decision made for good reasons, based on larger context, it can lead to knee-jerk reactions. Ultimately, this can impact team morale and cause undue friction in getting the thing done.
Some decisions require some level of sponsorship from another area of the company or from a higher level of leadership. The Sales aspect of this can help you gather support and overcome objections in a more hands-off, asynchronous fashion.
Decisions have impacts up and down the chain. Choosing to solve a problem with a 3rd party SaaS, for example, potentially impacts the individual contributors who have to learn and use the tool. It also impacts the bottom line for folks who are looking to keep operational costs in check.
By documenting the decision and the journey taken to reach said decision, you can avoid repetitive conversations and loss of fidelity as explanations spread via word of mouth.
When a decision has a direct financial cost, you likely made your case and got everyone on board to get the money to spend in the first place, but there are typically other concerned parties who would benefit from understanding. When a recurring cost comes back around, you might need to justify continuing to spend that money year over year. The documentation can help you immensely here. This brings me to my next point.
When you look at the map in an airport or a mall, that Red dot labeled "You Are Here!" is key to knowing where to go next. Could you figure out where you are the map without that? Of course you could! Would it take longer and require more effort? Sure would! Just like the "You Are Here!" marker, this documentation provides a solid jumping off point for reevaluating the decision in the future.
Sometimes, you need to look at how you do things and decide if you should continue doing things the way you are, stop doing the thing entirely, or do the thing in a new way. By understanding not only where you are, but how you got there in the first place, you can start the process of making a new decision with the information that went into the original decision.
When others find themselves in a position to start making similar decisions, understanding how the existing world came to be can be quite beneficial. Over a long enough period, systems will start to show signs of their evolution. Any technical debt or organizational constraint that gets carried into iterations of a system's evolution will start to show their ugly heads over time, and a documented journey can help provide valuable context and understanding in the future. Understanding why a system is the way it is can be beneficial in maintenance efforts, and can help you avoid similar trade-offs in future decision making efforts.
I've found it far easier to get things done with this type of documentation than without. It provides the context to help garner support, justify resources, and make future decisions more informed. When I changes jobs recently, my transition out was streamlined by the documentation. Instead of a last minute scramble to transfer knowledge to other parts of the organization, I clarified some points in the documentation and left it as a record for whoever picked up that responsibility.
- Careful consideration is not the same as analysis paralysis. I work hard to make sure decisions are also made in a timely manner, understanding that nothing is forever and at some point, decisions may need to change.↩