Discussion about this post

User's avatar
Kate Meyer's avatar

> dP&L/dt is 40% science, 60% art — and 100% doable.

When teaching this concept I frequently use the term "bets". During planning, some tasks we know they will pay off with a nice return, but everything else is a bet, maybe on time or return. By calling it a bet engineers were much more okay pulling the plug on bets that wouldn't pay out after learning more data. It also gave us a nice set of vocabulary to use. What might be the expected return, how can we improve our odds, etc.

dP&L/dt also lets me go after project after project that move this number. As long as I improve this month after month this is how I have built the mythical 10X teams. Some fun examples: Outside pure tech I could justify improving retention to improve the overall value by reducing onboarding costs. I took on a small project of two weeks of work to delay a migration by two years to get higher return on capital costs. My personal favorite is simply by increasing release speed revenue on capital costs can be returned faster. A project to simply expose costs saved untold amount of spending from teams who immediately noticed new big expenses that otherwise would have accumulated. Having a deep understanding of finance, manufacturing, and software engineering I do a lot of teaching to engineers, but the payoffs can be immense.

dP&L/dt I have found is cultural and pivot to it can be hard, but instead new teams/orgs/companies can be built with it at the core. While tempting to do a startup, I am sure there is a company out there that does it, just need to find them.

Expand full comment

No posts

Ready for more?