With ever increasing salaries in competitive markets, a lack of quality software engineering talent and office rental costs spiralling upwards, more and more businesses are considering remote members to grow their teams.
Here are some of our thoughts, suggestions and general observations 1. Access to a new, wider talent pool. Let's face it, if you are based in any major city trying to hire software engineers you are one of a thousand companies competing for the same talent. You might think you have the hottest tech stack, coolest office, best stocked beer fridge, more games than you can shake a pool cue at, but so has everyone else. Of course we all know about Facebook, Google etc and their super cool offices dotted around the globe, but even companies that you wouldn't automatically associate with being the cool kids on the block have upped their game to attract the best talent. Check out these Tech Crunch Cribs videos here One possible solution is to look further afield; whether that's within your home country or across the globe. There are plenty of amazing engineers who work remotely and they are experienced in the practices that make distributed teams work. 2. Managing remote teams One of the downsides of remote teams is the obvious physical distance between the team members. You might think in this highly connected world that this isn't an issue, but please don't underestimate the effort needed to keep everyone connected. There is a big difference between being tooled up to the max and managing effective internal communication. It's so easy for those quick 2 minute 'huddles' where everyone within earshot quickly gets involved (you know the ones) to morph into a key product decision and everyone who wasn't at the party (usually the remote guys) to be be completely oblivious until they see the end result ("oh that's nice - when did we decide that"). Clearly you can't choke spontaneous thinking (it's where some of the greatest ideas come from), but it's the team's responsibility to feed that back into the remote team members to get them involved. If they start to feel left out they will be disenfranchised and the cohesiveness of the team will be affected. You might think that since the whole team sits there from dawn till dusk with their noise cancelling ear muffler / headphones nodding along to Spotify whilst tapping away on their keyboards on hip chat or skype, that verbal communication is dead, but it's those spontaneous moments that can cause a huge rift. Daily stand ups become hugely important, those 10 minutes where everyone is away from their desk, updating the rest of the team on their progress are crucial to bonding the team and keeping everyone in the loop. Depending in team size skype is a perfectly capable tool to bring everyone in. Weekly updates - At our previous start up we tried to have an all hands every couple of weeks (my bad, this didn't always happen, will try and fix that this time around!) - we were only 15-20 people so everyone gathered round a lap top (one in London and one in Guernsey, we were co-located rather than remote). Most of the time it involved a mix of product roadmap updates and analysis on the impact (both positive and negative) of the latest big release - ie did it shift the metric we were aiming to shift (did we reduce churn, did we drive down cost per new customer, did we increase virality etc). It's important that everyone feels involved in the end results - no one wants to be a code monkey where their only involvement in the project is their next jira ticket. We also invited anyone in the team to host a session, this could be the head of UX to talk through her latest thought on the new lobby layout to the head of analytics talking about a new dashboard in Tableau. Open video channels - we didn't try this but feedback from teams we've spoken to have said this works well. It really depends on the office set up and whether your ISP is delivering the bandwidth! but just keeping skype open can make a huge difference - it doesn't mean it has to be too intrusive, but it's a constant reminder that everyones working together. Chat groups - whether it's Google hangouts, Hipchat, Skype or Slack there are so many to choose from. My advice is try and get everyone using the same tool, it's no good if half the team are using HipChat and the others are using Skype. Also, IM isn't a substitute for good old fashioned verbal chit chat. It's amazing how long you can spend on an IM discussion compared to a call. 3. Not everyone is cut out for remote work Someone described this perfectly recently - hire 'doers', they'll still need direction and guidance but ultimately you need people who just get on with it. If you are operating a flexible work schedule you can't be constantly worrying. You need to hire people you can trust to deliver. 4. Can you mix it up? Some say you need to make a call: all remote or all in the office. Personally I think you can mix it up, but you still need to make sure the remote teams all feel part of the team. As soon as you get into a situation of them and us, you're in trouble. Whichever way you do it, you should aim to get everyone together as often as practical. It might not be possible to do it all at once (last thing you want is a support call and everyone's 30,000 ft in the air). We noticed a reduction in nit picking and an increase in banter after getting team members together. 5. Regular catch ups Even though you can offer greater flexibility, you still need to set up regular virtual catch ups. These shouldn't be limited to direct reporting lines. We tried to set up 1/4ly or half yearly catch ups with the CEO where everyone from marketing to engineering would have a relaxed chat. Sometimes these only took a few minutes, but sometimes much, much longer. Never assume people will come an tell you their thoughts or concerns randomly - some people need a nudge to spill the beans. At Geektastic we plan to have a mix of office based and remote team members, with flexibility to come into the office or work from home. But these processes and tools discussed here are baked into our DNA to help make it work.
1 Comment
So it's time for our first mini Code Challenge. This one is aimed at Java Developers and we're running it as part of our first marketing campaign.
We're going to publish some data once we have run this for a while, early indications show only 10% are getting it right first time! So go on if you think you know the solution.. Clearly I hadn't done my homework yesterday when I posted a status update on my Linked-In profile with www.geektastic.com embedded in the message. Which, coming from someone who used to run a 'Social / Real Money Casino on Facebook' is pretty embarrassing. As you can see the image is broken, the title was incorrect and the description was missing completely. Had I done my research I would have realised that our website needed three Open Graph tags in the code. I have added them below so you don't make the same mistake I did.
og:title - A title to describe the page or the content - should be less than 88 characters and should be attention grabbing as it comes up bold. og:image - The left hand side image. We opted for a logo for brand awareness (it was a toss up between brand awareness and click through - at this point, since we are still in our infancy, we wanted to generate awareness of Geektastic through our Logo) although we should really test different images (such as people) for different click through rates at some point soon. og:description - A more detailed description of your content. This will be seen in smaller text and not bold so you can get away with a deeper description. This is what the post should have looked like before I pushed the 'share' button now we have updated all the tags. Just got to make sure we use these tags on our blog now! Live and learn. As a team we've hired 100's of software engineers in our time, everyone uses their own process, but without fail anyone hiring a developer will use some form of 'technical evaluation' as part of their hiring flow.
From the hirer's perspective a CV alone doesn't paint the complete picture. A candidate's previous employment history might look impressive and of course, if the candidate has come via a recruiter he or she will be "the best rock-star coder of all time" but without taking a deep dive into their coding skills a hirer is taking a huge risk bringing them on board. Coding challenges can vary from a few multiple choice questions (which in our view is more of a tech screen than deep technical insight) to huge 'build me an entire app, plugged into these API's, we want full documentation and functional tests' - which could easily take a two week sprint (good luck getting real talent to give up that amount of time). It's no wonder candidates hate them, taking 10+ code challenges which can take anything between 30 mins to a whole weekend to complete, to land your next role doesn't sound like much fun (unless you have a sadistic love doing coding challenges). When we started Geektastic we wanted to make this whole process easier, both for candidates and for hirers. We want to reduce the number of tests a candidate takes to find their dream role. We want to provide hirers and recruiters with deep technical insight into their candidates that you can't get from a CV or resume to allow them to speed up their time to hire, but most of all we wholeheartedly believe in real humans doing the candidate assessing rather than a machine. A score is great, but if a candidate has given up 2 hours of their weekend it seems pretty disrespectful to reduce all that work to a percentage - how would you feel? Very exciting times over at Geektastic HQ, we are now live - you can check us out here geektastic.com, we are growing on Twitter and now we have this super exciting blog.
Firstly, some introductions to the team. There are just three of us at the moment, Rick Brownlow (that's me, geek but not a 'techie', serial starter-upper, sometimes starter-upper-finisher), Laurynas Karvelis (our crazy Lithuanian, front end guru extraordinaire, part time quad copter building/flying/crashing enthusiast) and Charles Girdham (Molecular genetics researcher turned uber software engineer). We set up Geektastic to help solve what we perceived to be a flawed process. Hiring Software Engineers. There are so many issues here, the majority of recruiters are focussed on quantity not quality (there are quite a few exceptions to this, in fact we are working with some of them and are looking for more), there is a shortage of talent (understatement of the year), and the whole process gets everyone's blood pressure skyrocketing. We're tackling things one step at a time, firstly we're focussing on Code Challenges, and that we'll cover in our next post |
AuthorRick Brownlow Archives
March 2017
Categories
All
|