My old man reads my blog. He is an old B2C guy and he hates that I use the term dream client instead of prospect. And now he doesn’t trust your sales engineer. He writes:
“When passing the client off to the ‘engineer,’ how do you know the client was called back in a timely manner? How do YOU check and make sure the call was handled properly. What if you call the client to check on the result and they say ‘He never called me back?’ In other words how do you inspect what you expect?”
These are important questions. There is an art to delegating.
Lots of mistakes are made through poor delegation of a task. If you want something done well you first have to take responsibility for making known what you want done and what your expected outcomes are.
When passing on a task to its rightful owner, it is your responsibility to share the outcome and any limiting parameters. Using the request for technical information from the sales engineer is a good example.
When it goes wrong, it sounds like this: “Hi Jim. I need you to make a call to Really Big Client, Incorporated and give them the technical specs on our new product. Can you take care of that for me?” This kind of delegation has too much potential for error and is full of holes so big that you could drive a truck through them.
When it goes right, it provides more details and a desired outcome. That sounds like this: “Hi Jim. I just hung up the phone with Jane at Really Big Client, Incorporated. I am trying to help her move her organization to our new product, and she needs some technical specs. You know the technical details far better than I do. Can you reach out to Jane today, provide her with the details, and answer all of her questions so that she can be confident in making the recommendation to move forward?”
This is better, as it tells the engineer who he is supposed to contact, when he is supposed to contact them, and what the outcome needs to be.
As a salesperson, we don’t want to provide the client with technical data; we want to provide the client with the information she needs to confidently recommend moving forward. Those are very different outcomes.
Also note, we didn’t tell him he had to call. It’s up to Jim to decide whether to call or to drive across town to get the outcome he needs. He is free to exercise his resourcefulness and initiative to make a difference once he knows the outcome.
Build in Follow Up
If you want to know that the outcome was obtained, build that request into your delegation. It’s also a good idea to give some direction as to what to do if the outcome can’t be obtained.
That might sound like this: “Can you call me back after you help Jane? I want to schedule our next appointment as soon as you help her with what she needs. If you can’t reach her today, can you also let me know? This is a hot opportunity, and I am trying to help them get this project on their board.”
Now, the sales engineer knows the outcome he is supposed to obtain, why you want the outcome that you want, and what he owes you in the way of follow up. He also knows to call you if he can’t get that outcome, which gives you the opportunity to take some other action should it be necessary.
A Word About Trust
Do you still need to trust your sales engineer to achieve the outcome? Absolutely! If you don’t have confidence in your team, that’s a whole different set of problems that might need to be addressed in future posts.
Generally, the less trust you have in your team, the more direction you provide (maybe even putting things in writing). The more trust you have, the less direction you have to provide.
But you must learn to trust and delegate; you still don’t scale well.
How do you delegate with the confidence that your outcomes will be achieved?
What do you do when you lack the confidence or trust in the rightful owner of a task or outcome that you need?
How do you best inspect what you expect?
How do you stay engaged with ensuring that your client gets the results that you sold and promised and still stay out of operations?