How can you reduce distractions and keep your team focused on the key tasks at hand? We're not talking about obvious diversions such as Facebook, Twitter, or Youtube. For the most part, those are not the distractions that you need to worry about, since goal-oriented team members are likely to dip into them and then quickly set them aside when it comes time to get down to business.
How to build better support and understanding around your company's proprietary codebase. Download now (pdf)
The distractions that you do need to worry about are the ones that are caused by inadequate communication, by key pieces of information being lost, hidden, or simply forgotten without ever having been properly documented.
These are the distractions which are all too likely to seriously sideline team members and reduce productivity. To make matters worse, they may not be easily identifiable as distractions, appearing instead to be everyday tasks in keeping with your team's core purpose.
Communication Breakdown
Here's a quick survey of some (and these are just some) of the ways that communication in an otherwise well-organized team can go wrong:
Never Written Down / Stuck in a Drawer
Kai needs to find out how to send UTF-8 data to a poorly-documented API command. In a casual lunchtime conversation, Lin (who has worked with the API) provides the answer, which Kai promptly puts to good use—without writing it down. Now Lin and Kai know the answer, but it may still be a mystery to the next person who tries to use that API with UTF-8 data.
Note that the situation may not be much better even if Kai does write it down, either on a sticky note (where it's likely to wind up at the back of a desk drawer half-filled with largely expired containers of artificial coffee creamer) or in a text file (saved in the optimistically titled "Stuff to be Sorted" directory, along with five years worth of still-unsorted files).
Even if Kai and Lin discuss the API via email, the information is still likely to be effectively unavailable to other team members. Including them as recipients can help, but as time goes on, the information is likely to be lost in the growing accumulation of messages.
Our Little Secret
There are times when groups can keep secrets without even intending to withhold information.
If someone brings up a technical issue at the weekly development team meeting, all of the stakeholders present will be at least aware of the discussion. For a variety of reasons, however, there may be (and probably are) stakeholders who are not present—contractors who are not part of the core development team, for example, or technical consultants, or even members of the marketing or sales teams. If nobody who was at the meeting mentions the discussion to one of these absent stakeholders, then that person will effectively be out of the loop.
This is even more likely with small sub-teams and working groups, as they typically consist of fewer people and are more narrowly focused on specific tasks. It may be difficult for group members to recognize when specific individuals outside of the group are de facto stakeholders, so it simply may not occur to them to mention important points that came up for discussion.
Again, this is true of written/electronic records of communication within a group. If such records are not made available outside of the group, or if they are made available but are stored in a way that leaves them effectively lost under a pile of accumulated data, then the information which they contain may for all practical purposes remain a secret to "outsiders."
Ancient and Forgotten Lore
Every organization has lore—bits of information passed down informally, typically by word of mouth, and often (but not always) peripheral to the key functions of the organization.
Some lore is strictly good for entertainment value—stories of the days when the development team was located in a semi-converted warehouse with pigeons in the rafters, or tales of the former Director of Marketing who would come to work on Fridays wearing a kilt and carrying a full set of bagpipes, for example.
Other kinds of lore, however, may actually consist of important information, which, for one reason or another, is known only to one or two (or at best a handful of) people and is likely to be lost if and when those people leave. In the API example described earlier, if the information continues to be known only to Kai and Lin, it remains lore, just as much as the pigeons or the kilt-wearing marketing director.
Technical and business lore, in fact, may be much more common than most of us would like to imagine. Information not included in the documentation, ad-hoc workarounds, the existence and location of patch code that carries technical debt, even such things as account IDs for development tools and third-party services or the names of key vendor and client contacts—all of these things may at times exist only in the form of lore, with the attendant risk of being forgotten.
Information Lost is Time Lost
What are the consequences of inadequate communication and the loss of information?
Extra Time and Extra Effort
When people can't find the information that they need, they usually wind up spending time looking for it. This can involve tracking down the people who they hope can answer their questions or searching for documents which may be helpful. It might even mean setting up and conducting tests in an attempt to extract the information from the relevant software or hardware system.
This expenditure of time and effort may be necessary and unavoidable. But when the answers already exist within the organization, the time and effort spent attempting to track down and recover that information or to dig it out through testing is time needlessly lost and effort needlessly duplicated. The search is a distraction rather than time spent productively because it is needless. It is only necessary because the company's communication infrastructure is inadequate.
Lost Information and Decisions in the Dark
If people in need of information can't find it at all or don't have time to look (or if they don't know that there's anything to look for), then there's a good chance that they will make decisions in the absence of that information. When this happens, the consequences may cover the range from merely inconvenient (i.e., work that eventually has to be rolled back and redone) to serious (major design errors, inadequate compliance with client specifications or regulatory requirements, or system failure).
The time lost to such made-in-the dark decisions is itself a kind of distraction—one which can carry with it major penalties in terms of lost time, lost business opportunities, lost reputation, and even legal consequences.
Inconsistent Protocols and Inconsistent Policies
Failure to communicate key points of technical design and requirements (including such things as the details of seemingly minor API commands) can result in inconsistent design decisions and affect communication between elements of your application or between your application and third-party services. These inconsistencies themselves constitute a kind of technical debt with a cost which may make itself apparent at a time when it is least convenient.
Note that these communication-based distractions and their consequences aren't confined to technical issues. They also turn up with considerable frequency (and sometimes at great cost) in connection with company procedures and policies and, all too often, in relation to client needs, potential sales opportunities, and even contractual obligations.
Your Sales, Marketing, HR, and Accounting departments are as much in need of a good communication infrastructure as your software development teams; the consequences of inadequate communication at the customer relations or administrative levels can wind up landing heavily on everyone in the organization.
A Framework for Reducing Distractions
Effective teams need a good information infrastructure for internal communication—it should provide not only storage for key items of information, but also organization, easy access, the ability to find information when you need it, and a clear record of the history of each thread of communication.
The question-and-answer format of Stack Overflow for Teams allows it to easily and naturally serve as a highly accessible repository for the kind of information that is otherwise all too easily lost. When a team member asks a question, both the question and the answers (along with discussion and ratings) are visible to all members of the team. Stack Overflow for Teams has built-in functions for tagging, searching, and filtering that make it easy to find questions and their associated answers.
This means that, very naturally and with very little effort, otherwise undocumented technical information, unintentional group secrets, and even nearly-lost technical lore can all become part of an easily searchable, well-indexed living repository of important team and company information. You can even include the marketing manager with the kilt and the warehouse full of pigeons if you want to!
See how Stack Overflow for Teams can transform collaboration within your organization. Learn more