Yesterday I started the AWOL series – a look at dealing with the phenomenon of designers or developers going AWOL right in the middle of your project.
Today I want to share with you three tips that can help you before it ever happens – and all of this can be done before you ever start the project.
Use Carrots and Sticks
I learned this trick from a friend who was working with a developer. Only this wasn't a software developer. It was a construction developer. And what my friend knew was that this developer would have several projects running at once.
My friend wanted to prioritize their project. But they also wanted to make sure it didn't stall.
So they introduced both a carrot and a stick in the initial contract. They not only specified a budget, but added a 25% bonus if the project was delivered before certain milestones.
They also put in penalties if the project delayed past certain milestones.
This was their approach to making sure things didn't slow down to a crawl – or worse – to watch their developer go AWOL.
And nothing about that approach should be off-limits to you. Now, to be clear, building a home is a rather well understood process with a well understood timeline. So don't get crazy and start putting penalties on a web project when you don't understand how they work.
But if you do it collaboratively with your developer, it's a nice way to reward the proper behavior.
Control your Domain and Hosting
I know many clients who just leave everything – from buying the domain, to arranging the hosting, to setting up email, to building a website – up to their developer.
You've just given the keys to your kingdom to someone you may have just met. Sure you trusted your gut in picking them, but how extensive a background check did you do?
This is why I regularly suggest to clients that they go register their own domain name, and they sign up for their own hosting account. That way they're the owners of their infrastructure.
And if you do that, you can even call your hosting company and get their help to create a subordinate account for your developer – one with rights, but not total and absolute control.
That way, if you notice someone is going dark, you can get to your own stuff and make decisions about what you want to do next.
I can't tell you the number of times I've heard horror stories where developers have gone AWOL and the client can't even get into their email, their hosting, or access their domain registrar to move it elsewhere.
Lastly, ask for code access throughout the project
I have a lot of friends who just decided they won't be tweeting this article out because of that tip right there. But I hope they'll hear me out.
My friends at Zeek model this out beautifully. They understand the value of transparency in the client relationship. And to that end, after a lot of qualification, preparation, and expectation management, they give source code access to their clients throughout the project.
I'm talking about direct access even to the ticketing part of their git repository. So they can see what the developers are saying / commenting. They can see the pace of the work. They can see who's engaged. And they can even see when a developer uses “salty” language in frustration about a ticket.
But like I said, they've been prepped and expectations have been managed.
The net result?
Three things come of this, I think.
- They have to teach every developer that their primarily in the customer service business – and this has awesome downstream benefits.
- Their clients never stress about developers going AWOL. After all,they have access to everything.
- If they see slower pacing and less engagement, clients can ask (or answer) questions to make sure things don't stall.
I know people hate the idea of giving up or giving access to code too early. They like to think of it as the last ransom they have in case a client doesn't pay them.
But I'll tell you this – if you treat customers with distrust, they will distrust you. If you trust them, they'll often become trustworthy.
Protecting against developers going AWOL doesn't have to be time consuming
What you've hopefully noticed from those three tips is that none of them take a huge amount of effort to make a reality.
Sure, some developers won't like it, or won't want to work in that environment (with that level of transparency). If that's the case, at least use it to spawn a great conversation about your fears and concerns. They might have an alternative approach.
But using hope as a strategy (as in, “I'm pretty sure my developer is awesome; I don't have to worry”) is a bad call. Don't do it.
Protect yourself and mitigate the big risks and you'll enjoy your project a lot more.