Don’t talk about work.

So a colleague walks up and asks, “Can we [insert detailed request here],” you say “Sure, no problem.” Your colleague walks away .. here’s what happens next.

You open your shared project management app, try to associate the feedback with a relevant work item, attempt to recall the details of the discussion, and document them. Similar to a game of telephone, the details may have some dissimilarities from the original.

Now that the work is actionable and in progress, still more work discussions arise. As it turns out, several meaningful decisions get made throughout the process and when you and your colleague agree that it’s complete, other stakeholders enter the picture and get only a subset of the discussions, questioning how we arrived at these conclusions and why it’s taken this long.

We shouldn’t talk about work.

There are so many more meaningful things we can talk about. I don’t mean that we should chat at length about last weekend, but perhaps consider discussing communication improvements, process tuning, corporate and individual incentives, understanding more of the why, or encouraging each other. Overall, simply being more authentic. Our time to talk is scarce, so we should honor it. Respect the team, the process, and the time by documenting work, not talking about it. Appreciate that a work/life balance isn’t only achieved by the boolean frequency of time spent working or not, but also by treating each other more like humans and less like robots.

Complex work items can take the form of a reply-able message and simple items can act as to-dos. Historically we would talk things thru, because we didn’t have project management apps, bug tracking, email, etc. We have those services now and they stack up in a more-than-compelling way against work-items-as-oral-tradition.

When we document work instead of talking about it, then..

  • Setup, onboarding, and README details get better over time (each person commits to being a good citizen and updating as they go thru it), so each next person has a more well-thought-thru experience than those who came before. Therefore, questions that get raised should be rejected by those who know, they should update the documentation, and then prompt a reapproach, “I updated the documentation, does it address your questions?”
  • When work items are shared among groups, there is visibility for those closely or loosely involved so everyone can be on the same page in real time, and can adjust their notification mediums and frequencies to fit.
  • When talking occurs within documentation, then it’s clear how a request evolved over time, the members who played a role, and their position, bias, and abilities are clearer. This has the byproduct of more professional behavior, whether respectful or not, and accountability to detailed historic logs that can be accessed by the whole group at any time.
  • Items can be enumerated by the requestor in any level of detail, which can become the checklist, which can become the work product, which can become the customer value. So documentation becomes meaningful and actionable.
  • Valuable artifacts are generated in the process, which can serve as other documentation, reference materials, business paperwork, blog articles, tweets, searchable wikis, or any number of implementations. Not to mention that technologies may come along (or already be available) that comb through the documentation and produce valuable insights.

It’s pretty rough to get there in real life because you might sound like the odd one out. Hopefully, this article helps to bolster your position, shed some light on a sane approach to workflow, and demonstrate the concept to others.