Fake progress

May 24, 2022

There seems to be a very frequent occurrence of companies boasting with something I recognize as "fake progress". This is the thing opposite of what colloquially gets recognized as "moving the needle".

Fake progress manifests itself as working on features and processes, that overall, don't represent a particularly focused step to achieving a specific goal, and instead are more there to fill out the need of "something going on" and having some output that you can measure but often being a wrong or irrelevant metric. It's progress made for the sake of being able to say that you've made some progress.

Examples might be vain metrics such as the number of tickets closed, the number of PRs created, the number of lines of code written, features created, added team members,... These are tech-related metrics, but there are those on the business side, such as user sign ups or the amount of money raised etc.

Some of these represent valid matrics, but only when used as a proxy to some more relevant, business-oriented metric. It's useful to count tickets closed when those represent bugs and the current focus of the company is to work on stability and robustness, which ultimately affect customer retention and churn.

Companies get into an unhealthy and dangerous habit of reporting some metrics that don't move their business significantly forward, nor they represent any particularly validated learning (a "lean startup" terminology). Small companies and inexperienced founders tend to focus on features for the sake of features, on tickets/PRs/some metric for the sake of that metric, instead of being serious about where their business suffers the most and fixing those things.

I also noticed that there are companies that work in a "data-driven" fashion, and that does seem like a way to minimize the risk - "we might not know exactly where we're headed, but we can at least optimize for the least amount of risk while we're moving". Or they simply use the data to experiment and figure out the best option, while still intentional about where they're going.

The danger of fake progress is that it provides very little to no value, all the while draining the resources and keeping you in the safety of false comfort that the things are, well, obviously, progressing.

Some other, non-tech examples that I'm personally familiar with might be: buying books, but not really reading them, giving a false sense of being very cool about it. Or reading and watching about exercise and diet routines, while not incorporating them into my daily habits. It's easy to deceive yourself that progress is being made.

Now, we can be quite aware of the dangers of fake progress, but how do we really make a distinction between what's still quite relevant, what's really relevant and what simply really just makes us feel like there was a progress?

While there is no clear-cut answer, it seems helpful to think in terms of converting a particular metric to something physical, in the real world, or sometimes even something emotional. If something creates direct consequences that you can feel and/or touch, that might be a strong candidate for a good metric.

The number of tickets closed might become good if it's really representative of the stability of the product and the quality of the code, which in turn means happier developers and happier customers, which in turn means more satisfied people and less employee churn, and means more money for the company which means better things for employees and in turn more will to work on further things that make a positive feedback loop then.

Creating features just for the sake of it is obviously a bad thing, because it doesn't lead to any improved satisfaction on the customers side and it just leads to more fatigue, worry and bugs on the employees' side. But if we're making something that makes a significant difference on the business side, then it's again that similar line of reasoning of improved value for the users, and in turn, for the people in the company.

Learning and watching videos about diets doesn't matter particularly much (yes, you can still enjoy the learning itself, but that's still of very little value), but put into something that shows physical results (healthier or better-looking body) is a significantly better option.

Some other example that I've noticed:

  • creating excessive community meetings
  • making excessive irrevant blogposts and newsletters
  • asking for feedback on any and all activity to get you busy even replying to things, instead of building
  • engagement social posts
  • excessive redesigns of the product
  • excessive and often refactors (I'm guilty of this one for sure)
  • "investigating" options that results in non-exhaustive blogposts or twitter threads (guilty here as well)
  • investing in some bleeding edge, yet unproven, tech with no real reason but to be hip about it
  • working on way too many side projects or experiments that return no particular value (guilty here as well)
  • doing "consultations"

Be wary ot the metrics that you're measuring because they'll also be responsible for the incentives. Measuring stupid things will mean more stupid things being done.

The overarching theme might be summarised as: just sit your ass and build, measure real user satisfaction and relevance and stop finding excuses of your incapabilities of creating something actually useful and valuable. If it's anyone's fault - it's yours. Own it!

So, own it.