One of my former bosses had a nice sign on his desk: “It’s my fault!”. He often pointed to it silently when we came to him again finger-pointing on each other – complaining and quarreling.
Our project was very stressful. Everyone had a lot to do on a tight schedule. Of course, we had defined our responsibilities at the beginning of the project so that we could each concentrate on our areas. Given the complexity of the project, this was a must.
As usual, there were of course disputes at the boundaries of responsibility and where the specifications were not entirely clear. One was a simple switch that the frontend had interpreted exactly differently than the backend. It would have been a very simple change for any department replugging the cables – but everyone was keen to point out that it was the other one’s fault and that they would have to repair it. So, after a lot of back and forth, the boss had to decide which way to go and the problem was solved within five minutes.
He had urged us not to focus on the question of guilt, but simply to consider the impact and find the most cost-effective and low-risk solution.
This became extremely important in the test and pre-production phase. We had to struggle with many mistakes every day and the closer we got to the go-live, the bigger the decision-making bodies became.
Several divisional managers and board members were ultimately responsible and so it became essential to prepare the decision clear to the point: What is the problem, what is the impact, what are the solution options weighted according to effort and risk?
In this intensive project phase, we postponed the question of guilt. This decision wasn’t at all that easy, because besides personal sensitivities it was about real economic effects: While in the case of incomplete or misleading specifications the client had to cover the costs, we were liable in the case of implementation errors.
By excluding the question of guilt from our daily work, however, we had changed the project culture and were able to focus on tackling the upcoming problems. This was one of the reasons why the project changed from close to failure to a global showcase.
After the storm of bug fixing had settled, I went through the long list of bugs one by one with the head of the business department, and we classified them into your guilt, our guilt, and disagree. In the end, we had to smile because with our bottom-up exercise we ended up on a 50:50 split. We were glad that we hadn’t wasted our valuable time before the Go-Live on forensics and legal debates.
In another company, I was once asked to lead a task force. One of the most critical systems broke down frequently in production under load and everyone was already desperate. With a team of experts, we finally found the cause after 2 weeks of detailed forensics. It was then fixed with one line of code change. We were all very relieved and happy about the joint success for which we had spent days and nights.
We were happy to report the success to the board. His first question surprised us very much: “Who was that?” Even my hint that the employee could not foresee the effect of such an increased load 8 years ago didn’t help. I could then at least defer answering his question from this meeting so that we could continue to celebrate our relief.
Gratefully, at that moment I thought back to the other company where I had already learned my lesson.
How about you?
How does it look in your organization? Are you still hiding behind the question of guilt, or are you already working together on the solution?
Translation into English supported by DeepL and Grammarly
Like to read more of this?
Check my new book on Amazon:
