One Fluid Motion

When you're making something alone, take a carrot cake for example, it's easy, trivial even, to be connected to thing you're making, why you're making it, who it's for and it's impact on the end consumer.

It may not be the best carrot cake in the world but the meaning you take away from the process is quite high.

Say you wanted to make, not just a good carrot cake, but a really good one.

You might start obsessing over certain parts. Gathering the highest quality ingredients. Icing the cake with more refined tools. Testing over and again for the perfect chew.

You're quickly confronted with a resource problem. Each step in the process represents a different thing to be really good at. A daunting challenge for one person.

It occurs to you that if you really want to make the best cake, you'll need help. You recruit a master baker or a master icing-er or a master farmer and through combined effort the best, starts to feel real.

You are making progress.

So you march on. Extrapolating what you've learned. Divying up the work to be done until one person's only job is to steward compost temperatures. The compost is used to ensure the healt of the soil in the garden that grows the most ideal carrots. You repeat a similar divying motion with every part of the process.

But a funny thing happens.

While the vision remains clear to you. For compost guy and other contributors like him, it starts to become unclear what we're making, why we're making it, who it's for, and it's impact on those people.

All of the sudden he's making decisions in a vaccuum towards the preservation of compost that may or may not have anything to do with making carrot cake. Forget who it's for or why carrot cake should exist.

And your burden is now one of communication instead of producing the best carrot cake. Your connection to it starts to morph into something less grounded in reality and more abstract. You steward the idea of a carrot cake, but are so removed from the process you are doing anything but actually making it.

In our pursuit of the best we created a system that produces something else, and with much less fulfillment for the people involved*.* And the product quality, the thing we were after in the first place, starts to suffer because of it.

This is what a traditional software organization looks like. We seperated jobs in pursuit of quality and speed. But as we scaled we equally disconnected ourselves from the actual thing we were making.

So where does that leave us?

In my view, theres an apex point before we start seeing diminishing returns in both product quality and contributor fulfillment. A point where the products we make can be made better, not though further compartmentalization of the core jobs to be done but through added depth and connective tissue between them.

The understated part of the first carrot cake you made is that you were keenly aware of every part of the process. You didn't outsource any of the thinking, strategy, problem-solving or execution.

I basically think that the less handoff that we can do as a team the better product we'll make and the more fulfilled we'll be.

This presents a tall task when we change the end-product scope to that of a consumer software application. The bar to compete is incredibly high and the depth required to deliver that bar incredibly deep. The inherant complexity in producing quality software makes carrot cake seem trivial to produce in comparison.

In order to reconcile these truths I do my best to approach software as one fluid motion - a process similar in spirit to that of making the carrot cake end to end myself. In my experience, the best individual makers and teams making the best products in the world basically try to do the same.

They understand Design is not relavent without the market realities of competition and a real user need or the technical realities of delivering a solution for said users. After all, we don't produce problem identification or solution intent. We produce a product.

The more individual contributors can push against the edge of their traditional remit, and develop depth in what's traditionally considered "cross-functional" roles, the more connected they can be to the entire thing. As a skillset broadens less telephone is being played, more ownership is taken on, decisions are made faster and at higher leverage.

You are fundamentally more connected to the work in this way. The work is more fulfilling. And the outcomes are stronger.

The reality is coordination is a heavy burden and a single fluid motion is easiest to execute alone. No one to communicate to. No one else's thinking to download. No one to challenge your ideas.

As your skillset develops it's inreasingly tempting to go at it alone. Or at least it has been true for me.

But the greatest thing that pushing myself to work in this way has taught me is not a better way to sort a table or a better decision framework. It's empathy for my EPD counter parts.

I'm able to bring not only my design background to the table but a lot of overlap with non-design co-workers. This greases the wheels from insight to feature and is the connective tissue I was talking about earlier.

I think the future of work is less one person in a silo and more Maker (product background) + Maker (design background) + Maker (engineering background). T-shaped contributors with broad awareness and deep understanding in a specific or a couple specific domains. Perhaps this pod is able to work on multiple things at once but not without contributing to each other's projects.

Last note.

Making excellent software is still hard. Beneath each new discipline you endeavor to take on lies tremendous depth to uncover. There will be many unknown unknowns. This deserves a lot of respect and humility, especailly if you're working in a team.

I stress this because AI enabled development biases all of us, but especially non-technical folks, to completely abstract technical complexity. We might be able to build v1 or a protoype easily but without understanding how it's been accomplished there is no understanding to build upon come v2 and no path to resolve it coherantly in the likely chance that something doesn't go as expected.

AI presents both the opportunity to abstract meaning away from the process and the opportunity to go deeper. The value illicited from approaching software in one fluid motion does not lie in the appearance of new competencies, it's in geniuine formation of new competencies through depth and connection.

Choosing the latter might just help us all form deeper connection to the thing we make, develop more empathy for our collaborators and produce a higher quality product.