Counter the support stigma by bucking the trend

Support teams are all too aware that they get less respect than development teams. To offset this, you can use the supporting role in a way that encourages rather than discourages team members, while implementing skill building at the same time.

In the world of IT, there are those who create new systems and those who support old ones. Perhaps you manage a group that does both, or perhaps you manage a group that only does one or the other. Whatever the case, no doubt you are aware of the stigma attached to those whose role is support: namely, the work is second-rate and (by implication) so are the workers.

That’s a dangerous and unfair attitude, especially in this age of turn-on-a-dime business growth, constantly changing user needs, and rapid response requirements. In an era when the smooth operation and maintenance of your company’s systems are at an all-time high, the support team is absolutely critical, and its members are vital contributors to your company’s success. But they may not feel that way, and you may need to consider several important points in cultivating a spirit of encouragement around the support role.

Hidden challenges, hidden opportunities
Support is, pound for pound, tougher than design. Support pros are basically doing a job requiring as much thought, skill, innovation, and precision as design and deployment, but doing it under much more difficult circumstances. The budget for this function is more likely to shrink than grow; running over schedule doesn’t just annoy executives, it affects production; and support pros receive far less patience from the end user for any mistake than for an error of the same magnitude occurring in a design program.

But while it’s easy to look at design and think of it as art, consider that the artist who successfully duplicates a famous masterpiece has likewise created a work of art. The skill required to flawlessly copy an existing work of art is still profound.

The often-missed opportunity in support is progressive maintenance. When revising or fixing an existing system, there is often an opportunity to improve on it, to infuse elegance into the design, to shore up the system’s robustness, to increase its internal efficiency, to make it more user-friendly.

Creating this mindset within your group, or among the individuals who routinely do system support, is largely a question of convincing them that there is art to be found in this practice. It’s not something that can be easily instilled in those who feel their role is less important or less appreciated than that of their designer peers. But you can get the idea across if you make it policy, and keep driving it home. When assigning any maintenance task, sit down with these team members and put forth the problem with the question, “As long as we’re in this system, how can we use this fix or change as an opportunity to make it better?”

Simplify, simplify, simplify!

There are a number of ways to answer this, and they depend on your particular agenda and circumstances. But one response that will almost always give you a good result in progressive maintenance is to ask, how may this be simplified? Put this question to your support personnel at every opportunity when handing out support and maintenance projects. You can do your team and your users no better favor. Consider that internal simplification of a system almost always increases efficiency and maintainability, and interface simplification is almost always a big win with the end user. Often, when digging into a system to fix bugs or add features, the opportunity to simplify will present itself to programmers who have been primed to watch for it.

Can it really be that simple? Take a moment and recall ordering products on two years ago. You waded through five pages, maybe six? Today the same ordering process takes you through a couple of pages at most. Aren’t you a much happier user as a result? Imagine what your company’s systems would come to look like after several months of this applied simplification.

The up side of support’s reputation
The perception of day-to-day tech support as low quality is so universal that it is now the fodder of TV sitcoms. Understandably, being the butt of TV jokes will filter through to your team’s support people and affect their morale. Propping up high-traffic, high-volume systems is a thankless task at best, but it is made all the more onerous by the fact that your team is expected to perform poorly, and the users are predisposed to despise them for it. There’s no sense bemoaning this reality, because it isn’t going away anytime soon. It’s a stigma that constantly intrudes, like pet hair on the living room furniture. You can’t blame your people for resenting it, and wanting to move to other assignments because of it.

But there’s an up side. What becomes of the support team that not only doesn’t bemoan the role, but also embraces it, and gives the end user the same enthusiastic and value-added turnaround that the design team does?

You can answer this question yourself. In your professional and personal life, what do you do when you find a support person who not only gives you good service, but also does so cheerfully, going the extra mile? How do you feel about the mechanic who does terrific work on your car for reasonable prices, or the techie that not only talked your kid through a tricky software installation but also followed up with an e-mail? You feel like you’ve discovered a wonderful secret. You give them all your business. You can’t wait to tell others about them, and you eventually extend to them all the patience and goodwill you can, in exchange for the high quality.

Value-added support and positive word-of-mouth
Returning a system to your users, not only modified to order, but better than you found it, and doing so with pride, will earn you and your support people a reputation that will effectively counter the negative stereotype that goes with the task. But that desirable outcome does more than generate good word-of-mouth and much-needed “atta boys”: Charting such a course will make your people better analysts and better programmers and more effective in every way. Whether they eventually move into original design roles or not, they’ll be more productive, and—more importantly—happier in their work.

About Scott Robinson

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

Editor's Picks

Free Newsletters, In your Inbox