You Are Not a Resource

You’ve probably chafed at being described as a resource. A “design resource”, a “developer resource”, or any other kind of resource. In part this is because at face value being described in this way is fundamentally dehumanising. But there’s more wrong with this metaphor than how it makes you feel. It’s also an impoverished way of looking at work that makes for teams that are less effective at what you’re trying to get them to do.

It took me a while to figure out why the idea of referring to the time and effort of humans as a resource annoyed me so much. From a manager’s perspective it at least follows an internal logic. You need the care and attention of a skilled designer on your project for a day a week, and you refer to this as a need for “design resource”.

A clue was in watching talks about team dynamics by Sarah Mei. Sarah’s talks are loaded with useful ideas that take me weeks to unpack and integrate. One of those ideas is that of the immutable team. If you take someone out of a team, you don’t get the team you had before minus one person, you get a completely distinct team, formed as all of the roles and responsibilities on the team are implicitly renegotiated after your one person left. The same thing happens when someone is added to the team. I still couldn’t quite put into words why this concept was incompatible with the idea of software developers and designers as “resources”.

One of my hobbies is paper trading just about anything. If it has a price and the price fluctuates, then I’ve probably traded it in my demo spread-betting account. I enjoy the game of getting into long/short positions in the market, managing those positions (and my psychology), and getting out of positions such that e.g. I’m able to double my account in a year. Part of being better at this hobby involves reading and understanding how trading and exchanges work.

To be able to trade something on an open exchange, that thing benefits from being /fungible/. When we say a thing is fungible, we mean that any one unit of that thing is interchangeable with any other unit of that thing. A barrel of oil, pallet of corn, kilo of gold, share, bond, or option contract is fungible. Rare books, houses, and diamonds are not fungible.

For the people that buy and sell things at an industrial scale, there are many benefits to making that thing fungible. The more fungible a thing is, the easier it is to buy and sell that thing. There is less negotiation about particulars, you can manage risk with futures or options, and you’re set up to achieve a higher level of liquidity than otherwise. That’s a fancy way of saying that you don’t need to hunt far and wide for for a seller or a buyer of the thing you’re trying to buy/sell. Liquidity is the ability to trade the thing you want to trade, when you want to trade it.

We all want our jobs to be more simple, and the models we choose to help us make sense of the world are biased to that end. Managers would love it if developer or designer time was fungible. They would also love it if software development could be broken down into fungible tasks. Then all they have to do is supply enough fungible expert hours to complete the fungible software creation tasks and the software they are trying to create will be birthed into existence.

A pallet of corn is, by design, interchangeable with other palettes of corn. A developer hour is not interchangeable with all other developer hours. A well rested hour, an hour with a sick child at home, an hour after years of experience in your domain, an hour with a panic attack, an uninterrupted hour, an hour in productive meetings, an hour of pair programming, or an hour of goofing off reading articles on the internet are all hours you get when you pay for “developer resource”. Any one hour of real development time is not the same as any other.

If you buy a random selection of five palettes of corn, you would expect to get the same utility from any other random selection of five palettes of corn. Designer or developer hours don’t work this way. If you hire a software team of five random people, their effectiveness will be dramatically different from another sampling of five random people. How they communicate, their level of trust, their mutual self-interest, technical expertise, and level of engagement with the work (and their profession in general) will vary across teams. One hour of a developers time on a highly effective team has far less utility than an hour of that developers time on a less effective team.

A palette of corn doesn’t care much how you treat it. You can swear at it, make faces at it, read to it, or play music to it, and this should have no effect on it’s utility as a palette of corn. You can’t treat humans like that and expect them to be effective. A developer working for someone that has displayed a genuine interest in their success is more motivated to help that person be successful. An hour of a a motivated developers time is not interchangeable with an hour of an unmotivated developers time.

The core problem with being a resource stems from the fact that human beings, how they work, and how they interact are complicated. When dealing with complicated things that are difficult to predict and reason about, we reach for models and systems that help us make sense of the world. But the model of your time as a fungible resource as input to a production line isn’t rich enough to usefully describe how humans come together to build software.