In the software world, there’s no shortage of talk about the power of the small team. From famous stories about the handful of people who originally created Apple’s flagship products, to Amazon’s “two pizza rule,” it’s common knowledge that small, autonomous teams deliver the best software products.
And yet even in the most forward-thinking software organizations, teams can balloon in size and process can stifle good product work. It usually happens when a long-lived flagship product team gradually grows over the years, or when a very smart and well-intentioned leader thinking about risk gets some unfortunate advice about a software process for enterprises, and maybe decides to adopt SAFe. That leader might say, “This project is too important to fail. It’s worth the extra budget—just add more people and process to make sure we get it done.”
With the best of intentions, the leader just hit the brakes and slowed that project to a crawl.
It’s an extremely easy mistake to make. Leaders should be thinking about risk and doing everything they can do to set teams up for success. And sometimes teams really do need more people. But too many cooks in the kitchen means nothing gets cooked.
So when you want to de-risk, what should you do? Let’s look at a few strategies that we have seen work at Postlight.
If a project is at risk, sometimes amping up the pressure on the team with a question mark email, as Jeff Bezos is known to do at Amazon, sets everything back on track. But sometimes the team is overloaded. If a team’s responsibilities are truly more than they can handle, the project needs to be reorganized.
The team’s former responsibilities need to be split up into cohesive deliverables that another fully autonomous team can own. The “autonomous ownership” part is important—the new team can interface with the old, but shouldn’t be reliant on them. This is particularly important to keep in mind when teams or companies have grown over the years without close attention to keeping individual teams small and autonomous. Each product team should own one or more related, discrete product features, and they should own strategy as well as delivery.
What is the goal of the project? Is it measurable and achievable? Do you have clear objectives and key results? Sometimes when teams are struggling, it’s because the goal isn’t quite right.
Setting objectives and key results is a well-known practice for aligning teams to do great work. John Doerr says it best in his book, Measure What Matters. Objectives work when they are “concrete, action-oriented, and (ideally) inspirational. When properly designed and deployed, they’re a vaccine against fuzzy thinking—and fuzzy execution.”
To achieve objectives, you also need key results to measure your progress along the way. Good key results are “specific and time-bound, aggressive yet realistic. Most of all, they are measurable and verifiable. You either meet a key result’s requirements or you don’t; there is no gray area, no room for doubt.”
If you think your project goal and its benchmarks are off, the team might want to revisit the objectives and key results. For example, if your goal is to “exceed expectations in the fourth quarter,” it is probably not concrete enough, and is unlikely to fit well with specific and measurable key results. Always remember to revisit goals routinely but not too often (about once a quarter) to see if they are still a good fit.
Teams can be excellent at some things but a bad fit for others, which can be especially apparent when upgrading an organization. The power of small teams shines when a handful of the right experienced professionals have autonomous ownership of a cohesive product or feature. Sometimes the tricky part is those two words— “the right.”
To deliver good software, of course you need the requisite roles—an engineer, designer, and product manager. Sometimes you need several folks from each discipline. Sometimes you also need a project manager or scrum master; sometimes you don’t. Sometimes your quality assurance team should be a separate autonomous team; sometimes it’s best when one is part of the project’s core software team, or when everyone on the team pitches in to help with QA. In all cases, the software team should have one clear leader or manager responsible for delivery, and the stakeholders who interface with the team should be available but excluded from core team meetings and communication.
If the project still isn’t going well after breaking things down, revisiting goals, and considering team fit, it can be hard to know exactly what is off. Product is hard, and because the challenges vary on a case-by-case basis, sometimes the best solution is to talk to people with experience building great software teams and software.
Peter Croce is a Lead Product Manager at Postlight, a full-service digital product studio in New York City dedicated to building great products. Reach out on Twitter @PeterCroce or email him at [email protected].