Why functional silos and shared service centers do not work..

I have always hated functional silos and shared service centers with a passion, but never really thought about why.
They always get in the way of getting stuff done and it seems they only exist to slow things down.

Only recently did I realize how blindingly obvious it was why they did not work. They do not feel your pain. They are not in your value stream.

I’ll try to explain with some examples.

Procurement

We had a problem on our production machines. Our application would in some rare circumstances not only crash the application, but also the application server and sometimes the entire OS. Stuff that was never supposed to happen, but did anyway. We had looked everywhere trying to find the root cause, but were completely out of options. So we turned to Adriaan, a coworker who knew more about troubleshooting JVMs than anyone I know. So we asked procurement what we needed to do if we wanted to hire someone for 2 days. Turned out it was exactly the same (3-6 week) procedure as hiring someone for 2 years. Including a fixed maximum rate that was less than 2/3 of what his going rate was.
So we had to get creative and swapped places for a few days until the problem was fixed.

Procurement did not feel any of our pain of our dying servers. They had maximum and average hourly rates to worry about.

Facility Management

Or as Tom DeMarco and Timothy Lister call them in PeopleWare, the furniture police.
In another company I was hired as an agile coach. I was going to take their teams to a whole new level of productivity. So we grabbed a corner of the floor, put up some information radiators and got started.
Until the facility management people dropped by one night and removed our kanban board and desk reservation pamphlets and left us a red card each. Grave violations of the company clean desk and flexible seating policies. It took us a week of threatening and begging to allow us our own space and stuff on the wall.

Facility management did not feel our pain. Their goal was reducing the total amount of desks. And teams reserving desks worked counter-productive to that goal.

Sales

I was talking to someone at a recent conference and he was trying to get his sales to change. He and his team were often given too little time and money to properly do projects, which often resulted in death marches and bad quality code. But sales did not feel their pain. They had revenue targets to hit. As they were not responsible for the profit of a project they would often undercut an estimate by 10-20% because otherwise a client wouldn’t buy. The company had created an entire risk management committee to appraise their sales offers to make sure they were not too risky for the company.

With the revenue targets the sales department did not feel the pain of the development teams and the rest of the company. For them it was better to do a project, even if it cost the company money, than run the risk of not doing a project at all.

Operations

I am working with a team to develop a cutting edge prototype of a next-gen product. We have developed pretty much everything ourselves, but for one critical piece of the puzzle we needed some functionality from the operations guys. They were very happy to help us set up our servers. But when it came to one last configuration change someone refused to do it without a Request for Change, which might take up to 6 months.

They did not feel our pain of wanting to get this prototype out for customer testing now. They are punished for doing things without an RFC. And more importantly they are the ones that are called at 3 in the morning when things break down.

So in conclusion

This is why I love Amazon’s motto when it comes to operations. If you build it you run it. It puts the pain of both development and operations on the same team. Only then can we be making relevant trade-offs between them. It is time we start integrating a lot of those shared service centers and functional silos into value creating units again.