Failure as a catalyst: Designing a feedback loop for success

A few weeks back, Dan Courcy shared the first part of my “origin story” with you in his post The Many Paths to “Hello, World!”. Today, I’m here to share the rest of that story. And, with any luck, I’ll also be able to provide you with some additional insight into how failure can be quite the catalyst that leads to success, when processed as a part of a well-designed feedback loop.

Note: If you haven’t read “Harnessing the Power of Feedback Loops” by Thomas Goetz, I highly recommend it. It sets a significant amount of context for the remainder of this article.

In episode 4 of Command Line Heroes, “Fail Better,” I reference the phrase “fail fast and break things” and how small incremental steps forward can free teams from a dangerous cycle of blame, and move them towards an environment of continuous learning. To the unindoctrinated, this might sound a bit like the Wild West. In some cases, it may even be true. However, let’s wrap some context around those words and see how it works in practice.

In “Harnessing the Power of Feedback Loops,” Thomas Goetz describes 4 distinct stages of a feedback loop that include:

1. Data: An evidence stage in which a behavior must be measured, captured, and stored.
2. Context: A relevance stage in which the data is contextually shared to be emotionally resonant.
3. Consequence: An enlightening stage in which the data illuminates one or more paths forward.
4. Action: A change stage in which an individual recalibrates a behavior, makes a choice, and acts.

In the feedback loop, these four stages are critical for forming the correct path toward learning. The stages provide structure—a framework—to experience failure in a well-defined and controlled way. So how did I learn how to use this structure of a feedback loop to further my career? Really, how did I get back into tech after spending an entire summer typing a seemingly endless amount of code only to find it didn’t compile? The answer is similar to many in the tech industry: I didn’t arrive in the “normal way.”

Of mice and men

Years after my failed first attempt at programming a computer, I decided to attend the University of Connecticut with the intention of becoming a veterinarian. The university, knowing that not everyone who desires to be a vet is cut out for the job, makes first year students take a class that illustrates what is required of veterinary science students in order to graduate. Cutting to the chase: this class involved a cow, and a shoulder-length rubber glove. That’s all it took for this 19-year-old girl to change majors. I used my enthusiasm for an animal psychology class I was taking to make a rash decision to switch to psychology and graduated four years later.

So, how am I not a psychiatrist today? The short answer: I don’t like people. The long answer: I wasn’t a very good student and probably wouldn’t have made it through another six years of school.

Directly out of college, I used my learnings from statistics and math to become a financial analyst. I discovered that I could make spreadsheets bend to my will. I could automate them by linking them together, pull data from databases, and do far more work than the majority of my colleagues just by using macros to replace repetitive manual tasks. It was this love—the understanding of what I needed the spreadsheet to do, what I needed from the database application, and the ability to communicate those things—that led to my eventual fall from finance and descent into the technical world.

Taking animal psychology classes in college taught me the power of observation. Initially it was about observing animals in nature, but as the class work became more advanced, we started observing human behavior. Ultimately, getting that degree in psychology provided the foundation of listening and critical thinking skills that I use today in my current job. It didn’t hurt that I was raised by a man who loved computers. Through interacting with him, I unknowingly adopted much of his language, way of speaking, and way of being around computers that translates directly into how I interact with my colleagues today.

Dreaming together

How does this all relate to feedback loops? At the same company where I had been a financial analyst, I also experienced my first tech job as a project manager. We muddled about with the waterfall methodology for the first few years, and then the decree came: “Everyone shall do Agile.” It was absolutely the “output over outcome” version of Agile. It really was awful most days. However, when you pushed the conflict aside, a few of us did learn how to work better together.

We dreamed together as a team—not about the situation we were in with unattainable test automation and legacy code and design—but about what our intentions were for a perfect system to develop software. We embraced the simple idea that “we are uncovering better ways of developing software by doing it and helping others do it.”

Applying the framework

Unfortunately, what I didn’t learn during that period of time was to stay present in my career. I was so focused on the internal workings of the team that when I was faced with the prospect of finding another job, I was woefully underskilled in being able to explain how my experience would translate to other companies.

It wasn't that I was under qualified, it was that I didn’t know how to use the terminology of the time to compare what I did to what other companies needed. In retrospect, if I followed what happened using the framework in Thomas Goetz’s article, it would have looked something like this:

Evidence (data): I had 6 years of experience in Agile, but was failing to land the jobs I wanted. Interview feedback suggested that my experience wasn’t directly applicable to the company’s needs for which I was interviewing.

Emotional Resonance (context): I was turned down by Red Hat for a scrum master position because I wasn’t “qualified enough” even though this is what I had been doing prior to my job search. Red Hat was a fantastic opportunity for me and an opportunity to work on tech at a software company. I really wanted to work there. I longed to work there. (Note: Red Hat saw the error of their ways 4 months later and offered me a position that was hand crafted for my experience. The rest is history. And I’m forever grateful to my hiring manager.)

Consequence (path forward): I had two paths I could have taken, one which included pairing with a few coaches to work on my responses to interviewing questions. The other was to work on my resume and make it more relevant to the jobs I was applying for at the time.

Action (what we do): I took feedback from a particular interview and worked with a coach friend to restate some of the answers I was giving to questions, specifically focusing on things I actually did in practice rather than the theory of them. The exercise was to make the experience resonate with my “customer” (interviewer) so that they would understand how what I did could be applied to what they needed.

While this exercise sounds like it happened quickly (and it did work out for the best in the end), it took me more than a year to find a new job. During this time, I was traveling for work, layoffs were happening every 3-6 months, and a new CIO laid me off upon his arrival (he didn’t want remote workers), but was forced to rehire me 10 hours later by the COO. Mistakes happen, but they have long-term implications on healthy living, and in this case I was in “epic career failure mode” working for a company that sort of valued my work, but only for the output I was producing, not for the outcome I was able to achieve.

Failure is important

Ultimately, the severity of my situation taught me that I needed to be aware of what was going on in my industry instead of letting things go for as long as I had. Using the concept of shorter feedback loops, I review my professional goals monthly. I made sure to evaluate my career progress, or redefine what I want if my interests changed significantly or something didn’t work out as expected. It’s this process—this feedback loop cycle—and the idea that failure is important in order to learn and grow, that set me on a path for career success today.

Interested in learning more about how failure and how failing better has led to some amazing results? Check out the latest episode of Command Line Heroes, “Fail Better,” today.