As the owner of an IT business, how would you describe your Helpdesk team? Would you call any of them a bulldog engineer? They could be all of the these things, too:
- Customer focused
Visit any IT Solution Provider or Managed Service Provider (MSP) business and you’ll find engineers that love solving problems and helping people.
As an engineer, when you solve a problem you become the hero of the hour and win the gratitude of the client.
As a former engineer myself, I speak from experience when I say that it’s a great feeling to solve a problem and help somebody. It’s that feeling that motivates us, as engineers, to offer our assistance in helping solve problems for clients again, and again, and again.
Conversely, if we come across a problem that we struggle to solve then we are reluctant to give up on it. Quitting is for losers, right? Engineers don’t want to give up on the problem until they’ve found a solution – however long that solution might take to find.
I call this mentality being a “Bulldog Engineer”.
Not quitting, not giving up, and wanting to ensure the client is satisfied is generally admired as an admirable trait. But is it a profitable one for IT businesses?
The Bulldog Engineer with a Problem in Their Grip
As an engineer, when you come across an issue that you’re unable to solve, it infuriates you. You dig deep into your internal knowledge base (sometimes known as a brain). If that comes up blank, you look to see if others have experienced the same problem (also known as “Googling the issue”).
Next, you try obvious solutions. Then you try less obvious solutions. They don’t work. You try hacks. You try kludges. They don’t work.
As an engineer, your frustration builds.
Like a bulldog, you won’t let go of the issue. You bend your will to it, focus all your attention on it, and work hard to find the solution. You won’t let it beat you.
Sure, you could ask for help from a colleague, a friend or even a fellow engineer at another IT company – but before you do that you’ll just try this one final thing which you’re pretty sure will fix it.
As I’ve written before, your IT Helpdesk might even overlook a simple solution that you’re not aware of.
Before you know it, you’ve spent hours on the problem and it’s still not fixed.
Are Bulldog Engineers Eating Your Profits?
The problem with being a bulldog engineer is, put simply, it isn’t profitable.
Nobody doubts that you’ll find the solution to the problem eventually. But will you be able to bill the client for all the time you’ve spent trying to resolve that problem? It’s unlikely you will.
For instance, think back to the last nagging issue you or an engineer worked on. You know the sort – an irritating issue that bothers the client. But not so much that they’d be willing to pay you for all the time you’ve spent actually researching and resolving it.
To look at it another way, these are the issues that if you put the question to a client “I can solve this issue for you but it’ll take 10 hours at $90/hour” and the answer will often come back, “Don’t worry, it’s not that important”.
In the Managed Service industry where clients don’t pay per problem but pay an all-inclusive, flat fee per month, the “Bulldog Engineer” can cause chaos. Spending hours on a niggling problem might make the engineer feel good, but it wipes out any profit in the contract instantly.
For instance, I once had an engineer spend 20 hours fixing a Windows Mobile issue (yes, I’m showing my age here…) for a client. The engineer was pleased, and the client was satisfied – but when I pointed out to the engineer that the client was now unprofitable to the business as a result of their “bulldog” efforts – the reality finally sank in. We need to help our clients, but we need to do so in a sustainable and profitable way.
Making Sure Your Engineers do Work Profitably
If an engineer works on a ticket for 30 minutes without closing it, then insist that they MUST speak to a manager or colleague before proceeding any further.
With fresh eyes on the issue, the manager or colleague can often suggest a course of action (or indeed, a solution) that the engineer may not have thought of – preventing the engineer from becoming the bulldog chewing on the problem.
You might create a policy that if an engineer works on a ticket for 1 hour then, where possible, they MUST escalate the issue to a Vendor Technical Support team. I’m always surprised at the number of IT companies who don’t make use of the expert, free technical support that vendors offer them on products and solutions, instead preferring to wade through Google or online knowledgebase articles.
How to Deal with Pushback From Engineers
Your engineers might push back against these new policies. Remember that they love the feeling of fixing an issue on their own. They love being the hero.
But being the hero often isn’t profitable.
Share this article with them. Listen to their arguments as to why I’m wrong.
Then share with them that while they are there to serve the clients in the best possible way, if they do so in an unprofitable way, the company won’t be able to serve that client at all going forwards. Why? Because your company won’t be in business anymore.
Do they want to help clients in the short-term, or the long-term?
The “Bulldog engineer” is a common trait in helpdesks and Support engineers throughout the IT industry. It’s a trait that is to be admired.
But left unchecked, that tenaciousness can sap the resources and profitability from an IT company – leading to many problems.
Ensure that your bulldog engineers work as a team rather than individually. When they understand the benefits of resolving problems efficiently you’ll watch your MSP profits grow as a result.
Were you aware of bulldog engineers? Does your company discourage Bulldog engineering, or do you think it’s a positive trait rather than a negative one?
I’m interested in your thoughts. Please leave a comment below or get in touch.
You Might Also be Interested in
- Five Questions to Ask When Choosing an IT Support Provider
- How to Create a Vendor Technical Support Process
- Podcast: How to Outsource Your NOC, SOC and Helpdesk