How will you collaborate?

When there are decisions to be made, people have feelings about it. Some people want to make the decisions, others to influence it, others to hear about it.

Where does everyone in your group stand? Are you set up for conflict or for smooth collaboration?

For instance, say there’s a new product to start. We will need to decide how to market it, how to price it, and how to build it. Within building it, there will be all kinds of smaller decisions, from platform to architecture to every tiny piece of code.

Collaboration Contracts let us get explicit about how we will make decisions.

Doc Norton suggests: everyone pick your place in each decisionmaking. There are 6 options.

the six options as expressed by different colors of tooth people
which one are you?

Are you making the decision?

  1. Explainexplain person is orange“I will make this decision, and explain it to others.” No obligation to accept input.
  2. Consult: consult person is red“I will make this decision after consulting with others.” You can influence me, but I will decide.
  3. Agree: agree person is purple “We will make this decision by coming to agreement somehow.” Method of agreement to be determined later. You can influence us.

Otherwise, are you involved at all?

  1. Advise: advise person is green “You make the decision after I advise you.” I have thoughts; hear them and then I’ll respect the decision you make.
  2. Accept:accept person is blue“You make the decision. I’ll accept it.” Whatever it is, I’m in.
  3. Abstain:abstain person is grey “You do what you want. I abstain from this whole activity.” Why am I even in this meeting?

This lets us identify baked-in conflicts.

After everyone declares the role they expect to play in a decision, you can notice conflicts.

"explain" and "consult" and "agree" roles conflict with each other
“explain” and “consult” and “agree” conflict with each other.

If more than one person thinks they are making the decision, and they’re not all in the “agree” category, you have a problem.

"explain" and "advise" roles conflict with each other too

If someone thinks they’re making the decision unilaterally (the “explain” category), plus at least one person sees themself as “advise,” you have a problem.

Once you identify conflict, you can renegotiate. The person who thought they could make the decision without input can agree to ask others. The person who thought they would consult can seek agreement instead, or the people who wanted to agree can delegate the decision.

This model is useful at all levels of decisions. I find it especially interesting to apply it to low-level code decisions.

We can apply this model to collaboration on code.

Down at the nitty-gritty implementation level, someone is at the keyboard. Maybe its me. If I’m working alone, then I’m making the decisions. I am in the “explain” role.

After the code change is ready, what happens?

It’s OK to make unilateral decisions.

Maybe I push it to master, with an explanation of my decisions in a commit message. No conflict there.

Maybe I create a pull request, including an explanation of what I did and why. Then what?

If my colleage glances at it, sees that the build passed, and hits “merge,” maybe they’re taking the “accept” role and we’re fine.

There is conflict when we expect our decision to fly but it doesn’t.

But what if the reviewer has suggestions? Then they’re taking the “advise” role, and that is in conflict with my “explain” role. Looks like I actually have the “consult” role, except that I don’t get to consult until after I make the decision once and then I have to go make it again.

Pull request fight. Me: "Let's do this!" Them: "But what about..." Me: "Fine, they we'll..." Them: "That's not OK" Me (very sad): "Work with me here!"
the pull request slide, from decisionmaking to placation

And what if those comments aren’t suggestions, but blockers? Then we are both in the “agree” role. I thought it was my decision but it wasn’t; only I had to make the decision first and then someone else pops in and now we have to agree.

These are not smooth. I do not enjoy this.

We have ways of collaborating smoothly.

two "agree" people at one computer

If we were aiming for the “agree” role all along, why not start there? In pair programming, one of us is typing, but we make decisions together.

Or even better, mob programming: the person at the keyboard (the driver) is not allowed to make decisions, so every decision is spoken aloud. The driver is in the “accept” role.

mob programming with a navigator: an "accept" person with the keyboard; one "consult" person; several "advise" people

If your mob has a navigator, then each person takes a turn in “consult” and the rest are “advise.” This works.

mob programming: one "accept" person has the keyboard. Everyone else is "agree"

Without a navigator, everyone is “agree.” This works too.

Consider the design of your collaboration.

This model illuminates why pull requests hurt so much. They have conflict built in to their structure.

To make pull requests work, I have to lower my expectations.

I’ve learned to consider my pull requests to be suggestions. I’m proactively taking an “advise” role in a decision I hope some project committer will make. Success can look like: they implement the same functionality in a manner of their choosing. My PR functions as a very specific feature request. It doesn’t matter that my code didn’t make it into production, if my idea did.

The only exception to this is when I know the project maintainer (or am the project maintainer), and I come to agreement with them before submitting the PR. Then I expect it to be accepted, after some minor comments and changes are exchanged.

When you see conflict, consider your collective expectations.

Next time you feel resentment at someone else’s intrusion, or frustration at decisions made without you, try to picture the roles everyone thought they were playing. Are they compatible? Was conflict endemic to the structure of this interaction?

If so, don’t blame yourself, nor the other person.

Ask, can we be clear about our decisionmaking intentions? and then adjust them to remove conflict before it starts?

Be specific about your expectations. Set yourself up for smooth collaboration.

When knowledge is the limiting factor

In Why Information Grows (my review), physicist César Hidalgo explains that the difference between the ability to produce tee shirts vs rockets is a matter of accumulating knowledge and know-how inside people, and weaving those people into networks. Because no one person can know how to build a rocket from rocks. No one person understands how a laptop computer works, at all levels. There’s a limit to the amount of knowledge a single person can cram into their head in a lifetime; Hidalgo calls this limit one personbyte.

Our software systems are more complicated than one person can hold. You can deal with this by making each system smaller (hello microservices), but then someone has to understand how they fit together. And someone cannot. It takes teams of people.

You can deal with the personbyte limitation by forming teams that work together closely. The more complex the product we’re building, the more knowledge we need, so the less duplicated knowledge we want on the team. Team size is limited too, because of coordination overhead.

If you think about it this way, you might recognize that in many software teams, our limitation is not how much we can do, but how much we can know. To change a sufficiently complex system, we need more knowledge than one or two people can hold. Otherwise we are very slow, or we mess it up and the unintended effects of our change create a ton more work.

If the limitation of my team is how much we can know, then mob programming makes a ton of sense. In mob programming, the whole team applies their knowledge to the problem, and each person takes turns typing. This way we’re going to do the single most important thing in the most efficient and least dangerous way our collective knowledge and know-how can provide. In the meantime we spread knowledge among the team, making everyone more effective.

Mob Programming applies all our knowledge and know-how to one task. (Maybe we never tried it before because screens this big used to be expensive?)

If your software system has reached the point where changing it is one step forward, two steps back — it might be a good time to try working as one unit, mob-programming style.