DESIGN MANAGER JOURNEY
Scaling team rituals to grow with design organizations
Growing your processes, not just your team
I’ve managed teams between 5 to over 50 people, grown teams from zero to 20 in less than a year, and manage project portfolios that were a single tightly related product with a small number of features to a monolith like Google Search with 7+ distinct product areas with tenuous if any interrelated products and overlaps. Whether you have a team of 5 or a team of 50, no matter if you’re all collocated, or distributed across 5+ time zones, one thing I’m sure of now, is that team rituals must constantly be growing and scaling to the team’s size, shape, and evolving needs.
When I talk about team rituals I want to be clear about a few things ahead of time. Irrespective of teams’ structure (centralized, embedded, matrixed, whatever) There are meetings that the design team likely should be having, these are different than the meetings that cross-functional product/feature teams have to get their work done day-to-day, it’s also different than the continuous growth and guidance meetings you have as a manager with individuals on your team like 1+1s, performance reviews, growth plan check-ins and so on. I’ll talk about those in another post.The most common team rituals that continue to bring value to my teams, the ones that are relevant no matter the team size, product, or company are the following:
Critique — a space for designers to present work at various stages, and give and receive feedback from their peers
Stand-ups — quick check-ins to share work status, blocking issues, align on opportunities for collaboration, and give me, the overall lead a high-level status on where things are, and how I (or a team lead) and help to ensure success
Alignment & Approvals Reviews — bigger, complex, or more cross-cutting initiatives often need deep dives with functional leads (Visual Design, Writing, Motion, Design Systems, etc) and any leads who manage other products or features who might be affected by a related project. Even if you’ve properly delegated decision making as close to the product/feature as possible, there will always be initiatives that need more senior approval depending on the context
Program reviews — Ideally you and your team are thinking in longer time horizons, defining regular milestones, and having retrospectives, program reviews are a way to broaden the audience to make sure these long-term projects stay on track.
Drop-in Office Hours — I’ll go into depth on each of these formats, but keep in mind, there’s no need to copy this exactly, what works for me and my teams might not work for you and yours. I’ll try to talk about what’s worked and what hasn’t for each, and how they’ve evolved, and as teams change, think of it as a map, not a set of directions. Choose your own path
based on what your team needs and how they respond.
Critique
If you went to art/design school like I did this won’t be a new concept for you. Critique is a forum where designers talk about what problems they’re trying to solve, what their process is, get feedback on their solution, and get help from peers if they get stuck or need additional points of view.
I’ve tried many different formats for design critique through trial and error and come up with a format that tends to work well for me and my teams.
Keep in mind, for many, even with trusted peers, critique can be stressful, especially those without a lot of experience, I’ll go over a few ways to help reduce stress and ensure high quality, actionable feedback.
A few different formats that I’ve found work well are large open group critique and smaller functional/team-based critique.
Open Crits are regularly scheduled time slots broken up into 15 min increments, designers sign up, ideally days in advance, and can take as many slots as they need (commonly we’d try to find 2 days a week and have 4 slots each day back-to-back) If you have a large space with a place to project where people can gather close, stand up, and leave their devices at their desk, and focus on listening, and giving feedback. I’ve found that It’s most helpful for the person presenting work to prepare a single “slide” with the following 3 things
- What problem they’re attempting to solve
- Where are they in the process
- What feedback is most useful to them today
Getting people aligned on the problem to be solved is critical, it keeps the conversation topical, gives context to people seeing the work for the first time, and frames the solution. Being clear about where they are in their projects life cycle is also critical when reviewing something that is a new concept, feedback can be expansive, even questioning the premise altogether, however for a product that is much nearer to a launch, targeted tactical feedback tends to be most useful, small word changes, iconography, and subtle adjustments to the first time user experience. Finally, I always remind my team never to say “any questions?” or “what feedback do you have for me?” Say what you need! Does the design fully follow agreed-upon design systems and patterns? Does the flow seem logical? Are the key affordances obvious and discoverable?
Team Crits are more focused and need less setup, the smaller audiences tends to have more state on the projects and problems to be solved because they’re all working on related work, unlike open crits, the focus tends to be more granular, and the expectation is that everyone in the team shows some work every week, in some ways it can be a mixture of stand-up and a crit, with a focus on things like wording, micro-interaction, and highlighting opportunities for collaboration, increased feature consistency or coherence, and knowledge sharing around a similar set of goals.
Every company’s culture is different, but I’ve found that the most effective critiques tend to be the ones that are limited to just the design team. Engineering a “safe space” where someone’s closest peers for bonds of trust and people can be open and honest with each other is critical. When I say “design” I’m including all design disciplines, like UX, Visual Design, Writing, Research, etc.
I’ve never made a hard rule that folks outside of design are prohibited from attending, and certainly, designers have invited the PMs and engineers who they are working with to crits when they’re presenting work and getting feedback, but generally keeping the forum smaller and design-focused has tended to create a more psychologically safe space, where people tend to give and receive the best feedback.
Other things to keep in mind
If the majority of your team has an art/design education background the term “critique” might be perceived as neutral or positive, if they aren’t it might seem a little scary. With teams who have more mixed backgrounds, I’ve used the term “Work in Progress” to set expectations and avoid some of the negative connotations that “critique” might have for some people.
It’s important to make sure that both presenting and giving feedback at open crits is optional, having a regular time on the team calendar, and having people sign up in advance tends to help make sure people allocate time, and attend to see the work that is more relevant to them.
Giving and receiving critique is one of the most critical skills for designers, (I’d argue for anyone, actually) having a moderator to help guide the conversation can be useful. Ensuring the presenter is getting good quality feedback is critical to ensure that people continue to attend. Help the presenter by calling out when people give unhelpful or confusing feedback, “I don’t like it” “Why didn’t you do it this way”
Giving and receiving critique are both skills that we can learn and improve at just like anything else.
Additional reading on giving and receiving effective design critique
Stand-ups
Stand-ups are often associated with the Agile product development process, but I’ve found them to be a useful team ritual in other contexts as well. With many of us working remote these days, it can be difficult to know what each other are up to. Cadence can vary by your team’s size and needs, and even the topics should be based on what each person on the team finds the most value in.
A stand-up is simply a quick meeting where each person takes turns giving a quick update on what they’re working on. It can be just what’s up next, or it can be more complex (what you did last week, what you’re doing this week, what you're planning on doing next week, and if you have any blockers)
This is something I’ve iterated on a lot as my teams have grown and changed, been co-located, and remote. The tried and true format that seems to stand the test of time is a rolling deck, where each person gets 1–2 slides that they populate each week, according to your team norms and needs. On a video call (or in a room together if you’re all collocated) one person presents and advances the slides, when someones’ slide(s) come up they have 1–2 mins (helpful to actually have a stopwatch if the team is large) to discuss the work and issues.
Even the most interesting and useful status updates can start to wear on people, over time, keeping stand-ups limited to folks whose updates are meaningful to each other, and keeping the cadence only to a useful rate. E.g. a very small team (under 5 people) might find value in daily, a team of a dozen or more might consider meeting weekly or every other week. Also keep in mind that designers on the team might also be having similar meetings on their product team, so try not to overwhelm.
One thing that’s been really fun and helpful with working from home is to be open to having people’s slides not be work-related, we all know that our work output has been impacted. If you want to share with the team that today’s goal was making waffles and hanging out with their cat, that’s fine, and a completely valid update in my mind.
We’ve experimented with asynchronous recorded video-based stand-ups, and haven’t had a lot of luck with them, the goal is to be quick and easy to join for 15–30 mins when you give folks homework to watch and record videos for other members just never quite worked out.
Additional resources to help you get the most out of your design stand-ups
Alignment & approvals reviews
Getting people the feedback they need as early and as often as possible has been one of the constant keys to success for me and my teams. One of the best ways I’ve found to do so has been to have regular meetings where my leads and design horizontal leads to join regularly to review goals, progress, experimentation output, and evaluate launch readiness.
Aside from folks who are considered “approves” for your launch process, anyone who has expertise in key functions like Visual Design, Research, Motion, Writing, etc are suggested to be present, the goal is to uncover any feedback and changes that need to happen BEFORE a team is ready to launch a product or feature, giving them all the time they need rather than scrambling to do so at launch or worse, a fast follow to post-launch to address critical issues.
While most of the folks in attendance represent the design team leadership and functional leads, the folks presenting work should be the full-stack team executing the work, e.g. Design, Product Management, Tech Lead, and any dedicated Researchers or Analysts. This way any feedback delivered to the team doesn’t need to be passed through design and received by the rest of the team secondhand.
Finding the right balance of empowering teams to launch and experiment on their own, while upholding quality and consistency for the product as a whole is key, it sometimes takes a bit of trial and error, to get it right, but having a decision making rubric defined ahead of time ensures that teams know what is expected of them, and helps ensure that what goes up for review is done so objectively.
Program reviews
Projects and features come and go, but the underlying themes should be generally evergreen. Program review is a time (quarterly, bi-annual, yearly, whatever makes sense for you) for teams to come together and share what they’ve been working on since their last review, and their road map for the future. This might be product teams or something more meta like a Design Systems team, a foundational research program, or other support programs enabling other teams.
Program reviews are as much for the teams as they are for the audience, giving them an opportunity to clarify and focus their message, and giving the team visibility with peers and senior leads. Having a standard template for program reviews lightens the burden on teams and allows you to easily go back to see the progress a program has made over time, as well as matching up previous plans to later execution success.
Drop-in office hours
When we’re all collocated it's easy to just stop by my desk, when we’re all working remote, it's much harder to just swing by to say hi or ask for my opinion about something. Scheduling a meeting to ask a quick question over video can feel burdensome, and worrying about impinging on someone’s work time is always a concern.
Twice a week (sometimes more often) I’ll block out an hour on my calendar which I dial into the same recurring video call, sometimes I’m alone, working on something by myself, sometimes I grab a beer and listen to music. But more often than not, someone from the team will join, we might talk about work, we might talk about pets, or hobbies, or what we’re doing this weekend, but they all know I’ll be there, and they can join at any time for something small or big.
I always set expectations about what are good topics for drop in-office hours are vs our regular private 1:1s
These team rituals work for me and my teams, but every team is different, you can take the same ingredients and cook them in a million ways. Take what works for you, and iterate till it works for your team.
Let me know what you’d like to hear about next in my Design Manager Journey series 👋
