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.
Just right
“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.
Eric Aside
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.
Risky business
“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.
Eric Aside
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.
Do I look fat?
“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.
Eric Aside
I talk about gaining customer insights through iteration in Data-driven decisions.
How am I doing?
“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.
Eric Aside
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.
What about my needs?
“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.
Eric Aside
I rehash reuse in NIHilism and other innovation poison.
Can we talk?
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.
Eric Aside
I speak of space and sharing in Collaboration cache—colocation.
Corners like it’s on rails
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.
Eric Aside
I race through the advantages of shipping often in Cycle time—the soothsayer of productivity.
Judge me by my size, do you?
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.
Eric Aside
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.
Any thoughts on larger "teams" (from the standpoint of leads/managers) but with smaller V-teams that work on targeted customer feature areas? For example, our team is shipping the same customer feature set on three wildly different platforms (Windows, iOS, and Android). Our team includes all three because they are sharing significant amounts of code and sometimes have shared bugs, but smaller V-teams work on each platform. Do you think we would be better served by smaller teams in spite of this?
You've already broken down into small teams (v-team or otherwise). The question is, "Are there any team members working on non-critical work?" If so, you're too big or improperly focused.
Ah, it was unclear to me whether small v-teams counted as "small teams" from your post.
To answer your question: Nope, we're all doing critical work, either servicing existing releases, working on customer-critical features for whatever our current upcoming release(s) are, or working on our next release(s) on either customer-critical features or on reducing our costs (as in your blog Debt and Investment, and yes, we're not doing prettiness for its own sake). [Aside: you seemed to have forgotten "removing features your team no longer wishes to support" in that blog entry, which, for features that were once customer-important but no longer are, is generally cheaper than anything else you can do for said features :-).]
P.S. Love your blogs.
I'm all in favor of being lean and efficient. But this advice, taken at face value, works against a major, critical challenge of our day (which is seldom called out in any all-hands meeting):
We're always pushing for ever greater, more complex, more "gorgeous" feature sets. And now we push them onto ever smaller devices (Moore's law in reverse!). We need to redirect our efforts in order for this new direction to succeed.
How so? We've been accustomed to spending all our energy and resources managing and analyzing what our software PRODUCES (pixels and bits).
Meanwhile we've put relatively little energy and resources into managing what our software CONSUMES (memory, CPU, I/O, battery, bandwidth, handles, address space, disk space, …, and time).
When push comes to shove, "Small and Fast" for teams has ALWAYS meant leaving behing "Small and Fast" for code.
Reverse that trend.
Now we must gear up to put all the more effort into making the SOFTWARE lean and efficient before we decide whether our TEAMS are lean and efficient.
Else we fail moving our big code onto small devices using our small teams.
Great philosophy. One that fortunately many of us are pushing for.
A much-needed correction, though: Being data-driven is misguided and potentially dangerous without the in-depth generative and evaluative insight brought to bear by design research and the critical thinking explorations of UX design.
Without those, a team simply moves from guessing to reacting. We can do much better than that.
To incorporate design and research into small team operations, look at practices such as Lean UX. (http://leanuxbook.com/)
> …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.
So the people grow tolerant to less-then-perfect software, and eventually start producing the same glitchy stuff in their turn. Good craftsmen know better to keep their tools in perfection, not only because you cannot make clean cut with a blunt knife, but because seeing each day ungainly things, you forget how good things should look like.