The Devil’s In The Details

I’m a firm believer that context is everything, and that it’s needed in every constructive conversation we want to have as engineers.

As a nascent (but adorable) engineering field, we discuss (in blogs, books, meetups, conferences, etc.) success and failure in a number of areas, including the ways in which we work. We don’t just build complex systems, we are a complex system. In order to get our work done, we have to successfully bring together people and skills from diverse backgrounds. When we reach large-scale, we have to enlist deep and diverse domain expertise across our staff.

But sometimes, we can get frustrated or bogged-down in the details of these interactions between groups and individuals. We can feel like the blunt end (management) doesn’t understand the sharp end (practitioners), or we can feel as though one group doesn’t understand the goals, concerns, or tradeoffs of another, or we simply aren’t doing a good enough job of enabling people to have constructive conversations.

As usual, we’re not the only people who might be interested in how people work together, especially in combination with machines. There’s a great chapter in the 2005 issue of Organizational Simulation (link to journal) that outlines the concept of a “Basic Compact” that people have with each other when engaged in joint activity. From Common Ground and Coordination In Joint Activity:

People engage in joint activity for many reasons: because of necessity (neither party, alone, has the required skills or resources), enrichment (while each party could accomplish the task, they believe that adding complementary points of view will create a richer product), coercion (the boss assigns a group to carry out an assignment), efficiency (the parties working together can do the job faster or with fewer resources), resilience (the different perspectives and knowledge broaden the exploration of possibilities and cross check to detect and recover from errors) or even collegiality (the team members enjoy working together).

We propose that joint activity requires a “Basic Compact” that constitutes a level of commitment for all parties to support the process of coordination. The Basic Compact is an agreement (usually tacit) to participate in the joint activity and to carry out the required coordination responsibilities. Members of a relay team enter into a Basic Compact by virtue of their being on the team; people who are angrily arguing with each other are committed to a Basic Compact as long as they want the argument to continue.

That first reason why people engage in joint activity: because of necessity (neither party, alone, has the required skills or resources) points to some of the reasons why at the same time successful companies develop and employ generalists, there is an advantage to having people differing domain expertise come together. An example of this might be “development” and “operations”, or “design” and “product”, or “finance” and “business development”, or “public relations” and “community”, etc.

Regardless, two of the authors are responsible for some of the best writing on Cognitive Systems Engineering and Naturalistic Decision Making: Dr. David Woods and Gary Klein, respectively. There’s a lot of great bits in here. Costs of coordination, spoken and assumed behaviors, as well as touching on everyone’s favorite topic in engineering: automation and it’s affects on engineering behavior. Come on, what’s not to like in this paper?

The chapter is here as a PDF, so you best get it for your weekend reading! 🙂

 

9 Comments

  1. Mark Burgess   •  

    This a nice read from the era of multi-agent systems. I spent a lot of time looking at these things in the early 2000s, and that is what led me to eventually try to formalize these aspects of cooperative behaviour between autonomous people/agents. There was really no theory to explain the way that CFEngine worked (including all the important details that popular accounts usually leave out), but it was clear that whatever the theory was, it couldn’t be a deterministic or imperative story. The real story of “promise theory” starts in these ideas. If you have nothing better to do at the weekend, you can compare to the more formal story that led to CFEngine 3 here in chapter 5 about cooperative behaviour…

    http://cfengine.com/markburgess/BookOfPromises.pdf

    This is still unfinished, but for your amusement. 🙂 Cheers John

  2. Paula Thornton (@rotkapchen)   •  

    This underlying concept of ‘agreements’ goes to the heart of all sorts of things, including the pilot culture phenomenon brought up on your last post.

  3. Paula Thornton (@rotkapchen)   •  

    To the deeper aspects of ‘common ground’ we tiptoe through the significance of ‘shared meaning’ and the need to create artifacts for same — think Pixar (http://www.fastforwardblog.com/2009/11/09/why-fill-in-the-blank-fails/).

    One of the unwritten challenges is recognizing that all teams operate from a prevailing myth — a collection of shared meaning that is codified in unwritten rules. Often it is important to give transparency to this myth and work to write a new one (http://www.fastforwardblog.com/2010/11/22/e2-0-enabling-digital-realities-embracing-myths/)

  4. Larry Irons   •  

    The “compact” that makes Joint activity (I prefer action) work, regardless of the reason for the joint action, is a well known phenomena in social phenomenology since the time of Alfred Schutz and Harold Garfinkel.

  5. Pingback: Humility At Work « ccmolitoris

  6. Pingback: Data Science Delivered – Consulting skills – Models are illuminating and wrong

  7. Pingback: FAQ: Story points · El Javi

  8. Pingback: On Being A Senior Engineer – Kitchen Soap

  9. Pingback: How To Become A Lead Developer. Part 1 | SUMclicks

Comments are closed.