Signaling Cooperation: Employee's Dilemma
I’m assuming you’ve heard of the Prisoners’ Dilemma. My summary: 2 people are arrested. If neither tattles they both go free. If one tattles & the other doesn’t, the tattler goes free & the other person goes to jail for a long time. If they both tattle, they both go to jail for a shorter sentence. (The payoffs vary in different versions of PD.)
PD model the value of selfishness. Rational actors will always tattle because they can’t count on the other person not tattling. The real world doesn’t act exactly like this (the actors communicate & collaborate, they don’t just play the game once, morality matters), but it’s a useful model as a start.
What does this have to do with responsibility (consequences flowing towards power)? And what in the world does responsibility & Prisoners’ Dilemma have to do with software design? We’ll get to that.
Power Differentials
The workplace is full of human relationships with differences in power between the parties. The most obvious is the boss & the employee. The boss can fire the employee but not the other way around.
Both boss & employee are getting some of their needs met by continuing this relationship. How can the most needs get met?
Trick question. How can whose needs most get met? If the boss squeezes & underpays & bullies the employee, at least in the short run the boss gets more needs met (assuming the employee keeps working their heart out). If the employee slacks & relaxes & demands raises, at least in the short run the employee gets more needs met (assuming the boss doesn’t crack down).
With creative work, I assume that employee motivation matters greatly. The way the most needs can get met is if both parties treat the other fairly:
The boss offers good working conditions & fair pay.
The employee offers their best efforts.
Cooperate/Cooperate
It’s in both parties’ best interest to stay in the top left. Given the power disadvantage, how does the employee know to trust the boss not slip down to the bottom left? After all, if the boss defects & the employee still cooperates, that’s the worst situation for the employee. And empirically many employers try to sneak into the lower left.
That’s where responsibility comes in handy. By visibly routing negative consequences towards power, the advantaged party is saying, “You can trust me. I’m feeling as much (or more) pain than you are.”
Your options are under water? I’ve had my options repriced to the worst price any of you have.
Your salary is cut? Mine is cut more.
Having opened this door, there are way more questions to ponder which I don’t have time for now. Why do bosses so frequently defect? Why can’t we create better incentives to cooperate? What do the relative payoffs look like in realistic scenarios? What other honest signals can the powerful send?
Software Design
And now finally back to our topic: software design. The motto of Empirical Software Design is (repeat after me), “Software design is an exercise in human relationships.” These relationships necessarily contain power differentials. I know more about this code than you do. You have better credibility with reviewers than I do. And on and on.
On the engineering side of the team we get the best results when we cooperate. Software design is part of that cooperation. But I’m going to make decisions (exercising power) that impact you & vice versa. How are we going to maintain our position in the top left quadrant?
By aligning authority & responsibility. If I change an API that you use, then I either migrate your usages myself or we do it together or I maintain backwards compatibility. In other words, I own the consequences of my software design decisions. I send you a signal that I’m cooperating, that it’s safe for you to continue cooperating. And we both get more of our needs met.
So I finally have the theme for book 2 in the series—aligning authority & responsibility. Now, if that seems like too small of a topic for a whole book, rest assured that seems like too small of a topic for a whole book to me too. Experience shows, however, that this is about the right size once all is said & done. We’ll see.
Thank all of you who are supporting this writing, whether by paying or by trying the ideas & writing about them or telling your colleagues. I wouldn’t do it without you.
One really easy way to overcome the prisoner's dilemma is to just coordinate.
Obviously in the dilemma, you aren't allowed to, but if bosses and employees can't come to such an understanding, the trust must be very low indeed. Don't know how you get anything done in an environment that low trust.
The big difficulty is between the lead and senior programmers. They engage the most difficult questions together, but are in serious career contention. Leads have a very strong incentive to extract good ideas and seed bad ones to protect their position, and they have the default external authority.
The only enduring allocation of authority/responsibility I've seen is the code silo, with people and teams taking ownership. This flies in the face of almost every efficiency and coordination principle, but endures because, as you say, software is about relationships, and it's the only thing that reduces the impact of those relationships.