Tech stories: Land of No Owner

András Tóth - Feb 25 '21 - - Dev Community

In my professional career I have worked with a very hierarchical company and a very loosely coupled, very flat company.

Having to see the same problem in totally different context made me realize this:

Things without a clear owner will rot.

How was it in the hierarchical company?

Back in the day we had multiple teams in two different offices, each office having one engineering director but having only VP over them both.

There was a negotiation over technology we are going to use for the same product both offices were building. CoffeeScript or Javascript? Should we use hapi or express.js? And other important details... Having the same technologies would mean that anything happens to one team the other can take over the code and continue it.

The result: the other is going to use Coffeescript and hapi while we were going to use JS and express.js. The decision was the same as before the decision. The VP did not do anything, we never heard his opinion about this. Later on most of the team in the other office were gone and we inherited something we had no experience with (also please don't use Coffeescript, that was a dead-end).

The worst middle manager: who makes shit shiny

Here I think the problem was the VP was basically a political genius: we did not know what he was working on, we never heard his decisions except for announcements, but leadership loved him. He just did not make decisions, only carefully swept problems under the carpet. Everything was going according to the roadmap. On paper.

Hierarchical companies can be very effective if the conflicts are heard from the lower ranks and resolved through decisions. In this particular case we had two directors all having equal rights and a VP who could have chose either, or. But he did not. We have never learnt why. Later the pattern repeated itself and we had similar problems all along the way.

From the leadership point of view I understand it is pleasing to work with people who makes your life simple, but I suggest...

you should fire these folks that hide the flood with a facade instead of telling you will need a dam.

How flat companies fail at decisions

Later I changed jobs and arrived at a company that did not have leads reporting to directors reporting to VPs reporting C-levels reporting to the CEO (reporting to the board). Here in my first weeks I was even encouraged to talk to the CTO and I really-really loved it.

But then I saw a big problem. Multiple teams were adding code to an Angular 1 internal tool. The tool itself was created during a company hackathon and never got really cleared up. The resulting spaghetti had multiple layers of concrete poured over it by years of abuse. Many frontend developers tried to do something with it, cut it up or at least fix larger anti-patterns, but since so much code was dependent on the inner kinks of the original sketch it was an impossible task to do.

How would this happen?

There was no one clear owner of the tool. Every team was dependent on it, no one liked it, but nobody had the dedicated time or ownership.

A similar thing has happened to the hierarchical company but this time it was teams that could not agree on things not directors.

That led me to realize that the company had multiple similar problems.

Anything that fell in between two teams was deteriorating and had a growing list of problems, while none of the involved teams had resources to solve.

How not to fix this scenario

CTO asked me when I told him the problem: "What did you do to fix the problem?"

At first it was very empowering thought: I, the humble engineer could go to other teams trying to convince them that this important problem needs to get solved. Everyone agreed that "yes, this needs to get solved", but no-one could find the time and resources because they felt they had to work on their dedicated goals of their respected teams.

For a year or so I felt I just miss the energy for this.

My own day-to-day and private life was draining me enough not to have energy for this. "Yeah", I told myself, "I do not have it in me to be a lead".

But then I realized so many other people tried and also failed. So what could have been the solution?

How to fix this scenario then?

In a flat company structure you got to have proactive management.

One that actively collects problems and finds owners for them. The owners in turn are also given dedicated time for this: you can't expect quality work from overtime. In fact the bad quality was resulting from people working on the tool in their spare time.

People are going to be afraid to work on things they know are important, but take time from the job they are officially paid for.

Now it is very easy to argue that fundamental infrastructural work would yield higher productivity for everyone, but not if you are just one guy in just one team having other responsibilities as well.

If your company has only customer-value bound KPIs it is still important to be flexible over that and realize the importance of not just maintaining but optimizing the machinery. I know companies that add engineering goals as well, like setup time of a dev environment getting shorter quarter year by quarter year.

You can only do "extra" stuff if you have "extra" time. That usually never happens. So important inter team stuff never gets right. And then entire company struggles.

And if you pair it with leaders who avoid confrontation by hiding important problems you have a recipe for disaster.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .