Naval’s ‘Team That Ships’

As part of a team that creates ‘products’ (festivals and events) with a fairly standard roll-out and lead-time, I’ve begun to be fascinated with how development and deployment works in other industries and sectors.

While our campaigns for bluedot and Kendal Calling typically run over a recurring twelve-month with similar timelines and budgets, comparing what we do with the likes of the tech industry offers some great insight into how we could improve our approach. From this, our move to a new approach of ‘projectising’ within our campaigns – breaking our year into a series of mini-campaigns that each have their own brand, roll-out schedule, budget and marketing – has been a great first step towards a better, more rigorous way of operating.

One great example is Naval Ravikant’s great – if blunt – Build A Team That Ships from 2012. Naval’s piece offers some simple guidelines for how to build and team that builds and ships products on a weekly basis, with an agile, project-based mindset. Examples include…

People choose what to work on. Better they ship what they want than not ship what you want.

No tasks longer than one week. You have to ship something into live production every week – worst case, two weeks. If you just joined, ship something.

Peer-management. Promise what you’ll do in the coming week on internal Yammer. Deliver – or publicly break your promise – next week.

For Naval, building more strict structure is, of course, freeing – the first steps towards regimenting how teams and individual staff members operate ultimately result in an environment where staff choose to work on projects that they feel fit their own abilities best, and get the reinforcement of seeing their hard work delivered as products on a weekly basis.

Read Naval’s Build A Team That Ships