Have You Failed in 2018? You Will.
There’s no such thing as a clean slate. New year or not, we don’t get to periodically erase our past mistakes and start over fresh. Instead, we carry our flaws and past errors with us from year to year and project to project. While this may seem tragic, this inability to get out from under the past is exactly what allows us to learn and grow.
But, boooo learning! Who needs it? If you’re like me, you’d rather be dumb than fail a lot. And, you’ve likely tried a few different approaches to alleviate the pain of failure in the new year. Such as…
Resolving not to fail.
Haha. Nice try. You will fail this year — it’s inevitable. When it happens, it will be stressful and uncomfortable, and it may rock you a bit. And, you might be tempted to hide away and wait for it to blow over (WFH month!), but you won’t learn anything if you do that. Time is a decent healer, but it’s not a very efficient teacher.
Resolving to succeed so greatly that your successes overshadow your failures.
You can try to get ahead of the failure game by succeeding so greatly that your inevitable failures are nothing but tiny blips on your otherwise perfect record. This might work for you in your weird, little head, but, again, you’re not learning anything here. You’re going to exhaust yourself, confuse yourself, and end up ugly-crying in the bathroom by day 2. Striving to over-succeed in order to compensate for past failures is an endless and futile effort — it’s far more effective to address the failure head-on.
Resolving to fail remarkably.
Accept that you will fail, and seek to do so as remarkably as possible. Plan for it, prepare for it, be read to face it boldly. The more you prepare in advance, the more remarkable your failure response will be. As someone who failed many times in 2017 and was caught off-guard every time, I know firsthand how an unprepared response can aggravate and prolong the impact of the error.
My least favorite, but most instructive, failure of 2017 occurred at the end of the year, just a few months after starting my new role as a Software Engineer on the Emerging Platforms team at Group Nine. I made an oversight that lead to the delay of the deploy of an important project — an error that would have been disheartening at any time, but was particularly so since it occurred in the first three months of my employment. (cue Facepalm Picard)
Before The Fail
Resolving to fail remarkably starts before you even realize that you have failed — in your daily mindset and openness to the potential of failure. This openness will impact how you react in the moment you realize your mistake and will ultimately set the stage for the entire resolution process.
During our deploy, when my teammate, Chao, and I began to realize that something was wrong, Chao immediately began brainstorming possible problems and solutions, and I employed the revolutionary tactic of trying the same thing over and over again. I was so certain that everything was set up correctly that I was blind to the potential failure (and thus the potential solution). Once it became clear that the problem was indeed the result of my own oversight, I grew dismayed — so much so that I became inert and unable to find solutions at all (pictured).
I allowed pride, closed-minded thinking, and self-condemnation to dominate and tarnish my response. Alternatively, a successful failure realization process would include the following dictums:
Be humble.
Humility is the most important mindset you can employ when faced with the possibility of your own failure (heck, in all areas of life). Humility is not only an honest and fitting response to who we are as fallible humans, but it is also a response that will actually serve you. It will keep you open-minded and amenable to others’ suggestions when you need them most. It will shape your brain to accept your own imperfection, creating a world in which all faults are possible and every nook and cranny should be checked for potential errors.
During the deploy fiasco of 2017, I was so certain I had covered all the bases, that I was unable to admit the problem may have been due to my own oversight. This inability to consider fault limited the possibilities I explored and further delayed the resolution process. Entering a potential debugging situation with a humility mindset will result in a more thorough and timely approach to finding a resolution.
Forget everything you know (or do the next best thing).
Discard all of your assumptions about your project. Almost certainly, you are blinded by your internal knowledge of your code, and you are biased by your history with the project. You think you know it forwards and backwards — and you likely do, but that may only hurt you in a high-pressure debugging session. If you want to address the problem most effectively, you’ll need to forget everything you know and start from scratch.
But, how exactly does someone do this?
I must admit that I’ve never been particularly good at this. In the heat of the moment, I tend to fall into the same patterns — all of them predicated on my knowledge of the code I wrote. Perhaps this “temporarily discarding your assumptions” thing is something that develops with more experience, but I think there’s an equivalently-effective approach: ask someone else.
Ask anyone at all, but an outsider is best. Someone who has “forgotten everything you know” because they never knew it to begin with. I can’t tell you how many times some rando in Marketing figured out what was going on with my code just because they were loitering around eating lukewarm dev pizza and asking a lot of questions. There are smart, logical people all around you — explain the situation to them and listen to the questions they ask and the answers you give. There’s probably something there.
Ultimately, assume nothing — both about the problems your project possesses (if possible) and about who is best to uncover those problems. It may be that you are the least equipped to uncover the problem at hand, and it may be best to spitball with someone who knows very little about the code you’ve written.
Accept yourself.
Self-acceptance is integral to a successful failure resolution process, but unconditional self-acceptance is difficult to achieve. All too often, our self esteem and self worth is tied to our professional outcomes, rocking our sense of self when failure arises. When you realize that you have committed an error, you may be tempted to beat yourself up and tear yourself down, instead of embracing yourself as an error-prone individual who is fully capable of tackling the problem at hand. Attacking and belittling yourself will ultimately inhibit your ability to find a solution. If you accept yourself fully — regardless of the outcome of the project — you will remain present and active, poised to approach any unexpected hiccups with a solutions-oriented mindset.
After the initial fallout has subsided, you’ll begin a longer-term resolution process that will include an both individual and team-wide action plan.
After The Fail: Individual Action Plan
Gather the facts.
Ensure you fully understand the error that occurred and why it occurred. Make a list of the technical reasons for the failure and different ways the failure could have been avoided. Be as objective as possible. This list will be a helpful reference when speaking with stakeholders and when preparing documentation.
Measure the impact.
Seek to understand the gravity and the true impact of your error. The impact may be smaller or larger than you realize, but it is necessary to determine the true scale of the impact in order to approach the proper resolution. You don’t want to make a mountain out of a molehill, but you also don’t want to downplay the damage you caused.
Write documentation.
No one enjoys writing a post-mortem document. It’s dull and tedious and reminiscent of the things you didn’t want to happen. It feels forced and formulaic — and it usually is — but it’s also helpful for those necessary things that keep a company running. It formally documents what occurred, providing a standard outline of the impact of the situation and the team’s response to it. It provides a reference for stakeholders and other relevant parties to consult when questions arise. It synthesizes all the information and provides a starting point for determining how to prevent similar issues in the future.
Employ Empathy.
Approach the situation with empathy for those your error affected. Most likely, you aren’t the only person affected by your mistake and others will be involved in the clean-up. Make it clear that you understand the difficulty you’ve caused them, and ensure they know that you are grateful for their help and support.
Practice Self-Compassion.
Have compassion for yourself. Unless you intentionally acted in malice or negligence, your error was likely the result of an understandable oversight or an unintentional mistake. You are responsible for the mistake, and you must bear the burden of the resolution, but be kind to yourself. This mistake doesn’t define you — you possess just as much value and worth as you did before.
After The Fail: Team-Wide Action Plan
Facilitate a solutions-focused discussion.
Team-wide retro meetings serve to gather knowledge and understanding about what occurred, brainstorm solutions to the problem at hand, and consider prevention techniques to implement for the future. Such discussions also serve as a team-building exercise and a restorative practice for the most affected teammates. For those who were primarily responsible for the error, such an activity communicates that they are valued and respected team members who must be involved in the long-term solution.
Hopefully, your team already facilitates retro discussions at a regular interval. If not, start now! Don’t wait until something goes terribly wrong, as there are always improvement areas to consider and discuss. Then, when something does go awry, everyone will be comfortable with the format of the discussion and better equipped to contribute solutions.
After my deploy fiasco, the Emerging Platforms team at Group Nine discussed the situation together as part of our bi-weekly sprint retro process. As in all of our sprints, we listed out the things that went well throughout the sprint, and we listed out things we could have done better. (This sprint had a slightly longer “could have done better” column than previous sprints, but, otherwise, it was the same.) Then, we voted on the problem items we wanted to focus on and build solutions around. We all contributed several different solutions ideas, determined which solutions would be most impactful, and created tickets to enact those solutions in the next sprint.
Enact procedural updates.
Put the team-devised experiments into practice. Ensure relevant teammates are active and involved in the solutions-building process, and make sure all teammates are aware of procedural changes and invested in incorporating the new guidelines into their workflows. Communicate regularly and follow-up in the next retro to determine if the changes were effective.
Our team-devised changes included creating a general, project-agnostic set of pre-deployment guidelines and a set of questions to answer at the beginning of a project to ensure deployment issues are caught early. We also built platform-specific deployment documentation to synthesize our learnings from the deployment fiasco and provide a tool for engineers building similar projects in the future.
After The Fail: Gratitude
It’s refreshing to be a part of a team that viewed my failure as an unfortunate event that could have been avoided with refined team-wide processes — and then employed me to help refine those processes. My team understood that failures aren’t typically the result of rogue or unskilled employees making grave errors, but of good employees making human mistakes. Understanding this as an organization enhances employee morale and team camaraderie. Understanding this as an individual enables you to accept and address your failures in a remarkable manner.
