Once again, I have been inspired by an online conversation with a friend (oddly enough, same friend) and also by some of the conversations we have been having within my own org.
True, these folks are often (not always!) earlier in their career, and may not have the specialized expertise of an engineer, architect, developer, administrator or what have you. Certainly they aren’t as well paid. But I have been in charge of these functions throughout my career, and I have some news for some of these skilled and talented folks: they’re sleeping on real value. And those people you’re treating poorly have the potential to be your future colleagues (maybe they used to be you), so stop with the positional classism.
A higher ed colleague (and forgive me, I don’t recall exactly who), in a conversation about just this topic. She said “they’re the only ones who see it all” and it’s true.
It doesn’t matter if you support a product and a customer base, or you are support for your org or enterprise. Someone designs products/systems/services, someone builds and implements said products/systems/services and a support team becomes the first point of contact for these. Unless your org has a dedicated support team for each and every different component in the environment (rarely if ever), you have a team that sees not only one product, but several (or all) and how they interact or fit together.
What does your support team know that your engineers, architects, and designers don’t?
- What *really* works and what doesn’t
- Where “as designed” isn’t usable or useful
- What features and functions are discoverable and which are hard to find
- Where people using and administering these solutions run into trouble – points of friction
- Where solutions that are supposed to be consistent with one another…aren’t.
- What’s missing
- The myriad of ways to break everything
- Any accessibility holes
- Ways in which different components fail to correctly or smoothly integrate
- So much nuanced information you will never think to ask
- What the entire environment experience looks like from end to end
Chances are good that the support folks received different or less training than the client and is having to figure things out and try to meet the need. They may have documentation, but no documentation can reflect every possible thing a client will do with a system. They’ve had to figure things out…and without the ability other groups may have to specialize or look under the hood.
A few orgs have a formal or smooth informal process for integrating support feedback, but it’s not common.
The Challenge
Because most support teams live in a responsive frame, they don’t always know how to provide feedback in a way that fits into an improvement process. A tech can tell you a lot about a specific issue, incident, or set of circumstances, but typically if an engineering team were to ask how they make something better, they are going to get very granular, top of mind issues. There may need to be a fair amount of digging just to find out that the support desk wrote an internal memo months ago on a workaround for the most common issue, and solves it so routinely they don’t even consider raising it any more.
Interestingly, this immediate, responsive frame can sometimes keep an otherwise good technologist with potential from being successful at a broader or more project oriented role.
So what do we do?
- Build trending skills in team and service leadership
- Normalize involving support in project planning and design conversations
- Have specialized staff periodically observe or participate in support shifts or rotate serving as SMEs in active support chats/channels
“But no one has time for this!” Ok, I hear you. I have never worked anywhere properly resourced and these efforts can be expensive in time.
My question is whether you have time not to do it. And. Is there any better way to assure that support staff are prepared to be project participants and be ready to think critically when the time comes than giving them a more wholistic viewpoint where they can observe these processes?
I know with my support folks, being caught up in responsiveness and unable to operate as a representative member of a project team or feedback loop is a real problem and one we are using some of these thoughts to work our way out of. Watching people’s minds unfurl is amazing.
Your support team likely has some things to tell you. They also likely have some hidden gems that would be fantastic in other parts of your org over time. You’re not going to find them if the only place you look is down your nose.