The last 9 months we used n0tice to put into practice some of the things that I’ve learned the last decade or so about development and some of the things that I always wanted to try but didn’t have the chance.
Anyone who has ever worked in a startup will recognize most of what I describe here, but I think the way the n0tice team operates also has some lessons for larger projects happening in larger groups, as well.
The n0tice team is made up of 1 lead developer (Daniel Levitt) who drives the web site and most of the new concepts, 1 community strategist (Sarah Hartley) who sets the tone and spends time working face-to-face with customers, 1 infrastructure man (Tony McCrae) who not only handles plumbing but also builds services like the API, a mobile development pair (more on them later) who are designing and writing the iOS app, an apprentice (Andre Moses) supporting our social media efforts, and a host of volunteers, occasional contract help, and a cast of supporters who help us out along the way when they can (or when we ask).
Almost everyone has a hand in at least one other major project in addition to n0tice.
We chat most mornings at 11am for about 30 minutes, not always. None of us sit together physically. We try to work together in the same space every two weeks for an afternoon, not always. There are no other meetings.
We decide what to build as individuals, though everyone shares what they’re doing so we can talk about the work and feed ideas to each other.
I like the principles of agile development, but I’ve never found it great at handling multidisciplinary activity, particularly when you are dependent on the talents of the people around you as opposed to the timeline or milestones.
So, as a result, we just let everyone work at their own pace, doing what they can do when they can do it, united on a direction of travel.
We choose release dates based on when something is ready or when it might make sense for co-dependencies to join up. In some cases, a date is a codependency, but generally we care more about what is built rather than when it’s built.
Everyone uses their favorite tools to build whatever they are building. That means we’re running multiple programming languages, but you don’t have to trade simplicity for creativity if you can loosely join separate systems through a service-like approach…even with a relatively small stack like the n0tice stack. It seems to actually make scalability easier, too.
I’m as guilty as the next person who cares about their work of micromanaging, but I think I’ve solved that problem for myself and the team and the effort by attracting individuals who are not just talented but also very very creative. We can therefore deflect any tendencies I may have to define solutions to things because we all know that I could never have a better solution to a problem than the person responsible for the problem.
They force me to stay focused on where we’re going rather than how we’re getting there.
We pay close attention to what our users say. We setup a Google Group early in the process and invited people to say whatever they want. And they do. We also spent time face-to-face with many of the beta users to ask their opinions of changes before we completed them. We know what we want to do, but we take care to marry our ideas with their desires.
The whole effort is guided by a few principles that everyone on the team can interpret individually.
Everything ultimately serves the vision: “what’s happening near you.” Observe constantly and respond quickly. Think in a network native way. Technologies and tools are there to empower people, not the other way around.
We certainly benefit from being close to the Guardian, too.
We have internal advisors looking over our shoulders like Guardian platform architect Graham Tackley, and we get bursts of insight from UX specialists like Martin Belam and Alastair Jardine. We can test ideas out on the Guardian editors, mobile teams and ad sales teams. We also get informal advice from some of the Guardian executives and some very insightful external advisors who check that we’re not being stupid.
Now, all of this is less of a method and more like a state of play.
We can be sure that the next 12 months will change around us and that users will change what n0tice means. But we’ve taken great care to make adaptation a core competency so that the core factors that got us to where we are now continue to help us do well.
That’s a principle inherent in the medium itself. Â The Internet is a messy, ever-changing, human-powered, technically and creatively diverse platform that means different things to different people. Â In my view, succeeding online means aligning what you’re doing with how the Internet works and the characteristics that make it meaningful and interesting and important in the world.
It feels like we’re on that journey with n0tice, so far.
Of course, all of this is a recipe for building stuff. Â What we haven’t yet proven is whether or not what we’re building fully captures people’s imaginations and becomes important in their communities.
Hopefully, I’ll have a blog post like this in about 6 or 9 months time describing an approach for successfully empowering healthy community activity, too.