Have Your Cake and Eat It, Too: Generalists and Specialists in Desktop Support

Does your desktop support organization have more generalists or more specialists? In this article, we’ll examine and explore the differences between these roles, the inherent value of each, and approaches that can be applied to optimize an operation with either. Desktop support teams have to adapt and evolve along with the technology and workload that they support, and we’ll explore ways of doing that while maintaining efficiencies within the team. You can have your cake and eat it, too!

Begin by determining whether you have technicians or analysts on your team. Typically, technicians are more hardware-focused, while analyst are expected to have a sound understanding of the managed environments they support and the interoperability of all of the systems they encounter in those environments. Analysts triage issues toward resolution, or escalate issues to higher tiers of support. Meanwhile, technicians are becoming more of a commodity, particularly as technology becomes more complex and disruptive while hardware becomes more reliable and commoditized. Many medium to large organizations (500–1,000+) outsource this type of work, keeping analysts in-house.

Once you have an understanding of the make-up of your team, what’s next? You need to decide whether to staff your desktop support team with generalists or specialists. There are a number of factors that go into this decision:

The size of the organization: The size of the organization matters. Most smaller organizations have less complex needs and less money to spend on technology. These types of organizations either have few IT staff who wear many hats or they leverage technicians to do the sneakernet work as needed. This is a cost-effective methodology for small organizations, when deployed well. Sometimes it simply doesn’t make sense to bring in higher-level resources when there’s no apparent need.

The complexity of the organization’s support needs: Medium to large organizations typically have more complex technology environments, a higher volume of support calls, and more complex support needs. In these instances, it makes sense to leverage an internal team of generalists to support the environment. Actually, you will find that the majority of medium to large organizations leverage teams of generalists. Desktop support has operated this way for many decades because the technology shifts have never been significant enough to necessitate a reevaluation—until now!

Experience and talent availability: Availability of talent factors into the mix. The reality is that not all markets have available desktop support talent; therefore, specialization may not be an option. But organizations can overcome this obstacle by training their staff up and developing mentoring programs to support the current staff of generalists. Investment in resources is the only way you will enable your generalists to make the transition to specialists.

Workload: Workload and the complexity of the environment (and, therefore, support needs) are the most significant contributing factors in the decision to specialize. If an organization is operating correctly, desktop support typically fields the second largest volume of calls (largest, if your first and second tiers are merged). By fielding complex calls at high volume without sufficient depth of knowledge and specialization to perform root cause analysis, your resolution rates will plummet. You’ll be left with a team of ineffective, overworked analysts and a frustrated end-user base that views your team negatively.

While having a team of Jacks and Janes of All Trades is extremely useful and has served the industry well for decades, larger organizations would do well to consider developing a team of specialists while maintaining some degree of generalization.

This involves developing and leveraging subject matter experts (SMEs). In my organization, we identified the applications and systems that historically produced the most complex or highest volume of incidents. (This data should live in your ITSM tool and be easily accessible. If it isn’t, check out Cindy Smith’s “Synergy: Aligning Training, Communications, and Metrics to Optimize Knowledge Management.”) The top desktop support analysts at my organization are considered SMEs these applications and systems.

Each SME topic has a primary and secondary SME associated with it. The responsibilities of these individuals include developing knowledge base articles, working with vendors, digging into issues, serving as the primary points of knowledge for the internal team, maintaining the current information set, and performing root cause analysis. By assigning a secondary SME, we ensure that there is communication and a second set of eyes to evaluate and review the information produced by the primary SME. This also builds in redundancy, so we avoid having a single point of failure (SPOF). Every six months, the desktop support managers reevaluate the role assignments to see if any roles need to be dropped or added. Roles are then shuffled to ensure that knowledge and responsibility cycles through the team.

It’s important to note that this type of structure doesn’t excuse the entire team from being responsible for all issues; it just puts primary and secondary knowledge resources at the helm of specific issues. Generalists who act as specialists but are still generalists, if you will. Over time, everyone becomes a specialist, new issues arise, and the circle of SME continues.

Staff who don’t immediately embrace this approach can see this structure as a burden. In my experience, in time, they typically come to see the value and embrace it. Analysts should get additional credit and acknowledgment for solid work in these specific areas in their performance evaluations, creating an additional incentive—though it shouldn’t be the only incentive!

This structure definitely won’t work without a manager who believes in it and is willing to see it through. The level of effort and investment required to implement this structure is moderate to high, depending on the complexity of your environment and how easy it is to extract data from your ITSM tool. But both the effort and investment are well worth it.

This role-based structure can also be applied to standard operating procedures and other process-based functions. At my organization, we’re in the process of developing a process matter expert (PME) role.

By and large, this structure is in keeping with the HDI Desktop Support Advisory Board’s recommendation for desktop support managers to become more strategic and less tactical, delegating many of those responsibilities to their team members. By empowering your team to gain more knowledge without negatively impacting their work, you’ll have more time for high-level, analytical data mining, process building, and maintenance.

Remember, this is an approach that works in one organization—mine. It could be the right approach for other organizations. Ultimately, managers have to evaluate their data and allow the data to drive the decision-making process. The takeaway here? You can have your cake and eat it, too! You just have to put in a little effort and alter your mindset.

Prisnel Dominique is a senior IT manager at Goodwin Procter. With more than ten years of experience providing top notch IT support, starting as a help desk analyst and moving up to management, Prisnel prides himself bringing a pragmatic approach to managing his organization while still being able to take a step back and think strategically. Hard work, pride in his product, a passion for engaging people, creativity, and a commitment to service excellence have all contributed to Prisnel’s success.