Trust is the foundation of an effective software team. A team that is empowered and trusted is more likely to speak up and address pervasive technical issues that could threaten disaster for a company.
Recently – a developer posted on Reddit about a horrendous mistake he made on his first day at work …
[I] screwed up badly. I was given a document to setup my local environment… [but they] were actually for the production database… [I] basically cleared all the data from production.
The CTO told me to leave [and] I was told I “completely fucked everything up”.
Sounds pretty nasty and I do feel sorry for the software developer.
Based on the CTO’s finger-pointing reaction, it sounds like this developer is on the receiving end of a culture that might have a trust problem – and they won’t be the first.
When developers aren’t trusted and empowered, pervasive issues can slip unnoticed with reluctancy to speak out and inability to influence technical priorities.
Building trust in a team is not just managements responsibility, it’s down to the individuals in the teams.
An untrusted team can fall into a downward spiral – as the team become less vocal about issues that need addressing and become more likely to accept the status quo.
A well trusted team will act on the most pressing issues, which includes security risks as aforementioned, whereas a team that is punished for it’s failures will adopt a risk-averse position allowing systemic issues to thrive.
When product teams, prioritisation and decision making is made outside of the development teams visibility, expect these types of disasters and expect a lack of technical innovation.
Reid Hoffman recently shared in his Masters of Scale podcast how former Google CEO Eric Schmidt would use the concept of managing chaos in order to achieve innovation. Google is renowned for empowering and trusting it’s employee’s.
Google’s trust is exemplified in it’s 20% time and ensures the developers have input and a voice to raise issues earlier, that if not addressed could grow into more pervasive and systemic issues.
How to create a trusting, disaster-avoiding team?
- Support others with process, not solutions – Rather than giving solutions, encourage the use of correct process. Supporting with process rather than offering solutions builds problem solving skills and ensures more creativity and engagement.
- Watch your language – Tackle language such as “someone should sort that out”, or “someone forgot to do X”. Language that insinuates “someone” else is to blame does not help to solve systemic issues. You and your team is that “someone”. Instead talk about what you can do to fix the issue and use positive and action-oriented language.
- Practice systemic thinking – Following a disaster, don’t focus on events and individuals (blame culture), instead focus on all the different influences, forces etc that caused the issue, don’t just try to blame a single person. For a great intro to systemic problem solving read [The Fifth Discipline].
Question: What’s the worst software developer mistake you’ve made? How did you react?
— Let me know in the comments below
- 2023 Summary: Data Driven Stories About The Cloud - December 31, 2023
- 2022 Summary: The Open Up The Cloud System - January 1, 2023
- Open Up The Cloud Newsletter #30 (January Recap 2022) - March 1, 2022
