Company Culture as Principles Pt. 2
*This is part 2 of a 3 part series. Part 1 can be found here, and part 3 is here.
Recap
In the previous post in this series (Pt. 1: here) I wrote about the reasons why we chose to define the company culture as a series of principles early on, as well as taking a look at some of the first Principles in the document. In this part 2 of 3, I’ll take a look at the next set of Principles in our culture document and explain why we added them.
1. There can be no success without effective communication (continued)
4. Before creating a full design, make sure you speak to your relevant counterparts in Design/Engineering/Product/Art about your plan.
Example: An engineer designing a system which affects the player experience, should work with the Product Lead/Designer to ensure the outcome matches the vision for the game.
We work to avoid teams working in “silos” where different disciplines aren’t in communication throughout the development process. There is an initial overhead in terms of time spent on communication but it helps avoid costlier mistakes further down the line.
4.1 If you create a design you are responsible for following-up and making sure it’s implemented as intended. Speak to people early and check-in throughout development: this will result in fewer miscommunications and less time wasted correcting avoidable issues.
4. 2 It’s your responsibility to keep checking-in on your features until they’re live.
We push people to “own” their features. Whoever initiates a design is responsible for making sure whatever goes live matches their initial vision.
5. Things will go wrong, it’s a natural (and unfortunate) part of the development process. We want to create a high trust environment where people speak up when they see things.
5.1 “Be louder”
5.1.1 We need everyone to speak up when they see a problem, regardless of the rank of whoever is responsible. Seeing a bug in a game or an issue in the company and not speaking up, makes you complicit. We will always forgive honest mistakes, but not speaking up is not OK.
5.1.2 If you encounter a bug mention it to the person working on the feature and QA/Product Lead. Product quality is everyone’s responsibility, if you spot something it’s your duty to make sure it gets recorded.
5.1.3 If there’s something you’re not happy with, it’s your duty to speak to someone who can help you resolve it (like your manager for example).
There are two components to this:
1 — No matter how good we are, mistakes will always occur
2 — People perform at the top of their ability when they’re not afraid of making mistakes.
We make people aware that we understand this, and we empower them to call out problems wherever they see them, regardless of the person responsible. *This is similar to the Andon principle from the Toyota Production System
5.2. At Mighty Bear we strive for “strong opinions, weakly held”. Believe in your way of doing things, but be radically open-minded to other (and maybe better) ways of doing things.
5.2.1 The end goal is a “high conflict, low intensity” environment. We challenge each other openly and frequently, but both sides keep an open mind and resolve things quickly.
6. We will never punish anyone for speaking up or disagreeing.
6.1 Learn to love criticism: We can only improve by gathering feedback from people with other points of view.
6.1.1 We make an effort to seek out different opinions, even if they’re critical of our own.
We encourage our staff to challenge each other’s opinions and assumptions, and be open to better ways of working.
Openness to other people’s ideas and feedback is a pre-requisite for success, and we encourage everyone here to actively seek out dissenting views that challenge their assumptions.
Good ideas can come from anyone. We encourage everyone to speak up regardless of rank. No-one has a monopoly on good ideas (certainly not me!)
2. Time is our Scarcest Resource
Time is our only non-renewable resource. We optimise everything we to do to ensure we make the best use of our time. If we can get that right, we’re ahead of 99% of the studios out there.
1. Meetings are to be kept to an absolute minimum.
1. 1 No sidetrack discussions. If it’s not relevant to the wider group, then seek out those who it is relevant to afterwards.
1. 2 If a meeting isn’t relevant to you, feel free to get up and leave.
Meetings suck. We keep them to a minimum and we respect people’s time. If a discussion isn’t relevant to someone we’re fine (and we prefer it) if they leave and do something useful with their time.
2. Don’t waste people’s time in meetings by reading to them. Document your work and make sure people have read it before sitting down to clarify, discuss, and share ideas.
2. 1 If you haven’t read the Design then ask to postpone the discussion. If this is not possible then don’t attend the meeting. We can’t carry people who have not taken the time to get up-to-speed.
2.2 Make sure you give people at least 24 hours to read and think about designs before asking them to discuss.
2.2.1 There will be times where this is not possible, but these should be the exception.
We don’t allow people to rock up to meetings and expect feedback on a document which people haven’t had the time to consider, it’s a waste of everyone’s time.
If someone starts trying to gather feedback without having circulated the materials ahead of time, or if it’s clear the people who are supposed to be giving feedback have not prepared, we end the meeting there and then.
3. We have to be radically realistic when discussing plans. Discussions around “what should be the case” in an ideal theoretical scenario are not helpful. Our discussions are based on current plans and resources.
Game developers (Designers and Engineers especially) can stray into “theorycraft” during discussions. We make sure everyone stays focused on what’s doable right now rather than utopian visions of game development.
4. A bad decision taken quickly is always preferable to taking a long time to get to the right decision, or worse still, taking no decision.
4.1 Mistakes are OK if they help us realise how to get to the end goal faster. Indecision is never OK.
4.1.1 Don’t hold up development to get the input of someone who is unavailable. If a decision needs to be taken and the decision maker is out of the office, then call them. If they are uncontactable or on leave, take the decision yourself.
4.1.1.1 If you’re not comfortable taking ownership of a decision that needs to be taken then ask someone more senior to decide on the appropriate course of action. Don’t hold up development waiting for people to get back from leave.
We push people to take tough decisions rather than avoid them and have an outcome forced on us at a later date. If someone isn’t comfortable taking a decision it’s OK for them to escalate it for someone more senior to decide.
5. Addressing issues earlier in the production process saves time, money, and pain. We should do everything possible to catch issues sooner.
5.1 Strong QA processes save time and money. Ways to improve testing should always be at the forefront of our thinking.
It takes longer to fix problems the later they appear in the development process. To give ourselves the best chance of success, we structure our development processes to catch problems as early as we can.
5.2 Teams which are working on complimentary components need to be paired and work together in tandem, rather than working on components at different times or across sprints. This costs time in the short-term, but improves long-term effectiveness.
We combine teams working on similar features to reduce the risk of miscommunication and issues integrating them.
6. An extra hour spent planning can save dozens of hours in development
6.1 The core sprint deliverables should be explicitly agreed at the start of the sprint.
6.1.1 This means that for any feature that is considered “core” we need to agree on precisely what functionality it will include as part of the sprint deliverable.
6.1.1.1 Having an agreement to deliver “as much as possible” of a key feature will only result in all parties being disappointed in the end result. Product/Design and Development will usually end up having different aspects of the feature in mind as key deliverables and neither will be satisfied by the scope of the of end result.
Proper planning saves a lot of pain and developer anger. Everything should be clearly defined with the success criteria agreed during the planning phase. Agreeing to deliver “as much as possible” ends up with everyone being angry at each other: some will feel they overdelivered, and the others that it wasn’t what they expected, or that enough work was done.
6.2 Stretch goals are fine, but they should not be overdefined.
6.3 Stretch goals should only be delivered after all the key deliverables have been met.
It’s good to have stretch goals, but don’t spend too much planning time on them . They should only be addressed once everything else has been delivered, if your planning is at the required level this shouldn’t happen very often.
That’s it for Pt. 2 of the Mighty Bear Principles. In the next instalment we’ll share the final pieces of the document and some thoughts. If you enjoyed this then please leave claps and comments below!
