Are you cutting costs or creating bottlenecks?

As organizations grow, a common way to cut costs is to centralize certain capabilities into their own teams or departments. Common examples are centralized identity access management, integration platform management and more expensive kinds of testing, like load testing and penetration testing.

Apart from cutting costs, this approach has several other benefits:

• Standardized operations and processes
• Duplication of solutions and efforts can be avoided
• Improved security and data reliability
• Centralization allows for more specialization

But every coin has two sides, and this monolithic approach certainly has some drawbacks.

Approximately, an average feature spends approximately 80% of its lifetime in various queues and waiting states, and only 20% in active development.

It goes without saying that this is a highly unscientific observation, but I’ve seen it often enough to find it reasonably accurate.

What does this have to do with centralization? Well:

Almost all handovers between people in different roles, teams or functions are prone to become bottlenecks. And the worst offenders are usually situations when the team is dependant upon a centralized group of people in the company.

It’s not that these people don’t care or recognize your problem, it’s just that they have ten other people with issues just as urgent as yours. From their point of view, it’s tough to be objective about the order of importance.

If this problem occurs within the boundaries of the team, it’s easier to do something about it. The person responsible for prioritization merely has to make some tough decisions, and hopefully, the situation resolves.

But when several projects have to fight for the attention of another department, things get more complicated. And even if there is a willingness to change, it usually takes a long time to roll out new, improved processes at this level in an organization.

One of my recommendation in situations like this is to make one of the centralized experts join the team 100% for a limited period.

This person should have two obligations: 

1. to fully support the team in the short term, and,
2. to pass on enough knowledge for the team to handle these things on their own in the long term.

I realize that many organizations might have a problem with step two; with the rationale being that they cannot give everyone access to everything for security reasons.

In my perspective, this is just a trust issue. (Unless we are talking about classified data.) From a technical standpoint it would be pretty easy to solve; just give a selected few people read access to the APIs or databases and make sure they get proper training. Then they won’t be able to break anything, and the bottlenecks should gradually disappear.

Sure, this approach requires a bit of an effort to set up initially, but in my experience, it pays off in the long run.

What is your experience?