5 Reasons Why Support Ops and Support Delivery Are Not Playing Well Together

Continuing our 5 Reasons series, this month we tackle the frustrating lack of  alignment between the Ops team and the delivery team.

I’m a firm believer that all support organizations beyond a certain size must have an Ops team dedicated to planning for new releases, new tools, and new processes, as well as looking after metrics, training, and budgeting. Sadly, I often see the interests of the Ops team and the delivery team diverge, with the delivery team starting various grassroots efforts to supplement or even supplant the initiatives driven by the Ops team, with plenty of animosity and competition between the two camps. What a waste!

Here are 5 root causes for why your Ops team and delivery team may not be aligned, and suggestions for working around them.

1. The Ops team does not understand the reality of the delivery team 

Many Ops teams are started by assigning a couple of delivery veterans to work on planning and projects full time. All is well for a while, since these individuals have an excellent understanding of the delivery environment and retain good relationships with their colleagues. But over time, as new hires join the Ops team from the outside, and the delivery environment evolves because of product and customer changes, the Ops team members lose their understanding of how the delivery team functions day to day and may lose their edge and the trust of the delivery team.

While we want the Ops team to focus on what could be rather than what is, context is important. I recommend having each member of the Ops team spend a few hours at least once a year observing delivery team members doing their work, ideally in various locales. Get them as close to reality (that is, cases and customers) as possible.

Lesson: Create observation opportunities for Ops team members.

2. Initiatives flow from headquarters

Does every support initiative originate in the Ops team? No wonder you’re seeing pushback and full-fledged rebellions from the delivery team. It’s even worse if the entire Ops team is located at headquarters while the delivery team is geographically dispersed.

You must establish a true partnership between the two teams and specifically invite the delivery team to suggest initiatives, not just participate in initiatives dreamed up by the Ops team. And make that a worldwide effort: too often, my (US-based) customers seem to function in a way that ignores the special concerns and requirements of non-US locations.

Lesson: Set up a solid governance mechanism for the Ops team.

3. Initiatives are planned without thinking about change management

It can seem absolutely obvious that the delivery team needs to switch to swarming, or KCS, or to a chatbot–obvious to the Ops team that is, or obvious to the leaders in the delivery team, but not to the individual contributors, and the individual contributors are the ones who will make or break your next initiative.

Too often, initiatives are rolled out under a mandate philosophy and only after they fail do we create a mitigation plan. This is backwards! Working closely with delivery leaders around the world, the Ops team needs to anticipate what will be difficult or controversial about each project and give managers tools to ensure a smooth rollout. Actually, the Ops team must never work alone on any project. Having a support engineer or manager on each project team keeps it real.

Lesson: Always anticipate and plan for handling pushback.

4. The delivery team is ignorant of industry trends

I find that a lot of delivery leaders are so heads-down into their customers, their escalations, and their hiring challenges that they don’t always make time to keep up to speed on industry trends. And if they do, they can become fixated on a single source of information that may become stale over time. This is particularly problematic in larger organizations with low turnover.

Meanwhile, the Ops team members, with more time on their hands and more need to keep up with trends are going to conferences and reading posts and talking to tool vendors. They come up with ideas that follow interesting trends, but the trends don’t make sense to the delivery team. The remedy is simple but I rarely see it at play: have the Ops team share easily-consumable news and updates. (Psst! You can point everyone to this website and newsletter.)

Lesson: Share the wealth of knowledge of industry trends.

5. It’s hard to find information about current initiatives

This is more of a tactical concern but could point to a deeper issue of information sharing (or rather, not sharing!). It’s not uncommon to find that various delivery teams are working on initiatives that duplicate the official, Ops team-led initiatives, or that go counter to them–but no one knows about the overlaps or contradictions! Sometimes the delivery teams are simply unaware of what the Ops team is working on and will invest resources on projects that are not needed or at odds with ongoing initiatives. It’s a waste of resources and a very good way to get everyone riled up.

Better governance (item #2, above) helps but to ensure that everyone knows about everyone else’s project, create a master list and mandate its use.

Lesson: Set up a central point to track all initiatives, whether owned by Ops or by the delivery teams.

 

What do you do to align Ops and the delivery team? Please share in the comments.

(And if you need help, we can help.)

 

0 Comments on “5 Reasons Why Support Ops and Support Delivery Are Not Playing Well Together