The topic of ownership and contribution’s to other people’s or team’s work ignites everyone over and over again. Especially now, when “Agile” is in the mainstream and concepts like “ownership”, “collaboration” and “commitment” has become the main topics in many companies as strongly connected with people, their autonomy and independence.
How to make sure the work is done and people’s ownership is protected? Let’s check how to contribute to other’s work and survive.
In the modern world, our system becomes more and more complex. We have to deal with dependencies, changing priorities, context switching, etc. We more and more often work with some scaling approach. It does not matter if you use Scrum @ Scale, LeSS, Nexus, DSDM, SAFe, Spotify Model or something custom-made. One topic remains: where does my team’s ownership start, and where does it end?
Ownership definition to manage complexity
The ownership definition will vary and may depend on these key factors:
- skills of the team members,
- team experience on the topic,
- company’s experience,
- organisational structure,
- rate of change,
- importance of the project/product,
- risk appetite,
- current problems the company faces,
- level of trust on different levels of organisations,
We want to limit the complexity. Therefore, we create more boundaries between teams to clearly express their need for ownership and make an explicit responsibility structure over our environment.
There are no two identical companies where their setup is the same. Even if we have copied different company structures, our problems and goals won’t be the same. So we have to make adjustments to fit our purpose in each case.
Levels of ownership
The team may have ownership over different parts of our organisation. So I tried to model them in a pyramid below.
The higher levels of the pyramid represent a higher level of ownership and autonomy of the team.
- code – on a specific application architecture layer or endpoints / APIs / models,
- functionalities – from the application perspective or the end-user perspective,
- applications – seen as a computer programme,
- value stream or its elements – seen as part of the value delivery chain.
Even if not stated transparently, each team will possess some level of ownership over what they do. It may vary and change in time, but people require that knowledge. It lets them be effective, but it may build problems in the future:
- we may not have the skills needed to perform the work, or
- we may not have enough time to complete the job on our own.
You can fix the above problems with a Contributors Model. Originally, I know it from the LeSS practices, but you can use it in any environment. The subject of contribution change, but the main principles remains the same. Let me present you the RGB Contributors Model (I do not know how it is called – tried to find out but failed. I like to use this name).
Problem #1: Lack of knowledge and ownership
Naturally, we do not want to approach any work without the knowledge and skills required to accomplish it. In a complex environment, we constantly learn new things – to catch up with all the innovation on the one side and to execute our work and be effective on the other hand.
On a professional level, within our teams, we try, i.e. to focus on personal development; organise knowledge sharing meetings (or TechTalks); provide budgets for learnings; perform Proof of Concepts or spikes before approaching a problem (to know more about how people learn new things, check my other article: Determine the right way to improve learning).
However, sometimes we still cannot cross the chasm of the required level of expertise. It is why in most companies, we value the experience and knowledge of different subject matter experts. Thanks to their job, we can learn faster and resolve problems quicker. These people are our Special Task Forces. But again – because of that, their time is even more limited than ours.
Let’s call these people Blue.
Blue has all knowledge needed to do some work, but it is not his primary responsibility. Blue person will act as a mentor for everyone else. If you need him, he is there. The commitment to perform the required job still stays with the team, they have to discover their solution independently, but if they require support from the area expert, then it is their “guy”. He will come and help if needed.
You can also call him a free electron. He will jump from one team to another, help them and move one. In most organisations, it is chapter lead, lead engineer, expert developer, etc. This person can still do the required job on his own, but the maintenance and support tasks after completing the necessary work remain within a team. This person will still be around in the organisation if further assistance is needed. Still, it would be even better if the team knows what is going on in their area and can be effective without additional help.
What if we do not have the required skillset within our organisation?
Yeah, you guessed correctly – we will try to find an “external contractor”. Let’s call that person Red. He will help us for a limited time – to do his job and leave. He will go as soon as he fulfils his contract, and it is our responsibility as the organisation to learn from him.
So responsibility and ownership should remain within a team who works with such product/module/etc. Red has the knowledge required by the team, so how to make sure the team has all knowledge needed to maintain and support created solution?
Limit access to the organisation’s infrastructure to the bare minimum. The team should execute all required work to learn the fastest what is required to accomplish this task. How? By using pair programming, mob programming, knowledge sharing, instructions, etc. Let him sit together with someone from the team to do his job through the protein-based interface.
It gives better results regarding knowledge sharing and future ability to support and maintain a newly added piece of functionality/module/product.
Usage of Blue & Red will improve organisational transparency and accomplish more demanding work when required.
On the other hand, sometimes we do not have enough time, and this requires a slightly different approach.
Problem #2: So many things to do… so little time
We never have enough time. There are usually more things to do than we can do. This limitation in our reality promotes different prioritisation techniques and assertiveness.
Time cannot be saved, it can only be spent, and if not spent wisely and well, it is wasted.Henrietta C. Mears
But how to choose wisely? How to set our priorities properly? Non-intentionally we choose a possible solution with the assumption that work can be performed only by the owners of the specific area. It is natural for us because it follows our need for identity and recognition.
However, following the rule of less complex systems may not be in line with the needs of our organisation.
What if we can persist ownership and still complete more work?
Let me introduce the third part of the RGB Contributor’s model: the Green one.
The green person/team is the team that owns the system/functionality/module/product. It is in his best interest that it stays stable all the time. In our scenario, they do not have enough workforce to do all their job on their own, or they have different priorities at the moment, so some work.
So there are two apparent possibilities how to work with limited resources in that case:
- we can wait for the right time
- we can add more people to this team
These options will impact our budget (because time is money and more people = more money). But there is a third possibility.
We let everyone make changes to the other team’s areas of ownership. So if you need any changes from team A, then you can make them on your own. However, we face a problem of ownership.
Who should maintain newly added stuff? Should this be the original owner of the solution or the person who adds it? Developers love the principle “you broke it, you fix it”, but it may increase tensions between teams and block real collaboration. So we need a different approach.
In the RGB Contributors Model, the responsibility remains with the original owner of the solution, so we do not create a more complex organisational structure. But, how to make sure that the end-solution remains maintainable?
Anyone can write a new code/model/functionality/part of the value stream, but the original team must approve it. The Green ones are our Guardians. It is their sole decision if work completed by someone else is sufficient for them. No one can tell them to accept something if they are not happy with the solution. However, they can assist the writer with their guidelines, code rules, etc., – anything they require to be in place for their stuff. After this piece is accepted, it becomes the sole responsibility of the original team.
Best practices, how to use the Green Contributors Model
|Different codes of conduct between teams||➜ Explain your team style and the reasons behind it in your guidelines but don’t overdo it with the details. The style will always be evolving, maybe even through contributions.|
➜ Read the guide before starting with the contribution.
➜ Give feedback on the guide, ideally with ideas, how to improve it.
➜ Limit context switching while working on the contribution to avoid that developers have to work in different styles at once.
|Productivity is lower while working on a contribution||➜ Contributions are meant to be the exception, not the regular style of working. Always make sure the outcome justifies the costs using a structured and transparent decision process that involves both contributing and owning parties.|
➜ Make a thought experiment from time to time on potential contributions, maybe even together with a potential contributor unfamiliar to your codebase yet. Try to learn where your design or documentation could be improved – it might not only make the contribution easier but also improve quality in general.
|Solution propositions created by contributors sit around for longer time periods||➜ Plan a contribution jointly and align your timelines as required. Depending on the size of the contribution consider joint design sessions, pair programming, etc.|
➜ Make explicit commitments to each other, and change them as necessary. Anything is better than unspoken expectations or intentionally vague commitments.
➜ If you realize that collaboration will be very heavy, consider switching to the Blue Contribution model instead.
|Domain knowledge missing on the contributing end||➜ When two teams never collaborated before, consider a kickoff where the business context is clarified, terms are explained and maybe even people get to know each other.|
➜ Look into the domain-driven design technique for best practices regarding language and terminology – try to use it to improve and learn from each other.
➜ As the guardian team, use the knowledge transfer phase of the contributing team also as a means of feedback on your documentation and clarity of design.
This model protects teams from resource shuffling. We do not change the team structure to keep everyone busy, but we build new responsibilities over the current organisational structure. It promotes team identity and strengthens collaboration between teams.
In the end, we all push ourselves in the same direction and try to contribute to our success. Because:
A well-functioning team of adequate people will complete a project almost regardless of the process or technology they are asked to use (although the process and technology may help or hinder them along the way).Alistair Cockburn
- https://less.works/ – source of knowledge about LeSS framework
- Mine!: How the Hidden Rules of Ownership Control Our Lives – by Michael Heller and James Salzman (Amazon)
- Code Ownership – by Martin Fowler