A person (A) keeps asking their manager (B) for a much-needed tool. The manager hits their limit and shifts the load to a purchasing manager (C), who they know will not reply. C has adapted to protect themselves from directly saying No. A eventually resigns themself to not getting the tool and lets their work degrade. C knows they didn’t approve the tool but successfully reframes the issue as one of “tightening the purse strings during a downturn.” This shifts some burden to C’s manager (D). D promises that the issue will be resolved during the next budgeting cycle (shifting the load to the budgeting cycle).A hits another limit—they aren’t proud of their work anymore—and finds another job. This then puts newfound pressure on B, who reframes the whole thing as a “well, A wasn’t a team player!” The person B hires next is less likely to complain about tools.

Prescriptive engineering is when you say, “What are we going to build, and how?”, and then you execute your plan. Teams with strong prescriptive engineering capabilities can deliver high-quality features fast. And that is, of course, indispensable. But prescriptive engineering is not enough. As surprises emerge, we need to spot them, understand them, and explain them. We need to practice descriptive engineering.

What Disco Elysium proves is you can take an RPG, abstract away all the bullshit about swords and dragons and killing hundreds of bandits (those nameless NPCs who in the game world don’t have families, sisters, mothers), and still have a workable game. That the standard trope of an RPG protagonist being a hobo murderer who just loots corpses to sell their stuff to buy weapons to kill more people to loot more corpses, is not a cosmic inevitability for games.

Assessing whether what you are doing day to day needs to be an intentional process, something you and your manager re-assess routinely and compare to your goals and the organization goals.

Gaps can happen in many shapes and sizes, and you need to recognize when a gap needs more senior leadership attention instead of trying to absorb them all. In those cases, you should be working on properly communicating the gap and its risk to the business (and risk to which part of the business) and NOT attempting to solve everything.

One way is to adopt the simple model of a time horizon. Suppose a team declares the following as their goal: To produce the most value possible over the coming year. This team has a time horizon of 1 year. So, when there comes a proposal to make a particular improvement to their productivity (be it a process fix or some automation or whatever else), they can estimate: How many hours of labor it will take to implementHow many weeks it will take to complete that laborHow many hours of labor it will save them over the year (the remainder of the year, that is, after subtracting the weeks spent implementing) In this way, productivity investments can be evaluated each on their own merit, rather than being lumped together into the “technical debt” pile.

“Technical debt” is just what we call it when the deferred value takes the form of a decrease in our team’s velocity.

“Spend at least 20% of our time paying down tech debt” is not a principle. It’s an excuse to substitute our arbitrary personal taste for a realistic, evidence-based appraisal of cost and value.

So, in order to strategize – to decide what work to do in what order – we need to estimate, at the very least: t: The amount of value that will be created by doing a given taskP: The amount of labor required to do the task

Well-run companies don’t tolerate perception straying too far from reality, so their executives are generally accountable to their real outcomes. Poorly run companies often punish executives who are too familiar with reality, and consequently operate in a realm of shared delusion.

Instead, it provides a framework for quickly and effectively making decisions that protect users and the community, in ways that are predictable enough to be trusted by the community.Once we think about creating such a framework, we realize that this is the kind of model where the more useful data we have to help form our point of view, the better a decision-making process we can create. If we understand our challenge to be how to rapidly gain sufficient context with which to make an informed decision, then it becomes obvious we should consider a user's behavior off-platform.