Big teams vs. Little teams

Compiled: 5/2/2005

The Situation:

I’ve recently moved from a small development team/organization (10) to a much larger one (80) people. I’m having a hard time figuring out how to be effective getting things done without pissing people off – What I see as just being effective and efficient, is sometimes seen as cutting corners, going behind people’s backs, or being “a hacker”. What they see as diligence and proper procedure, I see as a (frustrating) waste of time.

Is there some way for a mid/large organization to keep the speed and autonomy found on smaller teams? Is there any advice I can give to the group manager that can help him balance his org size, and, assuming he agrees with me, with a desire to avoid bureaucracy and keep smart people like me moving at top speed?

– A fast fish in the slow pond

Big teams are trucks, Little teams are motorcycles

The basic rule of thumb is that the bigger the org, the more mass it has. It will take longer to get it moving, but once it does it can move more stuff than something smaller. The smaller the org the faster it can change direction and the quicker it will move, but it won’t be able to move as much stuff at the same time.

With this in mind, there’s nothing evil about big orgs. They just have different strengths and weaknesses than smaller orgs do. This isn’t to say that your desire to optimize or find shortcuts is misplaced, it’s just that the context is different and a successful optimization will be more involved than you’re used to.

Bureaucracy defined

Here are two definitions:

1. Management or administration marked by hierarchical authority.
2. An administrative system in which the need or inclination to follow rigid or complex procedures impedes effective action: innovative ideas that get bogged down in red tape and bureaucracy.

In any organization some hierarchy is required (Definition #1). But impeding effective action (Definition #2) is the opposite of effective management. It’s worth remembering the difference between these two notions of bureaucracy

Designing team process is hard

Hummel wrote "When designing software development process, the risks and consequences aren’t always as immediate and severe. It can be hard to see that the process itself is what is causing the project failures (delays, lack of quality, etc.). That is why process maturity models (i.e. CMMi) focus on ‘continuous improvement‘. In these models, every team member is incented to provide feedback. Over time, the process governors learn from this feedback and the process evolves. "

So this means that if you voice your suggestions of improved process to whomever is defining the process, it’s their job to consider making adjustments. If enough people share your opinion it should be in their interest to consider making changes.

The challenge though is that teams of any size have people with different opinions and needs. For every change that would make you super effective, it might make work mor e difficult for someone else. While it’s true your work might be more important than theirs, when we’re talking about the collective value of 10, 20 or 50 people, it’s difficult for a team leader to sort out the exact value of any kind of process change.

The person defining team processes has to find a way to balance them all out in a way that has the greatest chance of being successful. The larger the organization the more likely it is that leaders will result to a bland, procedure focused way of working. It’s the easiest way way, from a manager’s perspective, to easily track and understand everything that everyone is doing.

Big teams vs. Small teams

One simple way to think of this from a VP level is what level of integration work needs to have, and when you want to deal with integration between them. If there are 10 different products and they require no integration and share no components, there’s little reason to keep them all trapped in a mega-large Borg type organization. But if 7 of those 10 teams share a component from the 8th team, or if 5 of the 10 teams have related business and technological goals, it makes sense to try and keep those things aligned in some way from the beginning instead of waiting until it’s late to get them lined up.

Decentralization and high autonomy can certainly work for integrated projects. There are many good examples from military strategy of dividing forces into autonomous units that share strategic objectives, but diverge on tactics. But to do this requires a level of talent in executive and middle management that is hard to find. As a VP, distributing big amounts of authority to 10 mid level managers requires levels of trust that are rare. And the kind of management skill and philosophy that a VP or group manager would need to have to pull this off doesn’t seem particularly common.

So in some cases it’s not the organization or the people invovled: the organization just doesn’t posses the kind of leaders that could sucessfully manage a highly indepedent and authority distributed development organization.

Possible Tactics

• Do it the way you think it should be done, and to hell wit them. This is arrogant and risky. You’re gambling with people’s trust in you.
• Talk one on one with the people in power. Pick one specific thing you think should change, have a specific recommendation. Repeat until you find supporters, and then collaborate with them on what actions to take. Don’t fight organizational battles alone.
• Do it the way you think it should be done, and apologize later. This gambles that your approach is so much better that good results are guaranteed. If you can get support from your sub team before doing it.
• Play the game but attempt to suggest small changes from the inside. Plan to build the size of your suggestions as the smaller ones pay off and you earn respect.
• Go along to get along. Invest your passions outside of work (Volunteer for an open source project, spend more time with the kids, read those books you’ve been wanting to read). This doesn’t require giving in: instead prioritize your life differently and care more about the things you have control over.

Contributors

Steven Levy, David Gorbet, J Kremer, Scott Berkun (editor)

About PM-Clinic

The pm-clinic is a friendly, wise, open forum for discussing how to lead and manage teams of people. Each week a new situation is sent to the list and we share advice, ideas and stories. Anyone can join as long as they follow the simple rules.

PM Clinic discussion group

General info
How to join
Full archives
Other web forums