First off, a time sensitive note: Frank Elavsky (whose great essays I’ve previously cited) is having his thesis defense this week! If “Tool-making as an intervention on the accessibility of interactive data experiences” sounds like it’s up your alley, and you have a spare hour on April 29th, check out the details here.
(This is not an ad — but it turns out newsletters ain’t free so if you do want to advertise with the Picnic, you know where to find me.)
The wrong kind of productivity
For your regularly scheduled Product Picnic, I want to return to the idea of velocity, and specifically what it means to do our work “faster” (although the subtext of that statement these days is always “having our work done for us by an LLM”). But instead of discussing how much time design work takes, I’m interested in what kind of time it takes.
[Design] takes not just clock time to work but also calendar time to think.
I like these better than Kahneman’s “type 1 and type 2 thinking” because they are simultaneously more tangible and encompass a broader idea. Clock time is hours of butts-in-seats, eyeballs-on-screen, hands-on-keyboard. If you’re familiar with David Pye, the “workmanship of certainty” — production processes — runs on clock time. Clock time is how you measure commodities.
However, the organizations that produce and distribute those commodities operate on calendar time. Consider a package scheduled to arrive in “2-3 business days.” While your package may physically get from the sender to the warehouse faster if the train it’s on runs more quickly, it will still sit overnight until it’s time to load the trucks.
This problem shows up in every delivery process, including the one for software, because we need to deliver insights from one part of the org (where they are produced) to another (where they are consumed):
How well the time on the meter fits into time on the calendar depends on the real situation on the ground: the ability to sequester human attention and have it directed toward a meaningful result. More importantly, the sequence in which the insight to move forward arrives is unknowable in advance.
This is how an organization actually thinks: not as a collection of individuals, but as a system. Individuals may “know” things that the system does not register, and vice-versa — the system may compel individuals to perform actions they “know” are wasteful or even counter-productive.
Aligning org-level thinking with reality is the real work of leadership (this is why I say that design is a leadership skill). It’s hard work. And as with all hard work, managers have long hunted for “one weird trick” that would let them avoid doing it. They always fail: coordination is expensive, and when you try to sweep it under the rug, it just becomes more expensive.
If you skipped that link, I want you to go back and read it, because Hochstein makes a distinction towards the end that is highly relevant:
During incidents, coordination becomes an acute problem, and we humans are pretty good at dealing with acute problems. … But coordination is also a chronic problem in organizations, and we’re just not as good at dealing with chronic problems.
The industry as a whole is making one big bet: that it is possible to make individuals fast enough at solving acute problems on clock time that the complexity of managing chronic problems across calendar time takes care of itself. This is the trend that is leading many to (mistakenly) proclaim that “the design process is dead.”
But unfortunately, it also poses an insurmountable problem for industry leaders backing the idea that designers can now “do strategy” — because in this world, there is no strategy. Any horizon beyond the tip of your nose is outside of the organization’s semantic environment. The moment of “workmanship of certainty” that Pye promises never arrives; it’s risk all the way down.
Instead of strategy, we need to do something a little different, and a lot more human.
Designing for the compost heap
Mike Gallagher has a charming metaphor for this: a garbage can system in which decisions happen “by collision, rather than intention.” There are two interwoven themes in the piece that I want to highlight:
In garbage can systems, there are no shared conceptual models. Everyone has a different idea of what the problem even is, solutions circulate without associated opportunities, and every decision is made based on an incomplete, random sampling of available knowledge that people making that decision happened to have.
Design is the only way to make this system produce useful outcomes, but the work of design looks very different from what we are used to doing. The majority of the work becomes a maintenance activity: keeping problem frames and solutions salient enough that they are within reach when the decision gets made.
Individual productivity reaches diminishing returns almost immediately, and from that point onward, investing in coordination gets you much better returns. Hyper-optimizing outputs in your own context is a waste of time, because the chance of your context being important for any given decision is ~0.
Keen-eyed readers will notice that the tools we keep being told “will kill UX” do not help us do this and in fact make the problem worse by accelerating design drift and knocking the scaffolding out from underneath complex ideas that need time to percolate. The iterations that a designer would have gone through to flush out bad ideas instead get picked up as user-facing deliverables.
Scott Jenson writes about design principles for tools that resist this pressure. But you can also apply all of those lessons to choosing which tool to use in the first place, and deliberately reject clock time conceptions of productivity where they don’t make sense. If you normally work in visuals, interrupt your impulses by writing. If your tendency is towards high fidelity, spend some time on shitty first drafts.
And if your tendency is to throw yourself against a problem until you burn out, give yourself permission to clock out. The problem will still be there tomorrow.
If the crop you’re tending is emails, it’s easy to lose sight of the fact that the work is endless – and easy to imagine that some wildly impossible target … might in fact be within your capacities.
What you realise, the moment you ask “what would it mean to be done for the day?”, is that the answer can’t possibly involve doing all the things that need doing.
— Pavel at the Product Picnic