Mistakes can increase trust
If you admit them, own them, and handle them well
If, at the beginning of my career as a software developer, anyone had told me that "mistakes increase trust", I would have thought that this was either a very stupid idea or a bad joke (and considering my appetite for lame jokes, this means something). Today I know it better - both by my own experience and backed by science™.
I had learned very early about the value of usability in the form of user experience. In my last job as a developer, I worked in a team that was creating and maintaining pipelines for Continuous Integration and Continuous Deployment (or Delivery - CI/CD).
For a specific technology whose technical move to production I had helped to accelerate drastically, I had created a dedicated Slack channel for messages informing about pipeline steps and statuses. This included some meta data and links to the pipeline in question. For me, it was easy to follow what was going on. When there was a question, I did not need to get up-to-date.
One day, a developer using those pipelines pinged me. Something had gone wrong, and I could confirm it immediately via the automatic messages. Luckily, I could easily see what was the problem. Unfortunately, I had introduced a bug in the pipelines with a recent change. I tested my changes extensively, but even then, bugs can happen.
One advantage of the situation was that the developer was located in the same building as me. (Yes, those were the times!) While I could have just pinged him back a couple of minutes later, I went downstairs to his desk to talk to him face-to-face. I immediately admitted that this was a bug created by me, that I would start working on a fix, and that I would keep him updated. Then I went back to my desk to do exactly this. Here the advantage of small changes came in: I knew where to start. Within a couple of hours, I had a fix (including an updated set of tests to not make the same mistake again). Before getting it merged to master, I walked back to the developer to let him test the solution himself. I was honest and did not promise that the fix would get live on that same day (it was late afternoon), but if not, it would be the first thing next morning. In any case, it would be less than 24 hours before reporting the bug and its fix being there.
Now an interesting thing happened: The colleague was happy. And even better, his colleagues around him who had witnessed what had happened were also happy, expressing this explicitly to me.
While I was relieved that there had been no drama, I felt this praise was a bit undeserved. After all, I had made a mistake and all I was doing now was compensating for it.
As I learned from the last book I read, this is a general phenomenon! In "Influence: The Psychology of Persuasion", the behavioral scientist Robert Cialdini describes how small service mishaps that get personal attention from the responsible people create a better overall impression than a "seamless experience". The book is worth reading as a whole, so I will not spoil any details here. I was only surprised that it had never crossed me as a book recommendation in my professional circles. I found it via the Alternativlos-Podcast.
The easiest lesson to take away is that it is better to openly admit and own mistakes rather than denying them and being ashamed of them. Still relatively obvious is the fact that platform teams (in the sense of Team Topologies) need to care for the user experience of the developers using their products and services. Another noteworthy element of the story is what was not included in it: Nobody needed to make "caring for the users" a goal for me or put this on a roadmap. And, despite the happy end, there were also things that I could not solve with my willingness and engagement: Technically, it took minutes to go to production. But from an organizational point of view, my biggest nemesis, the heavy Change Approval Board (CAB), was still in place years later. Some problems cannot be solved by technology alone...
Peter Schilling: Fehler im System