Unforced errors make me sick to my stomach.
I love being on a team. I cannot imagine something more fun than working hard together, suffering and learning and growing as a group, all to solve a problem. When I make avoidable mistakes that get in the way of that goal, I let the team down. I hate dropping the ball.
And here’s the deal: I’m going to make mistakes. We all do. That part is fine. What I hate are the mistakes I made when I knew better. The types of errors that resulted from me not paying attention or ignoring the signals. These are things in my control. Making a decision and ultimately being wrong is part of building something. Forgetting to do something just because I got lazy? Ugh.
I also have terrible recall. Seriously. I remember essentially nothing that I do not write down or make an effort to retain. Atul Gawande’s book, Checklist Manifesto, is a framework that I use to overcome that deficiency by focusing on writing down the things I do, or do not, want to do.
Over time, I have kept a list of antipatterns - mistakes that I make an active attempt to avoid. I sometimes read this document multiple times per week. The only criterion for the checklist is that the antipattern be something I can make an objective decision not to do.
The list only exists thanks to the grace and compassion of people wiser than me who found the time to tell me I messed up. I am not always successful at keeping this list, but I make every effort to try.
I’m sharing it because I hope the cringe-worthy stories that inspired the different items are moments of embarrassment that you can avoid. You are probably part of a team, too. That team needs you to not drop the ball; same way my team needs me and everyone else on it.
About two months into my tenure as a product manager, I paid a visit to a mentor. I wanted feedback on how I presented some features we had released.
I showed up ready. Slide deck, narrative, demo. We sat down, I opened my mouth and proceeded to say a lot of words. Eventually I ran out.
His response: This doesn’t solve my problem.
Me: What is your problem?
Teachable moment mentor: Why didn’t you ask that ten minutes ago?
We started over. The outcome was better.
Finding the specific problem someone is trying to solve, and then working with them to see if you and your product can help, is not novel advice. That’s Product Management or Sales 101. I just got lazy and started talking. That motion is something I can control, and that mistake something I want to never repeat.
In 2015, I had what I thought was righteous anger about another group dropping the ball. I went into a meeting with no other purpose than to be mad about it.
I got started and made it clear that I was frustrated about a particular metric. This was a pretty measurements-driven organization and the source of my frustration was a number I thought I knew. About 5 minutes into the meeting, I realized I had the denominator wrong. I admitted to the mistake and lost a lot of credibility. The meeting went nowhere.
Even if the number was accurate, I would not have been in the right to to be as frustrated as I was - especially with just that number. Had I invested time in understanding the context, I think I would have had a clear idea about the nature of the problem.
I also think I would have built some empathy into the assessment. I would have cooled off and realized that being angry was not going to solve this problem. Demonstrating an understanding of the issue, though, might have.
On a Tuesday a few years ago, I attended a customer call with a sales team leader. They teed me up to chat about a product I managed. The customer described their problem, I talked about our solution, and the customer asked a pretty direct question about a capability.
First words out of my mouth? “Good question.”
I knew the answer to their question. I could have just responded, but I threw in that filler. I don’t know why. After the call, that sales leader pulled me aside and somewhat sternly informed me that “all customer questions are good questions.”
He’s not wrong. When talking to a customer or partner, or really anyone, I am not a professor looking to praise them for asking an insightful question. If they asked a question, either I failed to communicate the topic or they want to dig deeper into a particular area. Both are fine.
It’s my responsibility to be respectful of any question and, more importantly, to get to the point. Ripping this response out of my vocabulary took work, but I’m grateful to have found one more way to improve how I communicate.
I once gave a talk that was part of a series of presentations. I was given a speaking slot and a time limit.
I thought it went well. It probably was fine. I was excited to celebrate. Either way, the person responsible for the series found me afterwards and said, “You went over. Why?”
I did not have a good answer. I knew the constraint going into the talk. I thought I could keep it shorter. I failed.
I’m so glad they asked me, though. I had burned a bit of the trust they gave me when they let me be part of that series. I let them and my team down. Their feedback gave me an opportunity where I could make a conscious effort to avoid making that mistake again.
I’m not more important than the program that someone invited me to join. When people create something like that, they are balancing a larger vision that is greater than my small section. When I make that mistake, I impact their plan. It’s both disrespectful and something entirely in my control. There’s always time for Q&A off stage.
One of the best run businesses in the State of Texas is a chain of fast casual restaurants based in Austin. Everything they do, they do with excellence. Living in Portugal, I miss it as much for the food as I do watching their commitment to that pursuit.
On the founder’s desk is a plaque that reads “do what you say you are going to do.” No ambiguity in that rule. Over a decade ago, I sat in that office and read it. No excuses.
At one point in my career, during a time of stress, I found myself responding to questions or issues by saying that I’ll get to them. And then I didn’t. I wound up giving them a pocket veto.
This wasn’t deliberate. I didn’t hope that the person asking me for something would forget. I just got lazy. Sometimes I got “lucky” that they did move on to something else, but often I just let them down. I had bigger priorities, but I should have communicated that. Instead, I just said “I’ll take care of it” and then didn’t.
On a team, it is better to disappoint someone by telling them upfront that you cannot do something than it is to have them plan around you being responsible for the task.
This is a blog post, but it is also a markdown file in this blog’s Git repository. What I like about that is that this list can evolve in a way that retains memory of where it was when I first published it.
I hope I look back on this version in a few years and think “ah, you’re missing so many obvious lessons.” I hope I continue to have mentors and coaches and friends who are as gracious with me that they continue to provide this type of feedback. I hope I have the humility to listen, an item that would be on this list if I could find a way to apply it more directly.
This blog is also open-sourced on GitHub. Got something to add to this list? PRs welcome, I suppose.