People don't choose tasks over outcomes. The annual budget chooses for them

Let's start with something that isn't a linguistic curiosity, though it looks like one. In Polish a single word covers both: how much work we have done and what we wanted to achieve. English has two words for it, output and outcome, we have one, and in this episode we treat that gap as a symptom, not a coincidence. If we have no name for the result we are heading towards, it is hard to expect a company to think in those terms. By default we think about ourselves and others in terms of efficiency: how much someone has done and how busy they are. We begin this conversation by admitting that we ourselves aren't sure we are doing it well, because slipping back into the old habit happens to us just as it does to the teams we work with.

The second part of the episode matters more, because it takes the blame off people and puts it on the system. An annual budget closed in the third and fourth quarter requires a declaration of what will be built over the whole year, and in itself shows what mode the company works in. Add to that the lack of reserved time for asking what the point is. If we count on someone finding that time one day, individual people will find it, and only until the backlog crushes them. You recognise a well-implemented process by the fact that doing the right things in it is easier than doing the wrong ones. The third reason is purely technical: a delivered feature is easy to confirm, because it exists and it works, while the impact it had is hard to measure and even harder to defend in front of someone who asks about progress.

The conversation also explains where the habit came from, and that explains more than complaining about work culture. In the factory and in early software, value was known in advance. The product was defined, and all you had to do was deliver it in the planned time and quantity. Today value first has to be established, and that is different work from delivering. In its place there is often a certainty that we know what the client needs, bordering on arrogance, because if we know best, user research is by definition unnecessary. The episode gives the simplest example possible: a feature for removing a product from the basket, built the way other systems do it, without asking anyone and without an experiment. Then the support tickets came in, asking how to remove an item from the basket. Not one, many.