Don't let a mistake define you
Mistakes happen—and there's no changing that
As an engineer, I hate making mistakes. For me, they are tantamount to a loss. But mistakes are a natural learning process—they must happen whether we like it or not. The growth we can attain from an error can be massive. So, why do I hate them so much if they are a necessary evil? After a week of mistakes, I have reflected on my attitude towards these moments and realised it’s not the mistake that bothers me—it’s the side effect of the mistake I hate.
In a previous post, I spoke about how important it is to gain your peers’ trust as quickly as possible when you join a company. Trust is earned; it takes time to accrue. Different people will have different thresholds for trusting someone. But when you have achieved trust, you should treat it as sacrosanct. Trust will elevate your growth in a company and increase your peers’ respect for you. But trust is not static; it is malleable. You can gain more of it, or you can lose it.
For those of us who are diligent at our jobs and conduct our functions in a conscientious manner, our trust has a primary foe: mistakes. Errors we commit threaten the integrity of our earned trust. The technicalities of a mistake—a bad production deployment, a misinterpretation of a requirement, or saying the wrong thing in a meeting—can almost always be rectified and, in many cases, within a reasonable amount of time. A loss of trust, however, is much harder to fix. A mistake can be a huge setback. The setback might not be communicated explicitly, but you can typically feel it. There’s uncertainty in the air following a mishap.
But if, as engineers, we seek to accelerate our proficiency or competency, errors are a non-negotiable component of this equation. Having come off the back of an error-ridden week, I know this to be true. After the mistakes I have made this week, I’ve seen a development in several skill areas: my debugging capabilities have improved, I’ve had to learn new technologies, and I understand my teammates even better than I did before. This is invaluable data for an engineer.
As I said in a recent note:
I wouldn’t be half the engineer I am today had I not gone through hard times. I am grateful for these moments.
I’ve spoken thus far about mistakes from the perspective of engineers; however, observing errors made by engineers in your charge is a separate matter. When someone for whom you are accountable makes an error, your competence as a leader will be tested. A good leader will recognise mistakes are made, hold the engineer to account, and encourage them to learn from the experience—but they won’t hold it against them. I have compared the similarities between sports and software teams in previous articles. A leader who will stand by an engineer who has had a lapse of concentration is reminiscent of what you see in American football. For example, a wide receiver’s job is to catch the football thrown by the quarterback. Receivers, like engineers, make mistakes: they run an incorrect route; miss a block; or, critically, drop the ball. When a receiver drops a pass, a good quarterback, on the next play—or as close to it as possible—will attempt to throw the ball to that same receiver. It’s the quarterback’s way of saying, “You messed up, but I still trust you.” A strong engineering leader will do the same.
Mistakes for an engineer are an occupational hazard: we’re constantly taking risks. Every time we deploy new code to production, we take a chance. The company assumes that risk, too. This is one of the reasons why engineers are paid so well. A considerable part of the calculus is technical proficiency, of course, but it’s also the risk burden we carry when we attempt to release our work into the wide world. We have to manage this risk and work with our peers for support. And when we inevitably make an error, we learn from the experience and move forward.
Don’t let a mistake define you as an engineer.
Onwards.
H.V.E