One of the most common questions I get about applying lean ideas to product design and development is, “How can I make this happen in my organization?” Between entrenched corporate silos and existing team management structures, it can seem impossible for these ideas to take root in large companies. Over the course of a series of blog posts, I thought I’d share a few tactics I’ve used and have seen work with other teams to help get you started. In this first post in the series, I’d like to talk about how to structure your teams.
As much as who you hire, structuring your teams effectively is key to a lean team’s success. Many companies see the individual disciplines in their product development organization as service providers—internal agencies. The business reaches out to these agencies (engineering, UX/design, product management, et al.), expresses a need for staffing and the discipline lead provides the resources based on expertise, availability, and project fit. It sounds like a reasonable and efficient way to staff a project and to that extent it is—however, our goal should not be to simply staff a project but to build a team.
When building your team, focus on the following four criteria to maximize their chances for success:
Keeping your team small means everyone on the team knows each other—on a first name basis. It’s easier to manage a small team. It’s simpler for the team members to know who to go to when they need something specific. It’s easier to keep track of work accomplished and work left to do.
Small teams tend to self-organize faster and more effectively. They recognize the impact of mistakes and work quickly not to repeat them. They hold each other accountable (because they know each other) and build up a level of trust, across disciplines, due to a closer level of cooperation.
When thinking of size, consider Jeff Bezos’ mantra of the “two-pizza team.” That’s a team that can be fed with two (American) pizzas. In terms of numbers, this works out to somewhere between 6 and 10 people. Successful teams I’ve worked with have typically broken down these roles into:
- 1 UX Designer
- 1 Product Manager
- 4-5 Engineers
- 1 QA
Additional roles have included a visual designer, copywriter/content strategist, a marketing person, or a subject matter expert.
The easiest way to get a question answered is to stand up, walk over to the person who can answer it and ask. Collocated teams are simply more efficient. They can share physical artifacts in real time—like kanban/scrum boards, whiteboard sketches, and paper prototypes. They benefit from non-verbal communication. The opportunities for ad hoc communication are greater while the chances of serendipitous moments also grow.
Collocated teams can build a “space” together. That space becomes a part of their communication cycle. Artifacts are posted on the wall. Information radiators (like analytics dashboards) give the team a real sense of how they’re progressing towards their goal. And it’s by working in this space together that the team generates their momentum and energy. When it’s humming, that energy is contagious and can infect the rest of the teams in the office.
I’m well aware that many of us don’t have the benefit of 100% collocated teams. Innovation with these teams is, of course, still very possible but it will require some tools. I’ve covered that topic at length here.
Dedication to one team seems to be a common problems—especially for designers. For some reason, there is a widely held industry taboo that developers can only be assigned to one team but that designers can easily handle multiple assignments at once. This is patently false. The costs of any team member supporting more than one team—context switching, prioritization, additional email churn, etc.—often end up costing much more than the added productivity multiple assignments seems to bring.
Think of it this way—a designer (or developer, product manager, et al) assigned to working on three teams is pissing off two people every day. That person has to choose which of three number-one priorities she will work on each day and then explain to the other two stakeholders why she won’t be working on their project today. So, in addition to inefficient use of her time, the designer is now placed in the awkward position of navigating corporate politics or conversely working 18-hour days to satisfy everyone—neither of which is a good option.
People dedicated to one team get the opportunity to focus. They know how to use their time—because their P1’s are clear. They don’t have to put off colleagues on one team—who are likely waiting on their work—to do work for another team. They produce better work and they do it more efficiently. Also, by focusing on the same problem statement consistently there is a greater chance for innovative breakthrough as opposed to the “just get it done so I can move on” attitude of managing multiple stakeholders.
One of the most important assets of an innovative team is the ability to do what it needs to do when it needs to do it. Dependencies on other teams slow down the experimentation process, affecting momentum but more importantly, learning and progress. By staffing teams with all the competencies they need to achieve their outcome, you relieve them of many constraints that hold up traditional teams.
Self-sufficient means different things on different initiatives but at the core there should be representatives, at least, from engineering, product, and design. If your project interfaces with a unique system or requires insight from a discipline outside of the core three, by all means add it but keep in mind our two-pizza team size limit. Often, self-sufficient teams that adhere to the small team size employ multi-faceted individuals. They are people who can design and run a research study or develop on the full stack. The greater the competencies on the team (not the roles necessarily), the more self-sufficient the team will be.
As you start to build your innovation teams consider these four attributes. They serve as a good set of guidelines for the initial team structure. Over time, the unique context of your organization will morph this structure into one that makes the most sense for your company. However, I urge you to keep the underlying goal in mind as you modify this approach—what can we do, as an organization, to make it as easy as possible for our teams to succeed?
Jeff Gothelf talks with Lean Startup founder Eric Ries about “Better Product Definition with Lean UX and Design Thinking” in a free, live webcast on July 9, 2013, 10 a.m. PT. Learn more.