Why UX Teams Face Skepticism
UX initiatives often meet resistance before they even start. Teams that have been burned by poor delivery and unfulfilled promises tend to view UX work as a disruption rather than a fix for existing organizational problems. Building confidence in your upcoming projects means showing — not telling — that UX solves real issues.
One effective approach: identify and address the critical bottlenecks that affect the people you'll be working with. These are the points of friction that slow everyone down, and they're often well-known to employees but rarely surface to senior management, who are detached from day-to-day operations.
A bottleneck can be a single senior developer, a broken legacy tool, or a confusing flow that produces errors constantly. The result is long wait times, delayed delivery, and teams cutting corners in all the wrong places. You might not be able to fix the bottleneck itself, but you can ensure that non-constraint resources don't produce more than the constraint can handle. All initiatives should be aligned to support and maximize the efficiency of the constraint.
Before any UX work begins, look for what slows the organization down and demonstrate that internal disruptions — not UX work — are the real problem. Even a small delivered value can quickly change attitudes and open doors for more substantial work.
Surface the Unplanned Work
Meetings, reviews, experimentation, pitching, deployment, support, updates, and fixes all block other work from being completed. Exposing the root causes of unplanned work and identifying bottlenecks that slow delivery isn't just a first step toward improving workflows — it's also a strong way to show UX value.
Set up 1:1s with the team and ask what slows them down. Look for a problem that affects everyone: too much work in progress leading to late delivery and low quality, for example, or lengthy meetings stealing precious time. Since you can't manage work that isn't visible, visualizing the work comes first. Once the bottleneck is clear, you can suggest concrete improvements — perhaps introducing 20% idle time when the workload is too high, or shortening meetings to make room for other work.
The Theory of Constraints
The idea that work is never just "the work" connects directly to the Theory of Constraints, developed by Dr. Eliyahu M. Goldratt. The theory holds that any improvement made anywhere besides the bottleneck is an illusion. Improvements after the bottleneck are useless because that resource will always remain starved, waiting for input. Improvements before the bottleneck only result in more work piling up at the constraint.
Wait Time Math
To improve flow, sometimes you need to freeze work and focus on a single project. Just as important as throttling the release of work is managing handoffs. Wait time for a resource equals the percentage of time it's busy divided by the percentage of time it's idle. A resource at 50% utilization produces a wait time of 50/50, or 1 unit. At 90% utilization, wait time becomes 90/10 — 9 times longer. At 99% utilization, it's 99/1, meaning 99 times longer than at 50% utilization. The exact numbers don't matter; what matters is making wait times visible so you know when work spends days sitting in someone's queue.
Avoid 100% Occupation
The goal is maximizing flow: exploit the constraint but deliberately create idle time for non-constraint resources to optimize the whole system. Attempting to maximize utilization of all resources — 100% occupation across all departments — can actually be counterproductive. As Goldratt put it: "An hour lost at a bottleneck is an hour out of the entire system. An hour saved at a non-bottleneck is worthless."
For a deeper dive into these concepts, The Phoenix Project is not a design book but an excellent read for designers who want to think more strategically. It covers the Theory of Constraints in fine-grained detail through a very real story about the struggles of shipping.
Building Trust Through Listening
People naturally resist sudden changes and uncertainty, and UX work often disrupts established ways of working. Most people will block it by default. Before introducing major changes, you need their support — which means showing them the value UX can bring to their day-to-day work.
The path to that support is listening. Learn about the pain points in their workflows, the things that slow them down. Once internal disruptions are uncovered, tackle those critical bottlenecks and suggest steps to make existing processes more efficient. That's how you build trust and demonstrate that UX work doesn't disrupt — it solves problems.
