Consulting is not for everyone. One of our new hires lasted just one day before saying the consulting environment was too intimidating and intense. Those who can’t hack the rigors of supporting numerous clients, multiple budgets, and competing demands simultaneously often go corporate. That’s fine. But those who commit to consulting must be able to get the job done. There’s no honeymoon period in consulting.
Unlike corporate environments, where new projects may consume weeks of planning, months of preparation, and a quarter for testing, IT consultants often must spec a project, budget the numbers, get it sold, deploy it, and make it work within a week or two. This is a lot to ask of in-house engineers, who must constantly shift gears, get up to speed on new networks, respond to crises in the middle of another project, and still complete billing and professional development tasks.
When a consultant falls behind or fails, though, it hurts everyone in the firm; it hurts clients who don’t receive the service they require; it hurts other engineers who must break away from their projects to assist the coworker or fix issues the first engineer couldn’t repair; and it hurts the owner and profit-sharing employees by reducing revenue.
Performance red flags
Do the firm a favor, and spare the consultant additional difficulty by meeting for a private one-on-one conversation when any of the following occur:
- Clients complain. If clients complain about an engineer’s service, it likely means other customers are unhappy too but haven’t taken the time to let you know. Client complaints are an absolute sign you have a bad fit. Keep in mind that it’s not always the engineer’s fault, though; sometimes personalities might not match well. If multiple clients complain, it’s a sign the engineer is struggling. Find out why, and then develop a performance improvement plan to correct those issues.
- Trouble tickets take too long to close. If tickets are remaining open too long in an engineer’s queue, it’s a sign the employee is struggling technologically. It’s also possible you’re assigning all the walk-into-the-propellers, DEFCON 1 calls to the same staff member. Make sure that’s not the case. If it proves that run-of-the-mill calls are taking an engineer too long to close, figure out whether it’s an organizational issue (the engineer may simply be forgetting to close tickets) or a skills gap (maybe the technician is struggling with all the Cisco projects you’re assigning), and then come up with steps to close the gap.
- Issues are not properly resolved. If other technicians must repeatedly revisit another engineer’s work, it means the engineer is either incompetent or unlucky. Consultants should resign themselves to the fact that anything that can go wrong will. Still, even if a client experiences undue ghosts in the machine, it should not be necessary to revisit closed trouble tickets or resolved issues for any engineer except for a couple times a year, at most. If a consultant’s work must be regularly revisited, dig deeper to discover why trouble is arising. A consultant may require classroom training to get up to speed on a new platform, or sometimes a fundamentals refresher can pay dividends, too.
- On-site time doesn’t match billed time. If a consultant is billing only a fraction of the time spent on client sites, it’s usually an indication the consultant is taking too long to isolate issues, troubleshoot problems, return systems to proper operation, or complete new projects. Work with the consultant to learn whether traffic has been particularly bad that week (which often explains such scheduling/billing disparities) or whether some other issue is at play.
Tough conversations in a nutshell
No one enjoys potentially difficult conversations, but you owe it to the engineer who is struggling, as well as the firm and other staffers, to ensure everyone pulls their weight. By watching for these warning signs, you can help nip common performance issues in their infancy.