We all make mistakes, all the time, every day. Often there aren’t any consequences, or the impact is so minor that we don’t even notice. Perhaps not noticing mistakes is good for our self-confidence and well-being, but it’s also a lost opportunity to learn.
Losing growth opportunities is particularly regrettable when the mistake could have been costly. Getting lucky is nice, but luck runs out. It’s far better to learn when the cost is low rather than pay dearly later.
When you are in a position to mentor or lead, it’s your responsibility to point out mistakes, help people improve, hold them accountable, and avoid future catastrophes. However, if your response to the mistake is too harsh, it could seem unfair and disproportionate, causing the recipient to push back. If your response is too gentle, it could seem superfluous, causing the recipient to ignore it.
What response gets people’s attention, ensures they understand the significance of their mistake, and helps them to avoid that mistake going forward? If you stop reading, you’ll never know.
For more about dealing with mistakes, read I messed up and Crisis management. For more about setting expectations, read I expect you to read this. For more on fair responses, read Fairness rules.
Sliding doors
When someone makes a mistake, particularly one that might have been harmful or costly, it’s critical to take steps to avoid that mistake in the future. However, if the harm was quietly rectified or luckily the impact was minimal this time, there’s a good chance that they won’t recognize the issue or feel motivated to correct it. That’s when a leader or mentor needs to point out what went wrong, describe the consequences, and ensure it doesn’t happen again.
The leader or mentor might berate the person who made the mistake, embarrass them in front of their peers, or punish them in some way. Fear and intimidation can be effective, but they curtail growth and innovation because people become afraid to take risks.
Instead, the leader or mentor can invoke natural consequences. If the mistake had caused harm or been costly, what natural consequences would have occurred? Not the worst possible outcome—simply outcomes that would naturally follow had the person not been so lucky. Those natural consequences will seem reasonable and proportionate to the error, not too harsh or too gentle. They will make the harm and costs clear, make the person realize how lucky they were, and motivate them to avoid future related mishaps.
When the leader or mentor invokes natural consequences, the person must address them as if they had occurred. The person sees what can go wrong, learns how best to deal with it, and feels sufficient pain and accountability to avoid the mistake going forward, all without the actual external harm or cost. Since each situation has its own natural consequences, there’s no magic recipe. Instead, let’s go through a few examples.
Eric Aside
Natural consequences are also useful in parenting. For example, say your child whines and cries when they don’t get what they want. You could give them what they want, but that only encourages more whining and crying. You could smack them or yell at them, but that’s awful. Instead, you could focus on a natural consequence of their whining and crying: You can’t easily understand them. Say, “I’m sorry, I can’t understand you. Take a couple of slow breaths and calm down. Talk quietly and clearly so I can understand you.” As a result, your child will learn to calm themself and express their needs in words. Those are wonderful skills, and they reduce the whining.
For more about the pitfalls of fear and intimidation, read What’s my motivation? and Is it safe?
AI made me do it
Say an engineer on your team takes shortcuts with their assignments. Perhaps they use AI to write their code without carefully checking the results. Maybe they don’t adequately test their work or ensure it’s secure, accessible, and world-ready. These issues might be caught during code review, pull request (PR) validation, or production testing, but the engineer should be submitting quality code from the start.
The natural consequences of submitting poor, unchecked, or incomplete code are harm to customers and bugs that must be fixed. If you are the leader or mentor of this engineer, you can invoke these natural consequences. After noticing the engineer’s shortcuts, tell them that their PR won’t be approved until they successfully predict at least half of the errors found during code review and PR validation before their PR is submitted. Each time they fail, they fix the issues found, re-predict, and resubmit. (You could raise the bar to as much as 80% predicted, depending on their capability.) Discuss the impact these errors would have on customers and insist that all errors be resolved before PR approval. As a result, the engineer will discover how to find coding errors before they submit PRs, learn to fix the issues they find in advance, and better appreciate the negative impact of taking shortcuts.
Eric Aside
For more about writing quality code, read Nailing the nominals and A software odyssey—From craft to engineering. For more on security, accessibility, and world readiness, read Are you secure about your security?, Better for everyone, and Stupid in any language.
This is fine
Say an engineer on your team hides problems. Maybe work items are running late. Maybe there are problems with partners or coworkers. Maybe there are security or reliability issues. The engineer wants to avoid conflict, so they try to fix problems quietly or hope they go away before anyone notices. Unfortunately, the problems eventually surface in far worse situations than if the engineer had alerted people earlier.
When the problems surface, the natural consequences are felt by all involved, but the engineer who knew about the problems early on may quietly experience the fallout alongside bystanders or even avoid the consequences entirely. If you are the leader or mentor of this engineer, you can ensure the engineer fixes the issues (along with other coworkers involved). Tell the engineer what would have happened if you had known about the problems earlier—how they wouldn’t have had as much work, how more people would have been able to help, and how you could have negotiated fewer requirements or extended deadlines. As a result, the engineer will learn that withholding information doesn’t help and sharing information helps tremendously.
Eric Aside
For more about dealing with common problems, read You’re late, You can depend on me, and Bring out your dead: Postmortems.
No one is indispensable
Say an engineer always works alone. No one else on the team understands the engineer’s areas or codebase. The engineer might be doing a great job, but if they get sick or go on vacation, it’s a potential disaster.
The natural consequences of being the only person who knows an area or codebase are that the engineer can never get sick, go on vacation, or leave the team. If you are the leader or mentor of this engineer, you can insist that they not take sick leave or go on vacation until they’ve trained a backup for their area who reviews all their PRs and helps them fix bugs and make code improvements. As a result, the engineer will share information about their area, be able to take sick leave and vacation as needed, and understand the risks involved in being a single point of failure.
Say the engineer refuses to train a backup or let others touch their codebase. The engineer is willfully putting their product, customers, and team at risk, thereby failing to meet the expectations of their role. If this behavior persists, the natural consequence is disciplinary action. You should inform the engineer that they are falling short of expectations and that continuing to do so will lead to their dismissal. As a result, the engineer will understand the seriousness of their isolation and correct it, or they will eventually be replaced by someone more responsible.
Eric Aside
For more about avoiding single points of failure, read Knowledge loss.
Naturally better
People make mistakes all the time, but often they don’t learn from those mistakes because the consequences are delayed or avoided by chance. If you are a leader or mentor, you can ensure people learn from critical mistakes by invoking their natural consequences.
If an engineer takes shortcuts with their pull requests, insist that the engineer successfully predict at least half of the errors found during code review and PR validation. If an engineer hides problems, insist that they help resolve the problems even if they weren’t the cause, and inform them of all the ways the problem would have been minimized if the engineer had mentioned the issues earlier. If an engineer always works alone, insist that they train a backup before they ever take another sick day or vacation.
Invoking natural consequences feels fair and justified because the consequences are natural and the lessons learned help people avoid future mistakes. That’s an outcome we all can appreciate.
Special thanks to James Waletzky for reviewing the first draft of this month’s column.
Want personalized coaching on this topic or any other challenge? Schedule a free, confidential call. I provide one-on-one career coaching with an emphasis on underrepresented, midcareer software professionals. Find out more at Ally for Onlys in Tech.
Be First to Comment