In the book How to Measure Anything by Doug Hubbard, this section has stuck with me for a long time. In engineering, things often seem impossible to measure. Especially the soft, intangible things. But if something is valuable, it should be observable in some way.

After this book, I started asking much more: how can we observe the success we are after? (Which often opens the question of what success actually is.) And then trying to incrementally find a way to capture that observation into a measurement.

Some product issues arise from inconsistencies between two systems, where a single source of truth is hard to reach. For example:

• Invoice status synced in two cloud systems
• Code ownership defined in two places
• Customer data living in two systems

Some inconsistencies are ok, some are not. Without clarity on the required degree of consistency, you might find yourself in confusing situations.

If inconsistencies are not ok, then you might need two things:

1. Measuring the degree of inconsistency
2. Ensuring the inconsistency stays within an acceptance range.

Once you open up to the possibility of measuring inconsistency, you might find that measuring could be straightforward. For example:

• A SQL query across two dbs that have already been ETLed to the shared data analytics db
• A script in the CI/CD pipeline scanning for code ownership

Having the measurement at hand also helps communicating your technical work to your non-technical colleagues, who now have a better overview of the problem.

But again, it could be that inconsistencies are ok. Inconsistencies might have low business impact, or the systems are planned to be replaced with something else.

As with other things, you might benefit from understanding the surrounding technical and business context to choose the right action and the level of consistency that is acceptable to your particular situation.