Measurement of Management

Posted by Phil on October 16, 2018

A senior person in the company stopped by my office last week for a chat. I enjoy these moments - it's a perfect opportunity to sound out the mood and latest news from the view at the top of the company and offer a status update on my teams' contributions. This week was different though. We found ourselves on the topic of people management and evaluating the line manager's contribution to their performance. "If the team are happy and getting along with their work, how would we actually know how you influenced that? How would we assess your performance in leading and managing the people if everything is fine and there are no obvious problems?"

It's not an easy question to clearly answer. Obviously, if a team is in complete disarray and people are quarreling, resigning or failing to deliver results for the company, that's a pretty clear indication that the manager might not be up to the task (although even then - there are caveats). But if the water is calm and the ship's sailing a steady course, how does the leader demonstrate the results of their contribution? Similarly, does the absence of conflict and cohesiveness reflect a capable manager?

Productivity

There are many different ways to measure success, depending on the purpose of the business and the teams within it. What's a measure of success for an engineering team? Releases per month? Bugs? Story points? Perhaps you might argue it's some combination of all of those (probably with some other things) plus how efficiently these were produced. That is to say, if the team delivered on its commitments without working all weekend and late nights, are all pretty happy in each other's company, then that's a fairly successful result. The upshot though is that we can generally agree that a team's productivity can be observed through some form of quantifiable set of outputs that can then be used to shape our measurement of that team's performance. But this isn't the manager producing those outputs; it's the team. So we're back to asking "how is the manager's contribution measured?"

The thing with people management (or any form of leadership within a team) is that you aren't measuring productivity; you're measuring generativity. The expected outcomes and accomplishments in this capacity have shifted from "tactile" cognitive work - the physical outputs of software development, in this case - to "intangible" cognitive work: influencing the environment, flow of work and relationships in order to optimise the results of tactile work.

"The manager's function is not to make people work, but to make it possible for people to work"

Ok, so if the bulk of a manager's role outputs are intangible, how do we explore what their outputs should be? To help answer that, here are some more specific questions that should yield the sort of data that lends itself to better measurement:

  • What are the major objectives for which I am responsible?
  • What are the two or three things I must accomplish to be successful in this job?
  • What are the work environment characteristics we want to drive?
  • When do I look to other staff for input?

Financial reports or Objectives and Key Results are an easy - and probably a bit obvious - defacto measure of management success. If your department has stayed within budget for the financial year or revenues increase by 10% on the previous year, for example, those are probably noble and clearly-quantifiable outcomes. But as a people manager, what are you actually measuring when it comes to how successfully you're leading your team and encouraging your people to succeed?

Objectives from a "people / culture influencer" point of view may include retention rates, staff engagement, staff satisfaction / NPS (although I have personal views on NPS ratings), etc. Objectives might include shaping the culture: collaboration, communication, social interactions, "we need this team to interact and contribute more around X".

But the true measure of success for a people-focused leader won't necessarily be in specific, forecast targets. Typically the key gains will be found in how the team itself is functioning: is the mood in the office generally positive and fun? Are team members actively contributing to things and enthusiastic about their work? Are new initiatives being trialed or processes optimised? Is the work environment safe to make mistakes? These things aren't strictly something that can be set down as specific, measurable, time-boxed targets; they're progressive cultural artifacts that coalesce over time. For that to happen, you need a person steering decisions, information and responsibilities through and around the team.

In this sense, the trick is to detect rather than measure. Noticing things that need some attention and tuning, improving them and setting them on their way. Other KPIs like financials, shipped products or customer engagement scores will take care of themselves if the conditions within the team are set up to encourage the best possible outcome.

It's all engineering

When I left my programming role to take up management, I was genuinely worried that I'd made a terrible decision and that my true passion was really coding. With the benefit of hindsight, I can see that it wasn't the act of coding I was afraid of losing, it was the engineering as a means for problem solving. As a software developer, the enjoyment and sense of satisfaction I derived was from the tangible sense of accomplishment of building and maintaining something. Leadership is still an engineering problem, it's just that you're solving a "people engineering" problem now.

Buckingham and Coffman state that the relationship between an employee and their line manager is one of the most important factors in job satisfaction and whether employees stick around (First, Break All the Rules). I think it's more than that: I feel that people stick around in a team they feel resonates with their values and that allows them autonomy, mastery and purpose.

If we run with the engineering metaphor briefly, in programming, one of the basic goals is to optimise code, handle exceptions and remove bugs. In the same way, leadership engineering's measures aren't solely the observable gains across the team, but a reduction in the observable distractions: fewer complaints, fewer requests for information or permission and fewer mistakes or grievances. In short, better exception handling. It's these examples that are hard to measure. It's hard to quantify the absence of something.

Measuring leadership and management isn't specifically about meeting quantifiable targets. Sometimes that has perverse outcomes, as Goodhart's law says:

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes

In other words, "when a measure becomes a target, it ceases to be a good measure". That's true of team culture, alignment and values. A good manager optimises the flow of information, communication and collaboration within and across teams, and builds relationships. You can measure the outcomes from a successfully-gelled team environment, but if you're trying to shoe-horn a quantitative peg into a qualitative hole, you've fundamentally missed the point.

 

 

Photo Credit

Ethan Weil

rawpixel