Developer enablement – trust
This is my third post on the topic of developer enablement. The first one talked about the topic in general and the second one more specifically touched upon the role of planning. In this post I want to discuss the importance of trust in an organisation.
Trust is predictive of high performance
The DevOps Research and Assessment (DORA) has a great article about generative organisational culture.
In their article they conclude that:
[…] organizational culture that is high-trust and emphasizes information flow is predictive of software delivery performance and organizational performance in technology.
Not only did they see that “high-trust and information flow” correlated with high performance, the relationship was predictive: where there is trust, performance increases.
DORA also references Google’s “The five keys to a successful Google team”.1 Out of the five dynamics listed in the article, the top three are very much related to the quote above:
- Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
- Dependability: Can we count on each other to do high quality work on time?
- Structure & clarity: Are goals, roles, and execution plans on our team clear?
Why this clear relationship between trust and performance?
Risk is fundamental to a successful business
Running a successful company comes with an inherent risk. As a business owner, you try to understand what your customers want and therefore are willing to pay for. You risk developing the wrong thing hoping that you will eventually get things right and be able to make a profit. I wrote about this in the post about planning: the sooner we can give the customer what they want, the sooner we can move their money into our account. The feedback loop where the customer reacts to our attempts to please them is the motivation for reducing the amount of planning done in a software organisation, in favour of increasing the release cadence of the product.
When you (as a business owner) have employees, you must imbue this willingness to take risks in your organisation. This is true for every person and position throughout the organisation but, as we concluded in the planning-post, it is ultimately the developers that are responsible for realising the customers’ feedback and turn vague thoughts and ideas into code that do stuff. If developers are risk-averse, they will not dare be creative nor innovative, and find new ways to tackle problems with the product they are working on. They will be keen to always “do the safe thing”, but the safe thing will likely lead to your product being overrun by your competitors.
But don’t mistake the encouragement of taking risks with an organisation where no one is held accountable. As is stated by the second Google key above: people in an organisation must be able to count on each other to deliver high quality work on time. Accountability and psychological safety are not contradictions, they are both very much necessary in a healthy organisation.
How to stifle innovation
The best way to ensure your employees or teammates are unwilling to take risks and be innovative is to distrust them. You can achieve this simply by telling them outright that you don’t believe in them, but very few leaders do this.
Another excellent way of communicating distrust is by burdening teams with responsibility but not give them the mandate to deliver on them. Even better if the responsibilities are slightly unclear and the team members are not given the opportunity to seek out answers to their questions, “because that’s what the PO does”. If you tell a team that “they must ensure their product is of super high quality and well tested”, but don’t give them the time nor the resources they say they need, you are indirectly telling them that you don’t believe they know what they are doing. The consequence will most likely be that the team take the safest possible approach to the feature, which is likely to yield the least value to the customer, which in turn gives your competition an opportunity to get ahead.
A third – very common – approach to hamper innovation is to maximise the inflexibility in your product and the ways the teams are allowed to work.
-
Enforce work times and locations.
-
Demand that everyone use the tools and techniques (preferably by strict templates).
-
Don’t let the developers participate in discussions concerning:
- Sales and finance
- Architecture
- Testing
- Deployment
- or really anything not strictly related to building one feature at the time.
just have meetings among “non-developers” and then tell the devs what’s expected of them.
This shows the team you know what’s best and they are really just employed to do your bidding, not bring anything of their own to the table.
Self-organising teams
Everything I have experienced and read about “how to run a successful software development company” points towards the quote that is often attributed to Steve Jobs:
It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.
– Steve Jobs
This takes us all the way back to the top of this post and the article from DORA. In self-organising teams, working in a generative organisational culture, the developers trust one another to get the job done and are fast to ask for help if they realise that they need it. Everyone involved knows that risks are necessary in order to innovate and win the marketplace, so when something goes wrong, the teams have the support, tools and authority required to handle the situation. The organisation celebrates their willingness to attempt the things they believe will be most beneficial to the company as a whole.
The teams are responsible for the complete life cycle of their product and understand its financial position in the company’s portfolio, meaning they can be engaged in business related discussions, not only technical ones. Management understands that their role is to enable the developers to do their job and “pave the way”. They focus on hiring people who want to make a difference and are willing to take responsibility for their actions, as opposed to only looking at the tech-stack on the candidates’ CVs.
Trust is required for developer enablement
Going back to my original post about developer enablement:
We want to structure our organisation in such a way that each team can take full responsibility for their deliverables. The team should own the entire life cycle: Planning, implementing, building, testing, deploying, monitoring and supporting.
You cannot achieve the above in an organisation where teams are micromanaged and constantly hampered by their leaders. You cannot achieve this without trust.