Misunderstanding as Technical Debt

Published Jun 27, 2017
Misunderstanding as Technical Debt

We’d spoken before about my coming on board in a leadership role. The chemistry hadn’t been right, but some additional elbow grease was needed to get the next iteration to market…

My task was to alter a portion of the data model and related code to prepare for the large influx of users everyone hoped would come with new features and a marketing push. A portion of the system tracked the companies users had worked for, compiling what would be an authoritative inventory of companies. Trouble was that these were, in part, self-reported; so the inventory was already full of companies like “I am the Best”, “Boaty McBoatface Inc.”, etc.
The CTO rightly foresaw data quality issues as the customer base grew from thousands to “the sky’s the limit”. After working through the problem , two options remained:

  • We could allow for the proliferation of companies and live with having different quality ones (from those with web sites, crunchbase ids, DUNS numbers, to those that were just a name). We would build tools that would aid in raising data quality on an on-going basis.

  • We could introduce a new entity that functioned as a “proto-company”. These could be researched and promoted once vetted. As part of this we would go through the existing inventory and demote companies that didn’t make the grade.

We decided on the latter course; at least I thought we had. But as I dug in, it seemed to me that the CEO understood we were pursuing something closer to the discarded approach. I raised an alarm, sitting the three of us down to hash it out. I framed the issue. The CTO reiterated the plan and, to my astonishment, the CEO nodded in agreement. Both went off to attend to other matters.

The trouble came when several weeks later I ran a script against the shared test environment that demoted a third of the companies in inventory (and, as a side-effect, reduced the inventory by a third).

There was a huge freakout as the misunderstanding finally came to light. While there was little business difference between the approaches, somehow the implementation managed to impact the story people told themselves about the product enough to require significant rework.

Losing a few weeks of work probably isn’t fatal; but the harm grows with every repetition. Misunderstanding is inevitable, and here leadership required that someone listened for dissonances and kept the conversation going until we arrived at a shared understanding.

Discover and read more posts from Robert Moskal
get started
Enjoy this post?

Leave a like and comment for Robert