Post navigation

Can data make you a better manager?

Is there a more creepy term in the world than “people analytics”? It reeks of an Orwellian world where bosses spy on their employees and use data to manage them like robots.

Beyond the paranoid overtone, though, “people analytics” is a term that actually has good intentions at its heart. And those intentions are to create a happier place where data and information can be used to help managers provide better support to their employees. See, data in itself is not evil; it’s the way that people often use data that causes problems. “People analytics” can be a great positive for the employee.

The term “people analytics” rose out of Google’s human resources, or People Operations group. Like everything else at Google, innovation in the People Operations group stemmed from embracing data. The general philosophy is sound: if finance, sales, and engineering are making data-informed decisions, shouldn’t we do the same?

What is “people analytics”?

It started in early 2009, with Project Oxygen, a study designed to “build better bosses”. The People Operations group analyzed and looked for patterns in performance reviews, feedback surveys, and nominations for top-manager awards. From the analysis they were able to create a list of the top attributes of the most effective managers at Google. In general their findings were obvious, but they did surface some counterintuitive observations.

For example, they found that “technical expertise”, ranked dead last among the top 8 attributes of the most effective managers. What employees valued most were even-keeled bosses. These were the bosses who made time for one-on-one meetings. The bosses who helped people puzzle through problems by asking questions, not dictating answers. And the bosses who took an interest in employees’ lives and careers, not just their day-to-day work.

In a nutshell, they discovered that management matters and management centering on the softer side of things matters even more. Certainly, this observation was a positive one for the employee.

Let’s take a hypothetical use case to test this idea: managing software engineers. Specifically, we want to know: can we use “people analytics” to manage an unmanageable software engineer?

To define success, we must first define the job of an engineering manager. As I pondered the question of people analytics and managing software engineers, I had In conversations with many experienced and respected software engineering managers, and a universal theme emerged: an engineering manager’s primary job is to unblock their engineers. This means to removinge obstacles when an engineer is stuck. But how does a manager know when his engineers are stuck?

Face to face meetings, standup meetings and scanning through commits, code reviews, and JIRA tickets are some of the best practices for exposing blockers. But is this the most efficient process? And does this scale as engineering organizations scale?

In one word, no. As technical organizations get larger one of the greatest hindrances to growth are people management issues. Hiring and training good engineering managers is difficult so often as the number of engineers in a company grow the number of managers does not grow in step and they are left trying to manage more than 10 engineers. The aforementioned techniques simply don’t work when you are responsible for that many people.

Isn’t this a problem that data and “people analytics” can solve? Are there patterns in the way that engineers work that can expose or maybe predict an engineer being blocked and needing help?

The simple answer is yes. But with an asterisk.

Take for example a simple data point that an engineer hasn’t committed any code in two days. In a vacuum this means nothing. But in the context of a manager knowing that this engineer is working on building new features for an important release, this means problems.

Imagine if there were a system that could prompt the engineering manager that they might want to check up with the engineer to see if he is blocked and needs any help.

Here’s where “how the data is used” becomes a huge determiner in whether this is creepy or is helpful for the actual employee. A good manager would use this information to opportunistically ping his engineer in a very non-intrusive, non-accusatory manner. This would present the engineer an easy way to ask for help, something most engineers are bad at.

Let’s take another example of a team that uses GitHub and pull requests. Imagine a system telling a manager that an engineer has had many pull requests that were open beyond an acceptable amount of time. This would give the manager insight that the code review process, collaboration, and/or teamwork were all not up to par for this engineer. The manager could then proactively talk to the engineer in a one on one about whether the engineer was struggling at all with the team dynamics or processes.

Both of these are simple cases but they highlight how passively collected data can give the manager a head start on helping his team out. The manager is becoming a better manager by being better at unblocking his engineers. He is better at unblocking them by having access to useful data insights in a timely and useful manner. The end result is a manager who is better at helping his people.

When people analytics go bad

Obviously this previous scenario is the ideal case, and data in the hands of the wrong manager can be detrimental to the employee. We have all been cautioned about measuring developer productivity with flawed metrics like lines of code and really there is no single metric for measuring developer productivity.

If a manager uses data or pure metrics to make inferences about his employees without actually looking behind the numbers, we’re all in trouble. Take for example a manager who wants to stack rank his engineers based on number of commits made over a given time. Perhaps his goal is to determine who was the most productive during that time frame. All commits are not created equal and the above exercise would simply be an exercise in futility.

There is also a valid concern that software engineers will game any system that they know they are being measured on so exposing metrics to them will create unintended consequences. Managers need to explain how data is being used and must ensure the engineers that they aren’t being measured by metrics instead they are using the data to help the engineers.

Making people analytics work in the future

As long as we focus on that – helping the employee – “people analytics” will be a huge step in solving the management riddle. The exciting idea is how we can use this data in the future to stimulate and improve the softer side of management, coaching, mentoring and motivating. With more and more data produced each day about how people work, the amount we can learn from the data is likewise growing. The possibilities are truly endless as the way we work evolves.