There is a recurring complaint about the uselessness of software development (or engineering) managers in tech. At best, they’re considered a necessary evil. At worst, they’re incompetent programmers (or non-programmers1) who, through political means, weaseled into positions of power, became micromanagers, and actively impede the mission of getting software to customers. For some, they shouldn’t even exist.

While bad managers certainly exist, I believe that most of management’s work is largely invisible to developers. This is largely because managers, in many cases, are generalists who have worked themselves out of coding. People management is what our title would suggest we do the most of, but it is a relatively small part of our actual job. Managers, more often, accumulate four or five part time job duties and responsibilities.

Stephen Vance has put a post like this talking about the Different things we may mean when we talk about management, and this builds on the idea from another perspective. We were at the same company where he spearheaded an experiment to distribute the mentorship parts of people management, because this place had 30-40:1 IC to manager ratios. Ultimately, that project didn’t fully work and they did a combination of hiring managers from outside and promoting managers from within, often from those who were in this pilot coaching program. While the program helped increase mentorship, it ultimately failed because the other roles of management were being unofficially distributed to people untrained in the scenario, and important work was dropped on the ground because it wasn’t technical work.

That said, we absolutely could build organizations that do not have managers in the traditional sense. Consider this the blueprint of an organization that has no engineering managers below the VP of Engineering, yet still acknowledges the need for such functions.

What is a manager?

In the last three jobs, I have found that the job description2 of an software development manager (SDM) is an incomplete approximation of the actual job duties. To crib from that description:

  • Leading the development team in the design, development, coding, testing, and debugging of applications

This is effectively meaningless. The SDM does very little design below the architectural level, and do no development in most organizations. SDMs often will spot-check code reviews to see what is happening, but much of this is handled by a technical lead in most organizations. In a pursuit of an organization without engineering managers, we will consider this a duty of senior developers.

  • Managing all the activities of the software development team and setting goals for each team member to ensure timely project delivery

In practice, this means SDMs lead meetings and work as project managers. Further, setting goals for team members rarely have much to do with project delivery in most contemporary technical organizations. This is explicitly a role that most developers find little joy in, and as such we will need to think about how to staff for this. As much as we would like to say that timely project delivery accountability is a “bullshit job,” managing expectations in the organization is an important role in it.

  • Defining project scope, timelines, and resource allocation

In practice, this is a mechanical processing on the team’s estimation, combined with historical averages. Line managers rarely have much say on resource allocation other than advocating for another developer. They do advocate for project scope, however, and a world without engineering managers would require this to be negotiated between product representatives (product owners, or product managers) and senior developers.

  • Providing guidance to the team and ensuring they adhere to development standards

In practice, this is a check against poor senior engineering. Organizations with robust senior engineering cultures have little role for this in management.

  • Ensuring adherence to software development methodologies and best practices

This, however, is necessary in larger organizations, especially those with concerns about Sarbanes-Oxley compliance (SOX) or System and Organization Controls (SOC). SOX is important for public companies, and SOC is important for companies that sell to other companies. However, the real need is not for best practices - those can be handled by Senior Engineering - but for consistent practices that can be documented to corporate customers and investors. We need to account for this in our world without SDMs, and we need to consider a role for questioning and evolving these practices across the organization.

  • Collaborating with stakeholders to gather project requirements

For non-platform work, this has largely been delegated to product managers in most organizations, and organizations with product-minded developers do not need a level of management to abstract this. In agile development organizations with product roles, no SDM is needed for this purpose. Platform teams will need to consider this work, however, and product teams will lean on senior developers to define technical debt remediation and justify return on investment.

  • Managing software development budgets and expenses

Rarely is this handled below the director level. We can ignore this for line managers and in small enough organizations, this can be handled by a single person at the executive level.

  • Conducting performance evaluations and career development discussions

We will need to consider this in our list of tasks, even if performance evaluations are often problematic.

  • Identifying training and skill development needs for the team

Training budgets are largely a thing of the past for most organizations, and skill development largely happens by hiring or on the job training. Where this is needed, this can be identified by senior developers.

In practice, however, management is different in organizations based on the vision of the organization. Some organizations are very lean in management, where management is given as many as 50 ICs with little time for more than administration. Others have a Manager for as small as a team of 3-6, where coding and technical lead roles are conflated. Most EM jobs have one larger team or two smaller teams, and are teamed up with product and staff developers to cover all aspects of removing bottlenecks to solving business problems. Ultimately, the engineering manager is expected to have the emotional intelligence to adapt to the engineering and business culture and the skills to learn to be functional in the functions the organization lacks without training. Impolitely speaking, the engineering manager is often expected to be marginally competent in much of their role as there is no expertise in the organization from which to learn.

People, Process, and Technology.

People think of leadership within the categories of People, Process, and Technology. As such, I will roughtly split the responsibilities of management by this framework. In the path of eliminating the engineering manager, we will create a new HR position to handle the administrative tasks of a manager, adopt a role similar to scrum masters that is purely concerned with the processes of keeping a team unblocked, and expand the responsibility of the staff and senior developers by formalizing some of the informal roles currently handled by them.

People

First, we will separate out the administrative side of people management into a separate role. This part of the job accounts for about 10% of the daily workload of a manager with few reports and up to 25% for an over-extended manager, like one with 15 or more reports. For this role, we would hire people with HR experience; this work is not technical in nature and lends itself to a skillset that rarely is the primary skillset of those who started in an individual contributor role. I see a world where one HR representative could support 30-50 employees. This role would consist of:

  • Approving small expenses. this is largely an automatic role and only consists of applying automated rules that will be reviewed by the accounting team.
  • Approving vacation. In most development organizations, this is largely automated so long as there is enough support for any given role. There may be some conflict resolution necessary for times where teams are understaffed or have conflicting vacation wants, but there is no need for an software development manager to exist to resolve these issues.
  • Hiring support. Someone needs to make offers to candidates. In most organizations, these are hiring managers or directors. This group would also work with recruiting to help manage the interview workload of individual contributors. This is largely automated with newer recruiting software, but a group must be there to advocate for those who are burning out or otherwise overloaded.
  • Firing and offboarding support. Unfortunately, some developers do not work out. While a non-technical manager cannot make the determination of who is performing well and who is performing poorly, they can manage the exiting process. They also can manage any layoff support. Most organizations already do a bad job of determining who stays and goes in a layoff, and that SDMs rarely are involved in layoffs below a director level. As such, that this work could largely be handled outside of performance evaluation. Similarly, they would handle the logistics when an employee quits. Now, how would such a manager know if an employee is underperforming? This task would be distributed to staff developers in the organization. Usually, under-performance is evident to the entire team. A manager-less team would need a way to build processes to solve this.
  • Company interfacing. these HR reps would meet with employees monthly to make sure that all logistics are handled around the responsibilities of being a part of a company. In many cases, HR is only using SDMs as a conduit – SDMs have to follow up with an employee if they didn’t finish health insurance enrollment or similar administrivia.
  • Conflict management. While rare, conflict management often falls to managers, who are often poorly trained in conflict mediation. From microwaving fish to arguments about story refinement to flat-out racism and sexism, conflicts happen. These HR Reps would be responsible for dealing with such situations.

The truth is that this is a relatively small part of a manager’s workload, yet it is the work with which they are most associated. When people quit their managers, it is rarely because administrative tasks is mishandled.

There is one exception to this: raises and promotions. People absolutely do leave over financial concerns. There are two options here. First, this can be handled by a 360 review process. Coworkers can peer review and reviews can be conducted by technical leads and staff developers. As we will discuss later, a key responsiblity of staff and senior developers in this system is mentorship and feedback. It is a natural progression to delegate evaluation to these groups. The HR Representatives can be responsible for creating an environment that is fair and equitable, though. In some organizations, you could eliminate the performance review entirely, but that is a topic better covered elsewhere.

There are other parts of “People,” however. Mentorship and team alignment are key considerations. This would be poorly handled by HR management. However, mentorship is already a task expected of staff and senior developers: as such, this becomes a more formalized part of their duties in a manager-less system. As part of this, Staff and senior developers would need training in mentorship. However, they are poorly situated to facilitate team alignment and we will need to look elsewhere for this.

Process

For this work, an entirely new role is required. This role is responsible for about 30% of the job of a manager in a smaller organization and up to 60% in a larger organization. Organizations with project managers or scrum master/agile coaches will offload some of this from an software development manager and allow them to focus on the other elements. As such, there are two ways to think about this role. The first is closer to the role of a Scrum Master, one who trains the team to self-organize. In this model, the work of organization is left to the teams with support for larger, organizational problems being handled by the Scrum Master. The other is to look at the role of a project manager: A project manager is responsible for making sure to keep a project on track, tracking risks, and distributing knowledge from the team to the rest of the business. (In truth, agile coaches end up handling a subset of project management already in many organizations.) A smaller organization is likely to lean toward self-organizing teams more fluently than large organizations, and will need less project management metaphors. Larger organizations often have more trouble scheduling cross-cutting concerns such as database upgrades with breaking changes, managing team dependencies and blockers on larger initiatives, and coordinating work that does not explicitly belong to any one team.

This new role, which I will call a Team Coordinator, would be responsible for the efficiency and coordination of the teams. They would be responsible for helping the team be more efficient by handling with tasks such as meeting coordination and facilitation, keeping stakeholders apprised of risks and progress, and managing complex ordering issues such as mentioned above. Secondarily, they will be accountable for non-technical processes necessary for SOC and SOX compliance, as well as other industry-specific compliance needs, and will be responsible for evolving the process to align with the current organizational goals. (This is as often removing unnecessary process as it is introducing it.) The key differenciator of this role is that coordinators are not expected to control the output, but rather facilitate the process. Accountability is on the development team itself.

How many Team Coordinators are necessary? So long as teams are able to conduct most meetings on their own, the only constraint is the demand on Team Coordinator time. As this is a fundamentally facilitator role, they will need some technical fluency but it does not need to be their primary duty. They likely need up to 25% of time to do meta-work, but 30 hours of meetings can be a brutal life. Given most teams have no more than 10 hours of meetings a week, and that as an unproductive team, teams totallying twelve developers to a coordinator seems reasonable in smaller organizations, and larger organizations would expect no more than eight developers.

Technology

The role of a manager often partially overlaps that of staff developers or architects3. In organizations where these roles are understaffed or non-existent, managers are expected to perform this role. However, even in organizations with more established Staff roles, SDMs are expected to contribute to technical excellence.

Most organizations have the concept of a team lead already, and many of the roles and responsibilities are already in their domain in many organizations. The key, here, is that the staff developers and SDM operates as a check and balance against each other. In practical terms, The SDM is expected to challenge the staff developer and play the role of optimizing for business value in conversations with staff. Conversely, they are expected to support the reduction of technical debt in conversations with the larger organization with the gravitas that the manager position provides. They are expected to execute on judgement and facilitate the discussion of creating a technical roadmap.

In truth, once an SDM has stopped coding, it is a matter of two to three years before their day to day coding abilities are irrelevant, and most have their technical prowess fade. As such, technical leads are poised to work in mentorship, task direction and breakdown, and enforcement of good technical practices. In the average technical organization with staff engineers, little would change in the responsibilities of staff and senior engineers, but accountability would change. Staff Engineers are not currently accountable for the evaluation of technical leads, and they are not accountable for their mentorship. As such, most mentorship is either ad-hoc and most staff engineers are not trained on how to coach developers. (Sadly, neither are software development managers!)

In practice, this means that staff engineers would see more calendar meetings of technical 1:1s and technical evaluations of developers. In practices, most developers would now see their team lead as their “manager” and team leads would see the staff engineer as their “manager” in as much as they are now accountable for technical guidance and evaluation, but this is in practice a very small portion of the job. It is, however, one that developers do not enjoy and are not given appropriate training, so this will require help from the organization to work. I believe this is a surprise to most developers that this is considered a “minor” task for an manager. When there is an underperforming developer, it certainly takes up more SDM overhead, but I find that I rarely have that many underperforming developers at any one time, and the work that it entails is largely one of empathy and skill, not of time.

In this structure, we can assume that senior developers are all either capable of leading a team, or are in training to do so. We are expecting staff engineers to work with twelve developers - we can assume that a staff engineer and team coordinator are paired. Staff engineers and technical leads are still expected to code, but they will be ahead of teams with proof of concepts and work outside the critical path.

Context and Cost

It becomes obvious that you have built a system where team coordinators, senior and staff engineers have absorbed 90% of the SDM role, leaving the people management to be externalized. However, as you have split one role into three, you lose efficiencies in planning. As no one person has the context necessary to make a planning decision, many such decisions become meetings. It might be said that these meetings are nothing new to these roles – that is, tech leads have always provided input to the SDM when SDMs did not have all the information necessary to make decisions. They also historically work closely with project and product managers to handle project delivery and organizational conflict. In this model, the decisions are delegated to the network of people with the staff engineer as first among equals, and the enforcement is delegated to the team coordinator.

So, would this make financial sense? Using payscale.com salaries, an HR Manager is paid 74,000 on median, a good equivalent in job category. A scrum master is paid about 96,000 a year, and that makes a good guess as to the cost of this role. An engineering manager is reported at $133,000. A staff engineer is reported at $154,000.4 In this hypothetical organization, you would need 20% more staff engineers to handle the additional workload offset on them, you would replace a scrum master for an engineering manager, and you would have 1:50 HR managers.

Let’s assume an organization with 96 individual contributors to make the numbers easier. Assuming an equivalent 12:1 ratio (difficult for a manager, but not uncommon), you are looking at 8 SDMs and 5 staff engineers with a 20:1 existing staff:IC ratio (which is relatively common). Instead, you are looking at 8 staff engineers, 8 team coordinators, and 2 HR representatives. The traditional structure will cost 1.83 million, and the proposed environment would cost 2.15 million. In the traditional team, we are assuming that the SDM is doing the work that a scrum master would in another organization: adding scrum masters in such a small organizations would change the cost structure, but what team is incapible of handling its own ceremonies in 2024, especially in a smaller organization like the one proposed?

$300,000 is a significant chunk of change to remove the SDM role, but if we can make the argument that the new overhead is more capable than the previous system, that will pay for itself. The argument for such a system is that team coordinators could be trained specifically in organizational dynamics in a way SDMs are self-trained, and that a TC can be great at one set of work while a staff engineer can be great at making good technical decisions. However, the opposite can be argued as well: if you are loading these new duties on staff engineers, you cannot assume that they will be any more adequately trained than an SDM, and you have created a position where the skills that get them to the job are not the same that will help them be successful. Further, Staff and Senior engineers are supposed to be individual contributor tracks, and you have now turned those into quasi-management tracks, and limited career mobility for those uninterested in management. That is why we created the staff engineer position in the first place!

Ultimately, I believe that if we tried this, we have three possibilities. First, the TC will start to look like a management position and the salary will creep up and we will have removed technically competent managers from the value stream; Second, our staff engineers will start looking like managers, and we will have managers by a new name. Then, everyone will complain that staff engineers are useless. Finally, Product Managers will fill the power gap and start taking the power while team coordinators and staff engineers are beholden to them. In this environment, technical debt is deprioritized, teams are coerced into deadline-driven cultures with no pushback, and engineers are left without an advocate in the room as senior engineers and technical leads are not equipped to push back.

An alternative view

The obvious critique is to say that engineers could do all of these things and do not need the management layer to do so. Instead of adding the team coordinator position, we could add more engineering positions and have those organizational capabilities distributed. If you had self-directed teams that were no larger than 3, you would not need the complexity of the above. However, in that organization, you have distributed the workload on a larger number of developers, which means you have distributed coordination on them. You would need a much more disciplined organization in enforcing accountability than the above. In a sense, the system becomes a manager and you are relying on a very similar system as Valve. A smaller organization can likely handle this, but a larger org will be challenged. At some scale, accountability matters and you will see informal power start to replace formal authority, and you have not guaranteed that informal power is any better a foundation on which to organize an organization.

You could also look at the academy model, the traditional one used in Universities. 5 In that simplified model, a department elects a representative from the senior (tenured) members to represent them in the wider organization and distribute the administrative tasks. In an organization that was small enough, and an organization that hired for the right skills, this could work. However, you are then requiring that the path into senior engineering requires the political skills to manage an organization and the administrative skills to handle the self-management of a department. Instead of management being a sub-selection of senior engineers, it becomes an introduction at the midlevel with further and further burdens. I argue that this would push out neuro-divergent engineers and those who have no interest in managment, but it might be an alternative path for a subset of companies that come from an academic culture, such as startups that commercialize research, or for organizations that have a top-down agile mindset.

Ultimately, to look at replacing an engineering manager, you need to look at replacing the work they do. If you do not believe a manager is doing much work, or that their work is not valuable, it is because the role’s evolution has led to many hats that have aggregated out of convenience and have little to do with actual people management.

  1. That said, I do think all software development managers should have experience as a senior developers or QE. Even with technical support, it is hard to add value as a manager without such a base. ↩

  2. I want to cite the source, but this site seems to have been taken offline, and the wayback machine captures don’t seem to work either. ↩

  3. The Architecture and Staff Engineer titles largely duplicate the same function, but architects are often seen as a team onto themselves whereas staff developers are usually integrated into teams and expected to continue to contribute code in addition to their work in architecture and design. However, both roles are accountable for the facilitation of good decisions made by the technical organization. ↩

  4. We can laugh at these salaries, but we can reasonably assume that they scale proportionately. Double or triple the salaries if you feel appropriate. ↩

  5. For better and worse, public universities have steered away from this model with the introduction of professionalized management. As I am married to a professor, I see this as a closely invested outsider and will not pontificate on this until he is retired from academia. ↩