IC4 is where designers stall: it stops rewarding good work and starts asking you to lift others

Here is where we are. A stack of design writing landed this month that reads like advice but is really about the same thing: how you tell a junior designer from a senior one, and how you name that gap out loud. Career ladders. UX laws. Feedback. Working relationships. Design systems that grow messy. All of it points at the same job you have on Monday, which is helping people level up and knowing what "next level" actually means. Let me catch you up.

The deep cut

• Seniority is judgment, not output. The muzli ladder plateaus designers at IC4 who ship well but can't elevate others.
• Name the relationship before you fix it. Ken Norton's client stopped trying to change Jacob once he saw a relationship he owned.
• Exceptions are a paper trail, not damage. A design system with zero exceptions after three years means nobody is building with it.

The gap has a name, and it isn't skill

The product designer career path piece is blunt about where people stall. IC4, the staff level, is where designers plateau, because it asks for a shift from doing design well to elevating the work of others. The craft that got them there stops being the point.

Marty Cagan draws the same line for product. Riffing on Benedict Evans, he lists three skills: seeing the general problem behind the pain, discovering a solution that works, and finding one that also works for the business. Cagan's read is that "being good at sales does not make you good at making sales software." Using a tool and building one are different jobs. Same for design. Shipping screens and shaping behavior are different jobs, and your ladder should say so.

Senior designers argue about behavior, not pixels

The ten UX laws list makes the gap concrete. None of the ten are about pixels. Tesler's Law asks who carries the fixed complexity, the user or the team. Chesterton's Fence says find out why that ugly confirmation dialog exists before you delete it. Weber's Law is why Google ships redesigns in small steps instead of one loud overhaul.

The junior move is to delete fields to "simplify," then hand the mess back to users as errors and support tickets. The senior move is to ask who should carry it. That's the same judgment your ladder is trying to price. When you review work, listen for whether a designer is defending a layout or a decision about people. That tells you their level faster than the mockup does.

Feedback works both directions, and both are underbuilt

Two pieces treat feedback as the same idea at different scales. In the product, feedback is oxygen: the "your changes have been saved," the button that lights up. Late feedback is almost worse than none. Norman's dishwasher that beeps at 3am is technically informative and practically infuriating. Prioritize the signal, mute the noise.

For your team, the same rule holds. The career ladder calls the M1 transition one of the hardest in any design career and tells new managers to prioritize feedback quality. Junior designers are told to treat critique as curriculum. A crit where the signal is buried or the important note never lands is your dishwasher at 3am. Fast, clear, and weighted toward what matters, or people learn to tune you out.

The relationship you keep blaming the other person for

Ken Norton tells a story about a client stuck on a peer named Jacob. Norton asked for a metaphor for the relationship, and the client froze, not on the metaphor but on the phrase. "I guess I am in a relationship with Jacob, but I've never considered that." That reframe moved the client from trying to change Jacob, which he couldn't, to owning the relationship, which he could.

Norton points to Michael Bungay Stanier's five questions for a "keynote conversation," including what your best looks like and how you'll fix things when they go wrong. Design leads spend hours on user journeys and almost none designing the working relationships that ship the product. That's a free coaching move for your next one-on-one.

Mess is the receipt for real use

The design system honesty piece lands the same lesson for systems. A library with zero exceptions after three years isn't disciplined. It's brand new, or nobody's building with it. Every variant is a fossil of a real decision made under a real constraint: a legal rule, a performance budget, a stakeholder who wouldn't move.

The advice is to document the why, not just the what, and to budget for drift instead of pretending it won't happen. This ties the whole stack together. Whether it's a ladder, a crit, a relationship, or a component, the senior habit is naming the constraint out loud and writing it down. Juniors chase the clean version. Seniors keep the receipts.

Three questions for your team

• Where does your ladder actually price judgment over output, and does your IC4 rubric name "elevating others" as the bar?
• In your last three crits, was the most important note the loudest one, or did it get buried like a 3am beep?
• Which working relationship on your team is stuck because someone is trying to change a person instead of owning the relationship?