The importance of trust in software teams for disaster avoidance

When a junior developer destroys a production database on his first day it highlights just how essential trust is in software teams

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

Lou is a Front End Software Developer who currently lives and works in London. A voracious reader with an insatiable inquisition.

Like this post?

Sign up for my blog updates and never miss a post. I’ll send you a FREE eBook as a thank-you.

* indicates required
  • Tim

    The worst mistake I probably made as a software developer was completely removing a feature with a bad line of code that got shipped to a customer. I was horrified when I heard about it. Since then, I’ve become a really big fan of TDD and unit testing (unit testing definitely would have caught that issue).

    I’ve always been of the opinion that if you can’t trust someone, why did you hire them in the first place? Why are they still working for your company? I get so aggravated at times with my current company when people point fingers when something doesn’t go right (not necessarily within our team, but within management). It just isn’t productive. Everyone is on the same team, so it would be a lot more productive if everyone would just try to solve the issue at hand rather than try to shift blame.

    • Lou

      Hey Tim, good to see you!

      ha – everyone has some disaster story!

      I once deleted the style file from a big traffic government client. The product was whitelabeled and immediately looked hideous! Luckily I recovered it … but man did my heart hit the floor when I saw the site without its branding!

      I really do agree with you about the trust comment, we are all on the same team – failures by anyone is really a collective failure!

      The idea of extreme ownership is something I prescribe to…

      http://uk.businessinsider.com/lessons-extreme-ownership-jocko-willink-leif-babin-2017-5