I’ve been working at Ordered List for almost a year now and wanted to share some observations on how we work.
We launched two products this year while continuing work on our first. The ideas for these products came from spending time together hanging out, brainstorming, drinking a few beers, and talking about services we already used that caused us great pain.
The idea for Speaker Deck was born out of a frustration with other slide sharing services. Over a scotch or two Steve and John outlined what they envisioned a slide sharing service would look like, with me listening in intently.
When the conversation was over I had a pretty clear idea of what the initial product could look like and quickly volunteered to start working on it. At this point Ordered List was still just Steve and John, but this conversation, and my willingness to work on the product, eventually helped with them hiring me.
The ideas and visions for our products have varied greatly during our brainstorming sessions over the last year, but we always come back to the pain that inspired the product in the first place and execute on that first before moving on to some of the grander ideas we have.
After a product has shipped our users feedback begins to inform our decisions moving forward. We do our best to make it easy for them to share their ideas so we can add it to our brainstorming process.
We have very few processes that help us in executing our ideas, which is great, because it makes it easy for me to share them with you now!
Building The Right Team
I think the most important process at Ordered List is how Steve and John choose the people they want to work with.
They built their team with people who could work autonomously and take ownership of their products and client projects, filling in the gaps where necessary and taking leadership roles when called to. They built a team of unique individuals, each with different strengths. We have starters and we have finishers, visionaries and those not afraid to do the grunt work, those obsessed with the beauty of the code and those preoccupied with the beauty of the UI.
Over the past year we have been learning each other strengths and weaknesses and how to ask for help when we know another person on the team is better suited to make a decision or offer guidance. This has not been easy, but is essential to how we execute.
Whoever is the most passionate in an argument is the person that has put the most thought and research into it, so they usually win.
We do not avoid processes in our work day, but we definitely do not go seeking them out. The processes we use day to day are there only because it was more painful to operate without them.
We write tests first and implement second, except when we don’t. We use staging servers. We make sure deploying is easy and can be done by anyone on the team. This process of well tested code and a place to easily deploy it and make sure everything works as intended removes the fear of deploying code to production and having it bring down an entire service.
Using pull requests on Github has changed the way we work. Even more autonomy when implementing, but you still get asynchronous feedback once you get a feature to where you think it should be. We even switched to Github Issues for all of our products so that all of our conversations around code happen in the same place, next to the code.
Probably the most important but least obvious process that has emerged as we’ve coalesced as a team is how we communicate. Setting up email@example.com made starting email threads trivial, Hipchat made chatting during the day easy, and iChat or Google+ video chats kept us face to face with our two remote team members. Recently we’ve been using iMessage to text back and forth like a bunch of fourteen year old girls. Seriously.
We try not to ship a feature before it is ready, we prefer well thought out features, but some days we’ll ship six, seven, eight times if we’re fixing small things. There is no pressure to ship or not ship, when our intuition says its ready, it ships.
Everyone on our team likes shipping things we are proud of right out the gate. This doesn’t sound very agile, but since we’re building products that we use ourselves, we have a pretty good sense of what to build in the first place. Yes, sometimes things change once the feature is out in the wild, but this is not a common occurrence.
We take ideas, we boil them down, we build them, and then we ship them.
There is one other process I want to mention, my favorite one. We love to celebrate. Once a feature has shipped things have come full circle, the ideas that were born over a few beers have become a reality, and now we gather again, drink a few beers to celebrate, and start brainstorming the next big idea.