Managing Developers? Measure, Don't Micromanage!

For most of us, we don't like micromanagement and it isn't something we think is healthy in the workplace.

This view is backed with empirical evidence. Google's rigorous manager research (in Project Oxygen) found that effective managers empower their team and do not micromanage. They trust their team and advocate for it in the wider organisation, balancing freedom whilst being available for advice. One Googler described how a manager empowered her team: "She lets people run with ideas, but knows when to step in and offer advice to not pursue a failing issue.”

A Google software engineering manager, Eric Clayberg, remarked in a Harvard Business Review article that “Engineers hate being micromanaged on the technical side,” ... “but they love being closely managed on the career side.”

Identifying Micromanagement

In the worst cases, micromanagement can go as far as to amount to harassment, discrimination or victimisation (as has been found in cases in Canada and the United Kingdom).

However, in many cases organisational culture and a lack of awareness can lead to micromanagement practices being accepted, particularly when it is embedded in an organisation.

For software engineers, micromanagement may be combined with ever greater pressure to produce work at shorter and shorter timescales by both engineering managers or project managers. Micromanaging and close monitoring is used to mount additional pressure. Even where an engineering is following best-practice and working rapidly, micromanagement can take the form of putting team mates against each other and using harmful metrics like lines of code written or commits per day.

Micromanagement can also affect engineering managers too. Senior leaders can mount pressure on their managers. For junior engineering managers, this pressure can then cascade down to their engineers, damaging the team. Senior managers may even unintentionally set-up junior engineering managers to fail; for example, by deputising "Tech Leads" as engineering managers with none of the controls or responsibilities needed to manage their team.

We understand from the rigorous research in the DORA State of DevOps reports that loosely coupled architectures and teams are the strongest predictor of continuous delivery. Micromanagement can also take the form of centralised architecture teams and senior leadership not trusting teams to make their technical decisions.

In the worst case, we've heard an example where a CTO hired a team of "Principle Engineers" to be embedded within engineering teams to micromanage the team's day-to-day technical and personnel interactions of those teams and the engineering managers purely existed as a lightening prod for criticism. Ironically the company listed autonomy as one of its key cultural drivers.

Harmful Metrics Scale Micromanagement

Our competitors add features that allow managers to compare or rank engineers. They even advertise dashboards for 1:1 meetings. Setting aside that the metrics used are often harmful, these tools exist to help scale micromanagement and act as a tool for criticising engineers who are working well.

Google studied team performance in Project Aristotle evaluating a total of 180 teams (including 115 project teams in engineering) using hundreds of double-blind interviews and quantitative data sources. Google's researchers found that individual performance of team members is not significantly connected with team effectiveness, but psychological safety was essential.

Companies like Amazon adopt a “two-pizza principle”, such that no project team is larger than can be fed by two pizzas, to achieve the level of psychological safety for a company to experiment and grow.

Why we Turn Down Clients

At Haystack, we fundamentally stand against encouraging systematic micromanagement practices. Not only do we find that these practices stand against best practice, but they can risk unethical management practices.

We want to act in the best interests of our customers and it is in our interests for our customers to be successful. We are frank about the risks associated with micromanagement and someone contacts us wanting to pursue it, we tell them to find a competitor who believes in the practices they want to adopt.

Measuring The Right Things

Instead, at Haystack, we adopt proven metrics that are backed by thousands of data points to be beneficial to team performance. For example; we use the "Four Key Metrics" identified in the State of DevOps reports, where high performers are 2x more likely to achieve their commercial and non-commercial goals. Indeed, companies which do well under these DevOps metrics have a 50% higher market cap growth over 3 years. These North Star metrics measure collective team performance, so systematic bottlenecks and improvements can be identified. Indeed, the 2018 State of DevOps report found that companies which were elite performers against the Four Key Metrics "are 1.8 times more likely to recommend their team as a great place to work".

To manage risk in engineering teams, we offer real-time alerts allowing teams to self-resolve most issues without needing manager intervention. For example; if a Pull Request is stuck or code is being merged without review, daily Slack or email notifications allow these issues to be self-resolved. If the team is at risk of burnout, weekly sprint notifications can alert the team that this is a possibility.

Most critically, these risk factors identify potential issues before they happen, meaning you can act early with coaching instead of them merely being identified after the fact. They only identify risk factors using demonstrated best-practice, instead of harmful measures which are purely used as a source of criticism.