anthony galvin

A few weeks ago I left R/GA after nearly 4 years, working first as a Technical Team Lead and then as a Technical Director. I’ve learned 1000s of tiny lessons and quite a few big ones over the last few years. Here’s some key ones.

1. Multi-discipline collaboration from day 1
Complex (digital) projects require talented people from many disciplines. Casting the right team can be a challenge, but once on the ground (usually at R/GA in a war room), collaboration needs to be rapid, open and without (too much) ego.

2. Code scamps (aka prototypes) are essential
Just about working software is the best way of explaining an idea. If you can sketch in code, getting something up and running no matter how hacky then you’re moving forward. The things you learn by doing this early are nearly always invaluable as long as you’re prepared to throw away more than you keep - being over invested in the scamp is going to get in the way of iterating.

3. Really good QA helps produce really good products
The internet is everywhere and on everything (Brad Frost, also ex-rga has some great slides about this). I’ve worked on projects where the QA engineer is testing on 20 devices. Obviously there are real benefits in test automation, but there’s no shortcuts - at somepoint somebody is going to need to tap through your app on all the devices, again and again and again.

4. Work smart and work hard
The industry has a long hours culture and sometimes working hard (late) is the way to a briliant product. But it’s not the only way. From a technology point of view investing in smart work; automation, auto-scaling, developer tools that work is way better than just staying late.

5. Access to tools and permissions matter
The battle for better tools and services is constant. If you constantly put a barrier in front of getting things done then you kill the speed at which innovation can happen and in an agency environment slow projects die a slow death. If it takes a 48 hour helpdesk response to get the CI box back online or multiple paper based forms to spin up a cloud service then the velocity of your crack innovation team is being severly hampered.

6. Location doesn’t have to be important
There’s a clamour to have EVERYONE IN THE WAR ROOM ALL THE TIME. But collaboration doesn’t really work like that. Clearly facetime matters, and at the right stage of the project it really is worth having everyone sat in the same room. But having highly motivated, talented people pulling in the same direction is way more important than having them sat in the same office (or even timezone).

Today is my last day at R/GA. It’s been an intense and entertaining 3.5 years. Everyone says, “the people here are amazing”. But it’s true R/GA people are talented, hardworking and (borderline) alcoholics.

I remember a couple of days after I started having to be part of a sprint review for a major web app project. There seemed to be hundreds of people on the call from all over the world plus a ragtag bunch of us in London. The review went OK, but it seemed like madness - the ambition of the project was unbelievably high and I couldn’t work out how we were going to deliver the work or get the various random people on the phone to agree about anything. I really wasn’t sure that I’d made the right decision to leave my cosy client side tech role.

But somehow we did it. The work was hard but the results were awesome, even if perhaps the client didn’t quite understand what we’d built - which is probably true for most of my R/GA projects.

What I will remember most fondly are those times when we aimed high, put our foot on the gas and delivered something that seemed almost impossible on day one.

There’s way too many people to call out individually but a big thanks to Patrick and the tech team here in London who’s hard work and talent made me look good on a daily basis and in particular the project teams on Pearson and Getty.

Thanks - it’s been fun.

This is a slightly extended version of my ‘all London’ email to the fantastic folks at R/GA London.

I’d started drafting these tips for the R/GA tech blog when Bobby Schultz beat me to it with his post “The 5 pillars of remote collaboration”. Despite this I thought I’d post my thoughts here anyway.

It is certainly not a recent trend for organisations to be looking to work with remote software teams. Whilst previously this was primarily motivated by a move to reduce costs and offshore development, increasingly there’s also a desire to harness technical talent irrespective of location. The growing R/GA network means that we are often reaching across offices to staff projects teams and leverage talented technologists. 

Here are a few tips that help those projects along.

1. Daily stand-up has to run like clockwork
Even if you’re not running an agile or adaptive planning process it’s important that everyone is committed to making ‘the daily’ a success. This is your most important meeting of the day. It needs to be professional, effective and run to time. Time is important, on projects with a wide geographical span as someone is going to be getting up early or staying late to contribute to the daily, so everyone needs to respect that.

2. Keep an open line of communication for all developers
Informal communication is essential between the development team, what my colleague @philhawksworth calls a 'back channel’ for open discussion, questions and banter. This is where 'the culture’ of your team is going to be fostered.

3. Use video
Make all calls video calls, even though we can get by over the phone the psychology of video calls helps to re-enforce relationships. Where there are a group of people in a single location use a dedicated meeting room computer and gather round a single large screen so that remote workers take up a disproportionate amount of space in the meeting room.

4. Have a robust, repeatable build and deploy process
Whilst continuous integration and continuous deployment may not be appropriate for all projects, when working with remote and distributed teams a bullet proof build and deploy process is essential. If you’re running a semi-automated build system everyone should be able to run a build regardless of location - without this you’re going to start having bottle necks and some users are going to be more equal than others. With an automated build process all developers are have equal ability to break and fix the build. 

5. Be location agnostic
If at any point the team start thinking about people who are 'offshore’ or 'in New York’ then that’s the start of a problem. Everyone on the project may not be equal, but the source of the inequality should not be location. 

This doesn’t mean that you shouldn’t  be sensitive to different locations and cultures - if it’s a public holiday in London, then it’s a public holiday in London. These things tend to equal themselves out and there are no surprises - you don’t often get short notice public holidays. The key thing is that you’re being equally sensitive to location and culture regardless of location.

6. Let remote people lead parts of the project
This sounds slightly counter intuitive when working with a group of remote developers or a distributed team, but if you want to embed a location agnostic culture don’t be precious about having all parts of the project led from the largest or main location. If you’ve got a fantastically talented front end tech lead on the project who is based in South America and you’re in Chicago, then there’s few reasons not to let that person lead the front end development.

7. Make time for a 1:1 
If you’re leading a project and you have remote developers, make some extra time to have a one-to-one session with each individual. You won’t be to recreate that hallway conversation you might have if you were on the same corridor, but once you get a cadence to these conversations, it’s amazing how productive they can be.

8. Face to face buys you time
There’s an internal saying @RGA “that face time buys you 6 weeks”. Whatever the number for your team take advantage of any face time you can get, both from a work perspective but also from a social “let’s go to the pub point” of view. It’s worth it’s weight in something heavy and valuable.

Last week R/GA London had it’s first Make Day - two days of creative and technical exploration, in some ways done just for the joy of being able to make things. I was astonished by the diversity and quality of the work that people produced. Russell, has posted a round up of the different projects, which ranged from a (working) face recognition system running on Windows 8 (which isn’t even publicly available) to some marmalade. For my part I worked as part of team building a “tea and coffee roulette web app / game”.

The concept itself was pretty simple - make a webapp that would allow you to join a tea round, the twist being that the last person to set a preference and complete a simple task would have to make the drinks for everyone else. A quick 10 minute brainstorm and one whiteboard diagram later and we were underway, with @sanderkuypers doing the visual design and the rest of us (@benoitgrelard, @loopdream and myself) quickly began hacking together some working software.

From a tech perspective we decided on a web app (ie, a mobile application that isn’t device specific and can run in the browser) as the best way to get something working with our dev skills. From a front end perspective you can get quite a lot of motion data from some devices (such as an iPhone) via JavaScript, which meant we could build a ‘shake the sugar’ task for the race element of the game. Last one to a hundred shakes makes the tea.

To speed up getting to this device data and creating the UI we used the jQuery JavaScript framework. In the background the game engine was built using PHP and CodeIgniter to handle user registration and keeping everything in sync. We had thought about using node.js to handle socket connections to the devices, but with time limited we settled on using Pusher (a hosted socket service), which had us up and running in about 20 minutes. Behind all this sat a simple mySQL database for keeping everything together.

By the end of the two days we had a working game, that looked great and actually worked - user and device registration, automated email (warning users that the game was about to start), a countdown, simple game (track and field style) and notification to the winners and users - all in real time (via web sockets).

Apart from being a break from our usual client projects and lots of fun it was good to build something a little different - although we didn’t stray too far from our core competency, we did try a few new things. Russell and the management team set some pretty loose (open?) goals for make day, but as the project progressed it was clear that one of the main motivating factors of our team was to deliver working software - which is a pretty healthy team ethic.

I’ll post a link to the source code and a working example once it’s online.

– Follow Up –

Dave suggested that one of the factors for the (relative) success of the project was that the team comprised a variety of skill sets. Whilst this is true, it did come about pretty much by accident.