Before becoming a manager at New Relic, I was an engineer myself, working primarily on backend coding and database tuning. As I’ve developed my management skills I’ve also observed that you can apply many of best engineering principles towards becoming a better manager and increasing your impact on the organization. This is the first in a series of posts where I’ll explore the parallels between software development and effective management.
As an engineer
When I started as a programmer, the basics were hard. I struggled with syntax, understanding errors, and building a view of the system. At first, I worked within the current structure of the code. I was afraid to make larger changes, and sometimes when I did the results weren’t pretty.
As I became more experienced, the problems became more familiar, and I became more willing to make larger changes that improve the design. I learned when it was a good idea to change the design completely and when it was best to make small improvements or leave it as it is.
Later, I observed more experienced engineers work magic. They intuit the intent of a system and imagine how to create something completely new, out of thin air. They also visualize how to rework a complex system to be more elegant, and incrementally move the design to that new vision. At times I touched this magic next level, but at others it eluded me.
As a manager
In the same way, as a manager, I started with a narrow set of tools, and copied patterns from my colleagues and from what I observed. Initially, I didn’t change things much, but tinkered to make things better within the general structure already in place. For example, I ran a large release, and mostly copied what I had seen others do in the past for that release, even though in retrospect there were a lot of things I should have done differently.
As I became more experienced as a manager, I began to see new possibilities that would improve the team (and later, what would improve the organization). I could then imagine new levers to pull that were invisible to me. I could see how things should be, and see the levers to pull to recreate the organization in a better way. Running that same big release nowadays would be easy, because there are so many levers to pull and ways to approach it.
Refactoring organizations is a lot like refactoring code. In the today’s post, I’ll start by talking about the power of pull requests (in management), and then move on to how clear role responsibility is similar to the “don’t repeat yourself” principle in code.
Pull requests > filing bugs
Last year, we held management meetings where we would talk about the problems our teams were facing. We discussed in abstract terms what we might do better as managers. For example, we asked, “How are we doing with quality?” We’d then walk away from the meeting with to-do items and inspiration, but ultimately felt that something was absent. What was missing? Energy and focus.
So we changed the meetings to focus on proposals instead of problems. Stating and identifying problems is fine, and sometimes it’s all we can do when the solution eludes us. But proposals are the heavy artillery in meetings. They force us to focus on possibilities, and they force us to do our homework and weigh the alternatives.
After we adjusted the focus of our meetings, we also developed our own method of proposing things to the rest of the management team via email. It functions very similarly to a pull request: we send out the proposal, and if we get enough +1s, that means the idea is approved and we will go ahead and act on it. This little change improved the speed of our decision-making, and increased the momentum of our meetings.
Don’t repeat yourself (DRY)
In code, you only want one part of the code to be responsible for a given problem. You don’t want different parts of the code solving something in different ways, or a bug to be fixed in one place but not the other. You also face difficulties resolving differences between extremely close, but not exactly similar, parts of the code. In teams, the same principle applies. For areas of responsibility, you want a single person or a single role owning that job or problem.
I recently conducted an experiment. I made a list of the challenges facing the team and areas where team members want to improve or focus on. Next, I assigned each problem or area to one person on the team. Here’s an example:
Jack is our customer angel. He makes sure the experience for a new person using our software is so seamless that they require nothing more from the team than to be referred to our getting started docs. He incrementally improves our documentation and makes sure they have a great experience.
Jack knew that he was solving a big problem for the team — many teams were using our software, and they often needed a lot of assistance. He tackled the problem on a couple of fronts. First, he improved our documentation. Next, he improved our APIs, so they were more straightforward. He had full reign to address the issue, and he did a fantastic job of it.
The alternative was to have a meeting on how to improve things, or to have a project to fix it. But he completely owned the solution and probably enjoyed it a lot more than he would have otherwise. The end result was that the amount of time the team spends supporting requests for help has plummeted, and is no longer a large portion of the team’s time each week.
Responsibility is a way to avoid meetings and solve problems faster. This is just like code. In both examples, you have one clear place to go to get an answer.
More parallels to come
In my next blog post, I’ll talk about other areas in which organizing code and organizing teams are similar.
If you’ve seen any engineering best practices successfully put to work in team management (or have some parallels of your own), share them with us over in this Community Forum thread.
We’re looking for great managers