Many people draw distinctions between people who do management-kind of work and people who do “individual contributor” kind of work. I've been asking if they mean individual work or team member work. Sometimes, they do mean individual work. More often, they mean team member.
Our culture shapes our language. (And, our language shapes our culture.) When we recognize and reward people for individual work, the more often we will call them individual contributors. We reinforce a culture of resource efficiency. (Sometimes, we reinforce a project culture where teams break up after they're done with the project.)
When we talk about teams and reward and recognized team-based work, the more likely we will talk about teams and team members. We reinforce a culture of flow efficiency. (Flow efficiency can help create and reinforce a product culture.)
Technical team members tend to work on just one team. (Okay, the people who have reasonable managers do. Too many people multitask, which is costly and crazy-making.)
You might think managers work alone, as individual contributors. Some of a manager's work is individual. For example, managers conduct one-on-ones as individuals with another person.
The most effective managers I've seen are part of several teams. That's why it's so difficult to understand many managers' roles.
Here are some possibilities for how managers work as part of various teams:
- A cross-functional management team who assesses the systemic problems teams encounter, to resolve those problems.
- A cross-functional team who manages the project portfolio for their part of the business, for a product line, for an organization.
- As part of the regulatory/governance/operational team at the senior level of the organization, if your org has one of those teams.
- As part of product value teams.
- As part of a sales team.
There might be more. Why do you think managers have hours and hours of meetings in a day? They're trying to work across the organization to accomplish something. Managers are team members, too.
Let's rethink the term individual contributor. No one is literally an individual contributor. At minimum, everyone's work has a customer of some sort. That means everyone is part of a team, and that includes managers.
If you want to move to an agile culture, start thinking in terms of teams. Not just technical teams, but management teams.
Let's change how we refer to people. Instead of individual contributor, consider using the term “team member.”
The phrase “individual contributor” is an HR term of art. It identifies those who have no other employees reporting to them—nothing more. It has nothing to do with their contributions, team membership, or relative worth to the organization or to society. It is simply an attribute of the Employee (or Job) object that has proven useful in human capital management systems. In context, it is useful and meaningful. Out of context, maybe not as much. If someone said in a team meeting that they couldn’t abort a process because they were Catholic, how would you respond?
Also note that there are people with some variation of the word “manager” in their title who have no direct reports, and others who do not have “manager” in their title but nevertheless have employees reporting to them. So when the HR folks organize activities like performance reviews or compensation adjustments or select people for training, they don’t use the “Title” attribute.
Final thought: humans are only one type of resource to be managed. Some managers oversee financial resources, capital equipment resources, inventory, intellectual property resources, licenses and other usage arrangements, and other assets and expenses. Some may end up managing multiple types of resources and may interact with everyone from their own team to the general public or governmental agencies. Context is import, n’est pas?
Dave, it’s possible individual contributor is an HR term of art. However, it makes no sense in an agile organization. We change titles and names all the time to fit the context. With the realization that people work in teams, it might be time to change the words.
I prefer to change terms of art when we want to change the culture.
The idea of aborting a process is a very old idea in software. It took me a minute to think about what a Catholic might think 🙂 It is a process, however, not a something else. That’s what makes the difference.
The fact that there are title-based managers who don’t manage people directly (such as project managers, program managers) means that not all managers “manage” people. The non-people managers are responsible for shepherding the process by which they achieve results.
If I want to help organizations move to an agile culture (and I do), I need to help the HR people realize that individual-based compensation when we focus on teamwork is crazy-making for the people and for the teams. When the reward system is out of sync with the actions we want people to talk, it makes sense to change the reward system. In the same way, it makes sense to me to change the names of how we refer to people.
I think you and I might disagree with how much people need management. We all need to understand where we’re headed, and what done means. I’m not sure people need as much management-in-the-form-of-control as you might think. (I don’t know. We might violently agree!) In my experience, managing other resources is very different from managing people. I should do a post on that.
Thanks.
Johanna, I would note that managing, supervising, and leading are very different activities and one size only fits one; often, even that fit is temporary. Semper Gumby—always flexible.
Also note while it is preferable to reward teams as groups, few people are willing to accept that failure should also impact their compensation. Will we let people bail on a failing project because they won’t get their team-based bonus? If we do, then how will we back-fill them? If we don’t, how do we keep them from bailing on the entire organization? How will we recruit experienced people when we ask them to put a substantial part of their compensation at risk of poor performance by a group of strangers?
Dave, I agree that managing, supervising, and leading are all different. I have not seen the need for much one-on-one supervision in an agile team. The team supervises itself.
That’s because in an agile team, the manager supports the team and its capabilities. Does the team need help sometimes? Sure. Maybe even a lot of the time. In an agile team, the manager asks the team what they need. If the team doesn’t know, the manager might offer some experiments or some other alternative.
If anyone works in an agile-by-the-framework/book, they rarely work in an agile team with an agile culture. They might work in iterations. They might visualize their flow. However, they don’t create an agile culture. They might well be better off than they were before. They don’t have a self-managing agile-culture team.
I wrote several other posts about team-based compensation. I agree with you: I don’t want all my compensation based on the other members of the team. However, part of the compensation might we be shared among the team members. Take a look at Possibilities for Managing Individual and Team Compensation and my Agile HR series: Creating Agile HR, Part 8: Summary. That’s one of the reasons I treasure your comments. You help me articulate more of what I tried to say the first time. Thank you.
I don’t claim to have all the answers.
I do know this, based on my experience:
– Bonuses for individuals don’t make sense if we want them to work as a team. We reinforce their solo contribution instead of the team’s contribution.
– Bonuses based on sales targets don’t make sense for technical people. We are often way too far removed from the sales process to use our work as contribution to that.
– Bonuses for managers for “their” hierarchy make even less sense to me. The money reinforces internal zero-sum behavior (I win/you lose). Instead, we want the entire company to win against the competition/others in the market. If we fight ourselves, we are weaker and can’t manage our market standing.
I have used and believe in a team-based approach to hiring, to projects, to the project portfolio, everything. Again, if we believe in and reward flow efficiency, we can succeed as a team and organization. We each contributed differently, so yes, some compensation is personal. And, if we allow the compensation to be solely about what an individual does (regardless of where what individual sits), we lose the value of a holistic approach to the work, flow efficiency.
Maybe I should write more about this. I’m planning a series on what it means to be a product-based instead of a project-based organization. I might have to write that for you to understand me. (Yikes!)
Actually, I really do understand what you mean. And there are a lot of organizations with a mix of product-based teams AND project-based teams—Workday is the one I’m most familiar with. They are a very well-led company with a very sophisticated approach to recruitment, compensation, and retention, as befits a firm that produces the HR software used by about a third of the Fortune 500.
The overall trend among US firms has been for more short-term performance incentives—spot cash awards, team/small-group incentives, project bonuses and retention bonuses—for exempt salaried employees. To your point: the team members each get $$$ if the team gets to a specific “done” by a date certain. Once you achieve or miss that goal, you set a new one with a new award. It’s tedious and it might not be the “agile ideal” but it can be administered by line management without a lot of scarce HR involvement.
I haven’t seen much on long-term cash incentives for teams and small groups but I’m no longer a member of World at Work so I can’t access the new surveys. Compensation consultants deal in market surveys and scarce skills are hard to survey. It might be possible to pull together enough data to support introduction of a long-term performance incentive plan for software development teams, but I expect most HR departments will want to stick with short-term cash rewards and use equity plans for long-term retention.
IME as an employee and as a consultant, short-term incentives often don’t work. Too often, they are skewed to delivery date, without any other aspect. (See Drive and Punished by Rewards and some of Sutton/Pfeffer writing, which I can’t remember right now.
I would like us, as an industry, to move away from incentives of any kind. (For all levels.) Too often, incentives skew behavior to one specific aspect of the entire whole. It’s possible that OKRs done right do work, but too often the OKRs look like MBOs.
I prefer thinking about payment for work as a real transaction: the company agrees to pay me for the work-by-project or for a set time. I agree to do my best for that work.
I don’t need incentives as long as I have some transparency on parity and on how I will be measured for ongoing payment. I actually get that as a consultant. Many of my inside-the-org colleagues have very little transparency, insufficiently defined career ladders and little, if no, ongoing feedback.
Compensation is a tricky topic. I’ll have to do more work on this.
Compensation is a tricky topic, indeed. The basic Certified Compensation Professional credential requires you to sit for ten exams and every CCP I ever met has at least a Masters degree in HR. They make about 40% more than the average HR consultant and for most employers with a $200M+ spend on white collar compensation, they’re worth it.
They would be worth it!!