This is a guest contribution by Dr. Darina Goldin, Director of Data Science at Bayes Esports in Berlin. If you would like to submit a contribution please contact Bill Beatty for submission details. Thank you.
Making mistakes at work sucks! In the best case, it’s just a blow on your ego, in the worst case you might take your company with you. Just recently we had to give up a beloved project because of all the mistakes we had made developing it. It felt terrible! And yet here we are, advocating that we don’t just embrace mistakes but want to build our entire culture around them.
Because, frankly, what other options are there? Mistakes will happen, regardless of if you want them to or not. If you focus on avoiding them at any cost, you will over-engineer your products and have development times so long, they themselves will become mistakes. So instead let’s treat mistakes as a part of everyday life.
It’s less scary than it sounds – you just need to have a plan for when a mistake happens and execute it. It can be as simple as four points: communicate, understand, fix, and prevent from happening again. This plan works for both individual (“I put a bug in the code”, “I emailed the wrong person”) and company level (“We took too long to develop a product”, “Nobody wants to use it”) mistakes.
Handling Mistakes
Communicate: Once you find a mistake, immediately let all the stakeholders know that it’s there and what you plan to do about it. Keep them updated about the process. It’s tempting to secretly fix something and hope nobody will notice – but open and proactive communication builds trust and saves your colleagues time.
Understand: What were the causes of the mistake? How could it have been avoided? Some mistakes are just that understandable stupid mistakes, others are a sign that something deeper is going wrong and you want to catch it. This is not about passing around blame – it’s about providing support where support is needed. The Dutch researcher Peter Kuppens even went so far as to categorizing mistakes into three classes:
- Stupid stupidity mistakes: This is your basic typo. The rates of these will dramatically increase if your employees are overwhelmed or stressed.
- Understandable stupid mistakes: Mistakes that seem stupid in retrospect, but came from having the wrong skillset or trying something new.
- Mistakes routed in your thinking: These are mistakes caused by bad assumptions, like expecting your customers to act in a certain way. Understanding and correcting these will lead to deeper insights into your work.
Fix: Sometimes what’s done is done and we can only accept it and move on. But especially in tech projects, mistakes are usually fixable – it just needs time and resources. If a company emphasizes fixing mistakes quickly, there resources should be made available. It also sends a great signal to the developers – nothing is more frustrating than finding a mistake and seeing nobody care about it.
Prevent: Put safeguards in place to avoid making the same mistake again. This is the most important part – it’s your company’s opportunity to grow and emerge stronger than before. How someone handles their mistakes is a sign of ownership and agency, individually or as a business. And while a single mistake, or even a series of mistakes should never get someone fired (and everyone should know that!), failing to learn from your mistakes definitely should.
Our goal is to create a culture where reporting an error is met with gratitude and no mistake is ever committed twice. To get there, we need everyone in the company to be comfortable and interested in giving and receiving feedback to anyone about anything. Getting there is not a trivial feat, but it’s absolutely worth it.
How to Create a Culture of Mistakes
Lead by example
There are many ways to achieve this, and none of them begin with “The employees should…” Company culture is built from the top down. If the managers hide their mistakes and get defensive about critical issues, how can they expect more from their employees? Prioritize open, constructive communication within your company. Address running problems and explain decisions within the teams. Make it public knowledge that there is a plan for how to handle mistakes. And once a mistake does happen, admit it and clearly communicate how you execute the plan. Your employees will see the value in that and hopefully start adopting the procedure in their daily work.
Involve the right people
Handling feedback well is a learned skill, but it takes time to learn it. Having even one person on your team who recognizes the value of constant reviews and sets an example is great. So is having tech people who are really good at pull requests. Seek out these people and get them involved.
It’s also a quality you should definitely look for when hiring new employees. When interviewing prospective data scientists for the company, I pay a lot of attention to how they react to it when I point out a mistake they’ve made. Another trick is for you, the interviewer, to make a mistake yourself. Will they point it out or just quietly judge you? Of course they simply might not have noticed – but that’s not somebody I want to have on my team, either.
Welcome questions
It’s easy to say that there are not stupid questions, but asking a question still means admitting you do not know something. It makes you vulnerable. You can be sure that your employees will stop asking questions if they receive unhelpful responses or feel like exposing their lack of knowledge damages their colleagues’ trust in their abilities. But having people who operate on their best guess instead of acquiring the information they need can be dangerous and hurtful. Emphasise that there are no wrong questions and make information freely available. Saying “how can they do X if they don’t know this” doesn’t help anybody – maybe they should have found out a long time ago, but isn’t now better than never? A culture in which you can make mistakes is also a culture where you can ask questions freely.
Watch your phrasing
If you are new to giving feedback, it might become unintentionally hurtful and may disencourage people from being open about their mistakes. It’s a good idea to offer communication training to everyone in the company or at the very least to the management. If that’s not an option, having a couple of good resources, like the Nonviolent Communication books by Marshall B. Rosenberg, can help employees acquire a healthy communication style. Asking for feedback about your communication style is also a good idea.
Make error reporting a virtue
Another part of the culture is that people should freely report errors they find. You don’t want to be a year into development and then find out about an issue someone had suspected from the start. Yet reporting an error might feel like snitching on someone. Or it can be frustrating. If someone repeatedly brings up issues that are never addressed, they will stop. You certainly don’t want engineers who see mistakes and shrug! Instead, make sure everybody understands that people raise issues (or sometimes nitpick) because they genuinely care. Make it absolutely sure each feedback is addressed by the right person. If it’s not acted upon, take the time to explain exactly why.
Stop the blame game
Admitting mistakes is hard, and becomes even harder if you fear it will make people think you are a worse engineer or manager. As a company, make it a rule not to play the blame game. Encourage managers never to hang a project’s failure on a particular person. Instead of discussing whose fault something is, discuss how you can fix the issue at hand. Discourage gossiping. People should be comfortable talking to each other, not going behind their backs. If they cannot do that, understanding why is crucial to keep a productive environment.
Give time
In German, there is a certain kind of mistake called “Flüchtigkeitsfehler” – it literally means a mistake that was caused by being in a hurry. If you are constantly rushing from one deadline to the next, there will never be a time to stop and reflect on what went well or badly – the number of really stupid mistakes will rise dramatically, too. Crunch time can be important when finishing an overdue project, but it should not be our day to day. Make space for regular review sessions and post-mortems. When planning a project, plan not only for the time it takes to code a piece, but for the time it takes someone else to review it, and for documentation. And once the crunch-time is done, it’s a good idea to sit down and understand what lead to the project being overdue in the first place – there must have been some mistakes along the way that caused the delay, so how about avoiding them in the future?
Trust is everything
As a manager, if you see an employee make a mistake, it’s tempting to decide to supervise this employee more closely. This can be dangerous, as it signals “We no longer trust you”. In fact, studies have shown that this can trigger a downward spiral for the employee.
The opposite is conveyed if the employee is allowed to fix their own work. The management should still get involved, but in a positive way. Asking people why they did something the way they did it usually works. That’s not to say there should never be supervision in general – there should, but with different motivation. Standard work reviews and pull requests should be part of your daily business. New employees or old employees doing new things should receive more supervision and also a grace period where mistakes and experimentation are not just allowed but welcomed as part of learning.
Make reviews feel normal
Most people who have to go through a review process learn to handle it well. Just ask a mathematician or an architect – reviewing and getting reviewed while not taking things personally is both a skill and habit. And just like art students have regular meetings where their work gets discussed, so should your team. Let everybody get used to regular feedback rounds and 1on1s. Instead of having big sessions every couple of months, normalize discussing work as you do it. Treat feedback meetings with the utmost priority! I once worked with a manager who would treat these as optional and cancel the moment they got busy – I felt unvalued and unheard.
For those in tech, code pull requests are a great tool of giving and receiving feedback. Rigorous pull request checking is a staple of open source culture but they often get neglected in enterprises. Make it a rule that no code changes can be pushed without somebody reviewing them first and set aside enough time for this. Understand and teach that pull requests are a great tool of creating knowledge transfer and ensuring code quality – even if it means a ticket takes a day longer to get completed.
Be patient
While anyone will probably agree that all this sounds good on paper, some people will find the transition harder than others. Being told you’ve done something wrong and not taking it personally is a skill, and most of us have grown up in an environment where it wasn’t required. Be kind and be patient.
Once you lose your fear of making mistakes, it becomes apparent that the difference between success and failure is not that large and both should be treated the same way when it comes to retrospectives. Just as understanding what caused mistakes teaches us to safeguard in the future, understanding what caused our successes will beget future ones. It’s easy to focus only on successes, or to fixate on failures. How about treating them as two faces of the same coin instead? Ask yourself the same questions about a successful project as about a failing one – in fact, make it a habit to do a post-mortem on everything.
Yes it takes time and it’s tempting to sacrifice that for the sake for more development. But you’ll be saving this time tenfold when you apply the knowledge you gain to your next endeavor. In the long run, you’ll minimize the amount of mistakes that happen in your day-to-day – especially the repeated mistakes. Your employees will become more confident and engaged. And while your competition will still be spending their time fixing technical debt, you will be free to create new and exciting projects.
