Welcome back, picnickers! Although, the season to go out and touch grass is quickly wrapping up here in the North-East as we head into autumn. So, you know. Get a move on.

Today we’ll be picking up where we left off last week: on the pitfalls of “just doing things.” The obvious rebuttal to this thesis is: “what, you want me to stop doing things?”

Well, I want you to at least think about it. I’m actually going to be talking a bit more about that at Button Conference next week — how doing all the things is detrimental to your ability to get the important things done right.

A focus on “just doing things” is the epitome of local optimization. Any productivity gains obtained through decoupling yourself from your organization’s systems of value production are illusory, for obvious reasons. The “cost of going faster” may not be as visible to your organization as measuring the number of tickets closed, but that doesn’t mean it does not exist — only that you are not prepared to deal with it.

There is often value in not making new things, for example. We are often trained to think of all problems as blank-slate, but it is often wiser to evolve or mutate what is already there.

Or just take a breather and think about what you are trying to achieve.

Sure, sometimes you have to “just do” something, because the alternative is that you get fired. And then you should absolutely do it — because it’s an opportunity to earn trust, which you can then “spend” on long-term improvements. Stakeholders are just people and “I trust this person because they often get it right” is more powerful than any theory. Ray Newman outlines a good, simple framework for how to balance “just doing things” with working towards long-term changes.

Because that is the goal, actually. If your prevailing system holds you back from getting things done, successfully going around the system is just a stopgap measure. The long-term goal should always be making the system better, so that it can help you get things done rather than get in the way.

But that’s hard, and flooding the zone with thoughtless outputs is easy. You don’t even need AI to do it — the Extreme Go Horse framework has existed for a long time — although AI might certainly help you churn out outputs more quickly. Of course, amplifying a broken system only makes it more broken.

The first thing you can do to start fixing your system is to insist on accountability so that the Thing Just Doers cannot degrade the system any further than they already have.

The second thing is to understand that the system is made up of people, and the people are exhausted. Trying to simply muscle past them will quickly outstrip the broader system’s ability to assess whether outputs are fit to be inputs into any downstream process, and turn your entire pipeline into slop.

If you hope to make any kind of lasting change — which many Thought Leaders refer to when they talk about lofty things like “design should pivot into doing strategy” — you are going to have to give up the dream of the lone Design Desperado and start learning how to play nice.

These are people problems, which can’t be solved with technological solutions.

For systemic change to happen, you need to bring people with you. Which — surprise! — is design’s greatest superpower, and always has been. Jon Kolko wrote a very long and very good piece about synthesis as a sense-making process 15 years ago, and every part of it still rings true today. Kolko called out that synthesis is often performed privately, within the designer’s head, and this is a barrier to getting other people to understand what you are on about. The teams that succeed are ones who can get everyone (including execs!) to show up for these sense-making sessions.

Meanwhile, the individuals and teams who just yeet their work at the next person in line inevitably fail to make any real impact. Those people may be churning out deliverables, but they are also racking up comprehension debt. No one understands what they are on about because it is not possible to derive rationale out of the output alone. And if people don’t understand something then they can’t act upon it, and we are back to designers complaining that Product is “ignoring their designs.”

This effect is only intensified when no one can explain what the thinking was, because the output was generated by a stochastic parrot rather than a person. The cost of sorting out what was poorly explained and what was simply hallucinated quickly eclipses the organization’s cognitive resources.

That’s what we are going to talk about next week: intent. How to create it, propagate it, and maintain it throughout the entire product lifecycle.

— Pavel at the Product Picnic