The Crusty Customer

I was the new project manager, but I knew very little about the product that I was now working on. I spent weeks making plans—that was my job—for delivering our project to one of our key customers. This customer was no longer paying us for our product and service because our last delivery was so bad (before my time) that a judge ruled they didn’t have to pay us, based on our contract, until the quality of our product met the agreed conditions.

No pressure. I kept digging into our status, calling meetings with experts, and trying to determine if we were ready to go or not. It was maybe two weeks from our planned delivery date, and I was seriously considering putting off the delivery, as I just didn’t have confidence that we would be successful.

The Shift to Curiosity

Then something happened. After stressing for months over this delivery, I woke up one morning, and I no longer felt stress. Instead, I felt curiosity. I wondered how this was all going to work out. I no longer felt the desire to push off the delivery date. Instead, I wanted to deliver it as soon as possible because I just wanted to see—wanted to verify what I thought I knew—about the state of our product’s readiness.

It was a very startling but calming feeling. My sense of needing more information turned into the realization that I’d not learn anything more than I already knew. One more opinion, one more review, wouldn’t change anything—certainly not my gut sense of readiness.

Delivering the Product

I was at the customer site on the other side of the country. The IT director told me to “assemble my team,” and we’d get started with the installation and testing. I told him the team was “just me,” and he looked at me dubiously. Previously, we had brought a horde of engineers with us. The idea was to bring everybody so that when something went wrong—and it would—we’d have the right person on-site to fix it. Instead, my team was on standby to take calls from me, and they could watch the customer’s system remotely (they had full remote administrative access if needed).

Things did go wrong. The customer’s system administrator showed some output indicating the installation procedure had not worked. I told him to give me a few moments and went off to call my team members. In this particular case, my team could see in the log that the customer’s system administrator had simply typed in the wrong commands.

What did I do? I went off to McDonald’s, had a mid-morning snack and coffee, then came back and found the customer’s system administrator. I told him my team had looked at what had happened and asked if he would try again, following the instructions we had provided, to see if it was “any better.” It was—it worked “this time,” according to the customer’s system administrator.

We pressed on with the installation procedures and had a few more “it’s not working” experiences, all resolved in the same way. Our customer kept making mistakes, which highlighted that our system was not easy to install, but also that they weren’t following the instructions rigorously and were very quick to declare “it’s not working again!” anytime something went wrong.

The installation finally finished, the system was tested, and it worked as intended. The customer said, “It’s about time you gave us something that worked.”

Lessons Learned

What really happened? The first thing was that we scrubbed the delivery to within an inch of its existence. There was no rushing it out the door, as had always been done in the past. No wondering. No guessing. Is it really finished? Does it work? Do we have proof—tests showing that it works? Was there any corner of the organization trying to speak up saying, “There is a problem here!”?

We put quality first. As one manager said to me after I had later been promoted to Software Development Director, “You are the only manager who ever asked for quality first and actually meant it.”

We didn’t try to fix it on-site. We didn’t try to superman it into acceptable form and beg the customer to accept it as good enough. Nobody got an award or recognition for working superhuman hours to fix and deliver ultimately low-quality software. The product just worked—once the customer quit making mistakes.

Why the Customer Made Mistakes

The customer made all those mistakes because our deliveries in the past were so buggy and needed so much patching that they had no confidence in what we brought them. In the past, nearly every procedural installation step failed multiple times before being tweaked to work. Their mistakes, instead of them double-checking, just looked like our normal buggy delivery procedure. It seemed “normal” to them, except for the end when it worked—which surprised everyone on the customer side.

This delivery met the criteria for them to start paying us again and likely played a role in my later promotion to Director of Software Development.

The Role of Curiosity

To me, this is a great story of success, but what does it have to do with curiosity? It’s something I finally realized after years of working on projects and managing organizations. Once I’d exhausted my due diligence, I’d settle into a state of calm and curiosity. This state also told me that I was as ready as I’d ever be to take the next critical step.

Rudyard Kipling wrote a poem called If that included the lines:

“If you can think—and not make thoughts your aim;
  If you can meet with Triumph and Disaster
  And treat those two impostors just the same…”

These lines strike at the core of this notion around curiosity. Once I’ve done my work, with all the ability I had, I no longer truly worry about the outcome. Instead, I become curious about the outcome and want to see what happens. Whether the outcome is a triumph or a disaster becomes more of an “OK, so that’s what happened” and not an emotional high or low associated with success or failure.

Cultivating Curiosity

Once I realized this mindset was happening—that attaining a state of curiosity and not dread, fear, or even excitement was a positive indicator of readiness—I worked on cultivating it. This meant working hard with the confidence of attaining this state of mind.

It was also the case that when I felt concern, worry, or emotional highs or lows, I’d coax my mind into a curious, wondering state. This exercise also works well with mindfulness, where I quiet the fury of words in my head and hold the situation in mind without active mental analysis—just observing the rest of the world around me including the emotions from the turmoil that had been in my head.

Mindfulness, after regular daily practice, naturally puts my head into a curious mindset, which I now associate with successful efforts. And when I say successful efforts, I include those where things went wrong but where the curious mindset helped me learn a lot from the experience.

The Whimsical Wife

Speaking of things going wrong, my lovely wife has a memory that hoovers up the universe. She’s a walking Wikipedia on so many subjects. I, on the other hand, take pride (forgive me) in eventually getting things right.

In retirement, spending my day with her, I’ve discovered how often I am wrong—about nearly everything. I even got to the point of wondering how I ever succeeded in life while being wrong so often.

This was a great lesson. One spends a lot of time being wrong up until the moment they get things right. Thomas Edison noted, “I have not failed. I’ve just found 10,000 ways that won’t work.”

People may find things wrong with what we do along the way, but we shouldn’t let that discourage us. We will often be wrong up until we get things right. The trick is to keep trying—mindfully and with curiosity—and ultimately, we will be successful (or successful enough!).