Mutual Purpose and Agreed-Upon Methods

I’ve long preferred to work on teams that base cooperation on shared values like inclusiveness, respect, and curiosity. Teams where everyone feels valued at all times, both as a coworker and as a human.

Yet, the phrase “shared values” kinda gives me the willies. It implies that our compatibility as teammates comes from deep-seated beliefs. Which implies shared culture or even religion. I want to collaborate with people who are more different from me than that.

A teammate is anyone whose success is entwined with mine. We succeed
together and fail together. This means we have a shared goal: a mutual purpose. We are going to the same place, regardless of where we each came from.

Yet mutual purpose is not enough for us to cooperate: we need to agree on how to achieve it. If we want to have dinner together, and you go to the grocery for ingredients while I book a restaurant, we are defeating each other. We need to agree that we want to share dinner and we will achieve this by cooking it, and this will require gathering ingredients and cleaning the kitchen. We can pair on tasks or divide them, but we can agree on what needs done. This way we value each other’s work at all times.

In software development, I want to agree on who our customer is and what we are doing for them. Everyone in the team shares this purpose. And I want to agree closely enough on how to do that. Like in science: an “invisible college” of collaborators exhibits shared purpose and practices.

For instance: on my project, we aim to change the way people deliver software. Our methods include:

• provide an open-source software delivery machine framework, so people can write delivery in code.
• in TypeScript, because it is widely accessible (lots of people know JavaScript) plus makes a framework more discoverable (with autocompletion).
• delivering to npm, after passing our chosen checks, through code that we also control
• collaborating asynchronously, with pull requests and in chat, so that people worldwide can participate. We each follow the code changes and a few specific channels.
• with mutual respect and assumptions of positive intent. When we are confused by another’s actions, hop on a video call.
• plus near-weekly planning meetings where we can go deep on what needs to change.

Agreed-upon methods incorporate: what solution we’re building, what we prioritize, some degree of architecture and implementation detail, our collaboration practices, and how we evolve these. The level of detail and which parts are important will vary by team, as needed for their purpose. It is important that they do vary; otherwise this is not a learning system. In our teams as in our technical architecture, the crucial question is “how do we change it?”

Some of these methods conflict with some deep-seated beliefs. Personal values can matter. For instance, if one of our methods is: “when we communicate, every team member’s opinion is heard” and some potential team member believes “the opinion of a woman is irrelevant” then no. That person’s deep-seated beliefs are in conflict with the agreed-upon methods of our team. If a potential team member believes that ignorant customers are to blame for any mistakes they make, that is in conflict with an agreed-upon method of discoverability.

Hiring becomes, will you adopt our mutual purpose? can you join in with our methods? and will you help us reach better methods in the future?

A person’s values might conflict with our team’s purpose or methods, but I don’t want to ask someone to hold particular values in order to work on my team.

Can we please replace “shared values” with “mutual purpose and agreed-upon methods”?