Fri, 08 Feb 2013 11:33:33 permalink
Sun, 27 Jan 2013 23:57:00 permalink
Sun, 20 Jan 2013 22:40:00 permalink
The marginal gains of innovation.
Innovation in digital advertising. Innovation in advertising.
How do you create an environment and attitude that allows people to innovate on a daily basis? Is it possible to create a culture of innovation?
There’s an increasing tension pulling at the commercial web. The commercial web being that part of the internet that’s trying to sell you something - even if that something is as intangible as brand or an idea or maybe even an emotion. This commercial web is becoming ever more formulaic and codified. Measured in an analytic sense, but also in a careful way. There’s a pattern to campaigns, to exploiting social media with the big players. Facebook, Google and Twitter drawing more and more users and therefore advertisers into their orbit.
If you believe this to be true, that innovation is the key to stepping beyond the confines of the formulaic web, and therefore, standing out and being noticed, then how as an organisation do you make this one of your goals. Can you codify innovation? Make it reproducible? Isn’t that just like planning to be spontaneous. For teams involved in creating for the commercial web, innovation can not be something that happens in a vacuum, away from results - the formulaic, measured web has seen to that. This isn’t a story about “being brave enough to fail”. Client success isn’t a nice to have.
We seem to wrestle with this most days at work. I certainly don’t have all that many answers. Yet. But I’ve noticed that the most innovative projects I’m involved in have thse ingredients.
1. Be a team
Not just a group of people who happen to be free at the same time and who the resource manager and producer have cobbled together. That might be how the team gets selected, but it needs to evolve quickly into a genuine team.
The big idea is great. Someone probably needs to have one at some point in the process, but that’s really just a beginning. Innovation isn’t the eureka moment. Or rather it’s not one big eureka moment, but normally hundreds of tiny innovations, back to back to back. Build something, make it better, change it, test it. Improve it. Some of the most innovative projects I’ve worked on recently haven’t really worked all that well right up until the last minute. There’s no such thing as getting it right - it’s a case of keep making it a little less wrong.
3. Be open to the marginal gains of innovation
There are opportunities to innovate across a whole spectrum of disciplines. The most effective innovation might come from the way you change the hosting, deploy your code, manage your daily scrum or prototype the user interactions. Nobody knows where this is going to come from, but it’s important to recognise any opportunity for innovation and grab it.
Sat, 19 Jan 2013 00:44:17 permalink
Sun, 02 Dec 2012 21:01:00 permalink
Sun, 02 Dec 2012 20:32:00 permalink
Sat, 17 Nov 2012 23:29:00 permalink
Sat, 10 Nov 2012 21:54:00 permalink
Sun, 04 Nov 2012 22:29:00 permalink
Sat, 01 Sep 2012 22:09:25 permalink
Tue, 14 Aug 2012 22:54:00 permalink
Sun, 29 Jul 2012 23:08:00 permalink
Sun, 15 Jul 2012 14:13:38 permalink
In no particular order:
Sat, 14 Jul 2012 20:59:00 permalink
Tue, 10 Jul 2012 22:29:00 permalink
Tue, 26 Jun 2012 22:18:00 permalink
Mon, 04 Jun 2012 22:36:07 permalink
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.
Thu, 31 May 2012 00:23:00 permalink