We all know the problem
“Single source of truth” (SSOT) is common business parlance that inherently reflects a long history of big corporate institutions that suffer from a lack of coherent communications. Unsurprisingly, as a company scales, oftentimes there are many conversations and decisions happening on a daily basis, and it quickly becomes difficult to have the whole company on the same page, which is crucial for typical business operations. Modern businesses today also need to quickly make decisions and even change them often. If a product feature launch is delayed, downstream stakeholders like the marketing team needs to be made aware. So it’s no surprise big companies have a “change control board”, which is a group of people reviewing and approving requested changes. All this to say that people working in a large company typically naturally understand the need for maintaining a SSOT, because most companies simply do a poor job of it and the symptoms become extremely frustrating.
Perhaps somewhat surprising is that the problem also plagues small companies too! Last year I talked to a startup with barely 10 people and the CEO was complaining about the team communicating in multiple different tools, and enduring all the consequent confusion and pain. With 10 people in a tech startup, you probably already have a handful of concurrent initiatives. And don’t forget about all the external customers and partners and investors. The implication here is a simple caveat: Think about optimizing communication on day 0 of your startup. The honeymoon period of informal communications is simply a myth. The moment you have two people, you need a proper communications protocol. And many startups start with at least two co-founders anyways.
Scaling forward, and backward
Most people limit their understanding of communication to a snapshot of time. They think about the meeting they had in the conference room, and how to disseminate that information to the rest of the company later in the week. In actuality, a company is a living and breathing organism with memory. The processes you rely on and the decisions you make today are a consequence of the past. And so when you write a comment in an issue tracker tool to respond to a colleague today, be aware that the comment can and will be read by a future colleague 5 years later, who likely has not joined the company yet. Or it might simply be yourself! Good programmers know that a major reason that code needs to be “clean”, is that it will be read many many times throughout its lifetime. Besides serving the actual functionality, code is communication amongst programmers, today, and into the future. In the same way, ensure your business operations communications, whether it be simple transactional messages or technical specs, is clear and concise.
We’ll just document the result
Many folks fall into the trap of dismissing ongoing discussions as having only ephemeral importance, seeking to only “document” the results at the end. This is a classic mistake of traditional co-located organizations, where they simply don’t have the mechanisms to communicate efficiently. The idea is that everyone has a one hour meeting in the conference room, and they reach a perfect consensus and plan at the end of the hour. Somebody documents the go-forward plan and maybe there is some semblance of meeting minutes. Everyone that’s worked in the real world understands this never actually happens. Business is a messy affair. There are a lot of complications. Many things are consequently missed and lost. People try to manage these gaps with having more meetings, and thus the problem snowballs, a positive feedback loop. (Where positive means “negative” here!)
Remote teams that are just starting out typically fall into this trap by having a lot of conversation in tools like Slack. A lot of ideas fly by, and people are not motivated to document the ideas in a place that is more long-lasting and easier to properly organize and search. This is simply a lack of discipline where folks don’t consider the long-term importance of their ideas right now. A common excuse is that the result of a Slack conversation should be documented. Besides that rarely happening in the first place (who will do that job of documentation?), it’s very difficult to try and systemize the many threads of ideas and possibilities stemming from a Slack conversation. The tool (and really, the format of the communication paradigm), is not designed for asynchronous conversations that can be properly structured.
Iterative product collaboration model
As it turns out, the product development flow presents a very good model of communication within a business context. I have yet to seen a better model applied to product collaboration. And the product collaboration model applies to other departments and functions too.
This model has two parts. The first is simply having a SSOT that reflects a change proposal or spec. In the product development world, this is a single issue, or a user story, or simply a single development task. Many project management tools thus have a single work item with a description field, which is perfect for this use case. At the beginning, the description field reflects the change proposal. It is the SSOT of the proposal itself. Later on, as the proposal morphs into a spec, the description field becomes that spec. In more “agile” teams that don’t need a gating process, it doesn’t really matter whether you call it a proposal or a spec. It’s just the SSOT of what is intended to be implemented. Accompanying the description field is a conversation. In project management tools this is the comment thread. This is where individuals asynchronously discuss the change proposal. The discussion should be scoped to the change on the table. If folks have other ideas, simply create additional work items, and link them together. Most importantly, as your discussions evolve, ensure that the SSOT is maintained. This serves a number of important functions. First, there will be no confusion as to what is the latest proposal/spec, despite any conversations that can be otherwise wildly diverging. Second, any newcomer to the conversation can quickly see what’s the latest, without digging through the comments themselves. This is where a good remote work product manager really shines. They need to be a strong arbiter of conversations and help facilitate discussions so that they generally move forward. They need to link ideas together, organize them into proper hierarchies, and overall be a systems thinker. It’s a difficult task, but a crucial one. So you can quickly see how a tool such as Slack does not allow you the expressive power to organize a fast-paced asynchronous collaboration amongst many team members.
As a remote work product manager, maintain a single source of truth.