It would make sense when analyzing productivity to think that its marriage with efficiency is inescapable. If a process or person is inefficient, their productivity will surely follow the same downward trajectory. But, perhaps the analysis is misplaced, or the wrong question is being asked. Why does productivity matter to a business? Well, they have financial goals. Arbitrary milestones that determine success or failure in the eyes of executives. These goals are only met through the business’ ability to create and offer value. Say you’re a tech organization focused on building software. It would be in your self-interest to analyze and refine the process that leads to an actual deliverable being completed. Increased efficiency leads to increased productivity, which leads to outcomes that enable the business to meet its financial goals. That’s the enduring mindset. But if there’s no baseline to compare to anything then everything will be thrown at the wall, hoping it sticks and a new way to pump up productivity becomes possible. Developer Experience (DevEx) Teams are another dart being thrown in the hopes of a bullseye, an innovative approach that leads to increased yields. Is that really the case?

What Are DevEx Teams?

This ongoing focus on productivity in engineering has manifested itself in Developer Experience (or whatever faux term you prefer) Teams that focus on streamlining and refining internal processes for the benefit of developers. Organizations constantly seek ways to optimize their processes and enhance the developer experience. To accomplish this, companies have installed teams serving as detectives and mediators. They speak with higher-ups, with the teams doing the work on the ground, and then work to create an environment where everyone is as productive as possible. This is done through process refinement, tool creation, and many other practices. The purpose of creating these DevEx teams is not always to make developers feel more fulfilled in their position, even though that’s how they’re sometimes framed. Their contributions also eliminate any excuse developers would have if they started to lag in the productivity department. How could you not get your work done when you have all the tools, processes, and methodologies you’d ever need right at your fingertips? That’s the question asked, even if its merit is lacking. But how do you measure success when there’s no baseline to compare it? While DevEx teams have their merits, there are compelling reasons why software development organizations may not actually need them.

‍

‍

Productivity: The Impossible Measurement

It’s critical to understand that productivity in engineering and software development can’t truly be measured. You can try DORA. You can try SPACE. You can mix and match qualitative and quantitative aspects. But, at the end of the day, this is an imperfect science being pitched as something pristine. The focus should be on the outcome, the actual deliverable that impacts a business’s ability to live or die. Previously, an engineer would write line upon line of code, often with a rough bug density, over a long period of time. Now, a developer can utilize AI/ML accelerators and do the same amount of work in less time with fewer bugs. Are they more efficient now? Or less efficient? Productivity’s determination is oftentimes based on effort, and yet there are layers like DevEx Teams that increase the number of hindrances and inhibitors instead of offering refinement as promised.

Organizations that require output from engineers have developed a bad habit. They’ll solve the problem of complexity by either adding capability in terms of people or tooling. That’s when things start to snowball. Sometimes, less is more, and the creation of all these cutting-edge tools and processes means resource allocation gets all out of whack. The benchmark is constantly changing because of new tooling and processes when really the requirement can be simple. You have to measure the meeting of goals which translate to the company mission. You cannot accurately measure productivity when introducing obstacles every step of the way.

‍

‍

Remove Layers

Let’s contemplate a quick hypothetical. Say you’re Michelin Star Chef. You’ve spent years learning, training, failing, and succeeding. You’ve worked tirelessly to be great at what you do. Now, say the owner of your restaurant comes in and says any time you need to change the heat on the stove, you must notify the owner’s assistant. They’ll pass the message along, the action is approved, and now you can go up to Medium High on your burner. However, considering you have a responsibility to your “shareholders” to get their meals to them promptly, double-checking and gaining approval slows the overall pace of the kitchen down to a crawl. You’ll be in a dinner rush and have to wait as messages are ferried back and forth when a genuinely talented, capable individual sits on their hands doing nothing. See the similarities here? Developers know how to do their jobs. Sure, there will always be room for improvement, but if the code is bug-free and delivered on time, that’s all that matters.