Last time we thought about what we believe in as an engineering team was in 2012. The team has changed almost entirely since then, so we thought it’s a good time to think about what our principles are again.

The process

We started by asking everyone in the team these questions:

• What helps you succeed as an engineer at Songkick?
• When are you happiest at work?
• When are you most frustrated at work?
• Why are we here? What value do you think technology brings to Songkick?
• What are we lacking as an engineering team?
• What makes being an engineer at Songkick special?

We then grouped the answers to these questions into rough themes. Six themes emerged: Supportive Environment; Knowledge & Progression; Tools & Tech; Purpose; Space To Do Our Best Work; Quality.

These themes gave us the starting points for discussing what we care about as a team, which we did during our June offsite. We wrote down each theme on a big poster and discussed them using the World café method. On each poster we tried to answer questions like: Why do we care about this? What would help us achieve this? How can we do more of this? Or less of this? How does this help us?

Here’s an example of a poster at the end of the day:

We then tried to extract draft principles from everything we wrote down on the posters. This gave us a list of 50 principles or so. That’s obviously quite a lot so we took this long list and distilled it down into a more manageable list of six principles. Phew!

The Principles

We all own our stack

We’re all T-shaped developers. We each have specialities but we avoid knowledge silos. We treat pairing and code reviews as education tools and we use them when necessary. We never stop learning and we share what we’ve learnt with each other.

We code compassionately

Simple, maintainable code is our happy place — we choose readability over cleverness every time. We document what’s important, using an appropriate tool (git commit, code comments, wiki article). We follow the scout rule and leave things better than we found them.

We ship often and iterate quickly

Being able to release quickly and confidently is best for us and our users. We make small changes often and we use tools to help us with that. Our processes help us, not restrict us.

We’re here to deliver value

Technology is a means to achieve our goals, not the goal itself. Whether it’s our users, the business or both, we always keep in mind who we’re building products for. The right context helps us make the right decisions and we work together with the business to understand what value our work brings.

We take responsibility for what we ship

Quality and ethics of our products is a responsibility we all share. Everyone on the team can and will test. It’s what helps us sleep at night.

Writing code is not everything

Technical skills is just one of several skills we strive for growth in. We always have clear steps for growth and we designate time to achieve them.

What’s next?

We discussed the principles as a team and we were quite happy with the results. We are going to take these principles for a spin and check-in with the team in a few months to see how well they have served us. Is anything missing? Should something not be on the list? Do the principles still reflect who we are as a team and how we should be working? We’ll find out :-)