All discussions

Your team can love the work and still have no idea why it matters to the company. In UX, especially at large companies, teams are usually great at understanding the customer. The problem. The why behind the feature sitting in front of them. What's harder is connecting that work back up to the actual company strategy. Big company initiatives live at thirty thousand feet. The feature you're shipping lives on the ground. And there's no CEO in the room to ask "why this, why now." I think that gap is on leadership to close. Explaining the why clearly enough that it's believable, not just repeated. But it's also on every leader in the chain, and every individual contributor, to have the confidence to ask when something doesn't connect. Faking understanding at any level just pushes the confusion downstream. Here's the harder part though: what happens when a leader asks up the chain and still doesn't get a clean answer? I don't think the move is to fake total certainty. I also don't think it's to throw your own leadership under the bus. The best leaders I've seen can say, honestly, "this part's still fuzzy, and I'm working on it," without turning that into blame. That's a different kind of trust building than having all the answers. Curious how others have handled this, especially at scale. How do you keep your team believing in the mission when the why doesn't always make it all the way down to you either?

In UX, especially at large companies, teams are usually great at understanding the customer. The problem. The why behind the feature sitting in front of them. What's harder is connecting that work back up to the actual company strategy. Big company initiatives live at thirty thousand feet. The feature you're shipping lives on the ground. And there's no CEO in the room to ask "why this, why now." I think that gap is on leadership to close. Explaining the why clearly enough that it's believable, not just repeated. But it's also on every leader in the chain, and every individual contributor, to have the confidence to ask when something doesn't connect. Faking understanding at any level just pushes the confusion downstream. Here's the harder part though: what happens when a leader asks up the chain and still doesn't get a clean answer? I don't think the move is to fake total certainty. I also don't think it's to throw your own leadership under the bus. The best leaders I've seen can say, honestly, "this part's still fuzzy, and I'm working on it," without turning that into blame. That's a different kind of trust building than having all the answers. Curious how others have handled this, especially at scale. How do you keep your team believing in the mission when the why doesn't always make it all the way down to you either?

I'm reading Extreme Ownership for the second time, and this round I'm trying to sit with it longer instead of just nodding along. Taking ownership was already wired into me before I ever picked up this book. It followed me into the working world without much effort. But I've noticed that some days ownership is easy, and some days it isn't. When a project goes sideways and nobody is really at fault, owning it is simple. I can look back, find the three decisions I'd make differently, and move forward. That kind of ownership feels good. Almost clean. The hard version is different. It's when I genuinely believe someone else made the mistake. A leader above me. A designer on my team. Something that had nothing to do with how I led. I know the answer. Point the finger back at yourself. Ask what you could have done to set them up so they didn't fail you. How could you have done things differently to help them make better choices? I know it. I still find it hard. So I'm curious how other leaders handle that second kind. What actually helps you get there?

We ran three interviews for a pricing change and leadership called it anecdotal. How are you deciding when you have done enough to act?

Hall treats stakeholder interviews as organizational research. Does anyone run them before every study, or only on new projects?

The book argues for a constrained scale. Which base has worked for your team?