When it comes to leadership it seems that a lot of problems and a great many solutions come down to either a lack of communication or lack of trust, often both.
But why are those two skills so difficult to master? How much time and effort gets wasted simply because we don’t trust our employees, or don’t understand a request? How much dissatisfaction and uncertainty results from not trusting your boss?
Around ten years ago I was working on a major release of software, it was a gated waterfall project. I and three others were critical reviewers and gate keepers for a major component. At the gate review our component was a shambles, really late, testing was far from completed, documentation hardly started. My understanding of the gate review was to quantify risk and to ensure all components were on track with the plan. Essentially a structured early warning system.
We four reviewers unanimously agreed to reject the component. We met a lot of resistance and were put under pressure, we were told that “we were delaying the project”, that “it would make us look bad” it was a difficult decision and we were well aware that it would be uncomfortable. But the reality was that the project was behind and we saw no value in faking things to keep a plan looking good. We felt the purpose was to highlight problems so they could be corrected.
But at some point the plan became more important than the product. The next day a company wide announcement was issued, the project was on track, it had passed the gate and all was well. We were shocked, it turned out that our boss had removed all 4 of us as critical reviewers and replaced us with others that were willing to say all was well. My colleagues and I were deeply unhappy about this.
The lack of trust was shocking, the lack of transparency and honesty showed just how dysfunctional the process was. Unsurprisingly as the project neared the completion the target date it slipped drastically catching people by surprise and the project was close on six months late and we were not first to market. We will never know if being transparent at that point could have given the project opportunity to rectify the situation sooner, but hiding the problem certainly didn’t help.
It is not that waterfall projects inherently lack transparency, but a rigid plan that has a high cost of change creates a barrier to transparency, Project Managers feel pressure to hide problems in the hope they can fix them before anyone becomes aware, or as more often is the case in the hope that another part of the programme slips more so they are not in the firing line.
These days I advocate a software delivery framework that highlights problems as early as possible, but many execs don’t like this. I sometimes wonder if they prefer to pretend all is well or imagine that problems will resolve themselves, this is an Ostrich mentality that allows them to defer worrying until later.
Adapting to an Agile framework where everything is transparent can be a difficult adjustment for many execs and programme managers, being aware of day to day problems, minor issues, or simply that some tasks take longer than expected can be a difficult experience for managers used to only getting positive assurances from PMs. Suddenly they are exposed to information that was previously masked from them. They must fight the urge to interfere and learn to trust the teams, to trust the Product Owners and the Scrum masters. In many ways it was easier to ‘trust’ a Project Manager with a Gantt chart when the real story was hidden – even when 90%+ of the time that story was inaccurate. A pleasant lie is always easier to accept than a painful truth.
You can’t handle the truth
The sad situation is that for many execs they simply cannot handle the Truth, they want an agreeable story that lets them claim a project is on track and are happy to believe all is well until it is too late to hide it any longer, and then they can shout and blame, but all this occurs usually after it is too late to take corrective action, the screaming and the desk thumping achieves nothing but to upset people. No one wants a project to be late, chances are they have all worked very hard and done their best. So in reality they have far less influence over the outcome than if they had valued honesty over platitudes earlier in the process. Rather than enforcing overtime for the last couple of months or scrapping all quality control to meet a deadline they could have taken sensible planned corrective action much earlier had they simply fostered a culture of honesty and openness.
I like to think that most software professionals have a desire to do a good job, they want to complete projects quickly and to a high quality. Trusting them should not be a great leap of faith. In my experience you are more likely to get overly optimistic promises than padding. Your biggest dangers are more likely feature creep or boredom, it is very rare to find a developer that wouldn’t prefer to be busy and challenged.
In short trust the development teams, it is very likely that trust will be rewarded.
John Yorke 