For some professionals, the idea of joining a lean or small team at a growing organization is likely enticing. There’s the prospect of having one’s hands in multiple projects and a no-day-is-the-same energy to a role. Sure, contributions can be made and felt at a massive organization, but they hold even greater weight when made amidst leaner ranks.
But to be successful, such teams need to have the right structure, organization and processes in place to not overtax their talent. After all, there’s a fine line between moving fast and moving so fast that the wheels start to fall off. As design leaders at Postscript and Refersion, respectively, Bryan Lence and Cory Burnett aim to optimize their teams in environments that allow team members to be productive. In other words, to be effective — not exhausting.
“In my opinion, designer burnout can be distilled down to two things: load and not enough latitude,” Burnett said. “If we are over-burdened with too prescriptive of work, leaving no latitude for discovery or ideation, we become production cogs.”
Accordingly, thoughtfully structuring a team is imperative. Without the surrounding resources or guide posts, team members lack the right on-the-job compass to guide them in the right direction daily.
And for designers, in the grand scheme, that’s about doing work that’s going to positively impact users of the product without being hampered or bogged down by its scope (or lack thereof). As Lence said when emphasizing the benefits of having a well–thought-out design system in place, “Product designers should focus on solving customer pain, not rebuilding buttons and forms.”
Below, Lence and Burnett shared their advice and insights around getting the most out of their design teams — and not letting the work get the most out of their people.
When design teams have limited resources, team members are often asked to wear multiple hats. In your experience, which hats go best together and which don’t mix well?
I hire designers who are eager to practice and improve all areas of their craft, from research to visual design to metric analysis. A designer’s main goal is to take inputs from the customer and the business, square those with what’s technically possible, and package everything together into something that solves customer pain and ships. I ask that designers use all the tools at their disposal to build that consensus.
When I’ve built smaller design teams, I look for designers who are eager to try everything: research, flow diagrams, user testing, high-fidelity prototypes and post-shipping metrics-gathering. It’s rare to find a designer who has experience with, let alone mastered, all of these skills. And that shouldn’t be the goal. There will always be gaps and new skills to learn, because product designers come from varied backgrounds.
In response to the question, I don’t find it useful to think about skills (or hats) that don’t mix. Rather, a designer’s lack of desire to practice and grow in areas where they currently lack experience is problematic.
How do you structure a small design team for business success without burning everyone out?
Context-switching is a productivity killer if you’re a designer. For smaller design teams, the most important organizational adjustment a manager can make is to ask a designer to support multiple engineering teams that work in a similar product space. While the ideal ratio is one designer to one product delivery team, a designer can support multiple product teams if the work is related. Supporting separate product areas means it takes longer to understand the problem, longer to design a solution and ultimately longer to ship a solution.
If you have a high-quality, high-output engineering team like we do at Postscript, there will always be more work than a designer can complete in a day. We encourage our product delivery teams to look at upcoming work and decide as a group which projects require high-touch design support and which projects can be built quickly with existing patterns. Many times, we’ve found engineers and designers can whiteboard a solution in an hour and no additional design documentation is needed. The takeaway here isn’t “design less,” but instead, "have teams collectively decide where they need higher fidelity and where they don’t."
I would strongly encourage design teams to invest in their design system as early as possible.”
Beyond organizational structure, what are your go-to best practices for boosting efficiency on a small design team?
I would strongly encourage design teams to invest in their design system as early as possible. Finding a senior designer who can lay the groundwork for the rest of the team will pay dividends down the road. Product designers should focus on solving customer pain, not rebuilding buttons and forms.
Second, I would highly encourage the design system to be built by the development team as front-end components. More importantly, component names, properties, color tokens, etc. should match one-to-one. At Postscript, we believe our Storybook instance is the source of truth, and our design system is simply an approximation of what will ship.
Having this structure in place allows designers to communicate quickly and clearly with their engineers, get things built faster and ultimately ship and deliver value more quickly. I think it’s worth noting that while the question asks about boosting efficiency of a design team, that’s generally not the goal. The goal is, or should be, shipping code that solves customer pain. The faster a designer can communicate and collaborate with their engineering counterparts, the faster a solution gets in the hands of customers.
When design teams have limited resources, team members are often asked to wear multiple hats. In your experience, which hats go best together and which don’t mix well?
Resource constraints are a constant and teams are having to move faster and faster. Thus designers’ hat collections and skill need to be robust.
Designers should always look to drive for customer and business value through short, medium and long-term horizons. From there, some good hat pairings are explorer and systems thinker; qualitative interviewer and visualizer and listener and facilitator. Some not-so-good hat pairings are explorer and salesperson; and interviewer and decider. When selling our ideas, we should be concise and coherent, having already done the exploring. During interviews, we should be active listeners without jumping to conclusions.
How do you structure a small design team for business success without burning everyone out?
In my opinion, designer burnout can be distilled down to two things: load and not enough latitude. If we are over-burdened with too prescriptive of work, leaving no latitude for discovery or ideation we become, production cogs.
Structuring a small design team for success can start with a good mix of DesignOps (process, constant discovery, a design system and proper tooling); easy access to stakeholders and customers; space for macro and micro ideation; and autonomy to solve problems through the pod/squad model.
Then, success as a business partner can come about with visibility and value-creation through design reviews, workshops, strategy sessions and roadmap planning.
Designers should always look to drive for customer and business value through short, medium and long-term horizons.”
Beyond organizational structure, what are your go-to best practices for boosting efficiency on a small design team?
My go-to best practices include leaning on familiar design patterns and having more frequent and quicker touch-points for the team, as well as always driving for shared understanding and planning focus time.
