The sense of belonging is an important experience to have. Belonging means that we are accepted as part of, as a member of the group, the team, the company.
We want to be part of a team because what defines the team identity is appealing to us. The team is defined by its vision and its working agreements.
When you are building software the open source way, you can identify 3 main categories of team identity:
- Upstream project
- Downstream product
- Jobs to be done
1- Upstream project
The team members belong first to the upstream project. They will tend to prioritize what they think is the best for the upstream project. They will be progressively disconnected from the people that are using the technology they build. They could even miss new needs and be surprised that people switch to another technology that is not so different/better/other qualifiers…
2- Downstream product
The team members belong first to the product they build. They will tend to prioritize what they think is the best for the product. They will tend to forget that building the open source way is a great way to understand why people want to use the technology by confronting your point of view and requirements with those of the other members of the community. The extreme is that they will end up being alone, and disrupted by another product.
3- Jobs to be done
The Jobs to be done theory has been described by Christensen and his colleagues. I wrote an article about one of his book: How to measure our life and I will probably write another one about Competing Against Luck.
In short, the Jobs to be done theory explains why people are making choices, hiring or firing a product or service, by focusing on the understanding of the jobs, the problem they are trying to solve.
The teams that identify themselves to the jobs to be done are stronger because they can work on technologies in the open, curate technologies that they need, invest in new technologies that could replace their current core technologies, without losing their identity. They can envision their solution as a sole product, or integrated into other products knowing that the most important thing is the jobs to be done. They can partner with other knowing precisely what they are partnering on without feeling that they could lose/win something in the partnership. They can focus on their users and solve a specific problem, a specific “jobs to be done” without the temptation to expand the scope of what they are doing.
I guess that the jobs to be done should be the first thing you want a team to agree upon.
Thoughts? Please comment, tweet, email…
The header picture is from Ryan McGuire.