Building Appropriate Design Teams

No two companies are the same, so copying a design-org job description is cargo culting with long-term costs. This talk turns team composition into a design process.

• The premise. Every person is a shape—a spider graph of strengths—and a team's stack is those shapes combined. The stack surfaces gaps, and whether a gap matters depends entirely on what the company needs to succeed.
• Learn. Treat other companies as case studies, read every job description, and ask leaders who've built teams—the industry is generous with its time if you're respectful of it.
• Analyze (the funnel). Spit every relevant skill onto a page, filter to what the company needs, then to what belongs on design rather than PM/data/engineering, then to what's truly baseline for every hire.
• Beware hiring yourself. "I design and code, so we need more people who design and code" leads to echo chambers—and the assumption might simply be wrong.
• Baseline is smaller than you think. At DigitalOcean the assumed baseline was technical skill; one of the best hires couldn't code but understood systems, and learning quickly turned out to be the most valuable skill on the list. Teaching ability is what makes lean baselines work—one expert upskills the whole team.
• Evolve. Re-ask "is it working?" forever: skills already covered, team make-up changes, sourcing struggles, new gaps. When DigitalOcean finally had enough engineers, design stopped coding—and the job description changed with it.
• Verdict. As always, it depends. But be intentional about it.