Webstock2008: the make-it-happen meta-trend.

Being at Webstock was like being in the Matrix digital rain – a teeming rush of information and ideas. Since resurfacing, I’ve been trying to pull some themes out of all the things I heard and learned.

The most resonant theme for me emerged from a number of presentations that touched on not just what we do, but how we do it. How do we find new areas for development? How do we build a team to bring an idea to life? How can a workplace be arranged to help this happen?

So – here are the strands I’m pulling together as I think this through.

‘Design for the future’

Nat Torkington noted the importance of keeping up with your research: know what’s possible and what’s not possible (and keep an eye on it, ‘cos it will be soon).

We need to get better at gathering info about what our users are doing, analysing it and acting on it. We can exploit the real-time nature of the web through A/B testing.

And we need to make designers a key part of the team – they’re there to help us build a site the way people want to use it, not how we’d like them to use it.


‘Getting from stuck to unstuck’

Kelly Goto on how we find flow in our daily work:

• vision & purpose
• support and buy-in
• knowledge and ability
• collaboration and synergy
• platform and tools
• attitude and fearlessness
• progress and results.

‘Building big on the web’

Cal Henderson’s presentation was a highlight for me. I don’t develop software, but found some of his key points really transferable:

- Automate everything. Anything that’s hard or complex or that you do over and over again can be scripted down to a one button interface.

- Make everything visual. Find ways of turning data into visual images (beyond just graphs), so you can see at a glance what needs attention.

- Establish culture of blame. As in – have an easy way of recording what everyone’s doing, so if something goes wrong the right person can fix it quickly.

- Make error messages really apparent.

- Make bug tracking really easy.

- Have really fast admin tools for customer care.


‘Primal software development’

Michael Lopp’s presentation was also aspiring (as in, I aspire to this way of working).

On hiring

• Hire the opposite (fill your own blindspots)
• Hire complete people (who can talk about any part of the business)
• In small teams, everyone has a say about who joins.

Three key hires

1. The free electron: the most productive engineer you’ll ever meet
2. The historian: the communicator, the reality injector, the person with deep organisational knowledge who can course-correct your project
3. The Russian lit major: glues your team together, interfaces well with technology, the ideal QA or programme manager.

Decision making

• should happen fast
• should be as informed as possible
• should have lots of eyeballs
• should be distributed: giving people responsibility to make decisions gives them a stake in the project.

Communication

• be deliberately communicative
• find communication tools that work, and use them – whether that's a wiki or twitter (interestingly, Cal Henderson noted that its easiest to develop rapidly when all the people needed to do stuff are in one room and can yell at each other – how can this happen in a cubicle farm?)

No specs, just code

• your code is its own best comms tool: everything you need to know about its development should be right there
• take a project’s pulse by looking at check-in notes
• often, code is the only thing you can measure: don’t hide it.

Success

• Successful products are the ones where a culture spills out of them: Google, Apple. You can build lots of software; you can only build a culture once.

Change it up

• Change what you do every 3 years: it makes you smart, relevant and funny.

‘Designing for a web of data’

Awww, Tom Coates. You were my favourite. You told us to build small multi-disciplinary teams, which can be creative, can extend in different directions, and can get to the core of where the product comes from.

You warned us about how dominant job roles within an organisation can create imbalance on a project (like when marketing wins every debate).

You told us to build early and often. From all this I’m hearing: run your team like a start-up inside your organisation.


‘The Myths of Innovation’

In a previous life, I took part in a brand-storming exercise with some Saatchi’s guys. One of my colleagues wanted ‘innovation’ to be at the heart of our brand. The Saatchi’s guys told us that innovation is one of the most pointless words you could possibly chose to build a brand on: everyone wants to be / thinks they are innovative, hardly anyone really is.

But … if you want to encourage new thinking and new products here’s Scott Berkun’s message distilled:

1. Delegate: give people the authority to try new things, Innovation will be stifled if it’s constantly having to be signed off by people in levels above you.
2. Take risks / make mistakes: you learn from the mistakes, and you put what you’ve learnt into the next, better version. Give time, and if necessary budget, to test things out.
3. Reward initiative: in a meaningful way – make it worth people’s while to go to the effort of doing something new or differently. And don’t punish mistakes. At which point I looped back to something Michael Lopp said – if a member of the team isn’t helping you achieve your objective, get rid of them. There’s a difference between not doing anything wrong, and not helping).

In conclusion

I went to Webstock expecting more of an 'applied craft' approach: this was the problem we faced & here's how we solved it; this is the opportunity we saw & here's how we exploited it. What I came out of it with was a renewed drive to try new things, and to find the most efficient, most fluid, most equitable, most success-focused ways of working with people (and to have pity on the Morlocks, of course).

How about you?