Engineering Team Values at PlayerData
Team Values are concepts and behaviours that we value as a team; they are the things that we think help us succeed. Discussing Team Values can be a really useful exercise in itself but it’s also a great way to keep team purpose and goals aligned as a team grows.
When a team is small it’s easy for everyone to discuss things and make decisions but this doesn’t scale. Team Values can increase decision making speed across bigger or more distributed teams as there’s less need to escalate decisions if there’s an agreed way to approach problems.
Every software engineering team works differently so hopefully you find some interest in learning a bit more about how ours works.
Our Values
Always build the right thing
This value isn’t about building the right user feature (we don’t have a crystal ball!) - it’s more about building things in the right way.
We start by building a minimum viable solution in small iterations. This allows us to get early feedback from users, enabling us to quickly change direction if we’ve built something that doesn’t work as hoped. Once we know the core feature is valuable to users and works well we can add to it.
We also make sure any technical decisions we make can be backed out easily if they turn out to be wrong. We see the value in doing the simpler thing that solves the problem now, even if we know a more complex solution might be needed in the future.
Maintain strong foundations
Our development tooling is the foundation that allows us to ship high quality code reliably, so we’ve made it a first class citizen. It’s a bad feeling when you can’t get your work done because the tools aren’t up to the task.
If we come up against an annoying or time consuming process we try to automate it; if it saves us time, it’s worth doing.
Another part of our strong foundations is the quality of code we write. As a developer you spend most of your time reading existing code. That’s why our goal is to write high quality, human readable code. We want our systems to be understandable and extendable by anyone on the team.
We also aim to reduce tech debt because it’s a cost you pay every day in wasted cognitive load and developer time. It’s not some theoretical future cost.
Stop, Collaborate and Listen
We try to collaborate closely by pair programming often and soliciting feedback early in the development process.
Two heads are better than one when it comes to tackling a hard problem but we also recognise the need to work alone and let teams organise themselves in ways that work best for them.
We recognise that getting feedback is important and listening to it even more so. We run regular retros to find out the positives and negatives currently affecting the team. Crucially we record actions based on that feedback and track the progress. This way, we know feedback is being listened to.
Blame Systems (not people)
We operate under a personally blameless culture in the engineering department. We will never point the finger at someone personally for making a mistake.
When something goes wrong we try to fix the system that caused it. Automated processes are better at catching issues than humans are. For example, if there’s a code pattern that caused an issue we will write a linting rule for it; if an error case was missed at code review, we make sure there’s better test coverage next time.
Testing gives us confidence
We like to deploy our code multiple times a day. Our suite of automated tests gives us the confidence to do this. To maintain that confidence we value testing our code thoroughly, with both unit and integration tests.
The confidence in our release process also comes from the manual smoke testing we do on changes we’re making. It’s up to us to think of the edge cases and ensure we’ve got them covered. So, where possible, we do a manual test of a change before it gets merged.
How to generate Team Values
Our process for deciding our Team Values was to get all members of the team to prepare up to five general headings for values and then bring them together in a meeting. We put all ideas up on a board and organised them into themes and distilled the themes down into the values we have today.
I think it’s important to generate values in a way that gives the team ownership over them. Values also need to be reviewed and revised over time to keep up with changing culture and processes in your team.
