Culture of Trust
What does it mean to trust somebody? We tend to think of trust as either something we give by default and might take back if promises are broken. Or something that has to be earned. Both shorthands are useful and true to some degree, but they hide some complexity that’s import to understand in order to be able to build a culture of trust. They also might seem contradictory, which in my experience usually means the truth is more complex. Let’s explore.
When we trust the teams to act with authority in the face of changig conditions, we get quicker and better informed decisions than if they had to consult with another authority. The fine-grained authority (also known as trust) creates faster more certain outcomes.
On one hand, trust could be thought of as simply accepting a promise. A team promises not to release untested code and if we trust the team to keep their promise, we simply accept the promise and let them do their thing. In this sense, trust is also a promise - a promise to accept the outcome. On the other hand, if we do not trust the team, we might either not accept the promise at all or accept it conditionally (“you can release once you prove to us that the code is free of bugs”). Conditions are a sign of the lack of trust. Or to put it differently, conditions mean there’s a lack of promise to accept the outcome. A problem with conditions is they slow down cooperation (and might even lead to deadlocks), and they make it difficult to feel responsible for an outcome that’s not entirely certain. It’s not hard to see, I hope, that trust must be unconditional.
When Promises Are Broken
What do we do then if a promise is broken? First of all, it is entirely a judgement call that each observer make on their own whether a promise have been held or broken. It is subjective by definition and therefore any punishment will likely to be seen as unjust further inhibiting cooperation.
How do we promote trust in an environment where trust must be unconditional? The answer to this question is there are always natural consequences to any actions. Sometimes they might seem insufficient, but remember two things: (1) that might be the price you pay for a highly collaborative and trusting culture; (2) your judgement is subjective, what seems like a serious breach of trust to you, in reality might have been an environmental condition (e.g.: an intern committed code without tests and review). A healthy retrospective process is essential and might reveal process and environmental deficiencies that might have contributed to the broken promises.
On the flipside, if the team truly owns the outcome (is fully autonomous, trusted and empowered to act as it sees fit), it will be in the best position to quickly respond to any process or environmental deficiencies leading to a higher certainty of the desired outcome.
February 13, 2016
Feel free to comment on the post but keep it clean and on topic.comments powered by Disqus
Climber of rocks, maker of things, husband of wife and father of kids. Manage DevOps @SurveyMonkey. Views are my own, but damn they are good views!