Tools are recursive.
Increasingly the conversations I’m having in the office are about tools - digital tools, scalable tools, technology as a tool. But these conversations quickly get meta. There are as many definitions of a digital tool as there are tools themselves. And many of these tools are really incremental pieces of technology, built on a whole heap of other tools and platforms.
As an example, some people in the office have been using Slack, a collaboration and communication tool that’s been getting some press (and dollars) recently. Slack uses, amongst other things, some Amazon AWS tools. Which are tools that we also use to build tools for our clients. And you can create and integrate other tools with Slack, allowing you to create tools to extend a tool that you use to help a team create tools.
Confused? You probably shouldn’t be. The fact that there are few new ideas and that we are building on the ideas / frameworks / shoulders of others is surely standard operating procedure in the current point of our post-sampler creative and cultural continuum.
But what’s important is not the just the originality of the 1% being added to the collective digital noise, but the story that you tell. The how, what and why matter as much as the code you write. Perhaps story points shouldn’t just be in the backlog.
2014-12-11 21:53:57 GMT permalink
2014-10-27 09:47:23 GMT permalink
2014-09-14 10:55:58 GMT permalink
2014-09-11 20:20:02 GMT permalink
2014-08-05 17:25:00 GMT permalink
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).
2014-08-05 17:16:17 GMT permalink
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.
2014-07-18 21:56:00 GMT permalink
2014-07-11 23:20:00 GMT permalink
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.
2014-06-18 10:23:00 GMT permalink
2014-05-27 12:31:40 GMT permalink
2014-05-12 09:18:49 GMT permalink