A year ago that sequence would have been a two-week project. A brief to agree on the problem. A kickoff to agree on the direction. A couple rounds of mocks. A review. Another review. Each meeting a negotiation. Each negotiation a little leak of the original energy. By the time the thing landed in front of people, the idea had been sanded down into something nobody felt strongly about.

I think most design orgs are still operating on a broken assumption: that meetings are where decisions get made. They never really were. Decisions get made the moment someone can touch the thing and react to it. The reason meetings used to feel like the decision point is that the thing didn't exist yet. You couldn't walk into a room with a working version. You walked in with a deck, or a mockup, or a sketch of what you thought it could be. So the room argued about the representation of the thing. That's all there was to argue about.

Now the thing exists before the meeting. You build it in the morning, ship a URL in Slack, and the debate is over before anyone prints an agenda. Opinions are cheap when there's nothing real to engage with. The moment there's something real, opinions have to get their hands dirty. Most opinions don't survive the contact.

This is the part most design leaders haven't fully internalized. They'll say they believe in "prototype-driven decisions." They'll nod along at the right moments. But look at their calendar and you'll see six hours of reviews a week. Look at their team's process and you'll see mocks as inputs to meetings, not mocks as decisions. The prototype is still treated as preparation. It's not. The prototype is the decision. The meeting is where you ratify it.

Once I started seeing it this way, my week changed. I spend less time arguing for ideas and more time making them real. My calendar has fewer reviews and more building sessions. I'd rather ship a rough version in the wrong direction and have the team correct it than talk through three directions and commit to the wrong one by consensus. The feedback loop is faster, the decisions are better, and the team trusts each other more because everyone's reacting to the same real thing instead of their own imagined version of it.

The hardest part isn't the skill to build things quickly. That part is getting cheap. The hard part is giving up the comfort of the meeting. The illusion that getting everyone in a room with a deck is the same thing as making a decision. It isn't. It never was.

Build the thing first. Show it. Let the thing do the arguing for you. The leaders who figure this out are going to run circles around the ones who don't.

The more I do this, the more I notice every AI company is quietly racing to be the place this data lives. ChatGPT wants your health metrics. Meta wants your relationships. Google has had your email for fifteen years and they're finally starting to use it. None of these are features. They're switching costs disguised as convenience.

The war isn't about which chatbot is smarter. It's about who becomes your data OS. That's the whole game.

And the threshold isn't a single decision, it's a slow accumulation. You let the assistant remember your preferences. You connect your calendar for context. Your work history, your relationships, your reading, all of it starts compounding in one place. Six months in, the context is the product. You're not paying for the model anymore. You're paying to not start over.

This is how the smartphone OS wars ended. Nobody picked iOS or Android for the phone itself. They picked it, and then their photos, their app purchases, their contact graph, their muscle memory accumulated until switching felt like burning the house down. Every AI company knows exactly what this looks like. They're in a land grab for context.

The open, portable version of this is possible right now. The primitives are sitting there. Local-first storage, standardized query protocols, identity layers. MCP is an early form of exactly this. My own setup is proof you can build it. But it takes work that closed ecosystems do for free, so the people who care most about owning their data are also the ones spending the most time managing it. That's its own tax.

The average person will pick the ecosystem that makes them feel the smartest with the least friction. Right now that's OpenAI or Google. Tomorrow it'll be whoever accumulates the deepest longitudinal memory of who you are.

The real unlock is a protocol, not a product. An open layer that lives with the user, not the platform. But protocols don't have growth teams, and that's why nobody's building it fast enough.

When the AI starts finishing your thoughts accurately, the war is already over. Whoever holds your context, wins you.

Silicon Valley has been running the same play. The obsession isn't muscle mass. It's stock price. And just like in the gym, the question has always been the same. How do you get gains without carrying the weight?

Human beings are expensive. Salaries, benefits, sick days, parental leave, healthcare. That's the fat. For decades, tech companies had to carry it to function. You couldn't build anything without people, and people came with overhead. Then AI arrived, and suddenly you can automate away entire layers of the workforce and still hit your growth targets. Pure gains.

Anyone who has actually tried to cut fat knows that the leaner you get the worse you feel.

As AI absorbs role after role, the people still inside these companies aren't fighting to get promoted. They're fighting to be that last bit of essential body fat. The one function the machine still can't run without. Everyone wants to be the person who keeps the lights on just enough that they don't get cut next quarter.

It's not a race to the top anymore. It's a race to be the last one left.

Not every organization wants to be on gear though. Some will stay natty. They'll grow a little slower, without the side effects. Maybe a little whey protein here and there. Maybe a bit of TRT. A small boost when it counts. But they'll keep the human element intact. And honestly, 15% body fat isn't so bad. You can stay happy and healthy at 15%.

The traditional model is a pyramid. One design director, a few leads, a bunch of ICs. The director does strategy and reviews. The leads do project management and feedback. The ICs do the work. It's organized around throughput: more designers means more screens means more features shipped.

That model is breaking. AI tools are compressing production time so dramatically that a single designer can now cover the surface area that used to require three or four. If your team was sized around throughput, you suddenly have too many people. And if your management layer existed to coordinate that throughput, you have too many managers.

What I think replaces it is something closer to a studio model. Two or three senior designers who each own a major surface. A design leader who is also a working designer. AI tools filling the production gap. Shared systems that make consistency automatic instead of enforced.

The key shift is that the design leader has to be a player-coach. You can't just set the vision and review the work. You have to be in the work. Because when your team is three people instead of twelve, every person's taste matters. Including yours. Especially yours. The leader sets the bar by producing at the bar, not by describing it in a critique.

This changes what you hire for. You're not hiring for Figma speed anymore. You're hiring for judgment, taste, and the ability to operate independently. You want people who can walk into an ambiguous problem, figure out what matters, and produce something that moves the conversation forward. You want people who don't need a brief to start working.

It also changes how you think about influence. In a traditional org, design influence scales with headcount. More designers, more seats at the table, more surface area covered. In this model, influence scales with the quality of what you ship. A three-person team that produces excellent work and makes it visible has more influence than a twelve-person team that produces mediocre work behind closed doors.

I'm not saying big teams are wrong. I'm saying the ratio of people to impact is changing, and the leaders who figure that out first will build the teams that move fastest.

The management layer is compressing. The craft layer is not. The people who survive this shift are the ones who can do both.

The first thing I noticed is that design work was happening but it wasn't visible. Good thinking was happening, but it needed a dedicated surface to be visible across the team. So I fixed that first. I forked an open-source tool called Draftboard, customized it for our team, and deployed it as an internal design feed. Within a week, leadership was using it to make faster decisions because the context was already there.

The second thing I did was research. I spent time talking to the team, reading everything I could about our customers, and building a framework for who we're designing for. Not personas in the traditional sense. More like a shared understanding of our customer that the whole company could align around. That work ended up being adopted across teams as the foundation for how we talk about our user.

The third thing was getting in the product. I started shipping design work alongside the existing team. Not to prove anything. Because I think the fastest way to understand a product is to design for it, and the fastest way to build trust is to make something useful.

I'm also hiring. Building a design team from scratch is one of the hardest and most rewarding parts of this job. The model I'm building toward is small, senior, and high-autonomy. I want people who can own a surface end-to-end and don't need me to tell them what to do. My job is to set the bar, clear the path, and make sure the work is seen.

It's early. There's a lot I'm still learning about the company, the market, and the team. But the pace feels right. When you can move fast and the people around you trust you to move fast, the compounding starts early.

I've worked at companies where the best design leader was also the best designer on the team. I've worked at companies where the design leader hadn't opened Figma in two years. To me, the first model produced better work. The second model produced better organizations.

The argument for separating the tracks is that managing people is a full-time job. That's true at a certain scale. When you have 30 designers and a complex org to navigate, the management work is genuinely all-consuming. But that argument is getting weaker. AI tooling is compressing what a small team can do. The number of designers you need for a given scope is shrinking. Which means the management overhead is shrinking too.

What's emerging is something that looks more like a player-coach model. You set the strategy. You hire and develop the team. And you still make the thing. Not because you don't trust your team. Because staying in the work is how you maintain the taste that makes your strategic decisions any good.

The leaders I admire most never fully left the craft. Albeit, many of those are not designers. (I’m talking musicians, artists, athletes.) The ones who stopped making things eventually lost the thread. Their taste calcified. Their feedback got generic. "Make it feel more premium" instead of actually showing what premium looks like.

The industry is going to keep bifurcating into two types of design leaders. The ones who manage designers and the ones who lead design. The difference is whether you can still sit down and do the work yourself when it matters. (And I think that will matter now more than ever.)

The problem is universal: you generate ideas faster than you get feedback. Slack threads bury work. Figma links get old and go unclicked. Great thinking disappears before anyone sees it.

This is why I forked Draftboard, an open-source project by Matej Hrescak. It's a shared feed where your team sees designs, leaves feedback, and nothing gets lost. I'm not an engineer, but I used Claude Code as my pair programmer and shipped a custom production app in a weekend. That sentence would have been absurd two years ago.

Then I went further. I built an MCP server that connects Draftboard to my AI workflow. Every comment and reaction my team leaves gets synthesized into a daily briefing: who said what, what to prioritize, where the energy is. I walk in every morning with full context instead of spending the first hour rebuilding it.

This is what AI actually changes for designers:

The gap between "I wish we had this" and "we have this" is now a weekend. Speed becomes a trust signal. Ship a prototype the day someone mentions a problem and they stop questioning if design is keeping up. Artifacts replace meetings. Async comments on a shared surface beat a 60-minute review every time. Any IC who can vibe code and ship to a visible surface just 10x'd their influence.

If your work isn't visible, it doesn't exist. Build the thing that makes it visible. Then build the pipeline that turns your team's reactions into your next move.

I always share the sketch. The half-baked thesis. The thing that still has obvious holes in it. I put it in front of people before it's ready and say "here's where I am, poke holes in it."

It works because as soon as you open it up to other folks it takes ownership of, it becomes their idea also. It gives them permission to have bad ideas and be rough around the edges, and they immediately become your collaborator.

Most teams are slow because people are protecting their work. They sit on something for three days getting it "ready" before anyone else sees it. By the time it surfaces, they're emotionally invested and super protective. Now feedback feels like an attack instead of a collaboration. The whole cycle gets heavy and slow.

When you show the rough thing early, you're making a trade. You give up the appearance of having it all figured out. In return, you get speed, better ideas, and a team that actually trusts each other.

I've heard people call this psychological safety, which is true but kind of misses the point. It's not about being nice. It's about being fast. The safest teams are the fastest teams because nobody is wasting energy on performance. They're just working.

The catch is that you actually have to be good at sketching for this to work. If you share rough work and it's genuinely bad, people lose confidence. The trick is sharing work that's rough in resolution but right in direction. The thinking is solid. The pixels aren't there yet. People can tell the difference.

I've been doing this my entire career and I still have to remind myself every time. The instinct to polish before sharing is deep. It feels like professionalism. It's actually fear.

Show the rough thing. Move faster. The polish comes from the collaboration, not from sitting alone with it.

I can produce things that I would have never been able to product in an hour now. Not because the thinking is faster. The thinking is the same. But the distance between having the idea and holding the artifact has completely changed. I can go from a napkin sketch to a functional prototype before I realize my idea might not be that good. (Joking. My ideas are always good.) That changes what's possible in ways most design orgs haven't internalized yet.

The obvious take is “everyone will be replaced." I don't think that's right. What's actually happening is the bottleneck is shifting. Production was always the tax on taste. You had to spend hours in Figma executing the thing you already saw in your head. Now that tax is approaching zero. Which means the differentiator is entirely about what you decide to make and why.

This is uncomfortable for a lot of designers. Especially the ones who built their identity around craft execution. If your value was "I can design things beautifully in Figma," you're competing with a tool that can do that in seconds. But if your value was "I can walk into a room full of conflicting opinions, synthesize what actually matters, and produce the artifact that changes the conversation," you're more valuable than ever. The artifact just comes faster now.

The rate of change in tooling is accelerating. The rate of change in taste is not. Taste still takes years of reps, of looking at things, of building things and learning why they didn't work. That's the moat. (It always has been, btw.)

The designers who thrive in this moment will be the ones who were already operating above the tool layer. The ones who were already dangerous before the tools got good.

The vibes keep centering on generation. Feed a model some mood board images, get content or an avatar back. It’s interesting, but having worked in GenAI, I don’t know if it’s the future of what people care about. The output is directional, but is the utility functional for people who have to put real clothes on real bodies? Proportions that don't account for how fabric drapes. Colorways that look plausible on screen but would never work in production. It's the uncanny valley of taste. We might eventually get there. But right now I think the value lies elsewhere.

To me, the real opportunity is upstream. Curation, not creation.

This is what great buyers have always done for brands. They synthesize a massive amount of signal: what sold last season, what's moving on resale, what's showing up in street style, what their customer is about to want before she knows she wants it. That entire job is pattern recognition across messy, unstructured data. That's exactly what language models are good at.

The interesting question isn't "can AI imagine a piece of clothing on a body?” It's "can AI look at 50,000 SKUs across 200 brands and surface the 40 that belong in front of a specific customer right now." Not a recommendation engine. Those are backward-looking. This is more like giving every shopper a buyer who knows their closet, their calendar, and their taste graph.

Fashion has always been a taste business. AI doesn't replace taste. But it can make a small team with great taste operate at a scale that used to require a department store's worth of buyers.

The companies that win this won't be the ones generating images. They'll be the ones that figured out how to encode taste into a system and let it compound.

We spend a lot of energy debating what to prioritize. Which problem matters most, which feature moves the needle. But priorities aren't just about what. They're about when.

An initiative can be strategically sound but if the foundation isn't ready, it won't land. A project can be urgent in theory but if the team is stretched thin, the result is rushed work that never sticks.

Sometimes the smartest move isn't to plow forward. It's to say: yes, this matters. We're not ready yet. That's not indecision. That's protecting focus so the work gets done at the level it deserves.

Goals shouldn't feel like a to-do list. They should feel like a calendar.

It's easy to think of quality as a final coat of polish. One last review before launch. But quality is built into every stage before that. The sketches you share, the critiques you run, the systems you lean on. If your systems allow shortcuts, shortcuts become the standard.

This gets tested when speed is in play. Fewer touchpoints means the ones you have carry more weight. They need extreme clarity of intent. That's the only way to move fast without the work getting worse.

The teams I've seen do this well don't treat quality as a tradeoff with speed. They make the right path the easiest path. When that's true, quality stops being something you enforce and becomes something that just happens.