Living on the command line: Why mistakes are a good thing

Plus, five characteristics of a healthy postmortem team meeting.
200 readers like this
200 readers like this
Bug tracking magnifying glass on computer screen

Pixabay, testbytes, CC0

Failure = Freedom. Is that really true?

For many organizations, it is. These groups of developers... or marketers or educators... are applying the belief that "failing faster" is how we get better. That digging into disasters is how things get better. 

This is all a subculture of the agile way of working, by the way.

So, how can you do this too?

The incident

First, you have an incident. These happen every day. The mindset to have here is "issues and problems are a part of our daily life; they are normal and mean work is getting done." Versus a mindset of "let's do everything we can to avoid problems; problems mean something is wrong." Problems are part of work. When one happens you can have a calm, natural response for what to do next.

The response

For some teams, they identify the problem, throw around a little passive aggressive blame and move on with anxiety for the next time another problem comes up. As they do.

This is what innovative, healthy teams do: They have a postmortem that results in corresponding action items.

A healthy postmortem...

  1. is planned and expected
  2. is blameless
  3. is related to the incident
  4. gives insights into the work you're doing today
  5. helps your team plan for the future

When failure is normalized, teams can have respect for accidents and failures and dig on the problem in an honest way. 

"For someone to go from being in a situation where they're fearful of what might happen to a place in which they can try to experiment and try to grow and try to figure out what might be the right answer, is really great to see. It's like they blossom," says Jen Krieger, Chief Agile Architect at Red Hat, in the latest Command Line Heroes podcast.

Failure as freedom.

For concrete examples of how failure can make things better, listen to episode 4 of the Command Line Heroes podcast.

Jen leads a team of community managers for the Digital Communities team at Red Hat. She lives in Raleigh with her husband and daughters, June and Jewel.

2 Comments

Even in a team of one there is need and means for doing something like this. For myself, I call it a "lessons learned" session.

I find a quiet space and get my yoga Zen on. I review the problem, its symptoms, how the tasks of problem determination and problem resolution unfolded, and places in that sequence where I got off on the wrong track and why. Sometimes I add technical information to my web site to use as a memory aid for the next time I encounter these symptoms or something similar.

opensource problem solving has been my life. Wether work apps or home streaming. I have buffered workload or expense to meet my goal of better results. I have less issues yet usually have a few failures as I learn new methods of getting where I am going For home I am internet only with all services free.. For work I now only make queries from silo systems and do BI reporting. Being able to adapt is full of failure. The end result is satisfying. Knowing you can source, study and deploy solutions is enjoyable. Sometimes it is thought 5 steps are needed. Later you learn maybe two or really ten? When doing something new you must adapt.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.