Ownership & Delivery : Consensus

We need to semantically study the word “Delivery” and meaning surrounding it before we can start to work on problems relating to “Ownership” when working in big organisations and within teams.

As it stand, these words get thrown around as if they are mere buzzwords, to fill team building workshops.

The word delivery means in its essence, transportation of a tangible entity from A to B. These two destinations do not have to be physical destinations, but they can also be states in the progression of a project.

As a person talking from the experience of developing software, I will be focusing mainly on delivery on software solutions in this context.

Delivery begins at A, where the project specifications are defined, agreed upon, between all involved parties. Only once this point is clearly defined and settled, we can start to talk about point B and responsibilities of the delivery owner.

Delivery owner is the person who takes on the whole body of agreement made on point A, and extrapolates an achievable point B based on the knowledge available. Thus delivery owner, not only takes responsibility on taking the project from point A to B, but also a guardian of the consensus reached at point A among all involved individuals.

Any change, speculation for the point A after this, muddies the responsibilities & role given to deliver owner. An unclear definition of responsibilities, hurts power and leadership of this role. Thus any change & speculation during the delivery phase should be avoided if possible by delivery recipients. It is very important for delivery recipients and stakeholders to be part of the consensus alignment process in the point A.

If source of cynicism is coming outside of the delivery recipients, but from parties not involved in point A, it should be completely discarded. This is not only a measure to control power and risk mitigation, but also a measure to complete the process in a scientific manner. Because any process of delivery, is an experiment, and no change should be made to the experiment itself without involvement in the hypothesis definition. Changes made in the experiment platform during the experimentation process, renders the whole action useless. In a similar manner, any speculation on the delivery during the building process, muddies the result expected from the delivery. This makes outcomes from the whole activity untangible not only for the delivery owner, but everyone involved. The goals (B) and hypothesis (A) are entirely tied together, and no change shall be made in the goals without some change in hypothesis.

You might have some idea by now, why the specification and immutability of the delivery have such an important effect on the Ownership within a team.

This initial piece is on the effect of immutable Consensus, on Ownership. I hope you enjoyed the read. Please leave me your feedback in the comment section.

I hope to write about the effect of Modularity, on Ownership in future. I plan to talk about how breaking down deliverables into miniscule, small parts can be devastating for Ownership, leaving only a ghost of a “delivery owner” at the end of the delivery.