Beating the Talent Crunch with a Distributed Team
hkarthik.me
hkarthik.me
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.
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.
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!
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.
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.
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.
1. http://webcache.googleusercontent.com/search?q=cache:http://...
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.
Also, according to http://support.google.com/plus/bin/static.py?hl=en&topic... "There's a 90 minute check-in to make sure you're still there."
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.
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.
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.
If you want to hire interns, you really need to get some office space and pair them with experienced devs.
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?
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.
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.
If skype had threaded chat conversations, it would be much more manageable. Until then, I miss gmail... :)
Use the right tool for the job.
This setup works for us and has been going on for almost 2 years now.
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.
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
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.
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.
Because that makes about as much business sense.
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.
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.
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.
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.
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.
(But maybe I'm crazy)