There was a great discussion today on Hacker News, about experiences with remote working. I thought I'd re-post our experiences here, as my comments on the original question seem to have been well received. I've edited this a little for clarity.
Testled has seven people, all working remotely. That breaks down into three developers, one front-end developer, one designer, one salesperson, one administrator. I'm a director, but I've counted myself among the developers as that's what I spend around 60% of my day doing.
Our experience with remote working has been largely very positive.
- It keeps our overheads very low. I think that when we remove our staff wage bill, our operating expenses are about £200 a month, which is mainly service subscriptions. If we accommodated everyone in an office, we'd be looking at spending at least £3000/month on rent alone. This cash being available has meant that we can expand the company quickly, pay developers well, and still afford to take the team out to conferences and the occasional get-together and night out.
- Remote working means that your processes and working practices need to extremely well defined from the outset. All our interactions are online, so clear, unambiguous communication and good project organisation and management are essential. Of course, there is an overhead in this level of communication that might not be necessary if we were co-located, but I think that overall it benefits us.
- We are also able to expand our hiring pool. We've recently taken on a freelancer in Poland part-time (we knew him from when he lived in the UK), and we're not making adjustments to suit him; we're already well adapted.
- The tools which exist make up for a great deal of the shortcomings of remote working (we use Skype, Trello and HipChat mainly, with the occasional VNC/Skype screenshare session). This is a huge contrast to even a couple of years ago,
The disadvantages are almost entirely human factors:
- I think it's easy to 'hide' from the team if a developer is having a problem (either with their code, or their motivation). It's easy to coast through an unproductive day and there is often a delay in the other team members realising that a project is falling behind schedule. This is a problem which we're mainly trying to solve with visibility. We are considering adding a feature to our HipChat bot (which shares commit messages, Jenkins feedback etc), to just post "What are you working on" into the group chatroom once an hour. Like most problems, I think it can be solved with a bit of self-reflection and better communication.
- Sometimes working remotely can feel isolating. A few of our developers who live near to each other sometimes meet up at one location and work for a day, and I get feedback that everyone feels refreshed after. We have quarterly 'get together days', where we talk mainly about strategy and review our processes and performance, but I think we need to start having 'work together days', just to keep the morale and motivation high.
There has been a common theme at work recently; talent. This coincided with a spate of "how we hire people" posts on Hacker News, so I wanted to write about how we find people.
Testled is, at heart, a consulting firm. We dress it up with different language, but essentially our service is offering our expertise to clients. Our primary resource is knowledge ("We know how to do things!"), and we convert that into capital ("Pay us to do those things!").
Based on this model, clearly it's important for us to have and retain smart people who know how to do the things we need. Just the same as every other software company. The thing which I think we do differently to other companies is that we have never gone out to 'find' a person to fill a role; we just listen out for them, and try to be as flexible as possible when we do find them.
Our second major hire was our Creative Director. Alex had worked with us since day one in a freelance capacity, and once we found out that he was open to taking a full-time role, we modified our plans considerably to accomodate him. The same with our newest developer; we had a feeling that he wasn't happy in his current job, so we made space and found the money so we could make him an offer to join us.
There are a couple of factors which allow us to succeed with this approach; we are lucky to have a vibrant technology scene in the North West, and we're quite heavily involved with it. This brings us into contact with talented people on a regular basis, and the social side of these conferences and user groups allows us to avoid any difficultly integrating people into our team; they're usually already good friends by the time we bring someone on board.
Essentially, the key words are flexibility and visibility, and by adopting this 'talent spotting' approach, we have developed the most talented (and fastest grown) group of people that I've ever had the privilege of working with.
Leedshack 2 was brilliant.
I'm going to write a more technical teardown on the Testled blog in the next few days, but I thought I'd just blurt out some nonsense while it was still fresh in my mind.
We built Barebones, which is a minimal wireframing tool from the iPad, written using Django, a bit of HTML5 and the Dollar gesture recognition library
Our intention in the weeks running up to the event was to try to 'just hack'; that is, to aim for something technically different and interesting, rather than building a product, which is what we did at the first Leedshack, and what Pete, Bryn and I did at the Opendata Hackcamp. Not that building products it a chore, but at times before now we've spent valuable time building the dull bits (like user registration, payment/subscription systems etc.) and when time is limited that hasn't served us well. We've always 'finished' our products at hackdays, but sometimes if felt like we had created work which we just didn't need to do.
As it turned out, we built the functionality of Barebones earlier than expected (in fact, we were functionally complete by around 2am), so we did end up polishing it into a final product, but this time it didn't feel like a rush, and I'm incredibly proud of what we achieved.
There seems to have been a gradual shift recently at hackdays towards larger teams and building more 'finished' systems. I'm pleased about this, not only for the competition we find in it, but because people are launching truly amazing sites like Please Pledge, which would look at home in the portfolio of any high-end agency. I'm always amazed at what a motivated team can get done in 24 hours, but this year I was particularly impressed. If you consider that our team has a combined day rate of about £2500 (and 24 hours is around four 'working days'), and weigh that against what we would charge for comparable work in a 'day job' setting, motivation is clearly the key difference, but it's still very satisfying to know that you're presenting something which just existed in someone's head 24 hours previously.
As usual, I didn't get around to speak to enough people, but the usual fantastic crowd was there (and Kian's shrieks as he shoehorned 4GB of data into an sqlite database was particularly funny), and if anything Leedshack has made me look forward to Barcamp Blackpool even more eagerly so I can have the opportunity to talk to everyone without the distraction of hacking.
Thanks, Dom and team for organising. You're all invaluable.