Two habits that pulled a small design system team out of isolation when I led one at Intuit, a weekly lead check-in and a quarterly bug bash with collectible stickers, and how to start one small.
Lonely is a word I’ve heard from design system teams more than once, and I know it from the inside, because I used to lead one. The work happens underneath everyone else’s work. When it goes well, nobody notices, and when a team spends a quarter on audits and cleanup that won’t pay off until the next one, it can start to feel like the rest of the company forgot it was there.
At Intuit, my design system team was 12 people supporting 5 business units, and we had the same problem. Two habits changed it, and I’ve recommended both ever since.
A weekly check-in for the leads. Every Monday, the design lead, the engineering lead and the product manager met for a short standup. They started with their weekends, a human check-in before any work talk, then said what they were working on that week. Then they said what they weren’t working on, the things they knew were still out there. That last part gave the 3 of them shared accountability for the whole backlog instead of their own slice of it, and they messaged each other a lot more the rest of the week. It’s the same move as the follow-up post I wrote about in Say What You’re Not Doing, pointed inward at the team.
A quarterly bug bash. Once a quarter, the team put out a simple invitation: here’s everything we know needs fixing, come work on it for a day, and we’ll order pizza or cover your lunch delivery. Every component you fixed earned you a sticker, with a different sticker for each type of component. I designed the first quarter’s set, and then an illustrator I hired took them somewhere much better. Everyone at the company wanted the collection, and whoever had the most stickers at the end of the quarter won a prize. A team of 12 pulled in about 30 engineers and designers every quarter, and the stickers did most of the recruiting.
A team of 12 pulled in about 30 engineers and designers every quarter, and the stickers did most of the recruiting.
What it did for the team was bigger than the fixes. Once a quarter, the design system stopped being Pluto, the planet everyone forgets, and became the center of the universe. You have to make it enticing, and a sticker sheet turned out to be enough.
Start small. You don’t need a company-wide event to begin. If your team just finished an audit, you already have the backlog: a visual list of everything that isn’t right yet. Get a couple of designers and whichever engineers want in, pick a day, fix what you can, and then show the rest of the org what got done. A design system lead I work with has been eating lunch with engineers to hear where they get stuck in the system, and that’s the right foundation, because it tells you which fixes people would show up for.
Lead with what you know. Design system teams often have people who have worked on the system for years, and they can push back on a change until they hear the reasoning behind it. If you’re new to a team like that, open conversations with how you understand a component or a piece of the stack to work. When you’re wrong, someone corrects you early, and that kind of vulnerability earns trust faster than waiting until you’re sure. There are no dumb questions when you’re learning a system.
I’m digging up the old sticker and poster designs to pass along. If you run a design system team and you’ve found your own version of the sticker, I’d love to hear about it.