At Echo 5, we’ve gone back and forth philosophically between working remotely and onsite for clients. Our international and out-of-state clients obviously rarely ask for physical meetings, but we get a lot of clients in Atlanta looking for web developers to meet face to face. Perhaps more surprisingly just as many clients in Atlanta that want remote web development and have no interest in meeting.
Both remote work and onsite work have distinct benefits, but which is better? Let’s take a look at it from the the web developer and client end.
Bonding and relationships
There’s no doubt here that onsite work wins when you’re trying to build a relationship with someone. You just can’t quite build that same connection with someone when you’re talking over email or phone calls.
Skype, Google Hangouts, and Slack all help ease the burden a bit. At the very least you can put a face to who you’re speaking with and know that they’re “real.” This will never replace meeting a developer in person, but it certainly helps.
The major downside from the developer’s point of view is that if the client’s company starts making cutbacks, the remote web developer will always be the first to go.
But to the client this actually may be a benefit. If the developer isn’t doing a great job, it’s pretty easy to cut them from the team. It takes the emotion out of making what should be a logical decision.
Time zones and scheduling
Depending on where you and your web developers are, time zones and scheduling phone calls can get tricky. If you’re in Atlanta and hiring web developers in Atlanta, this usually isn’t much of an issue as you’re both on Eastern Standard Time. But if you hire developers in India or China in very different time zones, scheduling calls can be tricky.
I don’t see this as a huge issue if you do want to hire developers remotely and here’s why:
- The largest time zone difference is 12 hours
- If you’re located at the exact opposite sides of the planet this means a client’s 8AM is the developer’s 8PM
- There’s still at least 4 business hours on the client’s end that can be used for any discussion
The above has 2 caveats. The first is that you have to find a developer that is flexible. This doesn’t mean that your web developer should be at your beck and call 24/7. But it does mean that if you ask to discuss something given a reasonable amount of time you should be able to schedule a call without any issue.
The second caveat is that you “only” have 4 hours to discuss your web application or web project. I quote “only” because if you need more than 4 hours of chatting time, something is seriously wrong with your workflow (more on that below).
Development and productivity
Studies and surveys consistently show that remote workers and web developers are more productive than onsite workers.
According to the survey, 91% of remote workers believe they “get more work done when working remotely,” compared to only 9% who feel they don’t.
That same benefit we discussed earlier of getting chummy with your office mates is the same downfall of working in a shared space. Anyone can approach you at any time. While some feel this is a perk since they can share new ideas with you immediately, believe me when I say that it is not a benefit.
Most web developers will tell you that there is a certain “zone” they get into when they’re coding productively. Sure, I can idly chat while doing some low-level CSS work, but if I’m writing a controller in Ruby on Rails, please do not interrupt me.
This zone is not some weird phenomenon, it’s a real scientific thing. It has to do with our ability to hold pieces of information in our short-term memory while we’re working on something. When you’re doing higher-level programming, you’re actively holding onto a number of variables and functions in your head to complete the task. When someone interrupts your though process, you have to go back and regather all the information you had used to get to that point.
Water cooler chat is great. Well it’s great if you’re getting paid to do it and not so great if you’re the person paying your employees to sit around gossiping. There’s always some level of small talk that has to be done, no matter how task-oriented you may be. It would be socially awkward not to try and engage with someone in front of you.
What I love about a phone call or Skype meeting is that people don’t feel the need to do this. Sure there’s a quick “How’s your day going?” But then we jump right into the work that needs to be done. Everyone respects each other’s time and work gets done.
Commuting is a pain. Whether it’s daily or just for an initial meet and greet. If you’re driving to meet a client in Atlanta, you’re talking about at least 2 hours out of your day back and forth. Who’s paying for those hours? Does it come out of the developer’s pocket or the client’s?
Cost of web development
The cost of a good web developer should be the same whether they are onsite or working remotely. Arguably more if they’re a great remote web developer since they are more productive. The point is that payment should be paid for work produced.
If Web Developer A works remotely and produces a module in 6 hours and Web Developer B works in the office and produces the same exact module and code quality in 6 hours, they should be paid the same. But if that’s the case, Web Developer B might be taking an extra 2 hours extra in his day to commute, especially in Atlanta traffic. Who pays for these hours?
It doesn’t matter which side of the argument you’re on, both sides lose in this situation. If the developer is supposed to suck it up as the “cost of doing business” then you’re devaluing the developer’s time and his or her work will follow suit. If you’re a client paying for an onsite developer, you’re wasting hours and sacrificing productivity; not to mention that Web Developer B will almost definitely not produce in the same time as he or she may lose productivity from distractions.
The cost of onsite development work is more expensive. This applies to meetings, commuting to work onsite, and pretty much anything else that forces a developer to stop developing.
This doesn’t mean you should start hiring cheap offshore developers! Remote work should still remain high quality work. Hiring cheap developers will cost you sooner or later, trust me. Going offshore is still okay, but this doesn’t mean hiring a less qualified candidate or someone you have a difficult time speaking with.
What about initial meetings?
If I could go back in time and tell my earlier self something it would be this- “Stop driving to meet potential clients. (And don’t forget to buy Apple and Chipotle stock.)” Why? The majority of people that wanted to meet either
1. Did not have an appropriate budget for the project or were comparing bids across multiple companies to get the cheapest.
2. Were needy clients and needed something I couldn’t provide them on an emotional level.
Look- I’ll be your friend if that’s what you need, but I’ll do it after work hours. But if you want me or my team to drive across town during work hours and spend half our day prepping for a project you may or may not do, you may not be our client. Most real development teams will probably share this sentiment.
Why we work remotely
If it’s not ridiculously clear by now, I favor remote work. This doesn’t mean outsourcing to other countries or pulling together a ragtag group of web developers for your new web application. It means getting things done efficiently.
Our best clients have all worked with us remotely and we’ve definitely done our best work remotely. Clients come to us and know what they want and we provide exactly that.
How to fix remote working issues
This probably deserves a detailed article of its own, but there are some obvious issues that come with developers working remotely.
You have to find someone you can understand. Misunderstandings can be extremely costly. Even if you’re both native English speakers, it’s good to use visual guides and learn how to effectively communicate problems. Between screen sharing and the massive amount of tools at your disposal, this is not a hard problem to fix.
Scheduling phone calls and weekly meeting recaps may be good for larger projects. Having scheduled times to talk helps web projects move more smoothly.
Make sure your web developers have some level of project management. Organization is crucial for larger projects. If you’re a mid to large size company, it may be worthwhile to ask your developer to integrate with your workflow.
We moved from Trello to Asana and I’d say our communication on project issues is better there than in-person. Notes and files are attached to tasks and client notes are added in so that everyone is clued into the know. We can effectively prioritize day to day tasks in-house and seamlessly integrate this with an Agile workflow for larger projects.
What do you think? What has been your experience working with remote web developers?