I really like our system administrators, but I think I am their worst customer. It’s not that I’m behaving badly. (Well, usually I’m not.) 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 like our system administrators so much. Because no matter how many problems I generate for them, they always treat 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 3rd-party components. This increased variation of technologies makes it very difficult for the organization to support all those projects. And I’m sure that, when I allowed all our project teams to purchase their own computers and install their favorite operating systems and development environments, our friendly team of system administrators would skin me alive. With a screwdriver and a soldering iron.
But nobody in our organization would dream of inviting a system administrator into their cross-functional teams. And that’s not because we don’t like them. It’s because communication within the team of system administrators is more intensive than their communication with the project teams, even though infrastructure is an important part of many of our 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 sees itself as a small business unit that tries to serve their customers, by delivering something valuable. And that’s why we like them. They make the other teams feel important, because to them we are important, no matter how often I crash our systems or bring down our servers. Functional teams and cross-functional teams should be run as little value units, and there is no limit to the number that can be formed.
(image by Josh Pesavento)
This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.
Twitter - 
Subscribe - 
Newsletter - 
LinkedIn - 
SlideShare
| Latest, greatest and favoritest posts:
When You Are Rejected About Project Success and Failure I Follow My Rules, You Follow Yours |
