The One Microsoft strategy tells us we are one company. We have one operating system, one app API, one marketplace, one cross-platform set of apps, one search, one cloud solution, and one toolset. The days of duplication and reinvention are over. Good riddance.
What’s a huge team left to do? Get small and stay small. I’m not talking about shrinking the entire company (though that’s an interesting conversation). I’m talking about shrinking teams that used to do everything themselves.
“Oh, so Microsoft should just discard our talented people and their knowledge of our systems, abandoning our customers and surrendering to the competition?” Hold on, grandpa! No one said we should give up or forsake the customers of our legacy products. Instead, we need to focus on what differentiates our products and delivers the greatest customer value. My guess is, that doesn’t include yet another test framework.
“But my team needs a special test framework! And my people need a growth opportunity.” We’re all special. We all want to grow. Let’s grow by adding critical, differentiated value for our customers. Let’s meet our special needs by minimally enhancing an existing test framework (and contributing those enhancements back for others to use).
You don’t need a big team to deliver big value. You do need to understand the business (mission, model, and methods) and the customer (desires, demands, and delights). Your team needs to be big enough to deliver the high-value items on time, but small enough that every single team member is fully committed to critical work for customers.
I discuss right-sizing a small team and running it efficiently in Too much of a good thing? Enter Kanban. Most feature teams end up being around 5 – 10 people (including PMs, devs, and testers). Group managers can apply the same logic in order to minimize the number of feature teams they need, and so on up the chain.
“But isn’t lacking spare capacity risky? After all, there’s always basic work that needs to get done.” You must take risks to be competitive, but focusing purely on adding critical, differentiated value for our customers is not that risky. In contrast, getting distracted by folks working on nonessential business is quite risky (pet projects, reinvention of existing tools, extensibility for the sake of extensibility, and features unrelated to key scenarios, to name a few). Your team forgets what’s important.
Members of small teams do need to share information and cover for one another when someone is sick or away. They can accomplish that without diluting the team’s focus on value. Yes, it feels lean and edgy, but being fat and slow is far worse.
I illuminate where to focus your work so you’ll be rewarded in Is it important? It all comes down to having a clear vision and driving toward it with vigor.
“We’re fat, but we’re not slow!” Yes, you are. When your team is large, communication takes longer, coordination takes longer, and stabilization takes longer. Being fat is being slow.
“Yeah, but we’re big and mighty.” Microsoft is arguably big and mighty. In contrast, if you can’t name the critical thing for customers that every member of your team is working on today, your team is fat and slow.
“But we don’t know what customers will want. We need to try things.” Needing feedback is no excuse for pure guessing. Do your homework. Iterate your designs based on real customer feedback. Ship products that matter. No fat, no fluff, no kidding.
I talk about gaining customer insights through iteration in Data-driven decisions.
“What’s so good about staying small?” Plenty. Let’s start with reviews. When your team is small, and all its members are adding critical, differentiated value for our customers, it’s easy to argue for rewards at calibration. After all, other folks are only doing good work. All of your folks are doing good work that makes a clear and obvious difference. There is no fat.
“But not everyone on a team can be in the top 5 percent.” Right, but everyone can avoid the bottom 15 percent by only doing great work that matters. Even though our new review system no longer fixates on these percentages, your team will be rewarded best by having every individual deliver critical value for customers.
“But some people need to do the boring but necessary work (like setup, compatibility, and sustained engineering).” You bet they do. That work is critical. People willing to do it, and do it well enough to drive a differentiated customer experience, receive great rewards.
You probably doubt that people get rewarded for setup, compatibility, sustained engineering, build, localization, or a host of other necessities. I’ve attended roughly two calibrations a year for the past 16 years. I can tell you with firsthand knowledge that when engineers embrace the challenges of necessities, and deliver great value that is customer-focused, those engineers are praised, paid, and often promoted. The trouble is that necessities aren’t often embraced, and engineers typically focus on the technology instead of the internal and external customers.
“But we often just need a tool to do something. Who does that grunt work?” Small teams focused on delivering high customer value don’t have enough bandwidth to reinvent the wheel. Small teams recycle, reuse, and enhance existing tools, keeping their enhancements simple and minimal.
Yes, reusing existing tools can sometimes mean a compromise: not always having the perfectly suited tool for the job. However, small teams don’t waste their limited resources on perfection. They use what’s readily available that does the job and focus their efforts on delivering innovation to their customers. That’s what’s important.
I rehash reuse in NIHilism and other innovation poison.
As another bonus, small teams communicate better and faster—there aren’t many people involved and team members know each other well. Small teams can sit near each other, learn from each other, and better align on direction, understanding of the customer, and how to improve what they do and how they do it every day.
“But what if there’s a problem child? Can’t one bad person disrupt a small team?” Bad people can cause trouble on teams of any size. On small teams, bad people are far easier to spot, isolate, and remove.
Small teams can also communicate out better. Large teams have so much going on that it’s hard to discern their true status. Small teams are focused on fewer items at any given time, thus making status easier to track and corrections easier to implement.
I speak of space and sharing in Collaboration cache—colocation.
Because small teams carry less unfinished work, they have less inertia. Small teams respond more quickly to change, can readjust and realign in days (instead of weeks or months), and generally deliver far more customer-focused value in less time than larger teams doing comparable work.
Small teams deliver more, fast, with less. This is true not because big teams are filled with incompetent folks, but because big teams are slowed by their added overhead, their necessary reliance on their own existing processes, practices, and tools, and the volume of incomplete work they’d have to abandon to change direction. To go fast, you need to be small.
I race through the advantages of shipping often in Cycle time—the soothsayer of productivity.
As a company, Microsoft wants to change the world. We do that by breaking down our big ambitions into team-sized chunks. Those teams work fastest and best when every person on the team is delivering critical customer value at all times—no extra buffer or baggage necessary.
When teams are small, adjusting quickly to changing requirements and priorities, they deliver what’s needed today, not what they thought was needed yesterday. Their members feel empowered because they are empowered—who else is going to do the work?
So, if you’re planning your new team, go small. If you’re a fat existing team, get trim. And if you’re living the dream, shipping fast and furious, rolling with the changes, and racing around the corners, stay small. It’s great to make every day count.
Is Microsoft itself too large? We are top-heavy and overstaffed. But we do need to be big to accomplish big things. However, we can be big while staying small—a topic for a future column.