The Blame Pipeline

wc_pipeline sketch

Talk to any modern IT person about shifting the landscape of how teams work and I can guarantee you that you’ll hear a bit about DevOps as well as “siloed” organizational structures. Fingers get pointed in all directions as to the real culprit behind dysfunctional architecture. Perhaps changing the silo term to something more appropriate will help organizations sort out where the real issues lie.

You Dropped A Bomb On Me

Silos, or stovepipes, are an artifact of reporting structures of days gone by. Greg Ferro (@EtherealMind) has a great piece on the evils of ITIL. In it, he talks about how the silo structure creates blame passing issues and lack of responsibility for problem determination and solving.

I think Greg is spot on here. But I also think that the love of blame extends in the other direction too. It is one thing to have the storage team telling everyone that the arrays are working so it’s not their problem. It’s another issue entirely when the CxO-level folks come down from the High Holy Boardroom to hunt for heads when something goes wrong. They aren’t looking to root out the cause of the issue. They want someone to blame.

That’s where the silo comes in. The vertical integration and focus on team disciplines means the CTO/CIO/CFOO get to find out which particular technology was responsible for the issue and blame those people. Modern IT organizations revel in blame assignment. What they want more than anything is to find out who is responsible and berate them until they feel vindicated.

Silos aren’t organizational structures. They are pipelines that allow management to find “responsible” parties and get their retribution for any problems that happen. The focus lies solely on punishing the guilty rather than correcting the problem. Which leads to people not wanting to be challenged outside of their team environment for fear that they’ll get double the blame when something goes wrong.

Trans-Organizational Pipeline

How can we fix this issue with silos and stovepipes? Think for a moment about the physical structures that we use to model them. Silos and stovepipes are all vertical. They might as well be using sewer pipes for a visual representation. After all, the crap does flow downhill.

A better model for the modern IT environment should be the horizontal pipeline. These would be more like oil transport pipelines or other precious materials. Rather than focus on storing things vertically, horizontal pipelines are all about getting raw materials to a processing facility. There isn’t time to waste along the way. Product moves from one location to the next rapidly.

That’s how teams should function. Resources should be allocated and processed. Equipment should be installed and configured. Applications should be installed and be operational. No time to waste. But who should do it? Which team gets the vote?

The reality of the world is that this kind of implementation style needs a cross-sectional horizontal team. Think about the old episodes of Mission: Impossible. The IMF didn’t pick the disguise team to infiltrate or the computer team to hack door locks. They found one or two people with the unique skills to get the job done and focused them on their task. And when the impossible mission was completed everyone went on their merry way back to real life.

In the case of IT teams, new technology products like hyperconvergence and programmable networking require the inputs of many different disciplines. Creating ad-hoc teams like the IMF can go a long way to helping stagnant IT departments rapidly embrace new technology. The rapid implementation approach leads to great things.

But what about the blame? After all, CxOs love to point fingers when things go wrong? How does a horizontal team help? The best way to treat this kind of issue is to remember that these new, smaller cross-functional teams have a much larger atomic unit than traditional silos. A CTO can blame an individual on the storage team for a failure. But in a cross-discipline team, it is the team that is responsible for success or failure. Blame, if any, resides with the team itself and not the people that comprise it. That kind of insulation helps individuals rise above the fear of committing egregious errors and instead embrace the kinds of thinking needed to make new IT happen.

Tom’s Take

The best teams don’t happen by accident. It takes effort to make a group of people across disciplines work together to make amazing things happen. The best way to make this happen is to form the team and get out of the way. No blame shifting. No segregation of skills. Just putting awesome people together and seeing what happens.

The sooner we stop putting silos around teams for ease of management the sooner we will find that people are capable of amazing feats of technology. Let’s turn those blame pipelines into something infinitely more useful.


2 thoughts on “The Blame Pipeline

  1. Pingback: Worth Reading: The blame pipeline - 'net work

  2. Pingback: The Process Will Save You | The Networking Nerd

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s