Engineering Management and Diversity

I’ve been an engineering manager at Yammer for a year and half now. This isn’t my first rodeo, but my previous experience leading people was over 5 years ago. These two experiences have been very different, and the gap between has given me a lot of perspective. At the core of this perspective is a recognition of two different kinds of “management”.

The first type of management I call command-based. This is the one most of us assume when we hear the word “management.” Here, the manager is the top contributor, and treats the team as an extension of themselves. This makes sense to most people, because managers are usually chosen based on their success as an individual contributor. Their job is to get a team of people to do what they would’ve done.

In this model, engineering managers are primarily responsible for the success of projects and the quality of the work. The team is expected to follow their lead and defer to their judgment on important implementation decisions. In many orgs, the manager is even responsible for breaking down all tasks and assigning them to individuals on the team.

But this approach has some consequences that are not obvious.

Photo CC-BY Jessica Drossin, filtered.

Managers in a command-based org are under a lot of pressure. They take on all of the responsibility for the outcomes produced by their team. Engineering managers are held accountable for bad code, failing builds, production outages, etc. They may lead a large team of engineers, and they may spread that accountability around by exerting downward pressure. But eventually, the buck stops with them.

We all know it’s impossible to have full control over outcomes. Yet a manager in a command-based org is asked to control the outcomes of a group of engineers using any means at their disposal. When the team faces challenges, you see this control exerted in many ways. If you’ve ever had this kind of manager, you’re probably familiar with these. We talk about “micromanagement”, where the boss is constantly looking over your shoulder and questioning your work. We see strict timekeeping where managers want to be able to account for the hours everyone spends working. In engineering, this is at least partially responsible for managers who also serve as “architects”. They control the work by describing the system in detail and demanding that it meet their exact specifications.

At least in software, where I’m most familiar, there’s the sense that engineers will go off the rails if left to their own devices. The manager’s job is to look over their shoulders, keep them on task, find missteps before they get too big. This fits well with a command-based structure. The trouble is that the longer the manager stays away from producing work themselves, the less their judgment should be trusted by the team. This is the core problem with manager-as-top-contributor: the longer you are a manager, the less likely that you’re able to maintain your level of skill and competency at the work the team does.

Command-Based Management and How It Impacts Diversity

Photo CC-BY Benoit Dupont, filtered.

It’s not difficult to see many of the problems caused by command based management. But when we focus on diversity, we can uncover a more subtle effect. The tech industry has come under fire in recent years for its abysmal track record on diverse hiring. This industry is overwhelmingly populated with white males with the only other significant ethnicity being asian males. Women, minorities, and other marginalized groups are woefully underrepresented. As we go up the ladder to management, these numbers get even worse. I believe the perverse incentives of command-based management can help us understand at least some of these factors.

As command-based managers are accountable for all outcomes of the team they lead, they’re incentivized to find ways to control as many factors as they can that affect these outcomes. I’ve mentioned some of the obvious ones. But another important factor in team success, arguably the most crucial, is hiring the right people. A manager needs to hire the people they think are most likely to do things the way they would’ve done. And it’s here that we find a great deal of bias.

How can a manager know if a candidate can produce the way they would? We learn how to evaluate technical skills, but that still leaves so much to chance. Do they work hard? Are they reliable? Will they work well with the rest of the team? It’s difficult to get confident answers to these questions before hiring. But it’s easy to fall back on our own experience. It’s easy to take a liking to that person who has a similar background to us. Maybe they went to the same school. Maybe they started with the same programming language. Maybe they just remind you of yourself, or other smart people you’ve seen be successful.

Most of us would never admit that these factors affect our hiring decisions. Though sometimes people acknowledge this thinking — like when Paul Graham admitted his bias towards founders that look like Mark Zuckerberg. These biases make it very difficult to take a chance on people you can’t relate to. If you’re an engineering manager, you’re probably used to engineers who look a certain way, act a certain way. It’s tough not to fall victim to the norms that have developed around tech culture. If all you ever see is white men doing this job, how will you react when it’s a woman sitting across from you in an interview? Can you really see a black or latino person being that awesome geek you pictured yourself hiring?

In tech, there is plenty of evidence that says the answer is no.

Service-Based Management

Photo CC-BY Josep Ma. Rosell, filtered.

Command-based management has lots of flaws when it comes to building functional and diverse teams. But there’s another type of management: one where the manager isn’t responsible for the work, but for building a team that is effective at execution. The manager’s job is to support the team and facilitate whatever they need to be successful. I call this service-based management.

Many managers read this and think that’s the job they do today. But there are some key differences. Most notable is that the service-based manager is not seen as the top contributor. Maybe they used to be when they were on the team. But when they accept the new role, their focus needs to shift. The manager is going to produce very little work, maybe even none at all. The responsibility to consistently produce quality work falls squarely to the team.

A service-based manager doesn’t participate directly in deciding how the work gets done. The manager’s job is to establish high expectations for the team and set direction to help the team to meet those expectations. They establish trust with the team, understand and remove obstacles, and help the team develop ownership over their work.

A service-based manager is still intensely concerned with team outcomes. And outcomes can still be measured even if the manager was removed from the process. In engineering, some of the same tools apply. Monitoring the success of releases, number of bugs generated, etc. If these outcomes don’t look good, you take this information to the team:

“Our bug queue is out of control. What’s up?”

This is a test for the manager and for the team. Does the team know what the problem is? Can they communicate it effectively to the manager? Does the manager trust their judgment?

In a command-based system, it’s questionable whether these things are true. The team expects the manager to be on top of things. This sometimes means they have a narrow view of the world and don’t always have perspective on the problems that occur. A service-based manager has already set the expectation that the team owns the bug queue. So they should know what’s going on with it. They should tell you immediately why it’s in the current state and what they’re doing to fix it.  If they can’t, then they are failing to meet expectations and that has to change. The next step is giving the team the space to fix the problem. One of the major themes of service-based management is ownership. The team will excel because they know they own the problem. They don’t expect anyone else to do it.

Creating a cohesive team and building trust is part of a service-based manager’s job. It takes a lot of time and a lot of empathy to get the team to trust in their manager. My experience with 1 on 1 meetings with command-based managers haven’t been very useful, because it’s usually about control. “Here are your tasks. How are you doing on your tasks? Let’s talk about some tasks you didn’t do.” A service-based manager trusts that the individual in front of them knows what to do. They are looking for ways they can help.

My 1 on 1s now consist of things like “How’s this going? Any roadblocks? I can take care of that”. It’s also a time for constructive feedback, both positive and negative. “It looks like you’re having trouble with this. Let’s talk about how to improve.” Building trust is a constant conversation.

Service-Based Management and Diversity

Photo CC-BY Gemma Stiles, filtered.

Taking a service-based approach to management can also help with some of the challenges of diverse hiring. Changing the focus to serving the team provides opportunities to avoid bias.

In a service-based system, the manager isn’t directly responsible for the work that gets done. This has the effect of removing the problematic incentive to exert tight control over how it gets done. Micromanagement of individuals on the team is no longer necessary when outcomes are more important than controlling the work. In fact, giving people more freedom and autonomy in choosing how they get their job done has been shown to make them more productive.

When you value autonomy and flexibility as a manager, you can create an environment that is inclusive of different work styles. People who get tons of work done during off hours have less pressure to also be productive from 9 to 5. People with families can leave early or come in late when they need to, without the stigma that they don’t work as much as the rest of the team. A team that focuses on outcomes can welcome people with lots of different circumstances and backgrounds rather than matching a certain “culture fit”.

Having a manager shift focus to building a productive team also has benefits when thinking about hiring. A command-based manager might ask “how can I find a great engineer to fill this position”? This person is likely to fall back on these norms of what a great engineer looks like. But a service-based manager instead goes to the team and asks “what kind of person would make this team more successful”? Not only does it leave open a wider range of answers, it helps the team have a more nuanced view of candidates.

Involving this team in hiring can help avoid a monoculture when they look to add strong compliments to the team across a wide range of skills: “I think we would really benefit from this person’s expertise in web accessibility.” And a cohesive team will expect to work together to support each other, rather than judging people where they may be weak: “They stumbled a little on algorithms, but I think they can rise to that challenge with some experience.”

The hiring focus in this model is evaluating a wide range of skills and qualities in a candidate, and bringing the whole team’s perspective to bear on hiring. It becomes much more difficult to judge candidates just based on good coding skills and a gut feeling. The team is incentivized to create a more rigorous system to gain confidence in new members. And the manager can help with that.

These are only a few aspects of how outdated organizational systems can make it more difficult to create the kind of environment people can thrive in. Moving away from the traditional notion of command-based management is a great step towards companies that can be more inclusive as well as more productive. Exploring different approaches to management can have profound effects on your team and your organization.

This article was originally published in Autumn 2014 as part of Model View Culture Quarterly #3.