Decentralize all the things?

  To centralize or to decentralize, that is the question. This topic can be tricky. There's a lot of articles out there advising companies to decentralize, decentralize, decentralize. Typically, that's because many companies still have so much centralization. Usually for good reason, they see decentralization as risky. In many cases we see that pendulum swing too far in either direction rather than finding a healthy balance. 

   Everything should not be centralized. Waiting for a decision from the "central authority" can slow delivery to a snail's pace. Often we see companies with too much centralization have review boards and books of processes in place and their delivery rate is in the timeframe of months.

   When every team has to adhere to something like compliance, it's normal for a company to centralize the compliance piece to one team. When the one team is responsible for compliance across all of the teams it relieves everyone of even having to consider it. This centralization can lead to more risk of being out of compliance, more rework, and animosity between teams. The same can be said for companies that centralize testing or quality control. Things like compliance and quality should be everyone's responsibility and when we lay that responsibility on one person, group, or team we are increasing the likelihood that we'll soon be off the rails in one way or another. 

   On the other hand, companies that decentralize everything end up looking like the wild west.

Every team is autonomous but many times they lack any standardization and/or have trouble linking systems to each other. There's also mountains of redundancies and risk. For instance, teams that lack any sort of centralization might start building their own solutions for signing in. Rather than a single sign on for their many products, users have to create a unique log in for each system making it cumbersome to the users. For the record, wild west is NOT what we're going for. 

So... what do we do? 

   We have to find a healthy balance that includes making some trade-offs. In the case of the compliance or testing being centralized into a team, we need to make sure we aren't trading dedicated focus for increased risk of compliance or quality suffering. While a dedicated team sounds like a great idea, taking ownership of those aspects of the product away from the teams completely means increasing the risk that something will be missed. We've seen a level of centralization have success when instead of a testing team that does all the testing the centralization happens as more of a community or guild that is passionate and has some authority. I know what you're probably thinking...ugh not a community of practice, I think those suck. And you aren't wrong, most do.

   However, when the sole purpose is to promote the passion and craft in addition to guideposts across teams we see huge benefits. If the people in that group are people that have authority and can make decisions about their craft then you have a chance at guiding the organization toward improving their craft. The testing community, comprised of all levels of testers, can provide guidance to everyone around best practices to use, updates to make, and improvements that lead to better quality! The compliance professionals can do the same for the organization around staying compliant with present and future regulations. In the case of the decentralized wild west example above, that group could also benefit from a group of passionate professionals that can provide some guide posts to all the teams. The thing that is missing from many of these types of cohorts is the actual authority to make decisions and perpetuate those decisions across teams. Creating a cohort of testers without any authority to make decisions and guide those testing practices throughout the organization will devolve into a monthly meeting without any real purpose or action. The organization should be able to look to these skill-specific cohorts to guide the organization, to make decisions, and to be accountable to the cost and quality of products. When teams need changes to their tech stack or additional tools, it should be the cohorts they turn to.  

   I hope to have at least given you something to consider when diving into the centralize vs decentralize topic. If you have cohorts in place at your organization but they aren't giving you the benefits described above, let us help you rethink and relaunch an effective group! If you don't have anything like that in place we can help you figure out the right mix of folks, provide guidance, and facilitate the launch of a more effective cohort. 

Steph Weisenbach

Steph has served teams in a variety of roles but the journey all started with accidentally becoming a Scrum Master. Learning the SM role was just the beginning of sparking a passion for finding a better way of working and bringing joy into the workplace.

Other posts you might be interested in