What towns could learn from Apple

As a design person, I’ve watched the story of Apple pretty closely. What design person hasn’t?

This week, I listened to a Founders podcast episode about Jony Ive. It was such a great reminder of my respect for Jony, Steve, and Apple, and the lessons we can learn from them. So, here’s a little series with my take on translating their work into placemaking.

Thirty-eight reasons

Jony Ive and Steve Jobs would walk into a room with a thing they wanted made. Thinner than it had any right to be, with no visible screws, in a color aluminum didn't come in. The engineers, who were very good engineers, would come back with thirty-eight reasons it couldn't be done that way.

And Steve would say: figure it out.

Not "let's compromise." Not "what can we do instead." Figure it out. And, an unreasonable amount of the time, they did.

I’ve been in that room. Only in my version of the room, the thing on the table is a street, or a square, a small town, or even a building or a water system. And the thirty-eight reasons are the parking ratio, the fire marshal's turning radius, the traffic engineer, the lender, the pro forma, zoning, and building code.

And in placemaking, most of the time, the reasons win.

The problem isn't that towns have engineers, codes, lenders, budgets, and fire marshals.

Apple had engineers and budgets too.

The difference is their rank.

Most places are a Dell

If you're under thirty-five you may not remember what computers were like before the iMac, so let me describe it. They were beige. All of them. Or maybe black or grey. They were sold on a spec sheet, megahertz and megabytes, and the industry's whole theory of the customer was that she would buy whichever beige box had the bigger numbers for the smaller price.

It was an industry run by engineers and salespeople, and it made exactly what you'd expect an industry run by engineers and salespeople to make. Things that worked, mostly, and that nobody loved.

Dell optimized the parts/specifications. Apple designed the experience as a whole.

Now look at how we make places.

Developer: buy land.
Civil engineer: optimize circulation.
Traffic engineer: optimize throughput.
Fire marshal: optimize emergency access.
Lender: optimize financial risk.
Architect: optimize building.
Landscape architect: optimize landscape.
And then, at the very end, somebody hires a designer to pick the brick.

Everyone can do their individual job well, and the resulting place can still be terrible.

That's a Dell. That is exactly, structurally, a Dell. The product is whatever falls out of the constraints, and design is a finish you apply once the real decisions are made.

Some of those constraints are real. Fire trucks do have to turn around. The lender does need to be paid back. I'm not pretending otherwise.

During one of my first big design meetings with Trilith's founder, I showed him all these images of old narrow streets. He goes, “Yeah, I love those, too! The fire marshal says they have to be wide enough for the fire trucks… I want to know… Can we just buy some smaller fire trucks?!” That’s when I knew I’d like working with this guy. In the end, we didn't get streets as narrow as we wanted, or little fire trucks, but I appreciated that his first instinct was to look at what it should be rather than start with the status quo.

But here's the part worth sitting with. When Apple bet that people would pay more for a computer that was beautiful and worked as a whole, the industry said the numbers didn't work. Then Apple made the numbers work at margins the beige-box people could not believe.

And we already know this is true of places. The neighborhoods people pay the most to live in, the ones they fly across the ocean to walk around in, are almost never the ones built to the current spec. They're the old ones. The ones made before the thirty-eight reasons got written into code.

We didn't forget how to make an iPhone of a town. We just stopped letting anyone insist on it.

Design is how it works

Steve Jobs said the line everyone quotes: design isn't how it looks, it's how it works. People quote it and then go right on treating design as how it looks, so let me say what I think he actually meant.

At Apple, one small group owned the whole thing. The metal, the software, the box it came in, the store you bought it in, the little click when the cable seated. No seams, because nobody got to hand off their part and walk away. The experience was designed as one object, from the moment you wanted it to the moment you forgot it was there.

A place is also one object. You just don't experience it that way when it's been designed by twelve disciplines who never met.

Think about where places feel the worst. It's almost never in the middle of a good building. It's at the seams. The blank garage wall the architect wasn't paid to think about. The drive aisle between two "walkable" blocks. The fifty feet between the front door and the sidewalk that belongs to nobody's scope. The plaza that got built and then handed to a maintenance budget that didn't know it was there.

Every one of those is a handoff. Every one of those is a seam where the experience stopped being anyone's job.

I spent a few years as creative director for a new town, and if you'd asked me what the job was, I'd have said something about holding the vision. But the actual job, day to day, was in the seams. Walking the site and asking: what happens here, between this and that? Who's holding this piece? Nobody? Then it's mine now.

And the thing nobody tells you is that the seams are where people fall in love. The moment somebody tells a friend about, the one that makes a place feel like it was made on purpose, is nearly always a seam that somebody bothered to hold. A view that lines up. A doorway that opens onto exactly the right thing. Light on a wall at five o'clock.

Apple called that design. Most development calls it a budget line, and cuts it.

What it should be, then work backward

Apple didn't set out to make a better phone. Better phones were available. Better phones had more buttons.

They asked a different question, which was: what should a phone be? What would it be if you weren't starting from the one in your pocket? And once they had an answer, they made the engineering catch up to it. That's the order. Ideal first, then the thirty-eight reasons, then figure it out.

Development runs the order backwards. We start from the code, the standard, the last thing that got approved, the pro forma from the last project, and we improve it a little. Slightly nicer elevations. A trail. A pocket park with a sign that says Pocket Park. It's a better subdivision. It's still a subdivision.

You can't get to a great place by improving a bad base. You get a nicer version of the wrong thing.

I want to be careful here, because "start from the ideal" sounds like the kind of thing people say right before they draw a city with no parking and no budget. That's not what I mean. I'm interested in eutopia, the good place, the one that can actually be built by people with mortgages and lenders and a fire marshal.

The difference is where you start. Start from the ideal and negotiate back toward what's possible, and you end up somewhere pretty good, with a few compromises you can name. Start from the code and negotiate up, and you end up with the code, plus a trail.

Every code is somebody's old ideal, fossilized. The setback was once a good idea about light and air. The road width was once a good idea about fire. They were "should" statements, made by people who cared, often put there to protect from lessons learned the hard way, for a world that mostly doesn't exist anymore. Treating them as physics is a category error. They're just the last answer.

So ask the question again.

What should this be?

Not what does the code allow, not what did the last guy do. What should a street be, for a person who's going to walk down it ten thousand times? What should a square be, for a town that's going to live around it for a hundred years?

You'll get a better answer than the code did. Then you go find out which of the thirty-eight reasons are real.

(Also—this is why I’d love to move to performance-based codes, but that’s another post for another day.)

The special forces of designers and their champion

For most of the years Apple was making the things you remember, its industrial design studio had something like sixteen people in it. Samsung, in the same years, had thousands of designers, spread across divisions, each reporting up to somebody who reported up to somebody.

Sixteen beat thousands. Not because they were sixteen geniuses, though some of them were. Because the sixteen were protected. The studio was sacred in a way that's hard to explain to anyone who's worked at a normal company. Nobody in sales, nobody in finance, nobody in engineering could walk in and tell them no.

Jony Ive has said, more or less, that he couldn't have done what he did anywhere else. And I believe him, because I've watched what happens to a designer who has the ideas but not the protection. The ideas get rejected. Or they get improved by a dozen well-meaning people with a dozen reasonable concerns, until what's left is something everyone can live with and nobody would cross the street for.

The protection was Steve. That was his job, at least the part of it that mattered to Jony. He was the person in the building who had decided, in advance, that design would win the argument. Everyone else had to work around that fact.

We know what Apple looked like without him, because we watched it. In the years he was gone, products took four years to ship, and the product line was diluted. The best designers left, worn out. Jony nearly did. It was still a company full of talent. It just had no one whose job was to say yes and mean it.

There's a book called Loonshots, by Safi Bahcall, about why some organizations keep producing breakthroughs and most stop. His shorthand is artists and soldiers. The artists make the strange new thing. The soldiers make it ship, scale, and pay for itself. You need both, and in a fair fight the artists always lose, because the soldiers have numbers and the artists have a hunch.

So the artists need protecting. But Bahcall's real point, the one I keep coming back to, is that the leader's job isn't to be the artist. It's to love both sides equally and tend the space between them.

I think that's who Steve became. Not who he started as. The Steve of 1985 was pure artist, and the board fired him for it. The Steve who came back in 1997 had spent a decade running NeXT and Pixar, and he'd learned to care about margins, supply chains, and the retail floor as fiercely as he cared about the radius on a corner. He didn't stop being the guy who said figure it out. He became the guy who also knew what it would cost, and said it anyway.

There's an idea about leadership I've run into from a few directions (Jocko Willink: a special forces guy teaching on MasterClass; Ken Wilber's "transcend and include") that goes something like: the person who should lead is the one who can care for the most dimensions of the work at once. Not the one who cares most about design. Not the one who cares most about money. The one who can hold the design, the numbers, the fire marshal, and the hundred-year life of the thing in the same head, and not drop any of them.

That's the founder a place needs. Not a design partisan. A general who protects the artists and the soldiers, because the place can't survive without either.

Here is what I think that means for places.

Almost every place you love was made by two people, or two roles, anyway. One who owned the land or the money and decided, before anything else, that this one was going to be good, and could hold the design and the numbers in the same head. And one who could see what good looked like and was given the authority to hold it, against every reasonable objection, while a hundred small decisions tried to water it down.

A Steve and a Jony. A founder and a designer. Call them whatever you want.

Most projects have neither. The ones that get close usually have one without the other: a designer with real vision reporting to a committee, or a founder who wants it to be good but has no one who can see what good looks like. And a committee, no matter how kind, cannot make an iPhone.

You can't make someone responsible for the whole while giving twelve other people veto power over the pieces.

There's an obvious danger here. A town isn't an iPhone, and giving one person the authority to decide what it should be can go spectacularly wrong. That's the next essay. But replacing vision with consensus hasn't eliminated that danger. It's mostly eliminated coherence. You can see it nearly everywhere you drive.

Before the engineers

So, back to the room with the thirty-eight reasons.

The reasons are real. The fire marshal isn’t just making up rules to try to be difficult. The lender is not your enemy. The traffic engineer would, in most cases, love to draw a narrower street; he just needs someone above him to say the narrow street is the point.

The reasons are not the problem. The order is the problem.

In the Dell version of a place, the reasons come first, and the design comes last, and so the design is whatever's left. In the Apple version, somebody decides what the thing should be, and then the reasons get their turn, one at a time; some of them win, and most of them, it turns out, were just the last answer.

If you own land, or money, or a seat on a council, you're the person who gets to choose the order. Nobody else can. Before the engineers, before the code, before the pro forma: What should this be? Decide that. Say it out loud, to people who will hold you to it. Write it down.

Then find someone whose whole job is to protect that answer while everything tries to erode it, and don't let anyone tell them to butt out.

That's it. That's what Apple did. It worked so well we stopped noticing it was a choice.

It's a choice for towns, too. We've just been making the other one, for about seventy years, and calling it the way things are done.

Next: what Apple got wrong, and what it costs a town when one person's worldview gets set in cement.