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.
Are you making the decision?
- Explain:
“I will make this decision, and explain it to others.” No obligation to accept input. - Consult:
“I will make this decision after consulting with others.” You can influence me, but I will decide. - Agree:
“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?
- Advise:
“You make the decision after I advise you.” I have thoughts; hear them and then I’ll respect the decision you make. - Accept:
“You make the decision. I’ll accept it.” Whatever it is, I’m in. - Abstain:
“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.
If more than one person thinks they are making the decision, and they’re not all in the “agree” category, you have a problem.
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.
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.
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.
If your mob has a navigator, then each person takes a turn in “consult” and the rest are “advise.” This works.
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.