What I Talk About When I Talk About Management

2 June 2021 — about a 9 minute read

I stepped in it (again) on Dev Twitter, jumping into a discussion about management on agile teams. I saw this thread from @allenholub that had an interesting reply from @alexbunardzic:

I like the first sentence a lot. I am a strong believer in the team being the agent of work on an agile product team. I have a more complex reaction to the second. Nobody likes an “inane ‘performance appraisal’.” But there are times when people need individual help. So I jumped in…

Which led to this great analogy:

I find the assertion “Mature orgs only care about the baton” myopic. But let’s run with this one.

Let’s say we have a 4x400 relay squad who has a set of goals for the season and they have self organized. They are running agile. They are doing well. They have gone from the back of the rankings to contending in most meets. Medals! Success! Fantastic!

What about the individual runners?

This team probably has a coach, or even coaches. The coaching staff worries about all sorts of problems: individual runners’ practice schedules, exercises, hydration, injuries, and egos. That sounds a lot like management to me.

Is the coach, then a member of the squad? Sure. Slice the team however you want. I think the point stands that not all team activities, or team members, are directly about execution to outcomes. There are occasions for additional support to help the runner and the team.

Let’s pop up a level. Say our relay squad is part of an entire Track & Field (Athletics) team. There are more running events. There is the heptathlon and decathlon. The Athletics team has a desired outcome to maximize medals across all of the events. This means more fans and more sponsorships and a better future for all of the team members.

What if swapping a runner off of the 4x400 squad improves the chances of more medals for the team? Or that by moving a runner off of the 4x400, that squad’s time improves? And then that frees up a runner who can enter another event? Or if one of the runners misbehaves outside of their work and sponsors threaten to take away necessary support? How does the team handle these situations?

Running Turtles

When teams are given desired outcomes and given the agency to self organize, they can do amazing things. This is what Agile is all about. But teams do not exist in isolation. They are made of individuals. In larger organizations, teams are working with and/or alongside other teams.

There is self similarity here. It’s turtles - I mean teams - all the way down. A person is a team of one. An organization is a team of teams.

If you ignore the people on a team, you run the risk of losing people from the team and perhaps miss your goals. If you ignore the context in which your team operates, you may wander away from desired outcomes and lose funding. Oops.

This does not have to be due to malicious ignorance. It can come just from natural tendencies to over focus “on the baton” or team members who do not have skills on the team to notice and deal with the problems. So how can you fix this and “stay agile?”

Defining Terms

Let’s expand the model a bit. I’m going to avoid using the term Management and instead define some new-ish ones.

Coaching is the set of solutions that focuses on the needs of the individual within the context of their team. This includes helping a person reach their maximum potential within that team and the organization.

Teams can do a good job coaching directly within the goals of the team. But there are other situations - toxic personalities, complex feedback, or individual goals that are potentially outside the scope of the teams’ goals - that sometimes need an outside perspective.

Governance is the set of solutions that focuses on the needs of the teams within the context of their organizations. This includes helping teams reach their maximum potential within the organization while considering the needs of the organization. This includes supporting coaching.

A team only exists while it is funded. And it’s funded to solve a problem, usually to make a thing that solves a problem. When in the course of solving that problem, their actions or solutions detract from the organization’s goals, then there is a need for at least a discussion, and possibly a correction.

Some situations - both team and individual - can be solved by moving individuals between teams. These situations need input from a lot of directions - involving coaching and governance - in order to get resolved.

This model is the result of observation and iteration that happened during my time at Pivotal. We grew from roughly forty consultants at Pivotal Labs San Francisco in 2008 to the 2000+ employees who VMware acquired at the end of 2019. Coaching and Governance were a key part of that growth.

Implementing and Iterating

In 2010 or so, Pivotal Labs had several high performing agile teams - one for each client of our consulting practice. We had identified the need for team-independent individual coaching. We created a new role to fill that need and gave it the title of “manager.”

Managers remained consultants on projects about 80% of the time. They mostly, but not always, coached people on other teams. Which meant spending about 20% of their time coaching people in 1-1’s outside of the team context. Individuals “reported to” managers in the HR/hierarchy sense.

Some governance was simple. Our clients provided most of the governance for any one team. After all, we were teaching them agile practices for their products. They had their own goals and the teams managed themselves to them.

Pivotal’s need for governance across teams presented itself around staffing changes. We had to staff new projects and deal with projects ending. We needed to ensure we were growing individuals’ skills, onboard new people, and fill seats when someone went on vacation. People quit. Some people did not work well together. This governance was the responsibility of “directors”

We called the process of moving people around between projects “Allocations.” It was a calculus that took input from the clients, all of the teams, and all of our staff to determine who, if any, moved between projects each week. This was initially a meeting of two people and a whiteboard. Over time it grew to a continuous discussion between the team of directors and the managers. The managers were the proxies for their people in these discussions.

The managers were an agile team across all of the other teams. They needed coaching as they grew, met new challenges, and adapted. Managers reported to Directors who provided that coaching.

These management practices scaled, with several tweaks over time to, 17+ Pivotal Labs offices, the Cloud Foundry product teams, and had some influence over the rest of Pivotal R&D. I spent time managing in both organizations. By the time I left in early 2020, there was a lot that was working well. And there was plenty that was not. Some things remained very hard.

Annual Performance Reviews - which is a very non-agile implementation of recognizing achievement - was definitely one of them. It sort of worked. We did not bypass the team to get information and we cornered nobody. But it was not a smooth process and was a contributor to another problem: manager burnout. The burnout came came from other sources, too. Learning to be a manager was challenging and often amorphous. For managers of developers, I think the balance of time on teams vs time as coach was not sustainable.

Gathering, filtering, and delivering feedback was vital to coaching individuals to success. Bad actors were managed out of the company, people found teams where they could contribute more, and I know of a couple of careers that blossomed thanks to how we handled feedback. But as well as we did this, as a solution space it needs a lot more cross-discipline work before I would consider it smooth.

Interface and Implementation

All this said, I think our iterations and adaptations to add coaching and governance were valid and helpful to the people, teams, and company. I will use this experience to help any team I’m a part of.

What I hear a lot, and part of the arguments in the tweet thread, is that agile teams have an interface line (goals/metrics/outcomes) that management cannot cross. That any suggestions about changing things inside the team by a hierarchical manager is anti-agile! That teams could get so much more done without such meddling!

I agree that meddling and micro-management, what Elisabeth Hendrickson (channeling Jerry Weinberg) calls “inflicting help,” are anti-patterns. Agile methods aim to prevent these practices.

In my experience, to ignore the team-independent needs of individuals leads to other anti-patterns like burnout, resignations, and general unhappiness. And to ignore the team-interdependent needs of an organization can lead to funding being pulled, the wrong product being built, or organizational collapse.

Adding concepts like coaching and governance can help people and teams to do their best. And it is possible to add them incrementally, and process feedback about using them, just like you can with any agile practice.

This article is tagged with agile, software development, and management.