That's a tough question because it totally depends on who is on your team. If you do not have managers reporting to you, you can probably manage up to 8-10 reports before things start to fall apart. If you have strong managers, each can take on 5-7 people (assuming they're also rolling up their sleeves). If you also have more senior designers you can run a very slim team and accomplish a lot. I have had a team of 3 complete rock stars do more than 20 people before.

I think I would approach this by determining what you need to accomplish and carving out clear and reasonable chunks of ownership. The more people have autonomy and understand what they control the easier it is to gain alignment and deliver that output you're looking for.

Hey Steve,

Our teams are very integrated and functions are woven together pretty tight. PMs, Engineering, Data Science, and Design work together at the start to gather requirements and review PRDs. Lots of alignment happens upfront. Though designers have their own process for getting to an official hand off (crits, reviews, approvals) PMs and Engineers are invited to all of those forums and often field questions about the strategy and implementation in a design review. We also have separate product reviews which is more focused on the data, metics, and strategy.

Though we're pretty good at handing off projects to engineering (because they've been in the conversation the entire time) we're still not great at design QA. Making sure what lands in our user's hand is what we intended is achieved through time consuming testing and auditing my individual designers. Engineers also don't always know what it means to finish the work down to the last detail so this can often be a breakdown in the process that we want to fix.

Hope that helps!

Thanks, James!

Honestly, it really depends on how you define success and failure. Philosophically, experimentation is all about learning so if the team learned something (even if metrics went down) it's still a win. Sometimes knowing what not to do is just as important, right?

That being said, one of my favorite experiments at Airbnb was when we added the ability for hosts to create visual check-in guides for their guests. Project kicked off after we ran an analysis of how hosts were using image messaging. We discovered hosts were frequently using the messaging platform to help visually walk their guests through the check-in process. We took that finding and productized it into a standardized flow and a one-click action. I love when a team is able to perform a behavior analysis, identify inefficient hacks and workarounds, and then streamline that into an easy robust tool. 

Worst experiment...any test where there wasn't a hypothesis. I don't believe in "testing to find out what works". Every experiment should have a clear goal and notion of what you're looking for. The point is to create repeatable findings. If you launch an experiment and have no idea why it created the results (either positive or negative) then it's a failure. This happens all the time so won't go into examples but just know there's a difference between hacking/testing and "shooting in the dark".

Hey Jordan, right now our company is organized by "Lines of Business" and though design is centrally managed, we imbed design teams into each business. Process is really different from team to team because the work is really different. Ridesharing is definitely our largest and most mature business so they require multiple forms of deliverables and communication to drive projects forward. Early stage work might have several rounds of vision and "clarifying the problem" meetings. Smaller and more nimble teams are able to work a little more fluidly, testing and iterating as they go. I also oversee our Industrial Design team which has an entirely different process that's appropriate for their world. My job is to really support my managers as they set the process that's most appropriate for them (they determine if it should align to dev sprints). Of course I coach a lot and provide guidance when things could be done more efficiently, but in general I let the team determine what process works best for them.

Now that I've said that, there are some consistent threads to managing a team that I can offer that's in my playbook.

1. Create a sync or operational meeting early in the week with your managers. This is your air traffic control meeting. Know what's going on and raise any issues that might come up. Avoid fire drills with this meeting. Also use this time to cascade information from leadership.

2. See the work at least once a week. I setup a crit with each of my main teams and I never cancel (even on vacation, I'm always there). This is often the one time a week the ICs see me so make it count.

3. I have a monthly All Hands where we talk about the big picture. Sometimes we bring in actual users and hear from them, sometimes we talk about the future. This is not the time to talk about the work but focus on what we're really trying to do as a team and why we're all there. Inspire people!

Hope that helps!

Hey Taylor, congrats on the new role!

First best interviewing practice I can give is ask the same set of questions to everyone interviewing for the role. Often we treat interviews as "conversations" but that is riddled with bias and without knowing it, candidates may be vetted inconsistently. Create a list of questions before starting to interview and stick to it. Request the same be done by the people interviewing candidates for your team.

Second, never compromise when it comes to recruiting. It can take FOREVER to find someone that meets the bar. You may be so under water that it's tempting to just give an offer regardless of red flags. Please don't do this. It will be much more painful in the long run.

Most teams report 3Ps weekly and they writeup three bullets for each P.

• Progress: Three ways that the team made progress last week

• Plans: Three things we plan to do this week

• Problems: Three problems/blockers/obstacles we're facing now.

We share these on Slack to appropriate audiences. We start at the top (our leadership team will post to the entire company) all the way down to our pods.

Not a problem, happy to keep answering questions (it's not like I'm going any where!).

Usually a Design Director for a product team is responsible for all aspects of design that contributes to the end-to-end experience. This includes interaction design, research, content strategy, production, and program management. They might not directly manage all those roles but they're accountable for the final output (what lands in user's hands). In addition to growing leaders/managers under them they are setting the vision, strategy, and process in which their team(s) operate. There are many flavors of this based on personal strengths. Some people lean more into operations and are especially skilled at team management and creating well-oiled machines. Some are stronger at vision and can see the future (and the path to get there).

Biggest challenges of a Design Director

• You need to be highly effective at influencing other leaders not in your function. These are individuals that may not understand design or how you can help.

• Your job is to advocate and represent what the user's need which is often in direct conflict with what the business needs or what can be built (in a reasonable timeferame). This means you have to be willing to respectfully debate your PMs and Engineering partners. Often you have to let go and compromise. You have to be willing to commit to a plan even if you don't entirely agree with it sometimes.

• Typically a Design Director covers a large scope and many surfaces. The trick is to stay close to the work while seeing horizontally across. Magic happens when you are able to connect dots for your teams.

Creative Director tends to be more of a marketing and artistic/creative title. At Airbnb we had Creative Directors in Marketing and at our Art Department team which was like an in-house creative agency. These individuals lean more into aesthetics and can really articulate the abstract concepts and goals of the project. They still manage people but their reports are usually focused on more specific skills/trades/crafts (copy writing, photography, illustration, marketing strategy). Their scope can range quite a bit depending on the company and team.

Biggest challenges of a Creative Director

• Often their teams are operating like an agency and have to triage a lot. Managing requests and prioritizing constantly.

• Getting introduced to the work early enough to be able to drive some of the strategy and direction is always challenging. Often these leaders are getting late requests and time just prohibits stronger ideas.

• There's always a threat to 'take it outside" and hire an agency instead, especially if the team is already at full capacity. The risk is losing oversight of high impact work and Creative Directors often find themselves overextended as a result.

There's also a new title/role that I see emerging. As orgs become more complex and Design VPs/Directors are taking on more strategy and business leadership responsibilities we're finding that we can't do the job like we used to. Often vision is deprioritized and teams (across all functions) feel that they don't know where things are going. They want to know how work now will connect to the future.

In enters the Senior IC!

I see a future where product centric Design Directors are partnering up with product "Principal Designers". The first will manage the team and handle the operations, they will stay in the know of decisions and do much of the heavy lifting when it comes to gaining alignment with cross functional partners. The second will stay close to the work and guide the teams with a strong and compelling vision. The crossover between them is strategy and communication. We're testing this at Lyft, honestly not sure if this exactly how it will work but I believe strongly that 1. not everyone should/can be in every meeting 2. we need to divide and conquer based on strengths at all levels to succeed.

Thanks for the questions!

We just moved over to Figma as our primary tool in January. Dylan Field has already heard this from me but I'm a big fan of what that company has build (also shout out to Noah Levin!). Frankly, I'm so grateful we made the switch when we did because it's made this time of working remotely much more feasible. We're still working with a suite of other tools for various production and prototyping reasons but I think it's fair to say we're a Figma shop now.

As far as other tools - Lyft is HEAVY on documentation. We use Google for most documentation and share aggressively. We primarily use Slack for cascading info and sharing these docs.

Lastly, at Lyft we are using a system called the 3Ps (stands for Progress, Plans, Problems). It's a quick and standardized way to share status of projects in lieu of countless standups and syncs. As a leader that's generally in back-to-back meetings I'm so grateful for this system as it keeps me up to date and saves time.

It's hard to imagine anyone is not impacted right now and the same goes for my teams. The most obvious is the way we work. My teams were already distributed across two offices (NYC and SF) but now we're fully distributed. We are making it work. Lots of remote best practices are being created. We're leaning on each other more. We're doing our best to redistribute the load based on personal situations (like parents with no support). As for designing features, our approach is to continue focusing on quality and long term bets. I think the entire world is taking a big step back and determining what really matters, and we are doing the same.