Last day at R/GA London
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.
A trip to Le Tour
Yorkshire. Huge crowds. Good weather. Great riding. Good company and a long ride.
For the many British pro-riders who didn’t make the tour (or those that did and then didn’t get past the first week), the 2014 Tour de France is probably one to forget. But for British based cycling fans the 101st edition will stay long in the memory.
Your API is your brand
Recently I was asked to take a look at an API as part of an advertising awards entry that we were making. As with most awards entries the assessment I was making wasn’t just about the functional elements such as the available methods, approach to content negotiation and compliance with open standards, but also the way the API was presented. Was there good documentation and tools as well as an active an easy to engage developer community.
All those elements were there, but there was something else less tangible and probably more important that I was really looking for. What did the API really say about the brand? This assessment is more subtle, but gets to the heart of how and why an organisation is choosing to expose services to third-parties.
- How does the sign-up process work
- Can I have a limited number of API calls without having to sign-up, so that I can test if this is for me
- Which programming languages are the code examples available in (the choice of languages can say a huge amount about the brand)
- How often is the API updated, is this a live project
- Is there an easy way to submit bugs or feature requests
- Which developer tools are being used to share code and examples (can I do a pull request on GitHub?)
The most important area to understand is the value that the API is offering to developers and third-parties, and by extension what is the expected return value the business can hope to receive.
Empowering developers though your API is a form of co-development with people you might not know so well. Choosing the playing field (the services) carefully is an important way of shaping the development direction.
There’s clearly an assumption within some organisations that “having an API” (public or private) is enough, but just showing up is no longer a winning strategy. The way companies engage the developer community is a pure expression of branding through doing (show, don’t tell). If done in the right way it empowers others to realise your brand expression through their own art, copy and code. Which seems like something that is worth investing in.
Missing (these islands).
Saturday morning, doing the things you have to do (buying clothes for the children in Milton Keynes) and the dissonance with our recent trip to Coigach is rising up in my consciousness and beating me over the head. Robert Macfarlane, in his brilliant debut proposed the concept of ‘Mountains of the Mind’. The Summer Isles are firmly embedded as one of my haunting mental islands.
Short climbs. Rough roads.
There’s always another island.
Looking west from Haunn, Mull I can see the island of Coll across the water. The weather always looks slightly better over on Coll, the sunset brighter, the beaches a golden streak across the dark island.
And beyond Coll, the Uists, connected, almost to the conjoined isles of Harris and Lewis. There is always another island.
Which creates a slightly uneasy feeling, an unrest. A glance at the ferry times, thinking about the logistics. In the same way some people feel compelled to cycle up alpine passes, bag Munros or tick off indian provinces, the very existence of un-visited Hebridean islands creates some kind of implied experience vacuum.
Until perhaps you reach St. Kilda, the edge of the world, just Greenland to keep it a distant company.
But this is really a flat earth approach to island hopping, where the horizon represents the edge of the known world. A spherical planet surely means that there is always another island, near, far or unreachable.
Casting Teams: Digital agency agglomeration
In Evan Davis’ provocative documentary Mind The Gap, he argues that a key attribute that makes London such a successful city is the way that a huge mass of people with diverse talents are able to combine to produce ever more effective and powerful alliances. This effect, known as agglomeration, is a key reasons for the success of start-up communities such as silicon roundabout.
Digital agencies increasingly require the effects of agglomeration to innovate on behalf of clients. Brands are looking to ‘innovate to differentiate’, working with agency partners on ever more complex campaigns, co-creating connected products or pushing the web through responsive builds and smarter mobile development.
These kinds of briefs require an agency to line up diverse teams, with previously ‘non-standard’ skill sets. This isn’t just a production problem. The ‘mad men era’ copywriter+visual creative team isn’t an atomic unit in the world of prototyping, hardware hacking and auto-scaling cloud based solutions. Small project teams need to be comprised of specialists from a wide range of disciplines who quickly need to form productive teams. These teams need to live in the medium. Presenting ‘mobile first’ creative in a PSD is clear warning sign for agencies and clients.
So how do agencies find a way to crunch together multi-discipline teams at short notice. The 3 martini lunch era is a distant relic, and ever more efficient agency businesses are loath to run ‘a large bench’ of specialists. Conversely keeping control of freelance costs exerts financial pressure in the opposite direction. Staffing an effective and innovative team in 2014 is a challenge.
One strategy is to develop a t-shaped skills culture, where people continue to have a strong specialism (and craft) but also have a wide exposure to complementary skills. An agency of designers who code and hardware hacking project managers.
Agency frogger is seen as a threat to business continuity for agencies, but recruiting talent who have been exposed to a wider variety of projects and environments is a potential shortcut to a more diverse and flexible team. Encouraging staff to share, talk and present at events inside and outside of the industry is another way of exposing teams to external influences.
This isn’t an easy problem, but it is one that agencies need to solve to avoid producing out of date, commoditized work that is no longer effective. In many ways the type of skills required are the same, but the tools and landscape have changed. A digital agency that continues to show copy in Word and present ideas using PDFs is already suffering from having the wrong teams in place. The future is already here, it is just unevenly distributed.
Just over a decade ago I went on my first snowboarding trip with a group of friends - a lads week away. I didn’t really know what to expect - I’d never been to the alps (or any other major mountain range outside of the UK). In the back of my mind it was the start of some cool, extreme sports based adventure of jumping off enormous kickers, getting lost in powder fields followed by some serious partying.
Fast forward to the present and I’m sat in a chalet next to a baby monitor whilst the rest of family are off to catch a late lift to ski school.
Over the years I’ve realised that the thing I love about going boarding isn’t booting it over enormous jumps or dancing on the bar (though those things are pretty good), but just being out in the mountains. Nothing beats a day when the snow is good and the sun is out, cruising along with a view of some far off peak and no agenda except making sure you enjoy yourself.
Which is why we are here, dashing late to ski school, dragging a pushchair up to nearly 2000m and sledging in the afternoons. Not because skiing is an essential skill for the girls to learn, but because a love of the mountains and having fun is something that’s worth passing on.
Winter time. Cold. Dark, and paradoxically, in these northern latitudes, a perfect opportunity to watch the warmth of a winter sunrise without having to rise too early. A run of cold clear weather means that most mornings a pinkish, orange light spreads across the cold dark fields, leaves fringed with frost reflect the sudden glare and for a moment the sky flames.
Music to code by
What does work sound like.
What should work sound like.
If you walked the floors of a successful, creative digital agency with your eyes closed could you tell if ‘things’ were getting done.
One of the 12 items on the Joel Test is a quiet working environment, without distractions. For many developers, what this means in practice is a quiet environment where they can put on some oversized headphones to filter out interruptions and side conversations - and create their own carefully controlled musical accompaniment to coding.
In most cases developers are trying to create or maintain ‘flow’. Flow is for many coders the thing that gives them most satisfaction - the point where almost effortlessly working code seems to shoot from the brain through the keyboard and onto the screen without interruption. Coding downhill, with your feet off the pedals.
For many developers a day with good flow is a ‘good day at the office’.
Flow can be deceptive - extended periods of head down development without collaboration or an alternative viewpoint can result in a spaghetti code pile up of insane proportions. I’ve worked on plenty of projects where someone sat up all night writing code poetry - ‘fixing everything’ - because they were in the zone - only to leave the team saddled with the Object Oriented equivalent of doggrel.
Collaboration is a key attribute of a good developer, something that is especially true within an agency environment, but also true for anyone who isn’t just a ‘lone wolf’ developer. Which means how effective is ‘headphones on, head down coding’? Finding the right channel and balance of communication is important - traditionally IRC has provided the right level of persistence and real time for most developer discussion, but increasingly new tools such as HipChat and Campfire are finding ground. This seems to be especially true with more distributed remote teams.
So what to listen whilst coding, or rephrased, is there a musical shortcut to achieving ‘flow’. If it was that simple then I’d have one playlist or a couple of tunes to listen to on loop that would instantly transport me to the land of easy coding. If only it was that simple.
A dash for the train. Greens and brown blurred as the pedals spin and breathing hurries. The fields have a haze of green, early shoots of growth, wet with a misty rain. A pheasant fails to hide against this baize, an obvious shot, ready to be potted.
Into the effort now. Traffic grows; plumber, Golf, Audi, school bus. Past the two small woodlands, then down and over the little bridge, and up the bailey to skirt the embankment and into a village now fortified by roads and starter homes.
Down into the town, that welcomes careful drivers, though it does a poor job of attracting them, to make the train. Now I’m the one glistening with a morning dew.
The train pulls away, South. From the carriage window a kestrel hovers, already at work.
3 years ago moved into our little cottage. A new family with a new baby and a lot of work ahead of us. It had taken a few months to make the place even liveable.
A lot has changed since then, a wedding, another baby and an awful lot of hours spent fixing, painting, sanding and generally finagling a previously neglected old house.
We’ve had so much help from family, friends and neighbours that it almost seems like a betrayal of their efforts to be moving on. But moving we are, to another part of the same village. One thing we have learnt is that Stewkley, Bucks feels very much like home.
Dear Legacy Code Creator…
I’m sure you didn’t mean to create this problem. It probably seemed to make a lot of sense at the time. The client was a pain, you were under pressure to deliver - producer over your shoulder, asking “is it done yet”. As for that Tech Lead, he couldn’t code review his way out of a paper bag.
A project that nobody cared about. Ship it. Move on.
And it shows. Because 2 years later we are staring at the code. Trying to fix up some problem or other. It’s hard to know where to start because, well, there’s not many comments, the commit messages are garbage and the little documentation that there is makes no sense.
I understand that you didn’t think anyone would download that app, but people have. And the client, despite what you thought, thinks this is quite a good product and would like to promote it, if only it wasn’t so buggy. So now it’s over to us.
It’s OK for you, and the rest of the team. You left. A contractor. Got fired. Who knows, but you’re not here now as a couple of us go toe-to-toe with your lack of error handling and crazy re-invention of the most common design patterns.
And you know what, I know that we could all write better code, that I don’t have the context of those meetings and planning session when it all made sense. I wasn’t there.
But next time just write a few bloody comments and maybe some documentation that doesn’t assume you know the app inside out already. And think about those of us who have to up pick your pieces…
What we talk about when we talk about planning poker
How sizing stories (points, t-shirt sizes, days & hours) is more than just Numberwang.
For (digital) agencies who use agile techniques for managing the design and development process there are some added complexities hidden in the abstractions of the story sizing.
Depending on the nature of the development project, a typical agency team might run the gamut of disciplines, from Interaction & Visual Designers, working in Illustrator and Photoshop through to Python engineers coding in Vim and living in the command line. And each with a (subtly) different understanding of the complexities involved.
Planning poker is the technique of getting multiple people on the team to independently size user stories, whilst trying to avoid the risks of ‘anchoring’. It’s a great method for driving cross discipline understanding of those tiny assumptions that can threaten to derail a project further down the line.
Which looks something like this: Sat in a circle, post-it notes scattered across the floor and walls, someone is describing a level understanding of a particular user story — it’s pretty simple on the surface “As a user I can sign-in to the platform, so I can register to use the service”. People scribble on the post it notes, using the Fibonacci sequence to size stories based on the relative complexity involved for the UX (interaction and visual design) and technology teams. After a few seconds everyone stops writing and holds up their post-it notes. It’s near the start of the meeting so people are still getting a little warmed up, even so the variance in the numbers is quite high. Not just between disciplines but also between team members who work in the same area. This is where the interesting bit starts.
The discussion that follows is the bit I find fascinating. The cases where someone in tech misunderstands the complexity of a design challenge or someone missing the difficulty of integrating with a third-party (“it’s just an API call”) is understandable — that’s why we are doing this as a cross disciplinary group. These are easy to flush out and correct.
The real area of interest is where people explain the assumptions behind the scores they’ve given. At this point we are into the details, and it’s great for the momentum of the project. Weeks of thinking, sketching and notes come tumbling out in the conversation — no amount of ‘annotated wires’ can accomplish the benefit of someone challenging why “that’s only a 3”.
Capturing these assumptions is key — they make up the real scope and difficulty of a story. Often it’s also the risk factor that you’re gathering “I gave it a 21 because we just don’t know exactly how that’s going to work”. Whilst all forms of planning and project management are probably inherently flawed, you’re unlikely to get this level of collaboration and discussion whilst scoping out a typical waterfall build.
Agencies running agile are usually working with more constraints than a development shop. The client will probably have a fixed budget and timeline, so the only area of flexibility is scope. Whilst the aims of the project are (hopefully) going to be clearly documented and contractually agreed, these small instances of scope and the relationship between a ‘must’ and ‘could’ are the area of flex that teams are going to need deal with the reality of ‘unpacking a story’ and finding it’s more of a nightmare than a fairy tale. But that’s probably something to add to the backlog for another post…