Commentary: How to simplify your technical organization, and accidentally ruin it

I need to see global reports

When your software organization grows to a certain size, you will have inconsistencies that make your eyes twitch. Before, you used one ticketing, source control, and helpdesk system. Now that you have grown (and perhaps bought other companies or changed through other influences), or just had enough size that everyone isn’t talking to everyone, you find that there are multiples of each system.

You might walk into the trap of viewing an organization as a software system. The diversity bothers you, so you decide to normalize it for cost savings. “DRY (Don’t Repeat Yourself) it out” so that there is One Ticketing System for Everything and One Source Control Solution. You have the accounting team look over other costs and find that there are also software tools that do roughly the same thing, so you find out which ones are the most popular and move to cancel the others. Congratulations, now everyone hates you.

This is similar to a mayor staring at a map of their small town, noticing that the lamps and sidewalks are different throughout the city. They get someone to look into it, and it turns out that the city maintains multiple types of street lamps, trash cans, and city sidewalks. There are multiple widths and styles, and multiple vendors supply them. The mayor, a former engineer, is bothered by this. It feels wasteful and stupid. He orders his staff to normalize in the interest of Cost Savings. He feels that Everyone Should Be on the Same Page, and Live in the Same City. He gives a poorly attended speech about togetherness and simplification and launches his One City initiative.

There are protests. He has never seen such a response to anything he has done. They die down quickly, but as the city trucks arrive to tear up the sidewalks, they reappear and halt work. Some storefronts are losing sidewalk space, and some are gaining more, but both groups are equally unhappy. A neighborhood of elderly folk seems quite angry about the lamp change. They talk about safety and early-morning walks. They recruit the local historical society to prepare a report about the street plaques that will be moved and about the section of sidewalk with very old bricks. The mayor thought they were a tripping hazard, but the older citizens apparently love them.

The mayor, exhausted and unable to fire his citizens, has to face the truth: the city grew. It was not planned. And you can’t plan your way into some nice, clean order. The older neighborhood has those larger street lights for a reason: the larger sidewalks in one area were needed in the past, and keeping them there has some benefits. Changing things has to be clearly better; if it isn’t, people will actively fight it. A complex system resists change, and only those who understand systems have any chance of influencing them.

Just as a plant never grows straight and perfect, the city grew towards the light, the water, towards what worked. And he should be careful not to change it too much. He takes down the map and puts up smaller, more detailed maps of each neighborhood. At this level, he can see the beauty, the function, the right things.

It is a common temptation to try to mold the organization into something that seems simple to control. As a tech executive, you constantly search for information on how things are going. Still, receiving the right amount of information and context to understand each team is overwhelming. So instead of popping in and out of each team to get the right context, it can be tempting to want all the teams to behave in the same way. It can be tempting to want all teams to appear in a magical Global Report.

But teams don’t work like that, and complex work doesn’t bend to that format. You are asking people to spend extra time following a norm that isn’t natural. Sure, having everyone doing everything the same way might save money. But this isn’t McDonalds. Software developers are not line cooks; a good percentage of them are closer to chefs - you don’t want a predictable average; you want to encourage outliers. This makes your job harder, but it makes the organization work better than a robotic deterministic one.

The beauty of a team is how well it handles conflict and gets stuff done. The beauty is outside the computer in its work with the outside world.