original text QUESTIONABLE ADVICE: “MY BOSS SAYS WE DON’T NEED ANY ENGINEERING MANAGERS. IS HE RIGHT?”
I recently joined a start-up company to manage a team of about 40 engineers and serve as the vice president of technology. However, I had a big conflict with the CEO (formerly an engineer) on whether to hire a full-time technical manager. At present, engineers are divided into small teams of 3-4 people. Each team has an engineer leader who is responsible for leading the team, but their main responsibility is still to write code and deliver products.
I have HC who will hire more engineers in the next year, but no HC who is a manager. The boss thinks we are a start-up company and can't afford this luxury. In my opinion, we obviously need a technical manager, but in his opinion, the manager is just an extra expense. In our stage, everyone should try their best to write code.
I don't know how to argue. It seems obvious to me, but in fact, it's hard for me to express in words why we need a technical manager. Can you help me?
——Is it really unnecessary expense (?!)
There are many questions to be answered.
It's not surprising that your CEO doesn't understand why he needs a manager, because he doesn't seem to understand why he needs an organizational structure. 🙈 Why should he micromanage how you organize your team or which roles you can hire? He hired you to do the job, but he won't let you finish it. He can't even explain why he didn't let you do it. This is not a good omen.
But this question is really worth thinking about. Let's assume he didn't mean to make trouble for you. 😒
I can think of two ways to demonstrate the employment of technical managers: one is quite complicated, starting from the First Principle, and the other is very simple, but may not be very satisfactory.
I personally have a strong antipathy to authority; I hate being told what to do. Until recently, I found a healthy and practical understanding of hierarchical system from the perspective of system theory.
Why does hierarchy exist in the organization?
The hierarchy system does carry many negative burdens. Many of us have had the unfortunate experience of dealing with managers or the entire organization under a hierarchical system. In these places, the hierarchical system is used as a tool of oppression. People improve their status by monopolizing information and playing power games. Decision making is made through power repression.
Working in that place is really torture. Who is willing to put their creativity and vitality into a place that feels like a Dubert cartoon, knowing that their values are rarely recognized or rewarded, and that these values will be slowly but really suppressed?
But the hierarchical system is not autocratic in nature. Hierarchical system is not a political structure invented by human beings to control and dominate each other. In fact, it is an attribute of self-organizing system and appears for the effective operation of subsystems. In fact, hierarchical systems are crucial to the adaptability, flexibility and scalability of complex systems.
Let's start with some basic facts about the system and introduce them to people who may not be familiar with it.
Hierarchy is an attribute of self-organizing system
A system is a "network of interdependent components that work together to achieve a common goal" (W. Edward Deming). A pile of sand is not a system, but a car is a system; If you remove the fuel tank, the car won't work.
A subsystem is a collection of elements with smaller goals within a larger system. There can be many levels of subsystems in a system, and they run interdependently. The subsystem always works to support the needs of a larger system; If the subsystem is optimized only for its own best interests, the whole system may fail (this is the origin of the term "suboptimal" 😄）。
If a system can make itself more complex through diversification, adaptation and improvement, it is self-organized. As systems self-organize and increase their complexity, they tend to generate hierarchies - the arrangement of systems and subsystems. In a stable, flexible and efficient system, subsystems can, to a large extent, self manage, self adjust, and serve the needs of a larger system, which is responsible for coordinating the relationship between subsystems and helping them play a better role.
Hierarchy minimizes coordination costs, reduces the amount of information that needs to be tracked in any part of the system, and prevents information overload. The information transmission and relationship within subsystems are much more intensive and have much less delay than that between subsystems.
These should be familiar to any software engineer. Modularity, right? 😍）
According to this definition, we can say that the job of managers is to coordinate among teams and help their teams perform better.
The dichotomy of social technology system is a false proposition
You may have heard this fallacy: "Engineers are skilled, managers are skilled." I hate this statement. 😊 I think this totally misunderstood the essence of the social technology system. The "society" and "technology" in the social technology system are not completely separated, but intertwined and interdependent. In fact, there are few pure technical work or pure interpersonal work; There is a lot of bonding work involving two skills.
Look at some tasks that any effective engineering organization should do besides writing code:
- Recruiting, networking, interviewing, training interviewers, summarizing feedback, writing job descriptions and career development paths
- Project management for each project or commitment, prioritization, managing stakeholders and resolving conflicts, estimating size and scope, conducting review meetings
- Hold team meetings, conduct one-on-one communication, provide continuous growth feedback, write reviews, represent the team's demand architecture design, code review, and refactoring; Capture DORA and productivity indicators, manage alert volumes to prevent burnout
A lot of work can be done by engineers, and it is often the same. Each company assigns these tasks differently. This is a good thing! You don't want these jobs to be done only by the manager. You want individual contributors to co create organizations and participate in how they work. It would be more effective if almost all these jobs were completed by people with engineering background.
Therefore, you can understand why some people hesitate to spend valuable staffing on technical managers. Why don't you want everyone in the technology department to write and deliver code? Isn't this by definition the best way to maximize productivity?
Um 😉
The technical manager is a useful abstraction
In theory, you can list all the coordination tasks that need to be completed, and let different people take charge of each one. But in fact, this is impractical, because everyone needs to know everything in this way. Remember that one of the main benefits of hierarchy is to reduce information overload. The communication within the team should be efficient and fast, while the communication between teams can be less.
With the expansion of the company, you can't expect everyone to know everyone else; We need abstract concepts to work. Managers are the focal points and representatives of their teams, acting as routers for important information.
Sometimes I think of managers as the nervous system of the company, transmitting information from one department to another to coordinate actions. Focusing many or most of the functions on one person can take advantage of specialization, because managers will constantly build relationships and background knowledge, and constantly improve in their roles, which greatly reduces the context switching of others.
Manager Schedule and Maker Schedule
Technical work needs concentration and concentration. The cost of context switching is high, and too many interrupts are deadly. The management is to switch the context every hour or so, and deal with various interruptions all day long. These are two completely different working modes, ways of thinking and schedules, which cannot coexist well.
Usually, you want team members to spend most of their time contributing directly to the results they are responsible for. Engineers can only do limited bonding work, otherwise their schedule will become fragmented and they will not be able to fulfill their commitments. The schedule of managers is already fragmented, so it usually does not cause too much interference to let them undertake more bonding work.
Although not all bonding work should be completed by the manager, the manager's responsibility is to ensure that all work can be completed. The responsibility of the manager is to make every engineer be able to do interesting and challenging work, but not to make them feel too burdensome, and to ensure that unpleasant work can be distributed fairly. Managers also need to ensure that if we ask someone to complete a job, we must equip them with the resources needed to successfully complete the job, including dedicated time.
Management is a tool of accountability
When you were an engineer, you were responsible for the software you developed, deployed, and maintained. As a manager, you are responsible for the team and the whole organization.
Management is a way to make people responsible for specific results (such as building a team with the right skills, relationships and processes to make the right decisions and create value for the company), and provide them with the resources (budget, tools and staffing) needed to achieve these results. If you don't take organization building as someone's top priority, it won't become anyone's top priority, which means it may not be well implemented. So, who should be responsible, Mr. CEO?
You have a reasonable upper limit on the tasks that the technical director, engineer or anyone responsible for delivering software can complete in "spare time". If you try to make technical leaders responsible for building healthy engineering teams, tools and processes, you are asking them to do two incompatible jobs in the same calendar. Most likely, they will focus on what they feel comfortable with (technical achievements), and accumulate organizational debt in the background.
In the natural level, we look up for the goal and down for the function. In short, this is the complex reason why we need technical managers.
Choose a boring technology culture
The simpler argument is that most engineering organizations have technical managers. This is the default setting. Over the years, many people who are smarter than you or me have spent a lot of time thinking and adjusting the organizational structure, which is the result we have got.
As Dan McKinley famously said, we should "choose boring technology". Being boring does not mean that it is not good, but that its ability and failure conditions are well known. You can only get a few innovation points, so you should wisely use these points on the core differences that can achieve or destroy your business. The same is true of culture. Do you really want to use your points on the organizational structure? Why?
For better or worse, hierarchical organizational structures are well known. There are many people in the market who are good at management or cooperation with managers, and you can hire them. You can receive training, guidance, or read a lot of self-help books. There are various management philosophies that can be centered around them to unite teams or exclude others. On the other hand, the experiments without managers I know (such as the full autonomy of Medium and GitHub, or Linden Lab's "Choose Your Work") have been quietly abandoned or subverted. In my experience, this is not because leaders are crazy about pursuing power, but because of chaos, lack of focus and poor implementation.
When there is no clear structure or hierarchy, the result is not freedom and equality, but "informal, unrecognized and irresponsible leadership", as detailed in "Unstructured Tyranny". In fact, these teams are often chaotic, fragile and frustrating. I Know! I'm angry too! 😭
This argument does not necessarily prove that your CEO is wrong, but I think his standard of proof is much higher than yours. "I don't want any of my engineers to stop writing code" is not a valid argument. But I also think I haven't completely solved the core problem of productivity, so let's talk about it again.
More lines of code ≠ higher productivity
A brief review: we are discussing an organization with about 40 engineers, divided into 10 groups, each group has 3-4 engineers, and each group has a technical director. Your CEO believes that if someone stops full-time programming, this slowdown will be unbearable.
Maybe. But according to my experience, several large teams led by experienced technical managers will be far better than these small teams. The gap is obvious. Moreover, they can complete their work in a more efficient, sustainable and humanized way, rather than this desperate rush.
Systematic thinking tells us the reason! Fewer teams, but larger in size, you will have less overall management overhead, and greatly reduce the slow and expensive coordination within the team. You can achieve rich and intensive knowledge transfer within the team, so as to achieve greater sharing. Each group has 7-9 engineers. You can establish a real shift, which means less heroism and less burnout. The coordination you need can be more strategic, less tactical and more forward-looking.
Can five large teams write more lines of code than ten small teams, even if five engineers become managers and stop writing code? Maybe, but who cares? Your customers don't care how many lines of code you write. What they care about is whether you are building the right things and solving the problems that are important to them. The key is to drive the business forward, not just write code. Don't forget that simply writing code will produce additional costs and negative effects.
What determines your speed is whether you spend your time on the right things. Learning to correctly decide what to build is a problem that every organization must solve, and this is an ongoing work. The technical manager will not do all the work or make all the decisions, but according to my experience, they are absolutely essential to ensure the smooth progress and good performance of the work. As I wrote in the last article, the technical manager is the carrier of the feedback cycle used by the system for learning and improvement.
Will managers become unnecessary expenses?
Of course. The core of management is to coordinate the work between teams and improve the operational efficiency of the team, so any way to reduce the coordination needs will also reduce the management needs. If you are a small company, or your team members are very senior and accustomed to cooperation, you do not need much coordination. Another important factor is the speed of change; If your company is growing rapidly or has frequent staff turnover, or faces a lot of time pressure or frequent strategic adjustments, your demand for managers will increase. But there are also many smaller organizations that operate well without too much formal management.
I don't like the word "spending" because a) it's a bit rude, b) people who call managers "spending" usually don't respect or value the skill of management.
But management is really an expense 😅。 The same is true for many other bonding jobs! These works are very important, but they cannot drive the business forward by themselves; We should try to do only those jobs that are absolutely necessary. The natural attributes of glue work make it easy to spread, devouring all available time and resources (even more).
Restrictions are good. It is good to feel that there are insufficient resources, which should become the norm. Management is easy to become overstaffed, and managers may be very reluctant to admit this, because they never feel less pressure or tension. (In fact, the opposite may be true; overstaffed management may bring more work to managers, while streamlined organizational structure may make them feel less pressure. Bureaucracy tends to grow by itself. Especially when management pays too much attention to promotion and self-improvement. This is another sufficient reason to ensure that management should not only promote or dominate.)
Management is also like operation work. When it is done well, it is invisible. Assessing the work of managers can be very difficult, especially in the short term, and deciding when to create or repay organizational debt is a completely different and complex issue, far beyond the scope of this article.
But yes, managers can definitely become unnecessary expenses.
However, if you have 40 engineers who report to one vice president, and no other person is responsible for the work related to personnel, teams and organizations, then I can be quite sure that this is not a problem for you at present.
<3
💡 For more information, please follow the Bytebase public ID: Bytebase
