Software is made by people

By now people have generally caught on to the idea that software is made for people. The entire discipline of UX, ideas about design-thinking, customer-centricity, etc. are all predicated on the idea that it’s people who are going to use this stuff, so let’s make it easy for them to understand.

What is less commonly understood, perhaps intentionally so, is that software is made by people. Why intentionally? Because people are messy, organic, and unpredictable. The human participant in the software creation process is usually represented by an abstraction - a black box you pour requirements into that spits out production-ready code at a deterministic rate. If asked to think twice about this, we all know just how leaky and poor this abstraction is, yet we persist in at least paying lip service to it.

What happens if we reject that abstraction outright and instead acknowledge ourselves as people and not code-producing machines?

Well, for one thing, we lose the commoditization of team members. Good leaders already engage with their teams as individuals. Good people already approach others with empathy. Nevertheless, common abstractions in the workplace are in tension with these practices, whether through imposed scale or pace that seems to only permit surface level interactions, or financial metrics and concerns that aim to Quantify the unquantifiable and variable nature of people so that they can be Optimzed. Recognizing that software is made by people makes reductive thinking that much more difficult.

Instead, we become open to humanity. Uniformity and clarity of role comes at the expense of flexibility and inspiration. Abstractions and determinism are in some sense designed to avoid surprises and it’s both scary and exhilarating to open yourself up to being surprised. What great ideas have you been conditioning your teams not to bring up because they’d rock the boat too much?

Doing away with these abstractions seems to make planning much more difficult. Without the assembly line metaphor, how will we know when we’ll be done? A few things seem reassuring here. First, agile methodologies have already permitted some uncertainty in our mindset, correctly understanding that the further out you get, the harder it is to be more certain, and also that in aggregate it all tends to come out in the wash. Second, if you believe that the existing abstraction was leaky anyway, any planning derived from it was necessarily flawed. Choosing to ignore shaky premises doesn’t make them solid.

The real challenge then becomes repeatability and scalability. Without uniformity, how are we to have processes and policies? Even though these were based on flawed assumptions, the promises of predictability were certainly comforting. We need a different path to scalability and a way to recover that feeling of comfort. Culture is part of the answer – culture and principles scale better than practices when navigating complex situations.

The cultural implications of this mind shift are large enough to merit their own post in the future. For the time being, imagine the culture that would develop from the explicitly and implicitly emphasized idea that you as a team member perform a repeatable task with easily quantified output and aren’t materially different from anyone else. Now imagine the culture that would develop from the idea that you’re a human being. Where would you rather work?

For more on this and other thoughts, check out my webinar with Forrester.