Dealing With Rogue Support Agents

What To Do When Forward Deployed IT Support Agents Go Rogue Or Will Not Play Many organizations with remote or branch support staff face a common and perplexing challenge. Faced with the very real need to provide onsite support, local IT talent is hired to work at distributed business unit locations. These onsite support staff typically act in the capacity of desktop support agents, application developers or service desk agents and assist with the deployment of new services and technologies to the further reach to the organization they serve. However, while they are dispersed over the geographical span of the organization they are in principle the remote arms of a distributed enterprise IT function. The challenge faced by most organizations is that placing these helpful folks out on the range, so to speak, typically results in a double edged sword. In one sense they provide that necessary onsite IT presence that is required by the branch or distributed business unit. However, being geographically removed from the structures, values and norms of the corporate IT function they perceive themselves as less bound by the centralized dictates and more sympathetic to the pressures and personalities of their local environment. This perception is strengthened or mitigated depending on who is paying their salary. The following list represents different scenarios of reporting lines for these remote staff in a descending order of perceived accountability to follow a corporate policy or process.

  1. Remote staff are managed and paid by a centralized IT function, they are measured and rewarded on how well they follow enterprise policy and process as well as their response to localized requirements.

  2. Remote staff are managed and paid by a centralized or corporate IT function, they are measured and rewarded on how well they respond to localized requirements. They have a dotted line accountability to a local business manager.

  3. Remote staff are hired by the central IT function but are managed, measured and paid by a local business unit manager. They have a dotted line of accountability to the IT manager within the corporate or centralized function.

  4. Remote IT staff are hired, managed, measured and paid by a local business manager. They have a dotted line of accountability to an IT manager or process owner within the corporate or centralized function.

  5. Remote IT staff are hired, managed, measured and paid by a local business manager. There is no allegiance other than good will or verbal agreements to the management functions of a centralized IT organization.

  6. Remote IT staff are hired, managed, measured and paid by a local business manager and there is little to no knowledge of their existence and the technologies they use (shadow IT functions or service desks are typically established due to a belief that the needs of the remote organization are not being met by the centralized IT function and its processes).

Depending on what model you are employing you will find more or less success in gaining the cooperation of the remote IT staff or their business unit managers for that matter to adopt or comply with enterprise IT requirements. This issue obviously poses a significant challenge to organizations attempting to adopt common service management practices. The summary of these models comes down to the simple fact of “whoever pays my salary and does my performance review has my allegiance and cooperation.” The reality of the situation is that many organizations find themselves with many different levels of the list I have made above all in practice at the same time. It is my strong opinion that any scenario below option 4 is a no-win situation for achieving the successful adoption of an enterprise process and that other tactics have to be employed. The most obvious approach is to make structural and organizational changes to the hiring and management practices for remote IT staff to resemble one of the approaches higher up than the list I have noted. However, many of the readers of this article may not have the political ability to make the necessary changes so another approach may be needed. The second approach is to realize that if you cannot gain the commitment of these remote IT staff to adopt and follow common policies and processes then you have to define and treat them as customers. Any interaction with the enterprise IT processes such as Incident support, Change Management, Security, Procurement, Architecture, Consulting, etc., must enter the defined entry point for that process. For example, if the remote IT staff needs the cooperation of the Incident or Change Management process they must enter the process by calling the Service Desk as would any non-IT staff member that is not “part” of the process so that the appropriate workflow record can be logged and the correct process engaged. Of course they are going to want to by-pass this process since they know they can get their answer or aid quickly by calling their buddy in the central IT function. A quick phone call to Server Sam, Network Nancy or Darren Database and they can get instant action or information they have come to expect. The challenges with this approach are obvious and are the same ones we claim for anyone who bypasses the correct process or standard operating procedure. Typically their call is not logged for business intelligence or prioritization and an underground reactive support economy flourishes and saps the thin resources to the detriment of a kind of proactive approach to IT management. My advice is that if these roles refuse to operate within the process then they have earned the right to be its customer under the same conditions as any other customer would expect. In short, they can choose to be in or out of the process but both decisions come with consequences and activities that are different to what they are experiencing today. What you are doing is defining the rules of engagement for all customers of the process regardless of who they work for. Here are some typical scenarios for remote or forward deployed staff that resist participation in an enterprise IT policy or process.

  • Francine Frontline: Francine was interviewed by the central IT desktop support manager but hired by the branch business unit manager to provide desktop and miscellaneous IT support for the remote branch. She quickly became a hit with the branch users based on her ready smile and willingness to drop everything and drop by their cubicles. Her emotional and financial allegiance is to the branch and not to a distant corporate IT function. She has been asked repeatedly to log her Incidents in a support tool by the central service desk but she refuses to do this due to a belief that she is being paid to respond quickly to branch needs and not paid to do paperwork. This belief is shared and supported by her direct manager at the branch

  • Andrew Appdev: Andrew belongs to an application development and support group that is managed and funded by a large business unit. While Andrew spends his whole day either developing code or supporting application based Incidents he and his fellow developers do not perceive themselves as being part of IT and not connected in anyway with the infrastructure organization other than they require services to host their applications. They resent having to follow any policy or process which emanates from the corporate IT function. This perception of separation is augmented by the fact that he reports to a business unit CIO who is a peer of an Infrastructure CTO without any Executive CIO establishing enterprise IT policies and process across the entrenched technology silos.

Sound familiar? For more on this subject see the post on Service Organizations: The Service Organization Part 2 These two situations are perfect candidates to be introduced to the process as customers, until such time, that they realize that they are in-fact part of the larger IT Enterprise. Troy's Thoughts What Are Yours? “You know sometimes people tell you stories that are supposed to be something that happened to their wife's cousin's best friend, but actually probably got made up somewhere along the line. Well, it's like one of those stories, except that it actually happened, and I know it actually happened, because the person it actually happened to was me.” ~ Douglas Adams

Like this article? Like

Comments

Post a comment