Engineering Team Manifesto

The time has come for me to move on from my current role, and as is frequently the case when changing jobs this situation provides an opportunity to reflect on things, what went well and not so well and how I will approach the next opportunity.

One of the things I am most proud of from my time at Airfinity (and there are quite a few, not least of which is the amazing team I worked with, props to you guys) was the culture of the engineering team we set out to build and achieved.

As the first permanent engineering hire I was responsible for hiring and building out the team and our capability and the first thing I did was to sit down and think about the culture I wanted the team to have, the type of team i wanted to hire and work with, the kind of thing you don’t often get the chance to directly influence.

To ensure I had a point of reference I wrote this down, and looking back on it now it strikes me that this was in some way a manifesto for how I think technical teams should be, so I thought I’d share it with you here, because not only is it something I firmly believe in and that we should all aspire to, it was something we achieved and I am immensely proud of that, so here it is.

Engineering Team Culture

The culture of a team is one of the major factors influencing how enjoyable work is, it is vital that as we grow we nurture and retain a supportive, collaborative and enjoyable team culture.

This manifesto outlines a few main points that we would like to define our engineering team culture, it has been put together by the team lead with consultation and input from all members of the company.

We are all Product Engineers, not Software Engineers.

The distinction is important, we must all contribute to the definition of features and direction of the product. If we have empathy for our users we will create better products, everything we do should be aligned with the strategic goals for our products and company.

There are no stupid questions.

If you have a question, just ask. You will not be ridiculed or made to feel bad for asking or checking something. We must all prefer to answer a question to help keep work moving or clarify an issue than have someone struggle because they are reluctant to ask.

We strive for clear and frank communication.

When we stop communicating we are in danger of doing or building the wrong things, we must all keep informed about what we are working on (hence our stand ups, estimation, etc)

BUT - a brief conversation > an hour long meeting

Strive to communicate clearly and often, avoid expensive team meetings where possible (leave those meetings to the team lead if engineering must be present)

We will remain as flat as a pancake.

There is no hierarchy, there are however variations in depth and breadth of experience.

We should celebrate our differences and remember that we are greater than the sum of our parts, rather than adhere to a layered hierarchy.

We are all Product Engineers, it’s just that some of us have different areas of specialism and more or less context to the company and technical stack.

Everyone is able to work on any part of the technical stack.

We’re not saying that we want homogenous skill sets, as that is unrealistic, but we do want the ability to share the work across the team (via mentoring where needed) for multiple reasons;

It keeps things interesting and provides learning opportunities

It fosters a culture of knowledge sharing, preventing knowledge silos

It means that we can take holidays without fretting about something back at work

We actively encourage learning and development.

We want to build and maintain a team that enjoys learning new things, this growth mindset must be a key trait of team members.

Learning new technologies and techniques increases our value to the team and improves the products we build as well, it also motivates team members and helps drive innovation

Build, test, deploy, review, iterate.

Better to ship a feature quickly and review its usage/impact than to fuss over every possible edge and side case and take forever.

We can always iterate a feature, but we won't catch every edge or side case upfront so ship it and review

Long running tickets cause bottlenecks in delivery, ship and move on, raise a new ticket if needed

Deploy your own code, and sometimes other people’s!

We are all responsible for deploying our own features, unless unable to or it makes sense for someone else to do it

Sometimes it is helpful to deploy others code, and from other areas of the technical stack to your usual responsibilities, this helps share knowledge and workloads

If you broke it, you fix it.

Related to the above two points, bugs happen, if we don’t break a few things then we aren’t moving fast enough

BUT, if you break something by deploying your work, you have to fix it.

Of course your team-mates can ridicule you for the bug/all help out to resolve the issue, you will never be on your own when this happens

Have fun.

What’s the point of all this if we can’t have a bit of a laugh?

Let’s try and have fun whilst we work and if it’s ever not fun, please let your team lead know so they can try and fix things/address any issues

In summary

So there you have it, reflecting on this document (written nearly 2 years ago) I feel like we achieved this in our team, so I’d like to preserve this here for future reference and as a reminder that a supportive, collaborative and fun work environment is achievable with a bit of effort and perhaps also some good fortune regarding the organisation and context you are a working in.

I’ve worked in tech for twenty years and sadly this kind of environment has proven to be the exception, but I will do my utmost to ensure this culture prevails in all of my future roles and teams, I hope this inspires you to try the same.

Thanks for reading,

James.

Originally posted on my blog