Engineering Team Manifesto by James Heywood

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

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,


Creativity & Productivity Coaching Bot by James Heywood

Evening all, just a quick post to point you at my latest project page.

I've just finished documenting a side project I undertook last year, building an online coaching 'bot' called Pep for a client of mine.

Hello from Pep!

My involvement with the project started when I was asked whether I could build a working application based on an initial prototype in InVision which the client presented to me, from here I was involved in market research, planning of the project, scoping of the product, requirement gathering, development, deployment and user testing.

The project page is a full write up of the project, as such, it turned into a bit of an epic but hopefully, it will be of interest to someone, and if nothing else it helps to clarify my thoughts and learning from the project, as well as add to my online portfolio of work.

If you have 10 minutes spare and are interested in the process of bringing a prototype product to market (or at least my experience of attempting this) then head on over and give it a read.

As ever comments are welcome here, hope you enjoy the journey.



Vue.js & Websockets by James Heywood

Evening all, so as mentioned in my last post I've been adding pages about personal development projects of mine to this site, the latest of which can be found here

I set myself a little challenge to learn about the Vue.js framework and also have a play around with web sockets, I came up with the idea of a simple collaborative note taking application and following this idea came up with the concept of virtual post-it notes, that each user could add, edit, archive and remove.

You can find out all about the project over on the project page, the write-up format differs a little from the last project as this was more of a learning exercise rather than a production/commercial application, I hope you like it, here's a little screenshot as a teaser.


That's all for now folks, stay tuned for more project pages.