Small teams should diversify their efforts in order to increase their success rate.
(reposted from Medium)
In a consulting environment, the Sprint is a great method of meeting many important goals at once. The client gets results quickly, and is made to feel like you’re pulling out all of the stops to deliver something of real value. The working group, on the other hand, gets to rally around a cause in a way that encourages enthusiasm and mutual support. Everything is done before fatigue can set in, and progress is tangible and immediate.
But in individual efforts and among small teams with limited resources, Sprints can be highly destructive and expensive. Especially in the hardware world, and in contexts where the prime directive is to convert stuff that you don’t know that you don’t know into stuff that you know that you don’t know, weeklong periods that are dedicated to only one project are often totally unfeasible.
Moreover, the biggest challenge for young teams will be finding areas where they can offer real value to emerging markets. Very few startups will have the resources to enter existing marketplaces and compete with established products; the real opportunities lie in needs that haven’t been discovered yet. If Henry Ford had tried (as the possibly apocryphal adage goes) to build a faster horse, he would have had a long journey ahead of him, and would have needed to compete with breeders that had experience and resources that he couldn’t hope to match. Young teams need to learn what they’re good at, and where that fits into the competitive landscape, and focusing on one project at a time isn’t always a great way to accomplish that.
Every team needs to find their balance, but I recommend starting by putting in efforts that are measured in hours, not weeks. When working on hardware projects, I find it rare that I don’t need to order a few parts after a day or so of work. I almost always have open carts on McMaster-Carr, Digikey and Amazon, and keeping multiple projects going means that I put a minimum number of orders out (usually one a week from each of those, plus one or two more from smaller suppliers). This not only allows me to save on shipping, but it also means that I’ve always got something to work on. If I’m waiting on a particular screw to come in from McMaster, I can usually move forward with my wireless mesh network project. If I’m having trouble with my temperature sensor circuit, I can remodel my FM radio enclosure and send it off to get prototyped. And if all my hardware projects are stalled, I can work on product management stuff — constructing storyboards, or writing Amazon-style press releases.
Having many projects going at once encourages team cross-functionality and empowers team members to make prioritization decisions on-the-fly. It reduces emphasis on goals and emphasizes creative and strategic objectives, and allows ideas to permeate between spheres that would otherwise be segregated.
Another advantage to working this way is that it makes the act of pivoting almost unconscious. Projects don’t get discarded so much as they go dormant — which makes the emotional process easier for teams to manage.
Whatever you’re working on, and however you structure it, the important thing is to be learning where your interests overlap with what the marketplace is going to value and reward. My recommendation is to keep the process quick, and to make sure you make progress and recognize good work when you’ve done it — but to remain unemotional about ideas that are fated to remain on your backlog. As Churchill said, “Success is going from failure to failure without loss of enthusiasm.” Get out there and do it — you’ll find your stride in time.
