I was recently asked, “What is your management style?” I put together a few thoughts and thought I’d share here as well:
My management philosophy is that “Developers do their best work when they feel useful, supported, and appreciated.” (described in detail in the linked post). That said, more specifically, I believe in the following:
Manager’s primary responsibilities are:
To set the tone and expectations for the team culture:
This includes expectations around engineering excellence, creating an inclusive working environment, supporting individual’s learning and growth, enabling autonomy and accountability, and setting expectations of cross-discipline collaboration.
To Create Clarity:
That is, to ensure everyone understands what success looks like for the project, for a particular deadline, and for each individual.
To Deliver Success:
The buck stops with me on ensuring we hit our deadlines. This means we create an environment where we are honest about risks, engineers are encouraged to speak up and raise issues sooner rather than later, we include time in development cycles for testing and bug fixing, and since we know what success looks like, we are able to quickly reprioritize when the unexpected happens.
To Generate Energy:
It’s easy for a team to get bogged down in the day to day, so I believe it’s important for the leadership to celebrate successes, help the team keep an eye on the big picture, and generally don’t let the team forget how awesome it is to be working in this industry. If the team is having fun making the game, that’s likely to be reflected in the quality of the game itself.
Manager’s additional responsibilities are to:
To Build Trust:
I am also a strong believer in the importance of building trust across disciplines. As a manager I spend a great deal of time ensuring every discipline feels like equal contributors and we are delivering on the highest priorities across all disciplines, not just engineering. I had a PM once tell me, “I’ve learned that if John says everything is okay I don’t need to worry. And when John tells me this is something we should pay attention to, I know it’s important.”
To Provide Perspective:
I regularly find it useful to offer a holistic perspective to development. If a decision won’t matter in five weeks, it is not worth over-stressing about today. In five years you won’t remember the details of the project deliverables, but you will remember how the team made you feel and whether or not the project was a success.
To Expect Failure:
I truly believe that small failures are necessary ingredients for large-scale success. Inexperienced developers are often so afraid to fail that they are unwilling to take risks or try something new. Innovation requires experimentation, so I work to ensure all engineers know that failure is not just okay, but it is expected. If you are not failing regularly, you are not learning. Fail fast, learn, and move forward.
Facilitate (Multidirectional) Communication:
I’ve learned that communication is key to success both up and down the chain.
- Upper management requires accurate project status to make strategic decisions.
- Colleagues share learnings and resources when they are aware of concurrent (and sometimes inadvertently redundant) work.
- Individual contributors need context and perspective on strategy to ensure they are able to work with autonomy.
With this in mind, I believe it is the manager’s responsibility to find the best ways to communicate with each stakeholder. Whether it’s a monthly newsletter, a team status update, an all-hands meeting, or a daily update at standup.. finding the communication channels that work best for the team without being a distraction from focus time is an important part of my management style.
