(Come on!) Everybody’s Doing It

I’m not going to make you read the whole article to figure out what the mistake is. Mainly because nearly everyone makes it, it’s no secret, but it’s hard to catch unless you’re looking for it.

It happens on Zoom, Slack, Microsoft Teams, GChat, and even in-person conversations between two or more people.

I can also guarantee it probably happens every day at your company and is happening while you’re reading this.

How it Happens

It’s rare that people are making this mistake on purpose. This mistake happens due to the following top three reasons:

  1. There’s excitement on moving forward, and everyone springs into action without planning.
  2. Person A thinks it’s Person B’s responsibility, and Person B thinks it’s Person A’s responsibility.
  3. There is no clear procedure established for meetings that involve decisions.

New Problems Created

If you’ve heard of the phrase “putting out internal fires”, you’re probably also familiar with the problems that can be caused by not documenting decisions that your teams will make in ad-hoc discussions.

Your development team may be making many rapid but small decisions over Slack communications. At first, this will feel like quick progress, things are happening, and code is getting shipped. But, in a few months, things start to break down. “Why did we make this decision?” is a question that will start popping up more and more. Then it will turn into, “Who made this decision?” Eventually, nobody will even know why half the codebase was written the way it was, or why features were added when they were, or how the database became structured the way it did.

Your Marketing team could be having Zoom chats weekly. After a few months, you start to notice that the content marketing strategy has changed, and the publishing process has shifted to different channels. Then, even a different logo has begun to be used. Why? Nobody can remember. It was some decision that was made in some conversation, at some point in the past.

The sales team starts using a new script or adopts a new pipeline? You guessed it! The recent changes caused a reduction in deals. Who approved this? Nobody knows. It’s entirely possible a decision was never even made. It was presented as an “idea” that another person on the team mistook as an official decision.

Stop Creating Operational Debt

Lack of documentation, misunderstanding ideas from decisions, and making changes without documenting why all contribute to a company’s operational debt. Like technical debt, this is something that will need to be “paid back”. Paying back this type of debt usually costs time, money, and a lot of headaches. It’ll take 10x longer than it did to create it. Spoiler alert: This is not the type of loan you’d want to take out to grow your business.

There’s a Simple Solution

Fortunately, there’s an easy way to resolve this problem. It’s a three-step process:

  1. Create a structure around your meetings so that the discussions and, more importantly, the meetings’ decisions get documented.
  2. Ensure the documented decisions are easily found by connecting them to related work.
  3. Make this part of your company culture. It’s more than just training because you also need your teams to understand why it’s important and how it will help them be more efficient in the long run.

By default, most people will feel that the path of least resistance is to not document – that we should immediately take action. That creates a reward loop, and it establishes short-term movement but long-term operational debt.

Teams usually start to suffer from the effects of missing documentation within weeks. How often have you looked back on your notes that are only a few weeks old and thought, “What was I thinking?”. Now multiply that by the number of employees in your company and eliminate the notes.

If your team understands the long-term issues that this can create and the headaches that this problem can bring to them personally, a little leadership will help your teams quickly realize that the path they thought was the easiest is actually one of the most difficult.

Not documenting your decisions and relating them to the work they apply to is like starting on the bunny slope and finding out it ends with a double black diamond when you’re first starting to learn how to ski. In other words, it’s not going to end well for anyone.

In Practice

What does this look like in practice? The important thing is to make it easy to find why things are happening the way they are. You need a way to look back and get a reminder of the original discussion and why certain things happened the way they did.

  • Create structured meetings so that the objective is clear.
  • Clarify roles so that everyone is clear on who will document.
  • Be clear about what is an idea and what is an actual decision.
  • If you’re using Asana, ClickUp, Trello, or similar, note the related task or project’s decision.
  • If you’re using Jira, note the decision in the related issue.
  • Ensure that the person making the decisions is in the correct role to do so. Elevate if not.

Not Just About Future Proofing; Also Good for Asynchronous Communication

Getting into the habit of documenting decisions isn’t just helpful at resolving and avoiding operational debt and internal fires. It also helps keep communication strong within teams, especially with today’s distributed and remote workforces.

Consider this scenario: two developers jump on a Zoom call to figure out the best way to do something related to an API. They make a decision and start working on it without proper documentation as to what was decided on. When the front-end developer tries to do his job, he must now do any or all of the following:

  • Guess at what decisions were made (bad idea)
  • Interrupt one or both of the API devs to ask what was done (which is now stalling productivity)
  • Try to reverse engineer the API code to understand what needs to be done (significant slow down)

Now, let’s look at what would happen if the two developers documented things correctly. The two developers jump on a Zoom call, make a decision, and take one final step at documenting the decision and provide enough context so that everyone else can understand why it was made. Now, our front-end dev comes along, and all he has to do is look at the documentation provided. He knows:

  • What the decision was
  • Why it was made
  • How he can leverage it

Even though this is a development-related example, this same situation can apply to every team in your business — including the executive team.

Reducing guesses and assumptions, eliminating interruptions, and increasing team member efficiency all contribute to fewer internal fires and more stable operations.