LinkedIn Post Ideas for Design Leads

Six months ago I stopped opening Figma for my own projects. Not fired, not moved off design — a deliberate experiment. The trigger: I'd noticed I was still the person who "finished" every major screen, which meant my team's growth had quietly capped at "good enough for my touch-up." They weren't getting worse. They just weren't getting better, because I kept absorbing the hardest 20% of every project myself. What I did instead: reviewed earlier, said less, asked more questions than I gave answers. When someone brought me a flow with an obvious gap, I asked "what would you try first" instead of showing them. Month one was rough. Deadlines slipped slightly. Quality dipped on two projects — visibly, in ways stakeholders noticed. By month four, the team had developed their own critique instincts. Two designers who used to wait for my sign-off started catching each other's issues before review. By month six, output quality matched what I used to personally guarantee — except now three people could produce it, not one. The uncomfortable truth: my hands-on habit wasn't generosity. It was a bottleneck disguised as quality control. If you're the best designer on your team, that might be the actual problem.

Most design critique I've sat through is a status update wearing a costume. Nobody's mind changes. Everyone leaves agreeing with whoever's most senior. Here's the fix I rolled out, and the pushback I got before it worked. The old format: presenter shows work, room reacts live, discussion, done. The new format: — Silent reading time, five minutes, written feedback only, before anyone speaks. — A named decision-maker announced at the start of every session — not always me, often the project's lead designer — so the room knows whose call it ultimately is. — Feedback is submitted in writing first, then discussed. This surfaces disagreement before the loudest voice in the room anchors everyone else. The pushback: "this feels slower." It is, by about ten minutes per session. What it buys back: juniors stopped simply agreeing with my read of the work, because they'd already written their own take before I spoke. Two of our best catches last quarter came from designers who wouldn't have spoken up in the old format. Leads steal this exact structure for their own team meetings now, which is the actual signal it worked — not that I liked it, but that it survived contact with other teams' skepticism.

A junior designer cried in a 1:1 after a critique I gave two years ago. I've thought about that meeting more than almost any other in my career. What I said wasn't cruel. It was just unstructured — a stream of everything I noticed, delivered as if volume of feedback equaled thoroughness. She heard "you got this wrong" fifteen times in six minutes. What I do differently now: — Separate taste from requirements out loud. "This violates our accessibility standard" and "I personally would've used a different color" are different categories of feedback, and I name which one I'm giving. — Lead with a question. "What were you optimizing for here" almost always surfaces context I was missing, and it signals I'm curious, not grading. — Cap it at three points per session. Everything else goes in writing afterward, so the meeting doesn't become a gauntlet. — End with what's working. Not as a compliment sandwich — as an honest accounting, because good critique should leave someone knowing what to keep, not just what to fix. Managers of every discipline relate to this, because the failure mode isn't design-specific. It's mistaking exhaustiveness for care. What changed how you give feedback?

We tracked design debt for twelve months the way engineering tracks tech debt. Leadership had never seen a number like this before. The methodology: every inconsistent component, every duplicated pattern solving the same problem two different ways, every "we'll fix it later" ticket that never got prioritized, logged in a spreadsheet with an estimated hours-to-fix. Twelve months of logging. The total: 640 hours of rework debt sitting unaddressed, plus an estimated 12 hours per week of ongoing tax — designers re-solving problems that already had an answer, just not a documented or reused one. Translated to cost, using average fully-loaded design hours: roughly $180,000 a year in silent, invisible rework. We presented that number in a single slide at quarterly planning. Not a deck about design quality or craft — a number, in the same unit finance and engineering already spoke. The reaction: design got two headcount and a quarter of dedicated system work the following cycle. Two years of "we need more design resourcing" conversations hadn't moved that needle. One measured number did. Design doesn't get a seat at planning by being right about craft. It gets a seat by being fluent in the language the room already trusts.

One executive rejected the first draft of every project my team touched. Every single one, for two years, regardless of who designed it. I used to think it was a taste problem — he just liked something different from what we made. It wasn't. It was a timing problem. He was seeing finished work for the first time in the same room where he was expected to approve it. No context on the tradeoffs, no visibility into what got cut, no chance to react before the moment felt high-stakes. Of course his first instinct was to find something wrong — that's what the format invited. The change: I started looping him in at 30% — rough directions, explicitly labeled "not polished, need your read on direction" — a week before any formal review. First reaction to the new process: skeptical, thought it'd slow things down. Second project in: he started giving directional notes early instead of vetoing late. By the fourth project, he was defending our work to other executives in rooms we weren't even in. Nothing about our design quality changed. What changed was when he got to have an opinion. Stakeholder management is often a scheduling problem wearing a taste disguise.

I built my first design team from zero to six people in eighteen months. I got four things wrong, and they compounded. 1. Overvaluing portfolios. I hired for the prettiest final shots and skipped asking about process. Two hires produced beautiful work they couldn't defend when a stakeholder pushed back — no rationale, just taste. 2. Skipping collaboration exercises. Every interview was a portfolio walkthrough — a monologue, essentially. I never watched anyone actually work with another person until they were already hired, and two hires who interviewed brilliantly turned out to be difficult collaborators day to day. 3. Hiring clones of myself. My first three hires all thought like me, which felt efficient — fast alignment, no friction. It also meant zero perspective diversity. We missed the same blind spots four times over instead of catching them. 4. No onboarding beyond "here's the Figma file." New hires spent their first month reverse-engineering our design system and unwritten norms instead of contributing. That's a month of salary with minimal output, self-inflicted. The fixes: a working session in every interview loop now, an explicit rubric that scores process alongside output, and a real 30-60-90 onboarding doc. What did your first hiring cycle teach you the hard way?

A junior on my team said something last month that's stuck with me: "the tasks I used to learn on don't really exist anymore." She's right. Wireframe variations, basic component assembly, first-pass layout exploration — the tasks that used to be a junior's training ground for two years are now a ten-minute AI-assisted pass for anyone on the team. The old model: juniors did the "easy" 70% while learning the craft, and graduated into judgment work over a few years of repetition. That on-ramp is mostly gone. What we've changed: juniors on my team now sit in on stakeholder conversations from month one, not year two. They critique senior work out loud in crit, not just their own. They're assigned the ambiguous 20% earlier — the "figure out what we're even solving for" work — with heavy pairing, instead of being handed a spec. It's uncomfortable. They make more visible judgment mistakes earlier than juniors used to. But judgment is the only part of this job that isn't shrinking, and it can't be learned by watching AI generate a wireframe. If AI ate the training wheels, we have to teach balance directly and earlier. I don't think we've fully solved this yet. What's working on your team?

We killed our weekly status meeting eighteen months ago. Nobody's asked to bring it back. What replaced it: a Friday async demo. Every designer records a two-to-five-minute Loom of what they shipped or explored that week — work in progress included, not just finished polish. Post it in a channel by end of day Friday. Monday mornings, instead of a status meeting, we have "demo Friday reactions" — fifteen minutes, optional attendance, purely for anyone who wants to react live to something they saw in the Looms. What this fixed: the old status meeting was six people taking turns saying what they did, while four others checked Slack. Nobody watched, because a status update read aloud isn't interesting. A two-minute video of actual work, watchable on your own time at 1.5x speed, gets watched. What it also did, unexpectedly: it created a searchable archive. New hires now watch three months of Fridays to understand how the team actually thinks, which used to take months of osmosis. Attrition risk from killing a status meeting: zero. Attrition risk from another hour-long status meeting where half the room is on mute doing something else: real. What ritual has your team replaced that nobody misses?

Five questions I ask every design leadership candidate, useful whether you're the one asking or answering. 1. "Tell me about a time you disagreed with your own team's decision but shipped it anyway." Reveals whether they can hold authority and humility at once — a leader who's never lost an internal argument either hasn't been challenged enough or won't admit it. 2. "How do you know if a designer on your team is ready for more scope?" Tests whether they have an actual framework or just a gut feeling they can't articulate. 3. "Describe the worst hire you made and what you missed in the interview." Anyone without an answer either hasn't hired enough or isn't being honest. 4. "How do you talk about design impact with someone who thinks design is decoration?" This is the executive-facing skill that separates senior ICs from actual leaders. 5. "What's a ritual or process you killed that other people wanted to keep?" Tests whether they default to adding process or are willing to subtract it. Candidates preparing for leadership interviews: rehearse real answers to these, not polished ones. Leads hiring: the hesitation on question 3 tells you more than the answer to question 1. What would you add to this list?

Are player-coach design leads sustainable, or is it just a slow-motion burnout setup with a nicer title? I've done this role for three years — leading a team of five while still owning a meaningful chunk of hands-on design work myself. Here's my honest split: roughly 60% management (1:1s, hiring, stakeholder work, critique, roadmap) and 40% IC work on the highest-leverage problems. What makes it work on good weeks: staying close enough to the craft that my feedback stays sharp and specific, not abstract executive-speak. My team trusts my critique more because I'm still in the work, not commenting from a distance. What breaks it on bad weeks: the IC hours are always the first thing that gets sacrificed when a people problem or a stakeholder fire shows up, which means my "real" design work happens in fragments, at night, or not at all for a stretch — and that's the exact recipe for burnout nobody warns you about. My honest read: it's sustainable for a specific team size, roughly four to six people, and a specific season, not indefinitely. Past six reports, the management load stops leaving room for real IC contribution, and pretending otherwise is where leads quietly burn out while still showing up fine on the surface. What's your actual ratio, and is it working?