A Centralized Team aka “The Only Grocery Store in the Town”

What are tenets of a centralized team? First off, what does that even mean? Centralized teams are those that provide “Horizontal support” - implies that the team is not providing support to one specific domain or parts of business, instead it focuses on supporting all teams in a very generic manner. The support then takes the shape of becoming a service as opposed to being a domain specialized niche service.

There are pros and cons of moving away from being a niche service provider to being a generic service provider. One obvious upside is that the team develops a “cookie-cutter” type of solution and uses the same solution to service any and every line of business. The downside is that this is detrimental to the team members themselves. They lose the touch to understand nuances of each domain. Their expertise is diluted to a point that the service would devolve into a commoditized service.   

Typically, in most companies of reasonable sizes, teams such as network operations, database administration, system and storage administration and data center have the opportunity to assume the role of central teams and provide horizontal support.

Why are such teams formed and kept as central teams? There are multiple reasons for that. For one, a central team has a critical mass so it can be administrated as a team as opposed to “onezy-twozies” who are existing as differently skilled persons in a team of largely varying skilled resources. Then there is question of performance appraisals - this becomes easier since you can compare “apples-to-apples”. The career paths are clear – you can have a clear career path within a team of 10-15 system administrators as opposed to one system administrator residing in a team of developers. This is the high order bit of why central teams are needed.

If we want to double click on details then, from logistic standpoint as well, it becomes easier – you can restrict superuser passwords, sysdba, system passwords etc within the team and don’t have to share it across multiple teams and lose the notion of password itself. Finally, best practices are very well shared, standards are set and implemented. SLAs are drawn and people have set expectations on the type of “customer experience” for a given task.

When we combined the DBA teams under one umbrella in 2009 – after trying for many years – I realized that there were more leaders, especially those whose DBAs were being “snatched away” from them, who wanted this model to fail than those who wanted to see it successful. So there was a political realm to the whole implementation. While one part of the management chain wanted this to happen, the other part was doing simply window dressing by playing along in meetings and using every miss by central team to highlight the fact that it was a failed implementation.

Then there were DBAs who were behaving as if they have been uprooted from their comfort zone and were struggling to find their roots in the new land. They were still attached with umbilical cords with their previous organizations and wanted to restore the status quo. This behavior can largely be explained as a sole fish or few fishes falling into a bigger pond and being scared, loaded with skepticism of how things will pan out.

As is fairly apparent by now, there were struggles, external as well internal, to nuke the central team even as we had just started forming up.

Most of the external fears and misconceptions were very reasonable – for example, will the service levels dip, will the team get same focused support from their earlier DBA or will that DBA’s effort spread thin across multiple other domains, will team get new DBA to interact every time so they have to end up teaching  from scratch, the idiosyncrasies of their domain to the new DBA. However, it would be naive to say all of the opposition to move towards central team was based on above reasons only - there could be the omni-present sense of "loss of territory" coming into play as well in that opposing behavior

While all this was happening, I became convinced and somewhat determined that if we have to be successful as a central team, we need to behave as follows:-

Imagine that you are the only grocery store in the town. By being the only place where people can turn to for their groceries or go hungry, it becomes important that following tenets be followed:-

• No Customer Turned back – we can’t turn back any partner team for whatever reason – least of all due to things being out of stock or not enough salesperson to provide customer the service (akin to lack of bandwidth).
• Queue system established – we will have to establish a queue system that gives a sense to the customer when will he or she gets the attention of salesperson.
• Length of queue (or wait period before service) is reasonable
• Service is provided with quality
• Service is provided with a smile (because you love to do business with friends)

Luckily, we had a very mature leadership team in place. We had discussions within leadership team that we will do our utmost to make this successful. We ensured that we would provide the best service to all our partner teams including the new teams that we absorbed into our teams. This was more of journey. Over a period of consistent engagement with us, the “noise” generated by external partner almost died down and was replaced by a sense of “we are better off now”.

There will always be people who for their personal interests will go against the grain of centralization. At some point, it is better to make the right call on those. There have also been team members who came from external teams who have turned out to be exceedingly better than our existing team members.

What happens if you fail to follow the tenets?

Most of the times, central teams walk away with the arrogance and impression that people don’t have choices and they will do whatever we tell them. When that happens, customer teams tend to behave somewhat analogous to flows of rivers. Like a river figures out path of least resistance and eventual flow, a partner team not getting required service from the central team tends to eventually figure out how to find that support. They will devise a way to get that service – in most of the cases, the solution will involve seeking help from teams outside of central team, forming their own team, engaging with an external vendor to outsource their support needs. All this leads to undermining and ultimately destroying central team, so it is always in the best interest of the central team to behave like the "only Grocery Store in the town" and follow the tenets mentioned earlier.