15 December 2018
Amazon’s Two-Pizza-Teams is a scaling methodology that suggests organizational designers ensure independence and speed by keeping ownership of products to teams that can be fed by no more than two pizzas. These teams need total decision-making authority of their product, and a clear understanding of what success means for them. This works well for Amazon as these small teams behave as composable units of opportunity and service for customers internal and external.
Two pizza teams are about eight people, plus or minus two. That’s a great size to have a mix of analysts, engineers, quality and success folks. This article is about a bad habit I’ve had in building products under the direct care of only one person, usually an engineer; a two-slice team.
In building consumer software, research and development need to be two different things. I’ve been guilty too many times of assigning a single engineer to do some exploratory development on a new product or sizeable feature, and then not reinforcing their efforts enough as the research leaves the lab.
The story goes like this: there’s a new platform we want to install some technology into. A fearless and talented developer dives in and by Friday she has a deceptively slick looking proof of concept of the main workflow. There’re some obviously rough edges, so, sure, why not keep going until the demo is like butter. By this time the engineer’s started an expanding list of
//TODOs that are really more critical than they are nice-to-have.
Without stopping, a few weeks later, this prototype is being talked about like it’s customer-ready software. Pretty soon marketing and customer success are being spun up to trumpet about this achievement to your customer base, and before you know it this research product has paying customers, problems, and is going to need love and support for years.
What I just described isn’t necessarily indefensible. There are times when you want to parachute in and make something available in short order. Just do it sparingly. Don’t make a habit of having hero-engineers launching half-mature hit after hit without stopping to take stock.
At about the second week of an exploratory project it’s time to stop and take stock of what the future of this line of development is really going to take:
Take stock of these concerns now. Do with them what you will, but at least have the estimates and information.
“If you want to go fast, go alone; if you want to go far, go together.” – Unknown
This lesson is about portfolio management. After a few months carrying all the water for this product, this person is going to be burning out. The problems they’re struggling with are going to be taking on a character of insurmountability. The project needs fresh eyes and diversity of thought. You’ve got to either staff up a team around this project, or fold the project and the engineer into another group that can afford to lend a hand.
How many of these major features/projects exist for your team? How many exist whose engineer has been reassigned, likely repeatedly?
Automation is the aim in software, so to some degree it’s desireable to have bits that’re trustworthy and haven’t been touched in a year. Something like this is going to be well-instrumented and alarmed, and it’s not going to generate customer success challenges. However, that level of maturity isn’t going to happen in a worthwhile timeframe under a single caregiver.
Have a spreadsheet that maps out your organizations’ portfolio: the applications, major features and subsystems and the wellness thereof. Who knows these systems? What’s the future interest in developing them? What should be actively sunset? Estimate the commitment it would take to give the care you want these systems to have.
You’re going to be short of what you want, nobody ever gets ahead of the list. The question is are you putting resources where you expect to be growing the business? How many C-grade features do you have in the field that are a drag to support and make the staff cringe? Are you understaffed 15% of where you’d like to be or 40%? What’s going to give? Have that conversation with the larger organization. Suggest specific changes: cuts, simplifications, pesky-time-stealers.
Stop and plan. The allure of another quick-hit major feature delivered by a stellar talent is too good to be true. Products need a diversity of supporting actors to thrive in the long term. Engineers need a breadth of challenge and opportunities to keep them interested, learning and happy. Don’t shy from the exploratory work, go and learn about where you want to venture. But, if you’re going to take something on, take it all the way on. Give it the team it needs.