Own the Room, Or Leave It.

Unlearning the habit that quietly dissolves design's authority

Once upon a time, I was a young designer in a meeting that could have been an email.

The problem was straightforward: a support team covering 30,000+ knowledge base articles across 14 countries needed a better way for people to find answers to common problems. Employees couldn't find answers fast enough — losing time, making mistakes, escalating tickets that should have closed in two minutes. The proposal was clean. Elegant, even. A guided help feature layered on top of the existing knowledge base. Better search. Better surfacing. Faster answers.

This is when the meeting stopped being an email and became a war room.

I could see the problem. The knowledge articles were self-authored. No standards, no review process, some months out of date, some contradicting each other. A few were just wrong. The real fix was an audit — a slow, tedious, unglamorous crawl through every article before a single line of the new feature got built. And nobody in that room wanted to hear that. The timeline was set. The solution was decided. 

My job, as far as the product leader was concerned, was to make it look good.

I was barely invited to that room in the first place. So when the product leader pointed to usage data and like/dislike counts as a way to weed out the unhelpful articles over time, I looked at it and thought: “Ok. Good enough.”

The feature shipped. Support volume went up — by a lot.

Here's what I've had to sit with: I didn't fail to see the problem. I saw it clearly. I made a calculation, decided the partial solution was close enough, and let it go. That's a different kind of mistake. Harder to name. Harder to defend. Because "good enough" is always a choice — and at a certain point in your career, it's the most expensive one you can make.

Sound familiar?

The hard part isn't recognizing the story. It's recognizing that what felt like strategy was a habit. A well-dressed one. The kind that convinces you you're reading the room when you're actually just repeating a pattern you learned so early it stopped feeling like a choice.

That's the part nobody names. And unnamed habits don't get examined. They just get more expensive.

What took me years to understand: this wasn't a problem title could solve. It cropped up again and again — different companies, different teams, different products. Studio designers. Agency designers. In-house designers. Freelancers. The context doesn't matter. The problem was the same.

It was an altitude ownership problem.

Not a seniority problem. Not a politics problem. Not a "we just need a seat at the table" problem — though goodness knows we said that enough.The issue was never the room. It was what we did once we got there.

Altitude ownership is the refusal to let your discipline become optional — by naming what you own, defending what the work requires, and holding the stake even when the room would rather you didn't.

The inverse of altitude ownership is abdication, because silence in a room where you hold influence isn’t neutral – there is a cost.

Knowing the Cost Means Knowing Where You Stand

Design careers have altitudes. But altitude isn't a ladder.

You don't have to climb. Plenty of exceptional designers spend their entire careers at one level and do extraordinary work there. The principal designer who has spent fifteen years perfecting interaction craft at the interface level is not someone who failed to climb. They're someone who chose mastery over altitude. And that choice produces something irreplaceable — the foundation that everything else gets built on.

The difference between levels isn't seniority, salary or title. It's one thing: the ability to produce quality decisions under increasing uncertainty.

With each altitude, the uncertainty doubles. And the cost of being wrong scales with it. At the interface level, a bad call means you or your team has a bad day. At the product level, it means a feature fails and a roadmap shifts. At the systems level, it means something breaks that nobody saw coming — and people are scrambling to find out why. At the organization level, the wrong design bet doesn't just cost a sprint. It can cost people their jobs. Their livelihoods. And you have to make that call anyway, with incomplete information, under pressure, in real time.

That's what altitude actually means. Not where you sit in the org chart. How much uncertainty you can hold — and still make the call.

The Manual Ends Here

At the beginning of most careers, there are manuals for everything. Any designer worth their pixels has probably wondered if they actually knew what they were doing or were just really good at searching Google. Say hello to imposter syndrome.

Heuristics. Accessibility standards. Design systems. Best practices. Entire libraries dedicated to helping you make good decisions. These are at the tips of our fingers when starting out, and most designers assume mastery means learning all of them.

It doesn't.

Mastery is what happens when manuals stop providing answers.

At some point, if you're lucky, you'll find yourself staring at a problem no manual can solve, no Google search can answer, and no expert seems particularly interested in solving for you.

In that moment, the question is not whether or not you know the answer – it’s whether you’re willing to make a decision without one.

This is the proving ground where designers learn the difference between applying judgment and borrowing it.  Not because of inherited precedence, promotion or title, but because they take one of two paths: going deeper into the practice or going further than the manuals. 

This is the fork in the road that no one talks about. 

Some go deeper, becoming exceptional practitioners. Mastering a discipline so completely the rest of us study their work. The industry needs these people. 

Others decide to operate where the manuals end, making decisions before certainty arrives. These are the people who create patterns, frameworks, and approaches that everyone else eventually adopts.

Neither path is wrong.

But they are fundamentally different because they are different altitudes of the same work. 

The Judgement Gap

When I say altitude, I'm not talking about title, authority or job level.

I'm talking about scope – the combination of responsibility and uncertainty. The higher the altitude, the fewer correct answers available. Most assume that intelligence, expertise or experience alone are what help people succeed at these higher altitudes. 

Yes, intelligence helps. And yes, you want a boss that actually has more experience. 

But those alone are not sufficient.

It's judgment.

Not judgment as in being judgmental.

Judgment as in knowing what to do when the answer is incomplete, the information is conflicting, and the consequences are real.That's the hidden shift between altitudes.

Most designers assume advancement comes from acquiring new skills. Learn research. Learn facilitation. Learn business strategy. Learn AI. Learn whatever LinkedIn is excited about this week.

Skills matter. But after watching designers successfully make altitude transitions—and fail to make them—I've become convinced that skills are rarely the thing holding people back.

Judgment is.

Interestingly, this isn't unique to design. In “The First 90 Days”, Michael Watkins argues that one of the most common reasons leaders fail is because they continue doing the work that made them successful at the previous level. They aren't failing because they're incapable. They're failing because the job changed and they didn't.

Designers do this too.

• The interface designer continues optimizing screens after becoming responsible for outcomes.

• The product designer continues optimizing outcomes after becoming responsible for systems.

• The systems thinker continues optimizing systems after becoming responsible for organizational risk.

They're solving yesterday's problem at today's altitude.

Because every altitude transition asks the same thing: What do you do when no one knows the answer?

Four Altitudes in a Design Career

The answer is different at every altitude. In design careers, I’ve found there are largely four, each commanding their own scope of accountability and ownership: interface, product, systems and organizational. 

Interface altitude: Where you start owning the experience

At the interface level, someone has to own the experience details. That someone is design. Not because you were assigned it. Because the discipline requires it. The moment a tradeoff forces those details to get cut, your job isn't to accept the cut quietly. It's to name who is now accountable. Who owns the corner that just got cut. Because if you don't name it, you've answered the question by default — and the answer is nobody. When nobody owns it, design didn't lose the argument. Design forfeited its stake entirely.

What doesn't always exist is the authority to enforce it. A junior designer can flag a contrast ratio that fails accessibility standards and still watch an engineer ship it anyway, because nobody in the room outranks the deadline. That's not a failure of ownership, because ownership and authority are two different things. 

You can own the standard intellectually — it's already written down, already documented, already true before you walked in the room. What you can't always do is stop the cut. What you can always do is say it out loud. Name what's being thrown away and who signed off on throwing it away. 

Ownership at this altitude isn't about having the final call. It's about knowing what the work requires and refusing to let the decision get made silently.

This is also where the habit forms — see the problem, document it, wait for a better moment. Not because interface-level judgment is weaker. Because it's often the first place a designer learns that naming what the work requires can cost you the room. Design doesn't lose ownership at this altitude because the work is easy. It surrenders it, one quiet deferral at a time — and that can happen to a principal designer with fifteen years of craft just as easily as someone six months in.

Product Altitude: Knowing How to Own the Outcomes

The leap from interface to product is the leap from owning details to owning outcomes. The work stops being "is this screen right" and starts being "did this bet pay off." And here is where most designers hit the same wall: the moment you try to define what "paid off" means, someone tells you that's not your job.

It is your job. Just not in the way most designers think.

I once watched a designer run usability testing on a signup flow. The results were good — over 80% task completion. I asked one question: did they know what they were signing up for? Did you ask them to find a button, or find a solution? The designer stalled. The test measured whether people could complete a task. Not whether they understood what they were committing to. Those are not the same outcome, and nobody had decided which one mattered before the test was built.

I saw the same gap at a much larger scale years earlier, leading design at a Fortune 1 retailer. There was a program that let employees bundle several existing perks if they opted to use their personal phone instead of a company-issued one. Most employees were already eligible. They just didn't know it, because the perks were run by three separate teams that had never been stitched together.

The product team wanted to measure how many people chose to bring their own device — that was the number that mattered to the bottom line. But that metric only captured a fraction of the actual problem. The real question wasn't how many people switched devices. It was how many eligible employees ever found out they qualified for something they already had access to. I pushed to measure conversion into the bundle, not device adoption — because device adoption was the side effect, and the unclaimed benefit was the actual failure.

Neither room handed me the authority to define success. Someone had already decided what the number was supposed to be before I said anything.

The power wasn't in overriding the metric. It was asking what the metric was a proxy for — because every number in that room was already a proxy for something nobody had bothered to define out loud. Once you voice what the real number is hiding, the room can't pretend it didn't hear you.

That's the unnamed power at this altitude. You may not own the final call on what gets measured. But you almost always have the standing to ask whether the metric on the table is measuring the real outcome or a comfortable proxy for it. Most designers never ask. They assume that's a product question, not a design one. It's both.

Systems Altitude: Making the Invisible Cost Visible

Design changes rarely live in isolation. There's a cascading effect hidden in your working file.

A few years ago, before AI became what it is today, chatbots were the shiniest silver bullet for company problems. Long service desk wait times? Call center traffic jammed with the same question from 1,000 different users?

“Just throw a chatbot on it!” Is something I literally heard a VP in engineering say in a meeting.

But good designers know that designing a chatbot isn’t a surface change, it is a workflow triggering event. Adding a chatbot changes what gets logged, who reviews what, how escalations flow and what needs legal review if it fails “safe guardrails”. 

None of that shows up in a design file. All of it shows up eventually, usually as someone else's emergency, three months after launch.

The power here is making the invisible cost visible before it becomes someone else's emergency. That sounds simple. It rarely is — naming a dependency means naming it to someone who doesn't report to you, in a system you don't control, before there's any proof you're right.

It gets harder once you have actual authority to act on what you see — because then the temptation isn't silence. It's speed.

I once owned the vendor relationship for a usability testing platform inside a heavily regulated financial institution. Designers on my team would ask me to approve plugins — small things, the kind that would have made their week meaningfully easier. I could approve them. Nobody was stopping me. But greenlighting a plugin without first routing it through cyber and risk review wasn't a shortcut. It was a decision to absorb liability that wasn't mine to absorb alone, because a faster recruiting workflow for a usability study could just as easily become an unreviewed data practice that violates a "no contact" privacy law — and that's not a design problem anymore. That's an auditor-level problem wearing design as a mask.

This is the altitude where junior designers think: “If I were the boss, I'd do X immediately.” Then you become the boss, and you learn exactly why it wasn't. Not because the people before you were slow. Because they could see something downstream that you couldn't — the same thing your team can't see now, looking at you.

The most expensive design problems rarely look like design problems.

Organizational Altitude: Where Uncertainty Becomes The Work 

In a more recent meeting — one that could not have been an email — I got asked the question design leaders dream of and dread in equal measure.

“How will this research change what we planned for our Q2 roadmap for X product?”

That is not a design question. That is a capital allocation question and political landmine masquerading as a design question. Executives with honest answers come prepared with math, not design. 

My honest answer in that meeting meant showing the cost of hiring a contractor versus reallocating a staff designer to the project, all at the assumption of what revenue the feature could unlock.

At an organizational altitude, design leaders are making very few design decisions. The decisions become capital allocation, talent bets, org restructuring, board narratives — and design is the lens you bring, not the subject.

You're not arguing for design anymore. You're pricing it — translating a research finding or a craft instinct into the language the rest of the room actually allocates against: cost, time, population served, return.

The unnamed power at organizational altitude isn't vision. It isn't even risk tolerance. It's the discipline of making a call you can't personally verify — and building enough trust that the people who can verify pieces of it will move on your word instead of waiting for proof.

The Cost of Waiting

There are times when waiting is the right call. Trust takes time to build. Credibility compounds with slow purposes. Relationships take time before your word alone becomes evidence enough to decide.

That is not the type of waiting I’m describing. I’m describing hesitation that abdicates the one thing design is actually for – figuring out how something works, not just how it looks.

In the knowledge base story, waiting caused service tickets to spike. That was probably the cheapest consequence available at that altitude. Moving higher means the cost accumulates exponentially. 

At the interface level, it costs a sprint, maybe two – something gets fixed and the team moves on. At the systems level, when naming the dependency before it’s on fire is key, hesitation might mean a legal review was missed or a key workflow wasn’t redesigned in time. Operating at the organizational level means hesitation might cost a market window or a competitive edge because your competitor built the thing you were still getting permission to study. 

Decisions not made are still decisions. Accountability still lands somewhere — the only question is whether it lands on you now when you speak up about a tradeoff, or in three years when you scramble to explain why nothing happened.

Inaction scales just as quickly as action. 

Knowing when you need to leave the room

After a particularly harsh failure, I called up a mentor of mine to discuss what happened. I explained the situation – we found a vulnerability in the design which could potentially cause users not to get a refund, so I had flagged it as a dark pattern and refused to budge until Legal made the call. Legal sided with engineering. However, one specific partner escalated my decision as “not being collaborative” to the CDTO, which meant uncomfortable conversations with my boss.

After listening, my mentor said “You know, sometimes you can do all the right things and still fail.” 

That stuck with me longer than an unresolved comment thread in JIRA. Because I had exercised the exact judgement this piece has called for. I named the standard, defended the trade and held the line on real harm to real users with a number no one could dismiss. 

And the room still treated it as a collaboration problem instead of what it actually was — design functioning as risk infrastructure, doing exactly the job it was supposed to do. Not because they were wrong to push back. Not because I was wrong to hold the line.

Sometimes a room simply isn't built yet to recognize design as something other than polish — and it may never get there, in that room, with those people, at that time.

That's not a failure of ownership. That's information.

The room that will actually use what you bring might be one conversation, one team, one company away. Recognizing that — and being willing to leave for it — is its own form of altitude ownership. You're not waiting to be discovered. You're not shrinking what you bring so the room can finally clear it. You're reading the system accurately enough to know when the system isn't the one.

Own the room. Or know exactly when to leave it for the one that will own you back.