I lift my eyes from the computer screen to see our programmer Jim standing at the door. He closes the door and says: “Hey, I need to talk to you about something”. My heart fills with dread – here it goes again….
This has been the third time he came in to complain. He doesn’t like to use JIRA, you see. He likes to use Hansoft because that’s what he used at his last job. He really wants me to switch to Hansoft. He wants me to switch the entire studio to Hansoft. The studio that has been running on JIRA for years.
After he leaves, more complainers take his place. An artist who wants the lights off in the shared office, an Assistant Producer who thinks our feature delivery process is flawed, and so on, and so on…
Naively I was proud for a while that the team trusted me enough to come to me with their problems. In fact, I encouraged it. I thought I was creating an open atmosphere where people were free to express their frustrations without the fear of reprimand.
What I didn’t realize is that I was breeding an atmosphere of dependence. What was wrong?
- The team became dependent on the manager to fix their problems. They came to expect it. They got lazy in thinking through the solutions themselves.
- It built a sense of entitlement. By listening to them and attempting to solve their problems I made them feel validated in their negative thinking and feel entitled to a fix.
- It did a disservice to their career development by building bad habits. No boss ever likes to hear about the problems without also hearing about a proposed solution.
- It made the team feel things are worse than they are. Rather than focusing on solutions, they focused on problems.
- It discouraged team spirit. People get suspicious when they see their teammates talking to the manager behind closed doors.
- It took a heavy toll on me. Listen to this complaining daily and you’ll start believing your team and your job sucks and everything is wrong. And since you can’t fix everything for everyone, you feel helpless at times. Hello, depression!
Once I realized what’s going on, I changed my approach.
I now have zero tolerance for “empty” complaining. Instead, I promote the following.
- Understand the problem, its context, scope and history before bringing a problem to the manager. How many people is it a problem for? How did the problem come about? Were there attempts to solve it before? Why things work the way they work?
- Have a proposed solution.
- Think your proposed solution through. Are there any edge cases? Limitations (budget, time etc)? How does it affect the rest of the team? What’s the cost (time, effort, money) of implementing it?
- Discuss the problem and the proposed solution with the team. Hear their ideas, have them beat on your solution and refine it until it “works” for everyone.
- Own the solution. There is a saying “initiative is punishable” 🙂 See the solution through, and enlist the manager to help facilitate it.
This approach has produced tremendous results so far. People on the team became more self-reliant and shown more initiative in finding and addressing problems. It brought the team closer as they solved problems together. It changed the outlook on their projects, job and teammates from negative to positive as they started focusing on solutions instead of problems. It built their confidence as they realized they had the power to change things. And finally, it helped restore my sanity as I no longer had to listen to “empty” complaints.
So my advice: discourage bitching and focus on solutions instead.
Dunbar is an anthropologist at the University College of London, who wrote Co-Evolution Of Neocortex Size, Group Size And Language In Humans. In that paper he states:
… there is a cognitive limit to the number of individuals with whom any one person can maintain stable relationships, that this limit is a direct function of relative neocortex size, and that this in turn limits group size … the limit imposed by neocortical processing capacity is simply on the number of individuals with whom a stable inter-personal relationship can be maintained.
According to Dunbar’s hypothesis, that limit is roughly 150. This became known as “Dunbar’s number”; this theory is wildly used in various Social Networks and even online gaming (MMOs).
I think this theory could also be effectively used when determining whether it’s time for a formal process or policy inside a growing video game company. In a company small enough, there is no need for formalities – goals can be achieved much faster in the absence of the red tape because everyone knows everybody else, what they are working on and what their expertise is in. But once the company grows past a certain number (say, 150 :)) – and people lose that information. At that point inefficiencies are introduced and formal process will help eliminate those inefficiencies.
Beware: once you start introducing formal processes, the key is to prevent the formal process from turning into bureaucracy and killing the company’s culture.
As a producer, you will frequently need to introduce a New Process to the team. You’ll work long and hard on identifying the problem areas in production, think about different ways of fixing those problems, and finally come up with a solution. “It we only did it this way, it’d all work out much better“.
You’ll probably quickly run the new idea by a few people, everyone is happy after some back-and-forth – and you send an email to the team. “Team, Starting today, this is how we are going to do this” … only to receive flaming emails in your inbox and angry people at your door. And your perfect New Process will crumble in front of your eyes like a house of cards.
To avoid it, every New Process must begin with the grassroots. Think of it as a political campaign where you are electing the New Process to the office. You first go to the very bottom of the org pyramid, to those deep in the trenches. You discuss the problem with them, listen to them and collect their ideas. You propose your solution but let them shape its final form. It’s solving their problems after all.
Key point: Every New Process must begin with the grassroots. Think of it as a political campaign where you are electing the New Process to the office.
You do it one by one, no large meetings here! It’s difficult to control a group; before you can control the group you must control the individuals. Make sure you talk to the most respected (by their peers) people first. Get their input and their support. Then talk to the leads, then directors. In this journey, make sure to listen and adapt your proposal based on feedback. Only when you know that you’ve got people’s support, that you’ve got the “key votes” for your New Process secured, you do go public with the New Process. At that point your email will be met with cheers rather than resistance. If there are few who didn’t know about and are opposing the New Process, they will be quickly converted by their peers who helped build the New Process and feel a profound sense of ownership in it.
It takes much more effort to introduce change to large teams like this, as opposite to just dictating it down. But in the end it’s worth it – the procedure was refined by those closest to the problem and in the process it became THEIR ideas, THEIR decision, they will understand it better and follow it eagerly.