Managers are Dead! Long Live Managers!

Over the last few years in Appian Engineering, I have made sure to share one key aspect of our culture in every interview, because our management model is very different than it is at most companies. After more than 50 interviews, candidates are always amazed when I explain how we’ve inverted the role of the manager and how much sense it makes. We changed the typical employee-manager dynamic and found that it leads to much happier employees.

First, let’s start with the traditional model. The situation often starts with a developer under a manager.

The developer is good at the tasks they perform, but at some point, the workload becomes too great for just one person to handle. To handle the work, they get a few developers to teach and delegate to, and these developers each become a new manager with a team. This is the classic “delegation” or “Command and Control” model. The new manager knows how to do the tasks required of the team and can help ensure that the team learns how to do them correctly.

Now imagine that you are one of the developers hired under this manager. Your manager provides you tasks and you are responsible for completing those tasks. You report the status back to your manager. This is why it is referred to as a “Reporting Structure.”

When your boss gets pressure from their manager to get tasks completed, this naturally passes at least some of that pressure along to you. It may also be accompanied by anxiety from your boss to get more frequent status updates because their manager is waiting on them.

In this model, the manager/employee relationship is primarily built around the work. Good managers in these situations will still do their best to spend time on your happiness and career growth, but this isn’t the “natural” focus for them. Developmental areas for you could interfere with their responsibilities to their own manager. This often leads to micromanagement, especially by managers who are still capable of performing your tasks; they have an incentive to jump in and do things for you so they get done on time or according to their vision.

In addition, there is also the problem of how your manager became a manager in the first place. In this scenario, they were promoted because there was too much work for one person to do and they were good at those development tasks. However, being a good developer does not mean you will be a good manager!

Management requires an entirely different skill set than development. Some people have those skills, or can grow them, and others don’t and can’t. This is one instance of the Peter Principle, which can be summarized as: being promoted to the level where you are no longer competent. This can result in very good developers becoming really poor managers. These managers are even less likely to focus time on your growth and development, and even more likely to micromanage. This can add yet another incentive to jump in, because they were actually good at it and probably also miss feeling competent!

Shifting focus for a bit, let’s look at the typical Agile team, or “Squad” in Appian Engineering, and how they function so we can find where the manager role fits in.

Our average squad, as with many Agile teams, has a Product Owner (PO), a Squad Coach (SC, aka Scrum Master), Quality Engineer (QE), and a handful of Developers (Dev).

The Product Owner works with Stakeholders and generates the prioritized backlog.

As a Developer on this Squad, you pick up items to work on from the top of the backlog, based on priority, your skills, areas of the code you’d like to work in, etc., since we don’t have a hierarchy for Developers in a Squad.

Then you work with various other members of the team in the course of completing the backlog item. You may have technical design discussions, pair program with, and get code reviews from other Developers. You may discuss acceptance criteria and scope with the Product Owner, review automated and manual test plans with the Quality Engineer, and confer with the Squad Coach about impediments and off-team needs.

In the end, the team ships another increment of the product and the cycle continues with Developers picking up items off of the backlog, working together to implement and test them, and shipping them.

Nope, you didn’t miss anything. In the workflow we just walked through, there was nobody “tasking” anyone and therefore no real need for the traditional “manager” role that we saw earlier. Let’s look at the team in detail to verify what we’re saying.

The Stakeholders are off-team and often external to the department or company, and the QE isn’t a manager. Also, the QE and Product Owner should never be the team’s manager since that throws off the natural balance in an Agile team. So maybe the SC?

The Squad Coach should ideally not be the manager, because you run the risk of that person becoming a Project Manager instead of assuming the Servant Leader role like a traditional Scrum Master. They aren’t really supposed to be tasking anyone, just helping the team be self-sufficient. We have actually done this in the past, but we’ve moved away from it due to this issue. While some of our Squad Coaches are also managers, they never manage more than just a small subset of the developers on their own squad. So how about a Dev?

While one of the senior developers could also be the manager, there are many cases where there aren’t any senior developers who are also good managers (or interested in managing). Sometimes, you have a team of less senior developers, none of whom make sense in this role. Plus, it is better for team autonomy to have Devs making choices in the tasks they pick up, rather than a senior developer assigning them out.

So it looks like we really don’t need a manager in this picture since there is nobody tasking anyone else. So can we just get rid of the manager role?

If we do, then who will help us with…

While managers are not needed for a squad to ship software, there are still useful things that they can provide to the individual employee. They help you know how you are doing, how you can improve, how to navigate your career options, and let others know about your accomplishments.

Managers in Appian Engineering are not tasking employees, they are supporting them and working beside them (most of our managers spend 50-75% of their time doing hands-on development). The manager role has become a servant leader just like the Squad Coach, but instead of focusing on teams, they focus on individuals.

By removing the tasking function, it is easier for managers to be on different teams than some of their direct reports. Being on the same team does provide more frequent context, so we typically try to have managers with a few on-team and a few off-team employees. The original “Reporting Structure” has become a “Supporting Structure.” As an additional benefit, embedding developer/managers, who are trained in providing feedback on teams, has helped us to promote a culture of frequent, peer feedback.

This shifts the manager/employee relationship away from the deadlines and the work you are doing, since you are responsible to your team for that, not your manager. Instead, the focus is on your professional growth and development as a 2-way conversation. Your manager is gathering and providing you with timely peer feedback, connecting you with the resources you need, helping you to navigate your career options, and answering your questions about upcoming changes. They coach you to higher performance and promotions, and represent you to upper management and the broader organization. All of this leads to higher employee engagement, which is great for the employees and the organization.

As previously mentioned, in the delegation model, people are often promoted to management when they are good at some task and there is too much work for them to do it all themselves, often leading to bad managers and unhappy employees.

In Appian Engineering, when looking for managers, we look for people who show high emotional intelligence, are generous and genuinely enjoy helping people, have good mentoring and coaching skills, and are good listeners. We have found that those are the type of skills that make for a successful manager and one that employees will not only enjoy working with, but will also be more likely to thrive under. This fits well with our philosophy of finding the alignment of talents, interests, and company needs. The end result has been much happier and engaged employees, much better and happier managers, and a turnover rate that is about half the industry average.

According to Gallup research, most people leave their jobs because of their manager. By changing who becomes a manager and what their focus is, we’ve been able to make managers one of the main reasons people love working here.