We'll see | Matt Zimmerman

a potpourri of mirth and madness

Scaling Human Systems: From implicit to explicit

This is part 2 in a series on organizational design and growth.

What it means

Carefully communicating about what’s going on, and making fewer assumptions about what others know or think.

Why it’s important

As companies grow, many new people join who don’t have as much shared context. Many employees will also interact less frequently with each other, as we may not be able to maintain the same level of relationship with everyone. When we make assumptions about what our co-workers know, think or feel, we will increasingly be making errors of judgment. By replacing these tacit assumptions with explicit communication, we can help avoid mistakes and support cooperation within and between teams. Explicit communication is a vital tool for coming to agreement: by putting an agreement into words, we stand a better chance of understanding what we’re agreeing to, and can change it together.

Old status quo

We take a lot for granted. We know quality when we see it, but can’t explain it. New team members are expected to learn through osmosis or trial and error. Expectations are often ambiguous. Procedures live in our heads, and evolve in ad hoc fashion.

New status quo

We exercise care and thoughtfulness in our internal communications, telling others clearly what we expect and what they can expect from us. Key information and procedures are written down, and can be instantly shared with as many people as needed. We change them whenever we need to, and everyone concerned stays in the loop.

Behaviors that help

  • Document the basics: a new team member should be able to learn the essentials of how to do their work by referring to documentation. We don’t need to try to exhaustively document everything, but the essentials (e.g. for an engineer, how to deploy their changes) should be written and maintained, and where appropriate encapsulated in software tools
  • Make work visible: something as simple as a Trello board can offer a lot of insight into what’s going on in a team, both specifics (e.g. status) and meta information (this is how we get things done)
  • Define and track projects: a project has a beginning and an end and a scope. There will always be unknowns and changes, but there should be an explicit goal such that we can agree on when it’s “done”
  • Clarify roles and responsibilities: job roles are a tool to communicate with other people about what you do. By having a shared understanding of what roles we occupy, we can more easily divide up responsibilities and anticipate each other’s contributions.
  • Listen actively: “is this what you meant?” “who is taking responsibility for making that happen?” “do we have agreement on this point?”

Obstacles that stand in our way

  • Fear of process: Tiny companies can get by with very little structure in their operations, and may become attached to this as part of the “culture”. As they grow, this is less and less true. Process doesn’t mean bureaucracy! A process is just a description of the way things work. It doesn’t have to be rigid or foolish. The worst kinds of process are those that only exist in people’s heads, and are divergent from each other.

Written by Matt Zimmerman

June 25, 2013 at 17:09

7 Responses

Subscribe to comments with RSS.

  1. […] Source: Planet Debian […]

    • I’d like to share my hindsight from working with a small team over 14 years. We have procedures, and more procedures, and we’re finding that although they are good for reference and training, they detract from improving our service.

      My definitions: A procedure is a step by step description of a work process. A standard is a description of the required outcome of a process.

      I would rather develop standards. Procedures are good for examples of how to achieve the standard, but perhaps they don’t cover the edge cases or are now outdated because of external changes. Standards don’t change so much. My challenge to the employees: Show me different ways to achieve the standard, and let’s see if it’s cheaper, adds value, reduces stress and/or improves our customer’s attitude towards us!

      Jim Cooncat

      June 27, 2013 at 10:50

  2. Hi Matt, great post. I agree with you that explicit communication is important. I’d also say that, with the proliferation of distributed teams, explicit comms are going to become even more important over time. I don’t believe that you can be competitive without it.

    However, one side effect of explicit communication is that more “bandwidth” is required by everyone to process it. As you summarized on Twitter, “in addition to the greater number of edges, the cost of each edge in the graph may also increase.” In [Communication Overhead: The Hidden Cost of Team Cognition][1], the author briefly mentions that “effective team cognition has a communication ‘overhead’ associated with the exchange of information among team members. Communication requires both time and cognitive resources, and … team performance can benefit as a result.”

    One way of alleviating these issue is by introducing richer communications. The media richness theory says something like “the more complex an idea is, the richer the medium required to convey it.” Things like diagrams, pictures, video, and (in person or video conferencing) presentations can all help alleviate the “bandwidth problem” aka communication overhead. (As an aside, this roughly reminds me of compression a la “one picture is worth a thousand words”)

    Another way of alleviating this issues is by enforcing small team sizes. This results in fewer edges in the organizational graph and therefore lower edge cost. This is hinted to The Art of Scalability, where the author suggests that one can consider dividing teams as soon as they surpass six members to a team.

    [1]: (PDF) http://www.aptima.biz/publications/2004_MacMillan_EntinEE_Serfaty.pdf

  3. […] Part 2: From implicit to explicit […]

  4. […] commitments explicit: say “I will take care of that”, and record that commitment somewhere, preferably in a shared […]

  5. […] in particular are probably not well understood. Many people juggle multiple roles, all of which are implicit. Moving to a new team means learning from scratch what other people do. People take responsibility […]

  6. […] Part 2: From implicit to explicit […]

Comments are closed.

%d bloggers like this: