LW - Applying Force to the Wrong End of a Causal Chain by silentbob

The Nonlinear Library

Welcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: Applying Force to the Wrong End of a Causal Chain, published by silentbob on June 23, 2024 on LessWrong. There's a very common thing that humans do: a person makes an observation about something they dislike, so they go ahead and make an effort to change that thing. Sometimes it works, and sometimes it doesn't. If it doesn't work, there can be a variety of reasons for that - maybe the thing is very difficult to change, maybe the person lacks the specific skills to change the thing, maybe it depends on the behavior of other people and the person is not successful in convincing them to act differently. But there's also one failure mode which, while overlapping with the previous ones, is worthy to highlight: imagine the thing the person dislikes is the outcome of a reasonably complex process. The person observes primarily this outcome, but is partially or fully ignorant of the underlying process that causes the outcome. And they now desperately want the outcome to be different. In such a situation they are practically doomed to fail - in all likelihood, their attempts to change the outcome will not be successful, and even if they are, the underlying cause is still present and will keep pushing in the direction of the undesired outcome. Three Examples Productivity in a Company A software company I worked for once struggled with a slow development cycle, chronic issues with unmet deadlines, and generally shipping things too slowly. The leadership's primary way of addressing this was to repeatedly tell the workforce to "work faster, be more productive, ship things more quickly". In principle, this approach can work, and to some degree it probably did speed things up. It just requires that the people you're pushing have enough agency, willingness and understanding to take it a step further and take the trip down the causal chain, to figure out what actually needs to happen in order to achieve the desired outcome. But if middle management just forwards the demand to "ship things more quickly" as is, and the employees below them don't have enough ownership to transform that demand into something more useful, then probably nothing good will happen. The changed incentives might cause workers to burn themselves out, to cut corners that really shouldn't be cut, to neglect safety or test coverage, to set lower standards for documentation or code quality - aspects that are important for stable long term success, but take time to get right. To name one very concrete example of the suboptimal consequences this had: The company had sent me a new laptop to replace my old one, which would speed up my productivity quite a bit. But it would have taken a full work day or two to set the new laptop up. The "we need to be faster" situation caused me to constantly have more pressing things to work on, meaning the new, faster laptop sat at the side of my desk, unused, for half a year. Needless to say, on top of all that, this time was also highly stressful for me and played a big role in me ultimately leaving the company. Software development, particularly when multiple interdependent teams are involved, is a complex process. The "just ship things more quickly" view however seems to naively suggest that the problem is simply that workers take too long pressing the "ship" button. What would have been a better approach? It's of course easy to armchair-philosophize my way to a supposedly better solution now. And it's also a bit of a cop-out to make the meta comment that "you need to understand the underlying causal web that causes the company's low velocity". However, in cases like this one, I think one simple improvement is to make an effort for nuanced communication, making clear that it's not (necessarily) about just "working faster", but rather asking everyone to keep their eyes open for cause...