How-to: Handle job candidates who back-out after accepting an offer

It looks like Andy had a job candidate back-out on him after they had already accepted an offer. Thought I’d do a short post on some of the learning’s we’ve had with this already, just in case anyone else is going though the same thing.

First of all… don’t feel bad, because it happens. Try not to get frustrated, and realize that it’s just a cost of doing business. Easier said than done maybe, but it’s a goal, right? Best approach is to find ways to minimize the amount of pain that results when this does happen. As an aside, I’ve had candidates shop the offer after accepting, and it’s something that is hard to eliminate… often an employer will throw money at a good employee who’s considering leaving… so just keep that in mind. That said, the vast majority of the candidates that have accepted an offer seem to come on-board, and I always have a frank conversation with them about their current employer, and the likelihood of them doing a counter-offer, reminding them that we won’t get into a bidding war.

Next, it might be worth seeking legal advice if it really bothers you. It’s been my observation that the threat of legal action is a powerful one, even if there doesn’t appear to be much that can actually be done in this arena that’s really worth doing… but your mileage and options may vary.

After that come the practical things. First of all, get your bases covered… we don’t tune up phone contracts until after the first 90-days (consider letting them expense it, if it’s a sticking point), nor do we order business cards during that time period. In fact, we don’t do a lot of things until those first 90-days have passed. We stipulate that the first 90-days are an “evaluation period” when brining someone on, and that they’ll receive some type of review at the end of that time period. Other stuff we limit or otherwise restrict during that time period... Domain Admin access on client systems is restricted, as is access to the premesis after hours, all server room access, unsupervised access to clients (during the first month), and a few other things more specific to our business.

Things we do…
We do order a laptop/workstation once they accept (we can always use spares).
We do tune up a network account, and phone extension.
We do conduct the various HR tasks related to on-boarding.
We do send out a new employee introduction email to our employees as well as clients
We have lunch with the new person.
We do compensate based on the prevailing market rates (who wants an employee that doesn’t stick around beyond a year?).

Otherwise, pretty much everything is negotiable and flexible - despite the above. Oh yeah, and we try real hard to not let candidates who back out on us bother us too much.

SBS: Do you forward E-Mail though SmartHosts, or use DNS for routing?

Specifically, I’m referring to the SMTP Connector in SBS 2003 (Exchange 2003). You’ll find this option in the CEICW wizard – or the SMTP connector (ESM>Connectors>SmallBusiness SMTP Connector Properties).

I prefer to use DNS, but I’ll explain more below. I think the key take away is that if you’re deploying SBS servers in client-environments, then you should really have a process in-place to ensure quality and uniformity across the environments that you support. Certainly, there are a few specific circumstances where you probably need deviate from the “standard”, but these should be the exception and not the rule.

So why use DNS? I actually think the case for why you should not use the ISP/SmartHosts is a better argument. For instance, if you’re forwarding though the ISP email originating from your organization will show that it was forwarded though the ISP in the header. Secondly, since UCE/spam also uses this method, it increases the likelihood of the mail not being delivered, and some domains refuse to accept mail that has been passed though a mail forwarder. There are more reasons too… maybe your ISP gets added to a RBL – and suddenly you’re blocked by extension.

In any case – I prefer to use DNS. What’s more, our SBS deployment process is to specify DNS. What’s your process look like?

Business: The new client on-boarding process

To follow-up on my last post, one of the learning opportunities that came out of the DST effort was in our client on-boarding process. For the uninitiated, client on-boarding is just what it sounds like… the process that we follow when we add a new client. So how is this connected to daylight saving time?

Competing priorities.

For us the two most common ways that we engage a new client is through project work, or in some type business-down situation. As much as I wish that new clients all came on with clean, working systems, fully patched, using our supported application-stack… we all know that's just not how it works. What we did have though just prior to the DST change, was a CPA firm that brought us on to handle support issues and get them though tax season, as well as to do a network assessment and make recommendations to better prepare them for next year.

At the point that we brought this client on, we were running at about 125% utilization. Utilization is one of the metrics that we use to help measure our staffing/loading, and 125% is pretty high. As individuals maybe you and I can each do 150% for weeks on end, but as an organization, you can't expect to max out all of your people for an extended period of time without developing quality issues.

Getting back to the process – the client came on-board just days prior to the DST change. As a result, there wasn't enough time to schedule a proper network assessment. The on-site Engineer did a spot-check of their system to hit the highlights and... they were way out of date. The servers were all running 2003 (no SP), Exchange 2003 (no SP), no patch-management tools, out-of-date antivirus software... the list goes on. With DST approaching, we met with the client and highlighted the DST risks, and the considerable effort that would need to take place prior to the change. We then started working though the punch-list to get them covered for the DST change. Complicating this was the fact that the this is their busy season as April 15^th approaches, so treading lightly while still accomplishing everything was a key deliverable.

End result?

We were successful. Everything was patched, and functioning prior to the deadline. However, this success came a cost. From an internal perspective we were busy re-prioritizing tasks, shuffling resources, and generally making life difficult for ourselves. As a result, it has became apparent that we need a more effective client-on-boarding process. Not only should this process better address some obvious deficiencies – the hand-off from sales, technical account ownership, and network assessment projects, but also incorporate our metrics into the process. For instance, does our utilization rate, effectiveness rating, pipeline, and profitability in existing verticals support adding this client? Does this vertical present any business-specific risks? Or In other words, does this client fit our business model, and if so, can we effectively bring them on without risking current clients?