The four kinds of work, and how to get them done: part three

Those startups that manage to build a product people want have to deal with the consequences of that success. Having early customers means balancing the needs of your existing customers with the desire to find new ones. And still being a startup means continuing to innovate as well as keep the lights on. In short, it's hard, and easy to mess up - as I've certainly done more than my fair share.

In part one of this series, I talked about the four fundamental kinds of work companies do, and in part two I talked in some detail about the conflicts these differences inevitably create. Today, I want to talk about solutions. In short, how do you grow your team when it's time to grow your company?

For starters, there's whole volumes that need to be written about how to actually find and hire the people your startup needs. For example, you can read my previous post about how to do a a technical interview. But most startups succeed in hiring, one way or another, and are still left with the problems of organizing the people that rapid growth brings in.

To mitigate these problems, we need a process that recognizes the different kinds of work a company does, and creates teams to get them done. Here are my criteria for a good growth process: it should let the company set global priorities and express them as budgets, it should delegate trade-off decisions to a clearly-identified leader who is tasked with making trade-offs within a single kind of work, and it should allow personnel to circulate "backwards" through the kinds of work by facilitating clear hand-offs of products and features between teams.

1. Build strong cross-functional teams for each kind of work. Let's start with the most important thing you can do to help product teams succeed: make them cross-functional. That means every team should have a representative from absolutely every department that the team will have to interact with. To begin with, see if you can get designers, programmers, and QA on the same team together. When you've mastered that, consider adding operations, customer service, marketing, product management, business development - the idea is that when the team needs to get approval or support from another department, they already have an "insider" who can make it happen.
   
   The advantages of cross-functional teams are well documented, and for a thorough treatment I recommend the theory in the second half of Agile Software Development with Scrum. I want to focus here on one particular strength: the ability to operate semi-autonomously. Whatever process you use for deciding what work is going to get done at a macro-level, once the team accepts its mission, it's free to get the job done by whatever means necessary. If the team has true representation from all parts of the company, it won't have the incredibly demoralizing experience of coming up with a solution and then having some outsider veto it. The flip side of that is that you can have strong accountability: all the usual political excuses are removed.
   
   I have been amazed at the levels of creativity these kinds of teams unlock.
   
   
2. Create iteration cycles that provide clear deadlines and opportunities to revise budgets. Opinions vary about the optimal cycle length, but I do think it's important to pick a standard length. Scrum recommends 30 days; I have worked in one or two-week cycles up to about three months. At IMVU, we found 60 days was just about right. It allows each team to do multiple iterations themselves, before having to be accountable to the whole company for their work. You could easily manage that as two 30-day scrums, or four two-week sprints. Either way, create a clear cycle begin and end date, and use the cycle breaks for two things: to hold teams accountable and to reallocate personnel between teams.
   
   In order to prevent people from bunching up in the later stages of the work pipeline, those leaders need to be focused on automation and continuous improvement. Make sure you keep track of whether that's happening. Between cycles, put some pressure on those later teams to do more with fewer people. If they can keep their team sizes constant as the company grows, you'll be making it possible to have more people working on R&D and Strategy.
   
   
3. Find a balance between long-term ownership and learning new things. As the team grows, it's tempting to want to keep people on the same teams for long duration. That's more efficient, in a way, because they get to know each other and the better they get to know the part of the product their team is working on. However, I think it's more efficient for the company overall if people are moving between teams and learning new skills. That keeps the work interesting, and prevents specialists from becoming company-wide bottlenecks.
   
   Some people will naturally move with the work they do, as projects pass between teams. Manager need to keep an eye out for opportunities to move people simply for the sake of helping them take on new challenges. Team leaders should rotate less frequently, because too much churn works against accountability. A good target is to try and circulate about 30% of a given team between cycles.
   
   
4. Formalize and celebrate the hand-off between teams. When a project is done, there are three possible outcomes. Either that team is going to keep iterating it in the next cycle, or they are going to hand it off to another team, or they are going to euthanize it and remove it from the project. If you get serious about these hand-offs, you can prevent a common problem that startups encounter: lots of features that nobody has ownership of. If you celebrate these hand-offs, you reinforce the idea that different kinds of work are equally valuable, and you help people let go when it's time for transitions to happen. For example, the level of attention a project gets when it moves into maintenance mode is going to be less than it had before. Acknowledge that up-front, and celebrate the people who made it possible for that feature to run its course and help the company succeed.
   
   
5. Prefer serializing work to doing it in parallel. When possible, try to have the whole team work on a one project at a time, rather than have many going simultaneously. It may seem more efficient to have lots of projects going (each with one or two people on them), but that's not been true in my experience. Lots of little projects erodes teamwork and builds up work-in-progress. I believe that having the whole team work from a common task list, in priority order, lets everyone feel that "all hands on deck" sense that the founders experienced in the early days of the company. You can still do multiple projects in a single cycle, just try and have as few "in flight" at any given time as possible. You'll also be able to put more of an emphasis on finishing and shipping, than if everyone has to rush to finish their projects all at the same time (stepping on each others' toes, naturally).
   

This process can seem daunting, especially if you're currently running in ad-hoc mode. That's OK; like all lean transformations, you need to undertake this one in small steps. Remember the mantra: incremental investment for incremental gain. Each process change you make should pay for itself in short order, so as to build credibility and momentum for further refinements.

Where should you start? I rcommend you try building a cross-functional team and see what happens. At first, choose only a few functions, keep the team small, and give them a modest goal. Try your hardest to give them space to operate without supervision, which means choosing a problem that doesn't have huge risks associated with it (or you'll be too scared to let them out of your sight). Keep the team size small, maybe just two or three people. If the goal is clear, and the team is willing to embrace it, you may be surprised just how fast they can execute.

One last thought. These ideas are easier to give lip service to than to actually implement. So if it doesn't work right away, don't give up. Maybe you think you've created a semi-autonomous team, but the team feels like it's just business as usual. Or you may have too high a level of background interruptions for them to really stay the course. Or they may decide just to slack off instead of accepting the mission. Try to see these as opportunities to learn: at the end of each cycle do a five whys post-mortem. I gurantee you'll learn something interesting.