“Throughout my life, I’ve been able to see what was in front of me while noticing most people couldn’t. In time, I realized that if the crowd followed something, it was likely wrong, yet, even when this was pointed out, most people would continue to seek safety in mirroring their peers (whereas roughly 10% of people instead were self-directed and were much less susceptible to external pressures or the crowd dictating their actions).”
Seeing Truth in the Age of Information Overload, A Midwestern Doctor, Jan 11, 2026.

Most organizations I helped to improve practiced a very simple “Theory X” approach to managing people. Keep in mind they were continually managing projects that didn’t deliver on time and were always of iffy quality. They were absolutely sure that close supervision and micromanagement of people were the only real ways to show that they were actively managing a continually bad situation. Could anyone imagine that backing off and managing people less would suddenly fix things?

In one particular organization, early in my U.S. Air Force career, I took charge of a project and one thing I didn’t do was constantly check on my team members. I did something that was unique to this organization in that I gave my programmers areas of code responsibility rather than assigning them specific coding tasks. If something needed changing or went wrong in a particular area of the code, one particular programmer was responsible for fixing the situation. Boy, was there an uproar when people outside of my project heard about this. My team members loved the approach.

This was one of many things I was told I was doing wrong. This was not the way it was done at this organization and the way it had been done was the only logical way to do it. This project, which was something we did annually, was certain to be an even bigger disaster they insisted than how these same annual projects performed in the past.

This was not the only thing I did differently at this organization. I also told the programmers to ignore the schedule (heresy!) and focus on getting the code to work well and as expected. Everyone outside our project was sure that nothing would ever be delivered on time, for an annual project that had never delivered on time.

We delivered one month early. In the six months following code acceptance by our customers, not a single defect report was submitted. It was more normal for us to get dozens of defect reports and continue to “fix the fix to the fix” until we wore down the customer and they then finally, begrudgingly, accepted it. I don’t know what happened after that first six months, as I had moved on to my next assignment in the United States Air Force, to sunny Hawaii after Colorado.

Success often follows only after a lot of push-back that insists we are doing everything wrong because we are not doing it the way it had been done in the past. The project, it was insisted, would be even worse than they had been if we continued on with what we were doing.

Luckily, I guess, it never happened that way for me or my projects throughout my career. Observing the situation without the bias of “this is the way it is done and this is the way to do it to get rewarded” was the shortest path to helping a team, project, or organization dramatically improve on-time delivery and quality.

What do you see that needs to be changed to help your project get better, and are you ready to endure the push-back to making that change?

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!).

Focusing On Quality Makes A Difference

“Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”

Steve Jobs

Underperforming organizations are usually led by multiple levels of managers, all using and reinforcing each other’s bad habits and getting promoted for them. Try leading based on doing quality work first, and yes, it will be risky but worth it.

Numbers Uncover The Opportunities

“No one had ever counted this before, and I don’t think anybody realized that there was such a gap. Overall, we were about 75% male — for speaking characters and line count. That was standard across the industry.”

Jessica Heidt, features department manager, Pixar Animation Studios, Bloomberg Businessweek, March 21, 2022.

If something just does not seem right, no matter how well it is accepted by everyone, try capturing the numbers that characterize the ‘not right’ we are seeing. Expect denial and disbelief, but it will pass if we’ve done good research.

Good Estimates Deliver On Time With Quality

“Garbage estimates don’t account for the humanity of the people doing the work. … This ends up forcing bad behaviors that lead to inferior engineering, loss of talent, and ultimately less valuable solutions. … Can’t craft a quality solution in the time you’ve been allotted? Hack a quick fix so you can close out the ticket.”

Infoworld, Software engineering estimates are garbage, Jeremy Duvall, June 14, 2022. 

Otherwise known (by me) as Benson’s Bylaw: People will work at a quality deficit if given insufficient time. Use our past performance to make good estimates, and yes, expect pushback because the schedule will appear to be “too long” even though it is how long it is already taking. Delivering on time with good quality will annoy the naysayers but delight the customers.

Tools Enhance Quality And Productivity

I tell my computer science daughters that they have the greatest toys (ok, tools) to work with when it comes to developing and managing software-intensive systems. Make sure to learn and use those tools, including all the AI bots, when managing your projects, but remember that your best project management tool is still you and that paying attention every day helps to sharpen that tool. 

To avoid “articulate ignorance,” I like to look at the actual data. In the case of the news and social media, I try to see the actual tweet, speech, statement, video, etc. This helps me train my judgment and not be triggered when I see the typical headlines that are often sensationalized.

Experience The Actual Events Where Possible

Years ago, I listened to an admiral give a talk at the end of his assignment at the United States Pacific Forces in Hawaii. Giving such a talk is a tradition for an outgoing commander to do, and I decided to go listen to it in person as I was also stationed in Hawaii. The talk was fairly general in nature and touched on all the countries that were around the Pacific and were under the umbrella of the US Pacific Forces. It was pretty boring.

Compare Your Experience To What Others Claim

The next morning, the Honolulu Advertiser had a huge headline and top-of-page article about the Philippines, which was of great interest to people in Hawaii. They quoted the admiral, it seemed, as a way to have an excuse to write about the Philippines. The entire article was about the Philippines, and anyone reading it would have assumed that this was either everything the admiral said or what he emphasized. The massive front-page article bore no resemblance to what I had heard the admiral say.

Look To History For Similliar Patterns

This was back in the 1980s, and it taught me to treat with skepticism what people wrote in news outlets. This was a variation on the same insight I gained while working at the National Security Agency in the 1970s: that people will report what they think they know, even if they don’t know what really happened. The Hawaii experience added that people will report what they want to talk about rather than what was talked about.

Dig Deep To Discover The Real Insights

Finding the real information in the cacophony of media that exists is a skill that comes with practice. Read the original post or tweet. Listen to the original speech. Read the full judicial ruling. Find and read the actual research paper. Watch the unedited video. Always strive to find the rest of the context: the “what” that came before. It is too easy to accept what we want to hear and reject what we don’t want to hear.

Do It Regularly To Train Our Intuition

We don’t need to do this with everything. We just need to do it often enough that we train our gut, our intuition, to recognize the hazards inherent in the everyday reporting of data and events. When we drill down, we discover an objective reality. If we act on that reality, there is a better chance we will get the results we seek because we acted on reality and not the fantasy others were claiming.

Avoid Articulate Ignorance

All this is equally true in business and project management in particular. We need to look at the actual data plus its context, not always someone’s PowerPoint rendition of the data, and work to understand it. In my experience, more often than not, I had to go dig up the data myself because what was being reported was unusable because it didn’t capture the full data and its context.

For more techniques on getting the data we need see: Deep Dive and Be Masters Of Our Universe.

What about your project is important enough to take the time and effort to dig up the source data to understand the issue and avoid “articulate ignorance”?

First, Review The Numbers

I had a boss who told me that as long as everyone believed we would make the deadline, we would. “All they have to do is believe!” he would say. My boss also wanted me to conduct three status meetings a day to both drive the project and help people believe. Instead, I looked at the numbers: the rate at which we were completing and delivering features and the rate at which we were disposing of issues and defects reported, and I knew we would make our deadline. And we did. In the e-mail referenced above, Elon Musk had looked at the numbers and had concluded that sprinting at the end of the quarter didn’t really do anything useful but instead increased Tesla’s costs. 

Second, Focus On What Is Important

I went to read the article because I was looking for something specific.  I was expecting, or hoping, he would say something like “focus on the quality of our work first,” but instead he put the focus on “the most efficient action.” My experience in software intensive projects was that focusing on quality naturally and efficiently balanced cost and speed.

I’ve wanted to splurge and buy a Tesla Model Y. Decades ago, I originally chose Japanese produced cars over US or German produced cars because the Japanese quality, how well the car worked every day, was as good as the most expensive German cars and only a bit more expensive than the most popular US cars. My focus on quality over cost, features, or speed of delivery has always worked out well for me in both personal and professional contexts.

The real, repeat, lesson here is to capture and look at numbers that characterize one’s business or personal projects. It also helps to sort out such things as pandemics and politics. Getting good numbers and understanding them can be hard, but for much of life, simple numbers do just fine. The one reminder here is that those simple numbers should capture something real that is going on and not be numbers just for the sake of numbers or because they say what we want them to say.

Third, Insight and Science Evolves With Time

The worldwide pandemic has been a good example of how “science,” which produces the numbers we hope will guide us, changes over time as we learn more. Business leaders, managers, and politicians all feel the need to “do something” to justify their existence when a problem is encountered. In my experience, the best counter to such excessive help is to find something, ideally by using something like the scientific method, to base our actions upon. Musk’s shifting the focus away from sprinting at the end of the quarter appears to be a good example of self-correction based upon looking at objective data. While we still seem to be challenged by the changing nature of the pandemic, we should continue to try and nail down the fundamentals so we can make good public decisions. 

I do have to mention that just because there is a “study” doesn’t mean it is a good study or that it will hold up with time. Multiple studies, especially ones that corroborate other findings, are usually more useful. In this day of flooding comments, reviews, etc., I have a great concern that we’ll start to see a flooding of studies just to skew results down a predetermined, often self-serving or political, path. 

Fourth, Numbers Are Useful, But Only If We Understand Them

It sure does sound frightening when put that way. But the author goes on to admit that the normal seasonal flu is twice as deadly, so maybe “frightening” is not a good description, but it sure captures our attention. 

Comparing numbers to a measure of “normality” has always paid me dividends in managing projects and life. When the pandemic first hit, the numbers I would compare it to were the flu, car deaths (averaging 100 per day, 5 of which were children) and the overall average death rate of 7,500 people per day in the US. The pandemic was certainly real, but when we first heard of overflowing emergency rooms, I still recall the periodic news articles well before the pandemic about emergency rooms packed with people, and people even dying in the ER before an MD could get to them. I never felt any panic during the pandemic, primarily because I always had some foundational numbers to guide my feelings and judgement and I did not rely on hyperbolic media outlets whose main focus in life was to attract viewers (or clickers!). 

When was the last time you decided that the “sprinting” you were doing wasn’t helping and so chose another course of action and based it upon reliable data?