“Flat Structure” in Software Teams is a Horrible Idea!

Don’t get me wrong. Office politics are the devil. And corporate structure, where it is unnecessary, is the main culprit of that.

But... Do you remember that great “Bob’s Burgers” episode where some turkeys went bananas and Linda had to peck one turkey to restore the balance again?

Believe it or not, it’s a real thing. turkeys are widely known for having “pecking orders” among males and females. This is how they determine their social structure. When most decisions are ambiguous and opinionated, like whether to fight or flight, having a social structure for them makes things much easier to navigate through most conflicts. (Asterisk on “navigate through” because it’s far different from “resolving” a conflict).

It’s far from perfect and it’s certainly skewed, but it works and keeps them alive (don’t believe me, but believe evolution) because it keeps their group intact.

I want to clear up a very important point here. I’m not trying to build up my argument by taking turkeys as an example. The most recent common ancestor that turkeys and humans shared was 300+ Million years ago. So… it’s safe to say we are different.

What I’m trying to say is, that contrary to what newfound perfect cultural structure makes us believe, social hierarchies are not unnatural. Quite the opposite. I just want you to keep an open mind for what follows.

As with many other species, human social hierarchies go thousands of years back. But unlike any other species, these hierarchies are of utmost importance to humans.

It’s observed in all animals, including early sapiens, that after a certain threshold of a couple hundred in a group, it’s impossible to keep the group intact without them splitting up. But we do this quite effectively every day by maintaining anywhere from small organizations to vast countries. That’s because maintaining large effective groups is shown to be possible when you have hierarchies to structure this group, for making collective decisions, and for effective communication.

What a healthy hierarchy does is delegate responsibilities down and up. So any individual has a well-defined and bounded role that would help (or enforce) them to contribute to the collective goal of the group.

This “goal” is usually decided by the higher levels in the hierarchy. But as long as those higher levels are elected correctly, this mechanism works. (Again, a huge asterisk on “elected correctly”. This is the main point that bad politics poison corporations)

Ok, what does all of this mean for Software Teams?

Small startups these days (with 10–20 developers) are widely known for having flat team structures. It sounds very enticing indeed. Very short communication path to C-Level; everyone is treated and respected equally; and more importantly, no politics. No one would gain anything by kissing up to the “Manager”. (Yuck… Managers.)

The problem occurs when you have to make a decision. If it’s an unambiguous decision, being the intelligent engineers they are, it’s easy to discuss as a group and come to a nearly unanimous conclusion.

But as a lot of problems in engineering are, what if the problem was ambiguous and the solution has to be opinionated (i.e. conflict)? Again being the intelligent engineers they are, they come up with different solutions that they are fully capable of arguing for.

This is where this utopia breaks down. In these situations, what usually happens in startups is either the CTO or god forbid the CEO intertwines and makes the final (technical) decision. This is where you realize it’s not a flat structure at all. It’s a very shallow and very wide hierarchy; but not flat.

Here’s why this is bad — Well-deserved CTOs are well-versed in their role and, I’m sure, are quite intelligent. But most of the time CTOs have less insight about the inner workings of a project than a developer who’s been working on it every day. They also lack in-depth knowledge of a specific technology that’s being used or proposed. This leads to semi-optimal or downright wrong decisions that can become expensive to fix later. The worst part is, that the person who made the decision will not experience the pain points of this decision to make necessary adjustments until it bloats up to an unsustainable stage.

The solution for this is, choosing a “capable” individual who understands the scope of the problem correctly and can make a sensible decision when there are conflicts. And you finally (quite naturally) end up with hierarchies.

Alternatively, the second thing that could happen when there are conflicts in a flat team is the emergence of unhealthy hierarchies automatically. A few examples of these unhealthy hierarchies are “seniority by — ”,

• age
• who has been in the project for the longest,
• who can articulate a point the most
• who the others “think” is the most intelligent
• who is loudest (laughable but not uncommon)
• castes (very sad but true in some cultures)

As you can imagine, if left unseen these kinds of unhealthy hierarchies can be very destructive. And they, in fact, are usually left unseen when organizations “let the team decide” without defining a proper structure.

Now, you might argue that we can define guidelines and standards to resolve conflicts. Here’s the problem — if you’re a flat team, by yourselves you can’t define these guidelines in the first place. You will come across the same conflicts when you try to converge on a common set of guidelines. So again either the C-Level will have to define these guidelines with the limited technical knowledge they have. Or use some industry standard guidelines. Take design patterns for an example. Using industry-standard design patterns is a great idea. But there are hundreds of design patterns. It’s so vast and ambiguous on where how and when to apply them that there is a completely separate role in well-structured teams to take responsibility for just that. That role is called a System Architect.

Isn’t it very weird that we converge on the same solution in every avenue we explore with this argument?

But if the teams are very small, or if you can’t afford to hire Architects and Technical Leads, (which usually is the case in startups), you might think you can just wing it at first, hire some level 1 or 2 developers, and keep a flat team. That’s how it mostly starts. Not as an innovative new idea. But as a way to bootstrap a company without committing to a very expensive team. There’s nothing wrong with that, but after a while, this team becomes larger, and it comes to an unsustainable place.

The problem is, that it becomes very difficult to introduce a structure to the team at that time unless you hire from outside. Everyone is too used to the flat structure, so it becomes very difficult to restructure the team by promoting a few people that others thought to be peers. It’s not just awkward conversations that you might have to have with a few individuals. It’s quite possible that good people can leave because they feel unappreciated by contrast.

Hopefully, by now, I convinced you to at least think about flat team structures in a different light.

Didn’t I leave out the “elected correctly” part in the above argument?

It’s true. As I said in the beginning, for this whole structure to work, there should be a mechanism to elect each individual “correctly” for the higher levels in the hierarchy.

“Correct” is a relative term. What does this mean in a software team? Let’s take the role of a System Architect as an example. The correct person for this role should be competent enough to handle responsibilities as a technical leader for the overall design and operation of a software system. The good thing is, that unlike other professions, it’s not that difficult to define some measurable key requirements for this role.

• Has earned a Technical architect certification
• Has worked in a similar position or held similar responsibilities for x years
• Has a Bachelor’s Degree or equivalent (don’t get me started on this. It’s so weird how we started to underrate the importance of knowledge in favor of intelligence or experience these days. Knowledge is also experience. It’s just not your experience but that of millions of others.)
• etc

The great thing about this is, that it’s quite easy to define a very systematic mechanism to elect individuals to different roles in this hierarchy. This eliminates any need for organizational politics.

Of course, it’s not going to be perfect. You will always have bad hires, because of wrong cultural fit, or many other reasons. Flat teams also have the same problem. But when you have hierarchies, the problem can get magnified.

The solution for this is surprisingly hierarchies again. It’s so much easier to identify these bad fits when you have hierarchies rather than all the differences and problems being absorbed by the team as a whole.

There are so many “self-correcting” mechanisms like this in these hierarchies like choosing a competent interviewer to interview a potential hire. But this rant is long as is. So I will stop here.

So how do we set up a healthy hierarchy?

First of all, stop rebranding cost-cutting mechanisms as radically new ideas. If you are working at an organization that’s doing this, be mindful of the implications of this form of thinking.

Second, if you are starting up an organization, think long and hard before you say “We are a team”. You need to do better than that. “a team” is not specific enough. Who is responsible for the system architecture? Who is responsible for keeping the API contracts “sane”? What about the cloud architecture?

An important note here about all these architectures. In a well-structured organization, these are the responsibilities of different domain architects. No benevolent god architect is making all these decisions as in what CTOs do in so-called “flat” team structures. Having said that, I understand it’s impractical to set up this form of a complex structure in a small startup. But the idea is to not close the path that would lead you to something like this in the future.

If you’re joining an organization, prefer well-structured organizations more. Having been able to focus on a well-defined set of responsibilities is a blessing.

But let’s say, god forbid, you have a mature team that has been working as a flat structure for a long time. In those cases, it might be genuinely difficult to introduce hierarchies while keeping the team's morale intact. If the team is equally experienced and qualified, I would suggest the best form of action is to hire the required roles externally and define some career progression paths for the existing engineers.

But if the team is not equally experienced or qualified, or you are not in a position to expand the team,

Just have that awkward conversation… It’s bad if some good engineers left. But it’s worse if you let this chaos simmer and bubble up, and cover it up with the word “Team”