Shared Operations Teams

Since my personal subscription to the Agile Manifesto, and through attending Agile Maine conferences, and reading the plethora of articles in recent years on the newer trends in the support of our applications, I have been greatly encouraged. For it is all in support of the Customer. Two years ago I attended the Agile Maine Conference, and one session I attended, entitled “Agile Beyond Technology,” really inspired me to want to do more to help our customers succeed. The mission statement of that company – Vistaprint – was “To create and enable a customized and exceptional employee experience that inspires and supports our teams to deliver their best work for the customers.” What’s to argue here?  The hard part is becoming that team.

The Vistaprint presenters noted that the agency model was “This is how it’s always been done.” Though structure should not be an impediment to flow of value, we’re oftentimes constrained by structure—how things are: the policies, SOPs, etc., which create delays. In the movie “Babe” there is a segment called “The Way Things Are.” If you haven’t seen the movie, just know that “bad things happen to good pigs” in that part of the story. And later, in the barnyard, the cow tells the pig that in order to be happy with the status quo, we need “...to accept that the way things are the way things are.” The malcontent duck quickly shoots back: “’The way things are’ stinks!”

It is common knowledge that many of our IT organizations have become structured in such a way as to create bottlenecks.  This is how IT matured in the aughties (2000 – 2009).  We hired skilled people with deep expertise in specific areas, and that’s good. But they had very few skills in other areas. And so the organization’s architecture grew to become siloed and application support slowed down.  Due to this, we have come to experience push-back from customers who are dissatisfied, for instance, with bulky ticketing systems which cause long wait times in the support of applications.   From a customer perspective, such activities do not directly add value.  End users just know that they are poorly served. The bureaucracy created by the role-preservation of a siloed structure engenders gatekeepers who are insensitive to downstream impacts.  They come to have no skin in the game. The only solution I can see for this is to dissemble such organizational boundaries and bring the “disconnected” teams closer to the problems, that they see and feel the pain of the end users.

It has been the “word” in the industry for years now, but it always bears repeating: In order to become more Lean and Agile, we need to transform our organizations into cross-functional teams. Such teams would include professionals with deep knowledge in one area, yet also possess a broad knowledge of general IT architecture and architectural principles and policies. This requires individuals who are Systems thinkers – those who understand all the working parts of the application(s) they support and how it all works, soup to nuts. It is plain to see (for me), on a practical level, that this would help to eliminate role-specific individuals from throwing issues “over the wall.” And such high performing, emotionally intelligent teams, teams with autonomy, will also always be forward looking, looking at the industry and trends, and keeping an eye out for the red flags of potential issues and possible branching chains of unintended consequences. The challenge is in the “how” – how to become that self-organizing “Shared Operations Team” which can provide quick and continuous delivery and top-level support.

Our applications and systems are complex; they are often black boxes for the businesses we support.  The customers often don’t care about “how things work” though; they just want their apps to work, to be rich, responsive and reliable.  And the more we can do to break down internal IT barriers by building these shared teams, per product area, across all environments, the more we will be able to shorten our feedback loops and eliminate wasteful work which creates delays. The result, at the end of the day, will be that we will have more satisfied business admins and end users because we will have helped them to succeed in serving their own customers.