Over a decade ago, a project manager at my work approached me with a proposal. You see, we had a minor quality problem, and he wanted us to do better.

Some background: We were working on an internal data management product, a crucial tool that was used across many deparments for key business functions. We were releasing new versions three to four times each year, and had been consistently discovering enough wrong in each release to justify doing a quick hotfix, often within a few days of the original release.

The nature of the bugs varied. Some were minor UX glitches that just made the tool harder to use, others were crashing bugs caused by edge cases that hadn’t been previously identified. Some issues were more serious, such as new features that didn’t work for some users (due to other software installed on their machines) or defects hadn’t been discovered during user acceptance testing (UAT).

Regardless of the cause, each release had 5-7 significant bugs, and our project manager thought we needed to do better.

He was right.

His proposal was that we set a budget for bugs in each release, suggesting that we aim for just three bugs in each release.

I immediately misunderstood him.

I agreed that fewer bugs was better, but objected to setting a budget, pointing out Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.”

What I was trying to convey was this:

We shouldn’t be aiming for 3 bugs in each release, we should be aiming for zero. None. Nada.

What he thought I was saying was quite different:

Setting a budget was a bad idea because I didn’t want to be held accountable for a metric that might not be attainable.

Talk about different viewpoints on the world!

Aside: In fact, I was already working towards releases with zero defects, doing a full root cause analysis on every defect, and identifying areas where eveyone involved (including myself) needed to improve. Somehow, he hadn’t noticed I was doing this.

What went wrong?

I made assumptions about our shared understanding and common goals, and focused the conversation on the specific areas where I thought we had differing opinions.

By failing to confirm our shared understanding, we (the project manager and I) ended each thinking poorly of the other.

I’ve learned, from this and other experiences, that shared understanding should never be assumed, but always confirmed.

A quick conversation is all it would have taken for us to discover our common ground, and where our understandings diverged, resulting in better outcomes all around.

What’s the shared understanding you’ve assumed without confirmation? Anything going on with your team that might be attributable to this?

Comments

blog comments powered by Disqus
Prior Post
Old blog posts, restored  26 Oct 2025
Related Posts
Old blog posts, restored  26 Oct 2025
Better Table Tests in Go  21 Oct 2025
Error assertions  26 Apr 2025
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Archives
January 2026
2026