I think this is a valuable thing for a team to think about and understand. However, I don't agree that if someone's ranking of these values differs from others on the team that means that someone should leave.
As I see it, finding ways to accommodate the different goals, outlooks, and personalities that make up the team is one of the team leader's responsibilities. After all, there's not really much need for leadership if everyone is the same.
I work on a team with a portfolio of ~30 separate features and 5 people. I’ve almost never been in conflicts with my teammates’ values or aesthetic sensibilities, since we can almost never afford to have two people working on the same thing. If I’m working on someone else’s code it’s usually because they’ve left, so I’m free to change it to my liking. When we do surge several people to a project, there’s still one owner who calls the tune on design, style, etc. so just not much debate about it. It’s their house; the extra contributors are just passing through.
We always do code review, so no one goes too far off the reservation, but you accept diffs that are acceptable in their own context; values disagreements are nonblocking.
Indeed. I also really like that this hierarchy is... not a hierarchy. I.e., there's no universal "correct" ordering of what/how/why.
Lots of people emphasize the "what"/"why" when talking about software engineering ethics, and lament that everyone only ever talks about the "how". I think that view kinds of misses the point. The three questions are rarely completely separate. Plus, for most engineering projects most folks will work on throughout their career, the "what" and "why" are extremely straight-forward and at least relatively uncontroversial. The "how" (good security, good uptime, etc.) is by far the most important question.
> However, I don't agree that if someone's ranking of these values differs from others on the team that means that someone should leave.
The use of the word “agree” suggests that the article says the thing you say you don't agree with but it doesn't.
The importance (to be fair, absolute importance is probably more important than ranking here) of the questions is important to ubderstabing how much you can or cannot accept divergence in the subject matter of each question between your preference and that of (or imposed on, for those where the decision comes from outside) the team.
And the same works in reverse for the team’s perceived importance of each question and their ability to accommodate/tolerate divergence from you.
So understanding the ranking, yours and the teams, is important to understanding fit, but fit isn't driven by alignment of the rankings (in fact, to the extent that there is disagreement in preferences, it is ideal that your importance order is inverted from the teams—that you are flexible where the team is inflexible, and vice versa.)
As I see it, finding ways to accommodate the different goals, outlooks, and personalities that make up the team is one of the team leader's responsibilities. After all, there's not really much need for leadership if everyone is the same.