Big teams vs. Little teams
PM Clinic: Week 26 discussion summary
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.
Here are two definitions:
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.
Steven Levy, David Gorbet, J Kremer, Scott Berkun (editor)
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
|All content copyright 2005. Scott Berkun.||RSS Feed|