- About Environment, Products, Size, and People
- Consider Specialization First...
- ...And Generalization Second
- Widen People's Job Titles
- Cultivate Informal Leadership
- Watch Team Boundaries
- The Optimal Team Size Is 5 (Maybe)
- Functional Teams versus Cross-Functional Teams
- Two Design Principles
- Choose Your Organizational Style
- Turn Each Team into a Little Value Unit
- Move Stuff out to Separate Teams
- Move Stuff up to Separate Layers
- How Many Managers Does It Take to Change an Organization?
- Create a Hybrid Organization
- The Anarchy Is Dead, Long Live the Panarchy
- Have No Secrets
- Make Everything Visible
- Connect People
- Aim for Adaptability
- Summary
- Reflection and Action
This chapter is from the book
This chapter is from the book
This chapter is from the book
Turn Each Team into a Little Value Unit
The last team of system administrators I worked with was a great team. I really like them, but I think I was their worst customer. It's not that I was behaving badly. (Well, usually I wasn't.) It's just that my aura has an unpredictable effect on electromagnetic fields. People have seen reliable software crash whenever I passed by, and even the sturdiest operating system has an increased tendency to reboot unexpectedly in my presence. And remember those many times you saw a Fail Whale on Twitter? Yes, that was probably me having logged in before you. That's why I liked my system administrators so much. Because no matter how many problems I generated for them, they always treated me as a customer.
It is often claimed that cross-functional teams solve the problem of local optimization, which happens when functional teams optimize their own efficiency. This hurts the overall performance of the business. For example, a testing team may optimize testing procedures, making sure that all testing for a project is performed in one short period of time. Such an "efficient" practice doesn't take into account the dramatic effect this has on the development and support phases of the projects. But is this really a problem of functional structure? Or is it an example of the testing team not treating the development and support teams as their customers?
The opposite problem is that cross-functional teams tend to optimize for their own projects, which can also hurt the overall performance of the business. For example, there may be problems when different project teams all decide to choose their own architectures and third-party components. This increased variation of technologies makes it difficult for the organization to support all those projects. And I'm sure that when I allowed project teams to purchase their own computers and install their favorite operating systems and development environments, my friendly team of system administrators would have skinned me alive.
But most software developers I have worked with wouldn't dream of inviting system administrators into their cross-functional teams. And that's not because they don't like them. It's because communication within a team of system administrators is usually more intensive than their communication with project teams, even though infrastructure is often an important part of many business solutions. Therefore, it makes more sense to keep these people together in their own functional group, despite the communication penalty paid on any cross-functional communication.
What's important is that every team, both functional and cross-functional, should see itself as delivering value to a customer, no matter whether that customer is an internal or external one. Our team of system administrators saw itself as a small business unit that tried to serve its customers, by delivering something valuable. And that's why we liked them. They made the other teams feel important, because to them we were important, no matter how often I crashed our systems or brought down our servers. Functional teams and cross-functional teams should be run as little value units. Then they are truly fractal teams, and there is no limit to the number that can be formed [Leffingwell 2007:96].