The industry's feathers have been ruffled. A recent McKinsey article proposed that developer productivity can be accurately measured. Whether this was a ploy to generate traffic and attention or not, the discussion has been intense since the publication of said article. In short, the theory was that by iterating on existing metric systems, DORA and SPACE, a unique set of analytics can be created that paints a crystal clear picture of how productive your engineering team is. This is all fine and dandy, but it misses a critical point.

Software Engineering may not be science. It's also not art. It's some strange amalgamation of the two. Frankenstein's monster would serve as a great mascot. In science, you create theories that are proven right or wrong. Here, data provides accurate insights. However, art is a little harder to quantify. Imagine telling Van Gogh we will calculate his productivity in creating The Starry Night through the number of brush strokes used. That's lunacy. This dichotomy is what plagues productivity micromanagement in software development.

As Gary Hammel put it in his book “What Matters Most”

Senior administrators who've never been entrepreneurs and have never created something out of nothing are prone to view success as the default setting, as something that usually happens, rather than as something that is inherently rare and fragile.

The Fundamental Problem

Business and sales are often seen as hallmarks of analytics and the accuracy with which they measure productivity. I sold this amount; it made this amount. Simple. However, engineers and their productivity require more nuance. If all things were equal, i.e everyone was building the same exact widget, if there were no variables whatsoever, then micromanaging engineering productivity could be possible. The reality is that's not the case. The idea behind micromanagement is that by monitoring every detail of an employee's work, you can ensure they are productive and efficient. However, the opposite is often true. Micromanagement can decrease productivity, lower morale, and increase turnover rates.

Still, it's understandable that executives want some sort of tracking to be in place. There's money being spent, and if it isn't being utilized efficiently, it should be spent elsewhere. Makes sense. However, frequently, these professionals lack the context and experience within software development to understand how ludicrous productivity management is.

If you can't trust your in-house engineering team or the firm you've partnered with for software development, you should fire them or yourself. Lack of trust kills productive teams, and implementing invasive metric systems will further inhibit your workforce.

Watch Your Team Members Devolve

The Pragmatic Engineer wrote a part one and part two in response to Mckinsey's initial publication. These articles serve as incredible insights into how metrics actually function within engineering teams and the impact they can have. One of the recurring themes was that no matter what metrics are used, more often than not, professionals are smart enough to manipulate the system. Even in the McKinsey article, there was a section regarding the fallibility of metrics and how they're misused. All of these points contribute to a worrying trend within the industry —”resume-driven development”.

Resume Driven Development (RDD) - The act of writing software using every possible library and the latest stacks, not with outcomes in mind, but in self interest of becoming more marketable or increasing ones own market value.

Say a set of metrics are implemented measuring effort. Well, then engineers will make sure whatever work they do contributes. But that's like saying a person lifting five pounds five times is the same as a person lifting 25 pounds once. The actual amount of effort, or "productivity," is different. The same can be said for metrics measuring output, outcome, and impact. Focusing on one area will leave parts of the canvas unpainted, and that's where bugs, defects, and poor quality become frequent issues. Engineers are smart people. They understand what is required of them. Treating them like children, with PMs and other managers acting the part of helicopter parents, is wasteful.

Metric systems monitoring productivity incentivize selfishness. It's about what the individual can accomplish, not what the team can achieve. This resume-driven development starts a flexing contest between engineers as they seek promotions and raises. The focus should be on creativity and innovation, not the easiest way to do the least amount of work. Competition is healthy, absolutely, but fostering animosity between team members is the wrong way to go about things.

If everyone on a sports team were to all behave and act in the same way, a basketball would look like a military parade. Imagine that!

So, What's The Answer?

Please, understand this. There is no perfect system. Monitoring productivity through the quality of work done can be a decent approach. Still, even then, there are some holes in that theory. As ridiculous as it sounds, trust might be the solution here.

Create precise quality requirements. Construct a comprehensive roadmap establishing the tools, technologies, and methodologies. Have a timeline with obvious goalposts and expectations. Then, let your people do their best work. Empowering engineers with trust and autonomy makes them more likely to take ownership of their work and make decisions that benefit the organization. No more resume-driven development. No more gaming the system for a single person's benefit. Instead, collaboration is emphasized. Developers work together for the good of the team and the good of the project. All of a sudden, their productivity skyrockets. Quality expectations are met, timelines are easily handled, and everyone is happy.

The pointlessness of hiring experts for their knowledge and then telling them how to do their job shouldn't have to be mentioned. If the focus is utilizing resources as effectively as possible, then badgering your technical professionals goes against that very philosophy. Only with time do seeds grow, and that same approach should be devoted to software development.

So if you want to make software engineers quit writing software, start measuring them exactly like the consultants and administrators do.

‍