The Story

by Nick

Jake leaned back in his squeaky chair and pushed his keyboard forward with his one free hand. The other hand held a full cup of freshly pressed coffee. He was lost in thought. Even the shrill screech of his keyboard sliding across his faux wood desk couldn't pull him away from his pool of reflection.

Another year had passed and he was soaking in his achievements and failures of the past year. This was a familiar ceremony for Jake; he would take a beat every quarter or so and reflect. The idea was to tease out any areas he might want to improve on. It was one thing he gained from some Scrum training he had years ago - retrospectives: what went good, what could improve, so on.

He was in the middle of swimming around one of his most humorous failures from last year when he was jolted back to reality by a voice. Jake was flung forward by the cheap springs in his chair's back which made him absentmindedly slosh coffee on his pristine "wood" laminated desk.

Jake slung around, eager to readout the cubicle interloper.

"He...y-Hey", Jake announced in a "tough guy" tone; then finishing out with a friendly "brotha!" when he saw who it was.

It was his keyboard cousin, Dan. These two were inseparable. They had shared career paths and met when they first joined the company 5 years ago. They pair programmed, gamed at lunch, processed problems together, made incredible software, and broke builds together. All of this was usually within the first half of the day. Dan and Jake had a type of implied trust that could only form at the heart of a volcano or during a planning meeting playing the MMS version of buzzword bingo. These two were INSEPARABLE.

"Hey buddy, how's it going?", Dan asked.

"Good, good... I-I think, unless you're about to change that.", said Jake in an almost expectant tone. Again, these two bordered on pre-cognition because of the time they had spent together in the trenches. Discerning Dan's facial and body language was second nature to Jake.

Dan straightened up into a formal posture and spoke using hand gestures; much like how Bill and Ted would force out a sentence without a "whoa!" or "yeah!"

Jake shook his head, knowing he was about to get a worthy rendition of Dan, playing Keanu, playing Ted 'Theodore' Logan.

"Ok, so we have been asked to spin up a 'most excellent' intranet."

Jake giggled, "He-he, uh ok 'Ted' so now what's the real word?"

Then Jake saw it, the spark of, "I am not kidding" in his friend's eyes.

"Dude, no way! Is this the 90's?" Jake moaned as he put his hands up to hide his defeated face.

Dan, not missing a beat, "Yes way!"

"Shut it, Ted!"

The next day they were off. The pair didn't even wait for product definition or scope. They would later realize that this was a big mistake. Strike one.

The both of them were feeling a bit displaced because they were expecting to begin working on the API stack for the next iteration of their services. Something that both Jake and Dan had devoted some heavy design time to in the last months of the previous year. They could almost smell the freshly baked implementations and mixtures of Kubernetes, Go, and GraphQL.

"Gahhh, it would've been so sweet!" Jake barked unintentionally out loud.

"Intranet! Hold on, let me break out my mixtape to help us get into flow." Dan quipped back.

These two generally tried to defuse bad situations through joke therapy. In this case that was going to turn out to be a mistake as well. Strike two.

They collectively decided that this "intra-web" could be done quickly and that they would be able to return to their normally scheduled programming of doing something "fun." Unexpected situations that were generally unwelcome tended to make these two buckle on upholding good solid engineering principles as well. They would also recount this as an error in judgment. Strike three.

Much like when Jekyll transformed into Hyde, removing sound judgement was the tipping point to things going monstrously wrong.

Their keyboards sounded like a Monty Python coconut steed.

"I've got the boiler plates and the landing page, " Dan touted.

"Solid, I'll pick up the blog components and team pages." Jake said confidently.

It was as though the two were working off of a virtual task board in their networked brains. This went on for a solid week or two and then the first mistake's reaper came calling.

The designer of the project stopped by. "Hey, fellas here's scope and designs for the intranet site; I've also posted links to all of this in chat. Product was super serious about us nailing this - it's for the executives so let me know if y'all have any questions."

The two keyboard cowboys slowed their typing so that the clicking was now distinct and discernible. They acknowledged him and both glanced toward the designs and then back at the designer with a nod of acceptance. The clicking intensified and returned to it's normal pace.

"So, you think we should have a look? They put in the work after all." Jake said half-hearted.

Dan, continuing to type, "We'll check them out later, we'll make sure we deliver close to what is needed."

They never did.

It was getting late and they were trying to wrap the project for a demo on Friday. Then Dan stopped. He was in need of that one thing that always looms as a developer stubs out a UI - content. They were both feeling a bit salty so they decided to break the tension by making up stubs of content to help round out the interfaces that they had been building.

"What should go in the main content of the landing page?" Jake asked as he opened the migration scripts.

Dan thought for a moment, "Hmmm. Let's go with a message that will really convey how important this is."

Hubris, not taking their work seriously, and joking. Here comes the second error waiting to explode.

At this point in time they should've both recognized that they weren't approaching this project with their usual integrity, dropping who they were as developers on the floor, and kicking their professionalism around indiscriminately - but they didn't. Their pride and lack of enthusiasm around this project would be their undoing.

Jake filled out the data migration script in the project. This script was meant to roll locally so that it would create simple placeholder text while they finalized some of the designs tomorrow. No "lorem ipsum" for this, oh no this particular project required special text.

Dan then dictated the following:

"IF ANY OF YOU FOOLS FOUND THIS SUPER SECRET INTRA-WEBS THEN YOU BE TREADING IN THE WRONG PLACE SUCKAS. YOU HAD BETTER WATCH YOUZ' STEP!"

"Classic" the two said in unison.

The pair continued to come up with hilarious boiler text as the night went on. In reality, it was only funny because the two were riffing off of each other's previous text-based creation and the fact that they were both in need of sleep. It was 2am and way past time to go. Jake hurriedly committed the file and then pushed the changes to a working branch, or so he thought.

git commit -am"adds migration scripts for temp content."
git push origin master

There were many things at play here, negligence being chief among the violations. Jake was working from a new laptop and had not setup git aliases yet so he had been typing out entire git commands. Instead of pushing the changes to their feature branch he pushed the migration and source to master. Which wouldn't have been a major problem since this was a new project but the previous week the DevOps folks published a new policy that would automatically deploy changes merged to the master branch to a staging location and drop the URL into the team\org chat of the resulting build\deploy. The idea here is that the more eyes on something before it went out to production the better.

The next day the two scooted in like a pair of cross country skiers; no real steps just slides along the dense carpet panels. Dan was the first to see it, only to respond to the sight by sucking in air with the intention of producing a sigh. Then Jake noticed it.

There was a crowd of managers encircling their desks. They didn't notice it right away but with each concentric circle the titles of the group became longer and more "important." The outer ring had their managers, then the middle one was populated with VPs, and finally the inner ring was populated by C-level folks.

Jake looked at Dan and said, "We either did something really good or..."

"...really bad", Dan said nervously.

From the looks on the encamped visitors it was going to be bad. It was too late, the groups had already spied the pair of sleepy skiers.

The CEO, Charles Gibson stepped out from the crowd and asked the two one very simple question...

"Can either of you tell me why I should 'watch youz' step'?"

---

The Application

by Kirby

When I was thinking about this topic and the message I wanted to deliver, it was all about how helpful mistakes can be. Most learning comes from mistakes. We mainly grow through failure and adversity. All that jazz. I wanted to convince you to actually appreciate your mistakes and to be thankful for them because of how valuable they can be.

But if I'm being honest, I hate making mistakes. I hate screwing up and I hate looking like I screwed up. I was thinking through the numerous mistakes I made in the last several years as examples for this story. Cringe. I was thinking through mistakes from my childhood and teenage years. Cringe.

Cringe. Cringe. Cringe. It barely lessens with time.

So I'm not in any kind of position to tell you to actively appreciate mistakes.

However, I can teach you how to systematically use your mistakes to learn and improve. You can appreciate the growth you achieve if not the trigger for that growth.

You need a positive system that you can apply when you make mistakes to systematically get better. Try not to focus your mindful energy on your mistake. You have plenty of time to do that at two o'clock in the morning when you suddenly jolt awake thinking about the stupid thing you said to that person that one time.

Growing from mistakes can be a simple process that you should follow regularly:

1. Admit you made a mistake
2. Understand the contributing factors that led to the mistake
3. Put in safeguards so that you never make that mistake again

Simple, right?

Admit you made a mistake

Admitting we made a mistake is the hardest part, but it's vitally important. It's difficult because:

• We may not think it's our fault
• We don't like to look bad
• We're worried about the consequences of the mistake

First of all, it doesn't matter if it's actually your fault or not. Simply admitting that you might be at fault or that you believe you made a mistake creates a fertile ground for growth. It creates an environment in which real discussions can happen about what needs to be improved. Real growth can only come from a trust environment in which people can be real with each other. Admitting that you might be at fault also opens others up to admitting their own mistakes as well.

When you build an environment in which mistakes are simply opportunities to grow, the worry about looking bad diminishes. It becomes much more about team processes, operational safeguards, and training opportunities. It takes it from "Kirby did something really stupid by pushing the big red button" to "why the #*$& do we have a big red button?"

There are certainly times where making a mistake can get you fired. Sometimes there are bad companies, bad bosses, demands for scapegoats, and people looking for reasons to fire people. Most of the time, though, a person's response to a mistake determines how much that person will be trusted. For example, as a manager I know people on my team make mistakes every day. This doesn't shake my confidence in them. What gives me confidence is knowing they are going to do the right thing and look for ways we can improve.

Diagnose contributing factors

Many companies build mechanisms for identifying the single root cause of mistakes that are made. This is fallacious thinking because there are usually multiple levels of mistakes that contribute to the final undesirable outcome. It's important to uncover all contributing factors rather than the straw that broke the camel's back. Otherwise, removing that final straw just means that another will be added back on top leading to the same outcome.

One of my favorite techniques to use is 5 Whys. First, I like it because it's simple. You start by identifying the mistake and ask why it happened. You use the answer to the first why to ask your next follow up question. You keep iteratively asking more and more detailed questions until you get to the biggest contributing factors. For example (NOTE: I shamefully pulled this example directly from Wikipedia since it's so good):

The vehicle will not start. (the problem)

1. Why? - The battery is dead. (First why)
2. Why? - The alternator is not functioning. (Second why)
3. Why? - The alternator belt has broken. (Third why)
4. Why? - The alternator belt was well beyond its useful service life and not replaced. (Fourth why)
5. Why? - The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)

I also like it because it can be repeated to uncover all contributing factors. For example, you may branch off of any of the "why's" to dive deeply into multiple areas. Every "why" is a contributing factor that can be protected against.

Prevent repeats

We all make mistakes and many of them are outside our control. One might even argue that no mistake is under our control since most people don't willfully make them. The important action that people and teams need to take is to work to prevent repeating mistakes since prevention is inside our control.

For example, let's use the 5-why analysis of the vehicle that won't start. In the 5th why, we identified that the vehicle wasn't maintained according to the service schedule. That's an easy fix. Just follow the schedule! But it's also easy to see how it could happen again. You might not know the schedule or you simply might not notice that the odometer has rolled past an important milestone. So maybe you add a note in you calendar to check your odometer and your maintenance schedule as a repeating event that nags you until you do something about it. That's a step for prevention that recognizes that people are fallible.

Also, it's important that others around us learn from our mistakes. One best practice that I love is creating a collective Lessons Learned wiki page where people can document what they learned from their mistakes. It helps the collective whole get better so that prevention spreads positively. Also, importantly, it's something that we can reflect upon. When you look back at all the lessons you learned, you can appreciate where you are at today compared to where you were at when you made each mistake. It's hard to see your own personal growth unless there's a baseline to compare against.

Summary

I tried to avoid using the cliche of too err is human, but it's a cliche for a reason. It's a fundamental truth. While we might always struggle to embrace our own mistakes, we can build simple mechanisms to learn and grow from them. We can learn to appreciate how we've grown from our mistakes. It's the anti-cringe, and it's something to feel great about.