If Everyone Is Responsible, No One Is

The notion that developers are light bulbs and any developer or team of developers will output the same code or have the same perspective on every pattern seems to be pervasive at pretty much every company I have worked for over the last 20 years. Early in my career I believed the same thing and saw my inability to conform to a 'standard' as a deficiency in my abilities. As my abilities increased and I was exposed to a larger variety of teams and organizations my views shifted. My experienced views are that this is a failure in management abilities and not my own.

Shift in Perspective

The first shift was when one of my managers expressed his frustrations with light bulb management. When I asked what light bulb management was, he stated that it is when you manage people like light bulbs. When one burns out, you unscrew it and screw in a new one. It means you are managing people like they are a standardized commodity. If they don't behave to your standard, you discard them and find a new one.

The next shift in my thinking was when I read "The Mythical Man Month" and learned about Conway's Law. Conway's Law essentially states that your system architecture will represent the communication structure of your organization. This is an observation Mel Conway made in his paper "How Do Committees Invent?" in 1967. Over the years Conway's observation has been verified by MIT and Harvard Business School.

Lightbulb Management

Lightbulb management in software development is when managers or project managers swap developers or teams of developers on tasks arbitrarily. For example a feature is broken into sub tasks, and the sub tasks are divided across multiple teams. These teams may never have a sense of what the full feature is intended to do so they have no ownership in the features success initially or even ongoing. They also have challenges with producing multiple parts of a feature that either do not integrate well or they spend lots of time in high friction communication with other teams. If there is lots of swapping going on, this becomes even more problematic, as Team A might negotiate with Team B only to find out Team C ends up doing the work that Team B was initially going to do.

As an individual in an organization that sees software developers as a standardized commodity, you might start off motivated to always do the right thing, but find that the pressure to produce something (be productive) and the realization that you are fighting a losing battle will win out and you either stop caring about the outcomes or find a new job. There is a reason staying too long in a job is starting to be viewed as a negative on a developers resume. Everyone subconsciously knows that if you stay for a long period of time, you are probably OK with not caring about the outcomes.

A Short Story

To give this an alternative perspective. I have a story about pool vehicles that shows how the lack of ownership manifests. For those not familiar, a pool vehicle is a vehicle that is managed as a shared resource. An employee of a company will use any available vehicle from the pool and then return it when done. The vehicle is not assigned to any one individual.

Years ago, I was riding in one of these pool vehicles with a manager of the company. The manager pointed to the low tire light that was illuminated on the dashboard and complained that at one time the vehicles were assigned to individuals and those individuals were responsible for the care of the vehicle. For the most part the vehicles were well cared for. But new executive management had decided that pool vehicles were a good way to reduce the number of overall vehicles needed and stopped assigning individuals to vehicles. Since everyone was now responsible for vehicle maintenance, no one was responsible. Vehicles were driven for months with warning lights illuminated and broke down for entirely preventable reasons.

After we were done with the ride, we returned the vehicle to the pool and did not address the flat tire. When I asked why we were not going to address the issue he spent the last 20 minutes complaining about, the manager explained that if he always addressed the issues in the pool vehicles he would never get his true job objectives completed. The objectives he was rated on to determine if he was a successful contributor to the organization. Furthermore, his experience was that if he fixed that issue it would turn into a rabbit hole of issues with the vehicle that needed to be addressed. The manager saw the issue but stopped doing the right thing because the organization effectively penalized him for doing the right thing.

Flawed Metrics

As a software developer I often encounter flawed implementations in the process of implementing a feature. If I know my success is rated on how fast I get the feature completed and not the overall success of the feature, I’m going to put the blinders on and leave the flaw. If I were to choose to do the right thing in many organizations, I would be marked as a developer who is slow or find myself in the uphill battle to get the flaw identified and prioritized to be addressed at a later date. Effectively, I would be penalized for doing the right thing.

The Solution

There is a solution to this issue. First recognize that managing software developers is a unique challenge and we need to be managed as a collection of individuals who want to create something that solves a tangible need. Give them ownership of the larger outcomes and reward them for achieving those outcomes instead of how fast they can complete a story point or how many hours they spend on a feature.

Then organize your teams embracing Conway's Law instead of arbitrarily creating teams based on politics or your succession plan. This means spending time understanding what your architecture should look like and creating teams to support specific applications/microservices/websites whatever you call them. Stop assigning multiple teams responsibility for creating and maintaining the same application. Create small teams with clear boundaries and responsibility for specific outcomes that are tied to business objectives and give them wide latitude within the boundaries to solve for that objective in the best way they see fit.

You may be thinking, that sounds like knowledge silos and knowledge silos are bad. When you organize using Conway's Law knowledge silos become an asset that frees your organization from high friction communication and allows teams to fully own outcomes. Knowledge silos are only bad when they are created arbitrarily over time with no architectural considerations. Boundaries are good for defining responsibility and allowing individuals the freedom to solve problems in innovative ways.

Resources:

• Conway's Law Wiki: https://en.wikipedia.org/wiki/Conway%27s_law
• Melvin Conway: http://www.melconway.com/Home/Conways_Law.html
• Diffusion of Responsibility: https://en.wikipedia.org/wiki/Diffusion_of_responsibility