Weblogsky: flickr's organization: aha!

flickr's organization: aha!

My ears stood up when I started reading Jeff Veen's post about flickr's organization as close-knit collaboration between extremely talented people... "the abstraction of a tiered architecture is an efficient way for people to work, communicate, and collaborate. But that seldom works without a deep respect built from working together side-by-side, at least at first. In other words, designing things works better together, and building things works better with structure." Jeff also points to Tom Coates' overview of Cal Henderson's presentation on "How We Built Flickr," which led me to an aha! moment or two because it resonates so well with our evolution and thinking at Polycot:

One particularly interesting chunk was about the relationships between various people operating at different layers - with the developers able to easily create page logic-level functionality that allow the designers to take it away and build user-facing features around them. This relationship is phrased as a negotiation, with the designers coming back and asking for page logic level functionality as they see a need for it (and then being completely responsible for the building of the front-end elements of the site, and for checking it before launch). The whole enterprise is around continual development and improvement and reaction, which probably explains another fairly jaw-dropping moment of the morning - when Cal revealed that on 'good days', Flickr releases a new version every half an hour. In order to support this kind of working, they've built structures that 'supports rapid iteration but enforce at least a little rigour'. Stunning. Although clearly not right for everyone...

A lot of this stuff really fits with my aesthetics of developing products effectively for the web, because - I guess - it's actually a very responsive and very web-native way of building. This process cycle of rapidly building, creating structures that support future iteration, being connected to the users on your site and being able to react and redevelop your proposition almost on the fly - these all seem to me to be the way that most of my peers worked before moving to large organisations that attempted to enforce standard software development methodologies on a completely different medium. And of course, it all hooks in with elegant ways of writing and producing web pages in ways that allow rapid change and evolution, making design about interactions and services and components and design swatches and aesthetics and change rather than about .psd files, yearly redesigns and distant heavy-handed top-down management (and sign-off) from a distance.

jon posted this at 7:19 AM
Share on Facebook| email to a friend