Two types of work

There’s a distinction I often use that keeps coming up in conversations, and then people say “that’s really good, have you written it down anywhere?” and I have to shamefacedly admit that no, no I have not. Anyway, this is me writing it down somewhere.

The distinction is this: There are two distinct types of work, which I call crunchy and squishy. The thing that distinguishes them is what makes them hard when they’re hard.1

Crunchy work is work that is hard because reality fights back at you in some way. This might be physical, it might be logical, but the point is that when you’re struggling with it it’s because you’re up against something that will not budge just because you ask it to. STEM subjects tend to be crunchy - mathematics, software development, sciences, etc. you all end up struggling with the basic facts of the world in order to do the work.

Squishy work on the other hand is work that is hard because people are complicated and messy, have conflicting needs and preferences, and need to be treated as subjects in their own right who can make their own decisions that you have to work with rather than just problems to be solved. Management, negotiation, coordinating groups, all tend to be squishy work, but so is e.g. philosophy, most writing2, psychology.

Crunchy work tends to be characterised by getting right answers, and squishy work tends to be characterised by getting outcomes that satisfy people.

Not all work is clearly crunchy or squishy3, but I think in practice most work we do ends up being fairly obviously one or the other. Certainly at any given moment in the work it tends to be clear whether you’re fighting against pushback from hard constraints imposed by physical reality or the messy tangles of social reality.

Outside of the moment-to-moment experience, and considering a slightly large scale, most important projects seems to be a fairly inseparable mix of the two.

Almost every important project has some essential squishiness to it that it cannot succeed without. Many projects have some important crunchy core that is critical to their success. e.g. repairing a car is a crunchy problem, and you cannot run a business as a mechanic without actually being able to repair cars (or at least not for long), but also if you neglect the part of your business that requires you to be actually good at working with people you’ll probably fail even harder. As a result, neither crunchy work nor squishy work are more important than the other in any sort of generalisable sense - you really do need both.

Often they don’t separate nearly that cleanly, as problem definition tends to be squishy, so for a lot of technical work you’ve got a bunch of squishy work woven inextricably in with your crunchy work. Even if the “real work” of a project is crunchy, the squishy work is an essential part of the feedback loop to make sure you’re doing the right crunchy work.

Additionally, a lot of my best crunchy work has been done for reasons that emerged from squishy work4. Crunchy work is usually done in pursuit of some reasonably well defined goal, and squishy work is often a vital and interesting source of goals to pursue.

One of the reasons that I started making this distinction is that, for me personally, crunchy work seems to provide some satisfaction that I can’t get from purely squishy work - I’d been doing mostly consulting and coaching work for a few years at that point, and it was very much feeling like I was missing something major from my intellectual diet and was starting to get very antsy.

Most of my attempts to explain this prior to having this distinction centred around something like “it doesn’t feel like I’m doing real work”, but that never felt right - the work I was doing was real, and important, but it was missing something essential for my wellbeing, and the best way I had to capture the feeling of that was that it was missing a sort of “crunch” to it.

I don’t think I get the same sort of dissatisfaction in the opposite direction when my life has too much crunch and not enough squishy work, but to be honest I’ve never really had a shortage of squishy problems in my life so it’s hard to tell. I do tend to get dissatisfied with purely crunchy work with no grounding in real people’s problems - a lot of why I stopped working on Hypothesis was I felt too disconnected from software development at the time to really feel motivated by it.

Another reason the distinction is important is because without understanding it, people will tend to treat these types of work as more similar than they actually are, and you get people who are over-focused on one sort of work and tend to apply skills and faculties better suited to their preferred side of the divide to the other: Engineers who expect simple right and wrong answers to messy human questions, managers who lack the understanding that hard technical problems are actually hard and do need to be treated as such.

My personal preference is that everyone should seriously engage with enough of each type of work to really understand the strengths and affordances of each, and how they differ from the other. Also I’d like a pony. A flying one, ideally.

In practice I think the best I can hope for is to understand that if you are strongly specialised in one sort of work, that shapes a great deal of your thinking, and as a result you probably understand the other sort of work less well than you think you do. This means that you need to pay more attention to what people from the other side of the split are saying, especially if it seems alien to you.

¹ Work can still be crunchy or squishy if it’s easy, but there you need to think in terms of “What would make this hard if it were hard?” or “What would a harder version of this look like?”. The distinction is usually pretty obvious though.

² It’s very rare to run into writing that has no squishy components to it, but e.g. writing a mathematical proof is mostly crunchy.

³ For example, I think making art is predominantly neither squishy nor crunchy. It certainly has squishy elements and crunchy elements, but the thing that makes it hard when it’s hard feels like something different and important in its own right.

⁴ e.g. Hypothesis came about partly because I did the work of talking to users and finding out what they needed, which was a bold and unprecedented move for a property-based testing library