What's your cog ratio?

As far as product development is concerned, the only thing that matters is the change we make in the user experience. We want our users to be happier because our product exists or, at the very least, less sad.

So when we build things we expect that our work will result in a positive change for our users.

However not everyone is in the business of making direct changes to products. In fact not even developers1 spend every minute building things. Instead most of the work on a mature product has to do with planning, monitoring, testing, discussing, deliberating, and doing all manner of tasks that have no direct bearing on the material2 composition of the product.

Roles like program managers and product managers are one more degree removed from the engineered product. On top of that managers, HR, finance, and all the supporting roles are even further removed from the user experience.

Support infrastructure like build systems, testing infrastructure, and monitoring infrastructure help people build, monitor, and improve the product. However, the people working on the infrastracture are even further removed from the form and function of the final product.

Arthur Ganson - Machine with Concrete. The gear reductions mean the final gear will make one revolution in over 2 trillion years. The machine runs uninterrupted even though the final gear is embedded in concrete, and cannot rotate. CC BY-SA 3.0

In common parlance, the term cog ratio refers to the ratio of the number of teeth of one cog to the number of teeth of another cog. It translates to the number of turns we expect from the driven cog for each turn of the driving cog.

It’s cliche to think of ourselves as cogs in a large machine. But if we do, it seems natural to wonder what our cog ratio is with respect to the final products we ship our users.

This is specially true when the products we work on are not end user products, but are either infrastructure or support products that help people who help people who … build the product. What would the effect be if this product or service you are working on didn’t exist? By how much do you think your work will improve the lives of our users?

Does the product improve no matter how fast you turn?


  1. Contrary to common belief, developers in larger outfits spend most of their time communicating with each other rather than building things. See Coordination Headwinds by Alex Komoroske.arrow_upward

  2. We are using the term “material” loosely here, since software products aren’t technically material. It refers to the bits and bytes that comprise the product.arrow_upward