Improving Trust to Enable Fast Flow
Discussions of how to deliver software faster are ubiquitous in our communities. There’s a lot of noise around processes and organizational structures, but not much around improving trust as an enabler for fast flow.
I’ve had a number of conversations and experiences this year that have really put trust at the front of my mind. In particular, the trust relationship between leadership and teams doing the work. It’s something I’ve observed for a while but have been thinking about more lately.
This article is mainly just my observations, half-baked thoughts, and some mental re-organization. If you find anything relevant, or want to add to the conversation, feel free to leave a comment.
Lack of Trust Prevents Bottleneck Removal
“My developers all have OCD, they’re always talking about rewriting code and not delivering enough”. This comment from a CxO captures clearly a lack of trust between teams and leadership and explains why bottlenecks aren’t being addressed in the organisation.
The teams are being asked to deliver more work with aggressive deadlines. But the teams are dealing with legacy systems that have built up over the course of many years.
The teams can’t deliver any faster because understanding, changing, and releasing the legacy code all has very high costs. But they aren’t given the time to rebuild the legacy systems because management doesn’t trust them when they raise these concerns and request investment to address them.
Legacy code is probably the most common type of major blocker in my experience, but there are other types of blockers, too, like team organisation, high levels of work in progress, and standardised processes.
The general pattern is teams feeling the pain of a major blocker and voicing their concern and desire to address the issue, but their opinions are not given credibility because they aren’t trusted to make big decisions. The blocker(s), therefore, is never truly addressed.
Lack of Trust Creates Blockers to Flow
A lack of trust can result in more blockers to flow being put in place.
Teams are often forced to estimate their work, meet deadlines, follow standard processes, have their productivity measured, and use clunky tools. I usually interpret these as ways to measure and control the teams due to a lack of trust.
The most frustrating thing is that these controls reduce flow. Time spent estimating could have been spent delivering work. Time spent skipping quality to hit deadlines makes the code harder to change in future. Deadline culture leads to burnout and turnover. Clunky tools add steps and frustration to the development workflow….
Collectively, these controls and measures forced on teams can add up to be major blockers of flow without adding any value.
If leadership trusted teams, there would be little or no need to measure their productivity or set aggressive deadlines to make people work harder. Instead, leadership would be confident that whatever the team delivers is the maximum they could have possibly achieved. And the inhibitors to flow would be gone.
Improving Trust
I do work with organizations where trust is high and the problems mentioned in this article are largely non-existent. Teams have high levels of freedom in how they work, and have few controls placed on them from outside the team.
Equally, these organizations have a more mature approach to addressing major blocks like legacy systems and high levels of work in progress. Teams aren’t automatically given the freedom to do what they want, but they have a seat at the table and are trusted.
The first comes in acknowledging that the people doing the work feel the pain of blockers the most, and they understand in more detail what is causing the blockers. So their voice is important.
Often, the concern is that teams are too focused on the details and code, and not enough on “delivering business value”. That leads to the first obvious step: bringing teams closer to understanding business and customer value so that they are better able to articulate the costs and benefit of initiatives to address blockers.
So how to solve the issue of removing controls and trusting teams to work however they want to? In organizations that don’t have this problem, teams are usually performing to a high standard and they are recognized for it.
There are usually measurable signs like deploying to production multiple times per-day, and also a CTO who understands how high performing teams work and ensures they have the freedom required.
Teams do need to make an effort to earn the trust of leadership, but leadership must appreciate that the knowledge teams have is essential to improving flow.
