The first skill I teach designers isn't design

If you join my team, the first thing I’ll push you on won’t be your craft. It will be how and when you communicate.

That sounds obvious. Every job description asks for “strong communication skills,” and what most people mean by it is presenting well in reviews. I mean something more specific: saying the uncomfortable thing early enough that people can still do something about it.

I learned this the expensive way. I ran a design studio for five years before moving into product companies, and in the early days we kept discovering problems too late, a requirement we’d misread, a build harder than estimated. Every time, the answer was the same: the whole team pulls all-nighters to hit the deadline. We delivered, but it cost far more time, effort, and money than it should have, and it burned people out doing it. What those years actually taught me wasn’t how to survive a crunch. It was how to see one coming, plan for it, and say it out loud early.

Because here’s the scenario I’ve watched play out the most since. A designer picks up a feature. Midway through, it turns out harder than anyone estimated. Maybe the requirements shifted, maybe a dependency didn’t come through, maybe they just over-committed. It happens. The designer decides to push through quietly, because asking for help feels like admitting they can’t handle it.

Now the part people miss. Engineering has planned a sprint around that design. QA has planned around engineering. Somewhere, a launch date has been said out loud to someone senior. When the delay finally surfaces at the deadline, it doesn’t cost one person time. It costs every team downstream, all at once, with no room left to adjust.

The same delay, flagged a week earlier, costs almost nothing. In the decade since the studio, this has saved my teams more time than any process I’ve run. Flag the roadblock early and engineering picks up something else instead of waiting. Hand over the parts of the design that are settled, flows, structure, whatever’s stable, and they start on architecture while design catches up. The launch holds. Nobody works a weekend. A delay is rarely the problem. A delay nobody knew about is.

So this is what I actually teach:

• Bad news travels first
  If something threatens a commitment, stakeholders hear it from you before they feel it in the schedule.
• Be specific
  ”I’m blocked on X, I need Y, and here’s what I can deliver by when,” not “it’s taking longer than expected.”
• Hand over what’s ready
  A partial design with a clear structure lets others move; a perfect design delivered late helps no one.
• You don’t need permission to raise a flag. Raising it is the job.

There’s a second half to this, and it’s on me, not them. People only communicate like this in teams where it’s safe to. If someone on my team hides a delay, my first question isn’t “why did they hide it.” It’s “what made hiding it feel like the safer option.” That one’s a leadership failure before it’s an individual one.

Craft, I can coach over months. This, once it clicks, changes how someone operates within a week. It’s the highest-leverage thing I know how to teach.