To ship high-quality software that actually meets users’ needs, teams across a company must work together toward a shared goal. Unfortunately, I’ve worked at far too many companies where one or more teams spent more time protecting their own silo than delivering software.
One example that still stands out happened when I worked at a company in San Diego, California. Several teams operated this way, but the most difficult was the database team. Our team didn’t have a DBA, so we repeatedly asked for help. To this day, I can’t recall a single instance where they meaningfully supported us. After about two and a half years of constant requests and delays, my department finally approved hiring a dedicated DBA/data analyst for our team. The difference was immediate—and it turned out to be one of the best decisions we ever made.
More recently, I experienced this problem again while working on a contract—this time with nearly every team. The worst offender was the DevOps team. There was one individual who made even the simplest request painful. Every time we needed help, he demanded a written justification. After we provided it, he asked for more detail. Then more detail. This cycle repeated endlessly.
Getting anything from him either took an absurd amount of time—or we found a way around him. A perfect example: we begged for over two and a half years to get access to the AWS console so we could prototype and test microservices. The only access we were granted was read-only, which made real development impossible. I architected multiple microservices for that team, yet when I left the contract, not a single one had made it into production.
This wasn’t a technology problem. It was a people and process problem.
That one person—and the silo he fiercely protected—was a major reason why everything on that contract took five times longer (or more) than it should have. When teams prioritize guarding their territory instead of working toward a common goal, progress grinds to a halt, morale suffers, and the business pays the price.
Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks
Make a one-time donation
Make a monthly donation
Make a yearly donation
Choose an amount
Or enter a custom amount
Your contribution is appreciated.
Your contribution is appreciated.
Your contribution is appreciated.
DonateDonate monthlyDonate yearlyIf you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave
© The information in this article is copywritten and cannot be preproduced in any way without express permission from David McCarter.
Discover more from dotNetTips.com
Subscribe to get the latest posts sent to your email.
dotNetTips.com 
This is why Scrum focuses on fully-cross-functional teams. Re-organize so that the team has all of the skills (usually “T-shaped”) to deliver the software they are responsible for.