We have both in-house and remote developers at AutoRevo and while we've been successful at maintaining both, we've stumbled a bit in a few areas.
The biggest problem we have is the remote folks feel disconnected. Even with Campfire and Skype, it can still be a challenge to keep everyone connected. It's not uncommon for an in-house dev to ask a simple question to the folks around him and have that question turn into a thoughtful conversation. Sometimes, we'll think "Oh, fire up Skype and get so-and-so on the line so they can join in." But many times, we just don't even think of it.
I hadn't heard of Sococo, but it looks intriguing. Keeping an open mic with Skype was something we considered, but it seems intruding. This is an area we're still trying to get better at.
The other issue is one of team-building. Usually our in-house devs go to lunch together and grab the occasional beer after (and during!) work. There is a camaraderie there because these guys work together, eat several meals a week together and drink more than a few beers together. That just can't be replicated to a remote developer.
We've also found that some devs simply aren't disciplined enough for remote work. They love the freedom, but sometimes that freedom becomes a problem for them. We don't keep devs that have to be supervised constantly, but when they are remote it can be harder to gauge if they are just hitting a slow, unproductive period that will pass or if they are just doing as little as possible to keep a check coming in.
Distributed teams are definitely a huge bonus for a company, but there are challenges that have to be thought through up front.
We use campfire to do 90% of our conversation even with our team all in house. It helps kick off conversations, save them for later and keep everyone in the team on the same page. I think before you start hiring remote talent you need to build in that communication strategy to your core team.
Very much agree that in-person bonding, whether working side by side or having a beer, are important. If you do have a remote team- try to build in time for the whole team to be in a single office every other month at least.
We're the same. Even though the bulk of our devs are in the office, we still use campfire because it's the central hub of communication. (commit messages, CI build notices, when stories get updated in Pivotal,etc.)
And it's searching ability is very nice. Pro-Tip: Keep that searchability in mind when you discuss a candidate's interview in campfire..they might be reading it later when you hire them. Dohp!
I've actually found being in the opposite timezone can be handy. Currently I'm in the US while most of my team is in India. Often, our workflow is the following:
9AM-5PM EST: build a view.
9AM-5PM IST: view becomes nicely styled.
Similarly, I can work on a project, hand it off to my developer across the sea, and considerable progress will be made before I wake up.
Of course, this strongly depends on having people I can trust - not just any developer will do.
Can you elaborate a bit on what these projects entail? Maybe a short description and how long each project went on?
The work I do tends to require a lot of collaboration as we figure things out and experiment. Having a one day delay for every thing feels like it would slow us down A LOT.
We also use iterative development in a two week sprint, a day lost would limit our productivity tremendously.
Have you launched yet? Being in different timezones post-launch can be extremely difficult in my experience. Bugs and new code gets really hard to manage when the co-worker you need to talk to is asleep while you are working.
The site is down so if you can't read the article, see here [1].
The author is actually pointing out two distinct problems, which are both having a real impact on tech companies. The first and most difficult problem which every company faces (startup or otherwise), is finding great talent.
Every tech company is fishing in the same water trying to find devs in competitive places like S.F. or NYC. These cities certainly have the highest concentration of great developers, but there are hundreds of thousands of equally great devs scattered across the country. If your company can find a way to get the best of the best among these isolated devs (who may be in Kansas), you're ahead of the game.
The second problem he discusses is how to get startups to work well in a distributed team. As many have pointed out, using Skype can be awkward. There is also something missing from typical remote working platforms that doesn't capture the social dynamic of working in the same office.
I'mworking to solve both of these problems. Right now, I'm looking for beta testers before I launch. If you're interested and willing to give feedback, shoot me an email.
I'm surprised no one has mentioned a great technical solution for this: Hangouts (disclaimer: I work for Google).
Other posters are correct in that there is friction with Skype or in fact any solution that isn't always on (you could keep Skpe up of course) but I can tell you from experience that if you get in the habit of just keeping a Hangout open it gives you much of the benefit that physical proximity does.
Remote debs can keep a Hangout open on a second screen or possibly a dedicated machine. Your main dev site should just hang a monitor on the wall and hook up a Mac mini to stay always on (per room). You may need a decent mic for this.
Is there a solution whereby this common "monitor on the wall" could be logged in via some common account instead of with a particular individual's account?
Exception: always bring the interns in house. I've heard the talent crunch is bad, but I cannot imagine a remote internship being beneficial at all.
I tried working a remote internship once and it was awful. I didn't get anything done, had no idea what was going on, really a big waste of time. The first day I got to the office I fixed a bug and got the product to actually work though. The rest of my time there I did some good work.
Interns don't know what they are doing. If they did, they would be full time employees. They need to have somebody to point out some of the basics, not all!, but enough for them to actually be productive.
Eh. My first job was a remote (cross-country, even) internship when I was 16 for a 2-man bootstrapped startup that didn't have an office anyway. Since they were already setup to do most work conversations through Campfire, it worked great.
There's nothing keeping you from "pointing out the basics" via email, chat, or Skype and being available on chat if they hit walls just as you would be in person.
Sure, if you're not communicating well, maybe your full-timers can get stuff done despite that and your interns can't. But I'd say that means that having a remote intern is one of the most important things you can do from time to time. It will be a test of whether you're actually doing the distributed team thing right, instead of your team just being competent enough to work around it.
Maybe. I think there is much to be said for being able to just walk down the hall with your laptop and debug everything in person with someone who knows what they are doing. I didn't know much before that internship about software development and I learnt a ton about the whole field just watching other people. It's why I use emacs nowadays at a more than beginner level.
Again, if the intern is competent, then they aren't really an intern anymore. Just kind of a part time worker more likely to be hired in the future.
You really have to hire mostly experienced folks to make things work on a distributed team. You can hire juniors and let them pair with senior devs, but they still need to come with some previous experience.
If you want to hire interns, you really need to get some office space and pair them with experienced devs.
At my company, we like to offer great health insurance, but this can be difficult to provide if you only have a single person in another state or region.
In the US, each state (and regions within a state) have different insurance providers. All providers that I have investigated require a minimum of two people as part of their group. We are just beginning discussions with our agent on this topic, so a good solution may exist that we have not crossed.
For those of you that work distributed in the US, can you tell me a little about your health insurance (+life, dental, etc) and if it is great, average, poor or non-existent?
Anyone happen to have any advice on convincing the rest of your distributed team to use a chat room?
Our team lead has an odd aversion to using IM, which extends to distrust of any electronic messaging beyond email. However I really feel a persistent chat room would be a big help for the team.
I actually prefer a chat room over email. It's logged, with group discussion and it's asynchronous. I don't have to begin a reply and then wait for a response. I just get it out in the room and keep going.
Another thing I like about using a room is the chance to use Hubot (http://hubot.github.com/). It makes for some fun and can also be extended to actually do useful stuff.
If your team as an aversion to IM try to entice them with a room is better because it's not one to one and everyone can see and answer questions and it facilitates group discussion easily and it's asynchronous so it gets out of your way.
We've been using skype chat almost elusively for 3 years. At first, I loved the work flow, but in our case it has devolved into an email replacement for one of our team leads. He daily sends reams of chat messages into the room with the expectation of a synchronous response. Messages routinely get lost in the shuffle. I'm working to get him to use email for these sorts of issues -- status, in progress.
If skype had threaded chat conversations, it would be much more manageable. Until then, I miss gmail... :)
Skype has a pretty awful UI for chats. If you get people set up using a bouncer then it's pretty easy to get persistent conversations over IRC, and then people get to use the client of their choice. Plus it's a lot easier to automate with bots.
Skunkwork it. After all you are not forbidden to communicate with other team members using tools of your choice? If you are, then I have no advice for you.
This is an awesome article. I've been working on a distributed team and have learned some of these things in a rather painful way. Are all these lessons learned just from experience? A Hacker News type subgroup for distributed teams would be nice to have so we can share experiences learned the hard way so others don't have to. Someone please let me know such a forum exists.
I also work on a distributed team. While all my teammates are in the US I am the only one working in the Philippines. We use email, chat (yahoo messenger), skype and gotomeeting for communication. We use our internal tool to log our time every day.
This setup works for us and has been going on for almost 2 years now.
I also do some work from the Philippines when I'm there on occasion, but I'm based in the US. One problem I have is the reality of power "brownouts" in the RP interrupting bandwidth.
Good article Kar, I agree that the talent pool is drying up and I'm not sure what reasons are behind it. I wish more company's would adopt a work from home mentality as it also creates a competitive advantage to attract some of the brightest.
agreed. but you also need to be the change you want to see in the world. in a hiring role? ensure you allow remote/home-based team members. evaluating working for someone else? filter for that and demand it, else seek elsewhere. it's what I do (well, trying to do. mostly succesful so far.)
I work on a distributed team. Timezone is definitely an issue. But in a startup, folks work when they must, and get the job done.
We use Sococo Teamspace (I work for Sococo). It combines chat, audio conferencing, doc share and video conferencing. Everybody stays on all day. That means you can track what anybody is doing online, know when a meeting is starting, who's talking with whom etc.
Its not perfect, but it sure beats the isolation of working at home, checking email every 10 minutes.
I have always wondered how scaling across countries affects a company but I have never thought about a distributed founding or early-stage team. I think the intensity and sensitivity between founders would be lost in the ether. Great products require tough decisions that should lead to disagreements. Web-chat might obfuscate such tension or take the passion out of the process.
If you run a tech company and only think about hiring people locally you're crazy.
Why hire only locally when you can draw from talent anywhere in your country, in fact, anywhere in the world. Likely at a much lower cost for the same level of talent. Plus you have the advantages of your team not needing to travel.
Working together in the same office is a 20th century model of doing business, and I'm surprised that many technology companies are not open to a more distributed model.
A more important question is: What needs to be done from an office versus a distributed team?
From an office you will probably want:
Core executive team members (in a larger company, but not necessary in a small company, all team members can be distributed)
Local based sales people (if you are doing one-on-one presentations selling to local businesses)
Plus certain types of businesses do need an office
I agree with you, but in practice I've seen that even if a company wants to go distributed, they lack the knowledge on how to make the model actually work for them.
They resort to using the exact same process with more conference calls and emails. That clearly doesn't work as you miss many subtle communication queues.
More drum-beating about this illusory talent shortage, eh? I'm still waiting to see any signs at all that this shortage actually exists, aside from random "I can't find a rockstar!" anecdotes.
I think calling it a talent shortage is a mistake. It's not a talent shortage, but it is difficult to hire.
As for difficulty to hire, it seems to be driven by all kinds of things.. lots of potential-employees-turned-founders, a pretty decent splintering of tech-stacks, more companies getting more done with smaller teams (and therefore having more specific desires), and shorter term thinking in terms of velocity and exits.. making investing in longer-term talent/training less likely.. to name a few.
As someone that doesn't live in an area with lots of VC funding and investment activity, I disagree that there is no shortage.
It's always been very difficult to find talent but lately it appears to have gotten harder. It hasn't been considered a good idea to study CS for the past decade and we've only churned out about a third of the CS graduates that we did in the previous decade. Thats starting to turn around now, but it will be a while before we get caught up.
I do agree that the startup craze has reduced the talent pool, but I think thats a local phenomenon in Silicon Valley and NYC. In other areas with more traditional employment sectors, it's just not as prevalent. There are certainly some talented devs that have relocated to where the startups are (I have contemplated it myself) but I don't think it reflects the majority at all.
First off, everywhere (with respect to the talent pool) has lots of VC funding and investment activity. I can say without knowing where you live that with almost complete certainty:
1. there's more interest in ability to get companies funded there than ever before.
2. people are leaving your town to work in the bay.
That said, I was pretty lazy when I spat out a list of problems earlier. There's lots of other interesting reasons it's getting harder to find good talent... I'm just not convinced that it's because there are fewer developers (which is the only thing that would define a 'shortage' in my estimation).
If we assume that there are plenty of engineers (you know, to humor me).. then there's only two reasons that you (or I!) would have trouble hiring:
1. They don't know we exist.
2. They don't think our job is better than the one they have.
The bottom line is that both of those things have gotten WAY harder in the last, say, five years. I don't think I could do it justice ranting about why and how I think that is in an HN comment but I think there have been a lot of interesting changes in the way software developers perceive their jobs, find them, etc.. and I think the way most of us hire is lagging well behind these shifts.
It's generally all really good, though. I think during my career (since '97) we've mostly gotten away hiring developers the way you might hire accountants, or anesthesiologists. Software development is a craft, and if you look at the way artisans in other crafts work and find work, you'll see a stark difference. My guess is that paying more attention to industries like architecture, graphic design, or even tattooing is likely a window into what hiring software developers will look like five years from now.
If there is trouble finding people to hire because they are all out starting their own companies that means one or two things:
1) There is an over supply of management. Developers/engineers are able to manage themselves effectively enough that they do not need to spend their time enriching someone else.
2) Engineers are turning to their own business plans because that is the only way to get adequately compensated.
I think #2 is more likely. I believe we are seeing the start of a shift towards engineers making as much or more than the management/CEO types. Engineering bargaining power is on the rise and will only continue to get stronger.
Nah. You're assuming they're finding success doing this. Most of them aren't.
It's a relatively young trend. There's enough people getting funded, and having pretty nice exits to attract loads of developers to heavily prefer founding. Also, the heavy hiring market means that if things don't work out there's a soft landing waiting somewhere.
The truth regarding #2 is that the vast majority of these devs will make far less from these ventures than they would if they showed up at GOOG. It's cheaper than ever to start a company, seed capital is pretty easy to come by.. so why not roll the dice? That's the mentality.
Unfortunately I think all of the furor and entre-porn makes being a founder look more than a bit easier than it is. I think lots of these kids would benefit from a year or two at another startup to get some hands-on experience and mentorship, but I think as an industry we're also a bit more fascinated with youth than experience at the moment.
At any rate, I don't agree that either of your points are major contributors. #2 comes close, but being compensated for founding and running a business (and taking the risks to do so) is very different than being compensated for writing software for someone else's business.
Free market economics tells us that price is the variable that moves so that supply and demand intersect. I.e. it sounds like you are simply not paying enough.
As long as there's no decent form of vocational education, training in-house is a huge investment. You can only properly train one junior for every three to four seniors before it becomes disruptive.
Many companies that have already made the mistake of hiring too many juniors in an attempt to deal with the shortage, and have suffered the consequences (huge drops in quality and productivity, and in the worst case, seeing the experienced seniors they did have walk away frustrated).
Where education fails, major companies like Google and Facebook should take the responsibility for training juniors. Instead they spend their fortunes strip-mining the market.
As a junior developer at a major company, it sure feels like I'm receiving training. Since major companies are hiring both junior and senior developers, are you suggesting they stop hiring senior developers?
I'll believe there might be a talent shortage just as soon as one single person, who is not a colleague with whom I have a close personal rapport, approaches me either directly or through my network with an opportunity. That's what I'd expect to see, even if only occasionally, if there was really a shortage. As it stands, it looks much more like accepted hiring / job seeking practices are just grossly inefficient at matching up talent with opportunities. That's inconvenient, for both sides, but it's not the same thing as a shortage.
The biggest problem we have is the remote folks feel disconnected. Even with Campfire and Skype, it can still be a challenge to keep everyone connected. It's not uncommon for an in-house dev to ask a simple question to the folks around him and have that question turn into a thoughtful conversation. Sometimes, we'll think "Oh, fire up Skype and get so-and-so on the line so they can join in." But many times, we just don't even think of it.
I hadn't heard of Sococo, but it looks intriguing. Keeping an open mic with Skype was something we considered, but it seems intruding. This is an area we're still trying to get better at.
The other issue is one of team-building. Usually our in-house devs go to lunch together and grab the occasional beer after (and during!) work. There is a camaraderie there because these guys work together, eat several meals a week together and drink more than a few beers together. That just can't be replicated to a remote developer.
We've also found that some devs simply aren't disciplined enough for remote work. They love the freedom, but sometimes that freedom becomes a problem for them. We don't keep devs that have to be supervised constantly, but when they are remote it can be harder to gauge if they are just hitting a slow, unproductive period that will pass or if they are just doing as little as possible to keep a check coming in.
Distributed teams are definitely a huge bonus for a company, but there are challenges that have to be thought through up front.