One time, I joined a company. I had been offered the position and was excited to take it, though perhaps it wasn’t even in the top 2 most exciting times I’ve experienced over a new job. The salary was an improvement over what I was making at the time, and the technical work was something I was really excited to do. I was joining a small team of mighty developers, and I was primed to contribute on some of the most amazing work I had seen to date.
I was most amazed that the company had advertised how flat its structure was. I imagined working in an environment where I could independently identify work to be performed, do it, and receive great accolades for being such a genius.
OK, well maybe that last part is a bit of an exaggeration—I was experienced enough to know that any person who is established as the “expert” in a group is the genius de jure. This person may in reality actually be a genius, or perhaps they are a genius of one domain, but either way I knew I was too early in my career and too new to this group to qualify.
I have personally found a delightful level of genius in most people’s work, but typically that doesn’t matter. What really matters is the perception of an individual, and what image it is that they’re cultivating of and for themselves, and how well they’re succeeding at their methods to do so.
Perhaps unsurprisingly, nobody ever seems to be actively cultivating a view of themselves as incompetent, unintelligent, ignorant, or any other “negative” adjective.
Well, almost nobody.
People cultivate their self-images to accomplish their own goals. and it’s not always straightforward to know what they are. Some people itch to be out of work by 5pm so they can spend more time with their band or family. Others find more of their passions to be performing the work itself. Others like to be around people, and simply enjoy being well-esteemed among a group. Others enjoy the camaraderie of a close-knit team. Some are purely motivated by salary; the more they know they can obtain, the harder they’ll work to achieve it.
Those are the easy ones to describe. Others are buried much deeper in a person’s psyche, and their ostensible goals are merely the outer-most actuation happening due to the internal desires. I’m not a psychologist, but I don’t think that’s ground-breaking news to anybody. So the actions people perform and the image they’re trying to convey might not be easily discernible from a distance.
I remember having a conversation once with a manager of mine, and I asked why a certain team was growing so large. The amount of work they had was comparatively small and was not in any near-term critical path. My manager gave the sarcastic response, frustrated at the same situation, “some of the senior engineers and managers have asked that same thing, and it’s because Bob hasn’t lead this many people in the past, so of course he needs that many” (and of course, like every name in my writing, “Bob” is a substitute).
No one size fits all, but the obvious and general rule is that each person attempts to establish a stronghold around whatever it is that allows them to defend their own goals and enjoyment, even if we cannot articulate what that is. To that end, the pursuit of having more influence in an org or company is often so intertwined in these feelings that it often becomes synonymous with, even replacing, a person’s goals.
In this respect, it’s natural for us to all want to appear as a genius in our own ways and interactions. But here’s the kicker: “genius” is always, inherently compared to someone else. Influence always comes at the expense of someone else’s influence. If you had someone who kindly ruled an effort as a benevolent dictator, and then someone of the same stature was hired to assist the effort, the benevolent dictator has immediately lost a great amount of influence, simply by the team growing.
What happens when you have a flat company full of people who are trying to cultivate their perception of genius and increase their influence among their peers?
It doesn’t really matter what the team size is, the same phenomenon always occurs, if left unchecked. The more reserved people give way to the more outgoing, and the more aggressive people come to take the leadership spots. Eventually, there are not enough leadership spots for the number of strong personalities, and something has to give, because there was nobody to temper expectations of grandeur. This can play out in a number of ways, and none are pleasant.
A flat structure isn’t bad, and it has its place. It can be really appealing, and is maybe even necessary at the early points in a company or team’s existence. What happens when the effort is so large that it isn’t possible for everyone to be fully aware of each other’s tasks, why they’re performing them, and how it all fits for the common good of the group?
The flat structure works for a while, possibly even a long while. But it eventually stops working when you keep growing the team, and you may outgrow the flat structure faster than you realized you would. It doesn’t take much—perhaps only 15 or so people across 2 cooperative, parallel efforts—and now you start having immense communication difficulties as people independently make decisions without communicating them broadly and effectively (too much information is as useless as too little, in practice), or outside influences (other teams, orgs, or customers) independently reach into your teams to directly ask the developers questions, or ask for favors.
Even with an established layer or several layers of management, companies can still operate as though they are flat. In some cases, managers and leaders do not lead with business goals in mind, they lead with self-promotion in mind. With nobody able to internalize the meaning of all of the effort to organize it (how would you get everyone to agree who this should be?), or minimally to run interference, well-meaning developers find themselves unable to choose priorities for tasks in such a way as they benefit the company.
Without strong managers or other leads to recognize these situations forming, developers are left to determine on their own what the highest priority at any given moment is: help another team, or help my own team.
Unfortunately, that’s not an easy thing to decide with consistently good outcomes, and it’s not because developers are somehow socially inept or some similar suggestion. It’s more that you can’t ask people to divide their time between 2 completely different types of tasks and expect them to perform well in each. Consider this point I’ll often explain to leaders as they struggle to understand why, in their estimation, developers do not prioritize tasks correctly:
Time spent building a mental model of a new or existing software system or application is time that is unavailable for use to build a mental model of the current business or product needs. The converse is also true.
– Me
I think this is an easy thing to trivialize because of the way these mental models are built:
- People sitting in meetings are simultaneously sharing or interpreting others’ speech and building their mental models of the business system.
- People sitting in front of a computer reading code or documents are building their mental model of the software system.
The first case requires interactions with other people, in a highly-visible activity. Multiple people see where the hours of the day are going for this person. The second case is an act of solitude. Even if somebody sees this work going on, they are inherently unable to participate. Come tomorrow, there have been no more tests written or features working. By all visible accounts, it’s as if the developer did nothing. The longer the process takes, the more nothing it looks like they’ve accomplished. It’s an unfair assessment of their work and incidentally, for this reason, I always ask my reports or mentees to produce a deliverable in the form of improved documentation or MVP-quality code for a piece of the overall task when they undertake research tasks, and as the lead of a team, I reciprocate by doing the same for them when I attend a meeting that has impact on our team.
Since time cannot be effectively split between building a business-level model and building a software-level model, it is good and natural that a leadership layer forms so that people are intentionally more focused on one or on the other, but not necessarily one to the exclusion of the other.
But the word, “intentionally,” is key. If the organizational structure remains too flat, without people with the express job of facilitating communication between teams, the more aggressive or outgoing people start to fill more of their time interacting with other teams, growing their influence, while the rest are simply told what to do and float from one task to the next, unable to learn the changes that continually go on around them that impact their work. Now we have leads who are not leading (even when they seem to be giving a lot of orders), leads who are not transferring their mental models to their team.
The leads probably don’t recognize the problem; the system is working well for them. They have ready access to all of the information and “face time” with higher-level leaders (and there’s a future topic—balancing your own branding as a leader with satisfying your reports’ needs for their own branding) they need. They have no evidence that it also shouldn’t work well for everyone else. Eventually, the non-leads’ stellar performance can seem to slip into mediocrity and there is great temptation from either the leads or the non-leads to correct this by having “under-performers” exit the company.
Even if the extreme case is not experienced (though I suspect teams and companies are not aware of how often it does), it might not matter. As this continues, eventually the leadership lacks a true understanding of the implementation-level difficulties as the leads continue to grow their influence at the expense of working with the non-leads to transform the business or product goals into code. I have been party to a number of conversations with managers in companies of all sizes venting their frustrations that there is a mistrust between developers and leadership. Leadership complains that developers seem to give insanely-high estimates and make designs too complicated for what is necessary, and developers perceive leadership as myopic, always asking for the simplest hack-on-a-hack to get a new feature working. From both perspectives, the company seems to invest mountains of effort with very little positive outcome.
The only cure is to embrace the reality that organizing people and organizing technology are very different things and act accordingly, not let people-organizing happen by chance as the more aggressive influence-seekers rise to prominence.
This means that at each level of a company’s hierarchy (regardless of whether or not it is an official one), business goals need to come down from the top, and operations realities need to come up from the bottom, and it needs to happen in such a way that leaders and non-leaders alike have their social needs fulfilled. That is, the product’s goals, timelines, and company constraints need to flow down to developers in an organized way, and the realities of design feasibility, tech debt payoff, painful workflows due to company process or tooling need to flow up in the opposite way, all while ensuring credit is given where it is due, and being aware enough to create situations where there is credit to give.
“Flow” implies a proper level of decomposition and abstraction. “Flow” implies a hierarchy in place to perform this decomposition at each level. A topic for a future post, you can tell how well this is working by how well planning goes—are specific-enough plans developed at each level of hierarchy that progress could be monitored accurately by the layer above? Is progress somewhat predictable? Are you retaining your employees?
The layers of management (whatever the people’s titles may be) between developers and executives need to wed the flow-up/flow-down goals and realities into a plan, or at least recognize the problems on each end and delegate specific tasks to achieve a plan. Each layer of the hierarchy needs to be invested in their work and, importantly, they need to see these a reward for working with the team and accomplishing their mission. Only a strong middle management can provide this type of guidance where the business goals at that level are transformed into personal goals that make people become invested in their work.
Often, in the name of reducing bureaucracy, this layer of middle management is missing, and each person is left to find their own rewards and set their own goals. This seems like it should be greatly stimulating and keep people involved and energetic—and for some, it does. Those are the more aggressive people we’ve been discussing.
But overall, it has the opposite of the intended effect; instead of the company becoming more efficient, it becomes less, as with decisions being more federated in this way, they become untraceable and are often unaligned with the intended direction of the business, even while the federated decision-makers still believe that they are in alignment. This means that the company leaders do not see the progress they expect to see, and they can’t tell why.
A present, but weaker form of middle management in a flat org skews very heavily toward one side or the other, relating more to business goals or more to developer needs. For an example of each: in one situation, a mountain of tech debt causes lost ground to competition in what seems like should be an almost a trivial implementation for a feature request, and in another situation, a team has spent an immense amount of effort to build an amazing set of tools to improve their own job satisfaction and sense of fulfillment—at the expense of being able to field a product or meet other business goals.
Some companies are relatively large, or have several layers of management, yet they share more in common with a flat organization than a hierarchical one. How can you tell which yours falls into?
Affecting the non-leadership portion of the official hierarchy, if developers are frequently discussing matters with other teams or managers that are not a part of the plan to meet the goals built with their immediate manager (or skip-level or higher managers continually bypass the immediate manager), these distractions are evidence of a flat organization. These distractions are evidence that there is another path for developers to achieve broader influence rather than investing in a plan to meet the goals they developed with their manager. This can work out very well for developers and their expanse of influence, or very poorly. It’s really difficult to tell in advance. The shorter an effort is, the more likely it will work well for the developer. But this can have the opposite effect on the business, as people optimize their plans for very small tasks, too few are working to advance the large-scale (and thus slower) vision and changes that may be needed.
Affecting the leadership of the official hierarchy, if the same implementation and team struggles repeatedly rise to the level of org leadership and never seem to be fixed, this is evidence of a flat organization, as the management hierarchy finds itself unable to exercise leadership with clear authority to fix these problems. Often, the people involved may not even want to fix these people-centric issues. They simply wanted influence, not to solve people problems. But to the topic, more broadly, to whatever level the problems continually rise, the lack of leadership is at one level lower and can only be fixed with help from the next level up.
As a senior manager or business owner (depending on the type of company), your job is to recognize when things are trending in an unhelpful direction, and to intentionally steer your company’s leadership into a helpful hierarchy. Remember, hierarchy exists whether the company creates it or not. The hierarchy that the company creates might not even be the true hierarchy of influence. Any hierarchy that is not the one you intentionally built will always appear “flat,” as decisions are made outside of a visible, measurable, and deterministic process for a sound and healthy software development business. You must keep on top of this, and the employees who helped get your company off the ground and into the state that it is might not be the best ones to determine a management hierarchy. You may need to hire outside the company.
As a manager, your job is to keep your reports focused and busy. They are professionals, so you are not a task-master. Your job is to enable them to do their best work possible to achieve their goals, the goals that come from their own interests and incentives, and the ones you have explicitly worked with the reports to align with the goals of the project. This implies that you regularly and transparently share decisions and supporting data for those decisions, as well as helping your reports determine what their goals should be in light of the business or product goals, and available staffing. It is your job to ensure that there is sufficient reward (which often involves helping your team brand itself) for their effort and results, and to calibrate the team on it. If they are determining their own goals apart from your project’s needs, both you and they will suffer.
As a developer, your job is to know the goals at hand and to continually work with your manager to prove that their trust is not misplaced—you know how to meet the goals, and you can demonstrate continued progress against a plan that you helped to create. You may dislike the idea of hierarchy, but it’s there to help the business, which means it’s there to help you. Your salary, bonus, influence, and engagement and stress levels depend on it. Use this hierarchy to your advantage! Grow your influence through the hierarchy by offloading tasks from your manager. Work with your manager to determine what to offload, and keep your work organized and traceable enough to give your manager a strong case for a promotion in due time.
Flat organizations can be fast. Hierarchical organizations can certainly be bureaucratic. However, flat does not imply “fast.” “Flat” does not imply a lack of bureaucracy. It merely implies lack of an official one. The cure is a strong hierarchy that operates as intended—acting as servant leaders to help the next layer down to do the fullness of their jobs.
Trevor Kemp 