I was wrong: tech mistakes, accountability, and trust

Last week, I was honored to present for the second year at the NTEN Nonprofit Technology Conference. It was such a thrill to share on a topic near and dear to my tender lil heart, along with a roster of truly impressive and insightful colleagues. How cool is it that sessions were selected based on a democratic process? Since I know we can’t all attend every snazzy conference, I wanted to make my resources publicly available, and continue the conversation here at TDAA!

The big ideas

• Perfectionism is an outgrowth of white supremacy culture
• Practice saying “I was wrong” alone and in the mirror
• Being wrong is normal when working with technology! No one knows it all.
• There are 5 main categories of tech mistakes. By naming them, we can mitigate their impact when they inevitably happen.
• Plan proactively for what to do when mistakes happen. It won’t be so stressful and you can put your attention where it is most needed!

The five categories

Photo Description: The five categories outlined below, with some red accents and cute font.

Metric mayhem: I miscalculated a metric
Product Placement: I selected a technology product that doesn’t work the way I expected
Honest mistake: I made a bad decision.
All lift, no shift: I built a system around a bad process instead of fixing the process first
Show pony: I built something too complicated and introduced technical debt

I think that MOST technology mistakes fit into these categories. Luckily, within these categories, we can plan for course correction pretty effectively when these issues happen in real life. Check out my slide deck to learn more about these categories, and what to do about them.

Testing has its limits

Mistakes are good
They help you grow
They teach you what you need to know

So when you make mistakes,
don’t cry!!!
You’ll do better
If you try

Nursery rhyme

As I was developing this presentation (and these ideas, long before the presentation was even an option), the nursery rhyme above came back to me. I’ve been turning it over in my mind for weeks now, alternating between applauding insight (stanza 1) and repelling the blame/shame game (stanza 2). (I don’t believe that mistakes happen because we didn’t “try”).

I shared vulnerably in a professional forum about a mistake I made recently, a mistake that had a bit of a cascading effect on my team at work and their trust in our data processes. Luckily, it was fixable. A colleague gave the sage advice (paraphrasing) … “as you grow, your checklists get better and better.”

I had a flashback to a time when I was upgrading an application to a new version, and I wanted to test to make sure it worked before letting ‘er rip. I came up with about 40 different scenarios to test, and iterated through the list, making tweaks and reporting issues to the support team of the application, until I thought we were ready to officially move to the new package. Unfortunately, there were some critical features that had not made it into my list of 40! After that rodeo, my list grew to 55 things to check. I still have that list, and I use it for reviewing BIG changes. Most of the time, I end up adding to the list every time I use it. This list enables me to avoid things that went wrong in the past, but it doesn’t necessarily help me guarantee that nothing will go wrong in the future.

Years ago, I learned that there is an entire industry dedicated to this way of thinking. People call it “Quality Assurance” (QA) and developers can even write code that can do many of these tests for us. I dipped my toes in that world through training with the team that supports CumulusCI. I never retained all of the details about how to DO this on my own, but even learning that it was possible expanded my professional imagination. It made me a better builder and tester, even the low-tech way that I handle it for my projects.

The thing about testing is that the perfect number of things to test is always an asymptote.

It’s just not possible to test or even imagine absolutely everything that can go wrong. (And that’s why major platforms like Slack or AWS even go down sometimes!). So it seems to me that we need to take a two pronged approach here:

1. Test as well as we reasonably can, while balancing perfectionist tendencies with making improvements! Test more for things that are high risk, while leaving room for creativity, emergent design, and faster innovation for smaller efforts.
   
2. Own mistakes, communicate transparently and authentically, and build trust. (while trying not to make the same mistakes twice!)

Focusing on the first approach has been fruitful (I’ve prevented some of the BIGGEST things from going wrong) but it’s also been spiritually damaging. I feel immensely guilty and incompetent when I failed to test for something that ultimately went wrong. Shouldn’t this have been preventable? Would someone else, someone better than me in some fundamental way, thought of testing that thing? It takes me a long time to dig myself out of the pit of despair when something goes awry. Can you relate?

So, it’s been really a huge relief to begin to explore option two. Yes, it’s humbling to admit that I was wrong, and I’d prefer for everything to work seamlessly, but I’ve noticed that those vulnerable conversations lead to more trust and intimacy rather than the reverse.

In my presentation, I shared email templates, learning logs, business continuity plans, and documentation templates that I think are essential tools for those of us who automate things, which is to say, those of us who make mistakes sometimes. I shared ways to mitigate the effects of mistakes, what to do when things go wrong, and how to not lie about it. I believe that we – the larges “we” possible! – need to embrace a learning mindset in the face of mistakes, not a punitive mindset. I’ve begun to pair my “uh oh” emails with a list of things I’ve learned. I like this because I find learning intrinsically rewarding AND it demonstrates to my team that I take the mistake seriously without grovelling.

A self indulgent confession: amid a roster of impressive presenters on topics about things going right, it was cathartic to discuss what to do when things go wrong. My dad used to say, “two wrongs don’t make a right,” but what I see in my work is that many wrongs make for great technology. So, let’s get better at embracing the messy middle, declaring “I was wrong,” here’s what I’m going to do about it, and let’s move forward together.