Thinking About What to Call Team Members and Managers

Bob Sutton (@work_matters) tweeted this the other day:

Perhaps companies ought to stop using “IC” or “Individual Contributor.” It seems to absolve such employees from helping others

I retweeted it and we had some back-and-forth about what to call people i organizations.

Let’s eliminate these words for people who are not managers:

  • Individual Contributor: There are no one-person projects or efforts. Every work has at minimum, the person doing the work and the customer for that work. In what lifetime does a person work alone on anything in the organization?
  • FTE (Full Time Equivalent): FTE implies we have working units who are fungible with other working units who get paid the same amount. (Uh, no. Not at all. We have people who work.)
  • Resources: Resources removes our humanity. I have said before that people are resourceful. They are not resources.

We could call them any of these:

  • Team members
  • Employees
  • Staff (I used to use this word. I’m not so sure I like it anymore. But, I’m sure you can go back in this blog and show me places I’ve used it. I’m learning, just as you are.)
  • People

I like team members or people the best. That’s because I don’t see people working alone. Even in non-agile organizations. People work with other people. Even if they don’t collaborate together to finish the work. Even people who are part of one specific team often collaborate across the organization. Do let me know if you have a better idea.

Now, let’s go to the word, “Manager.” Managers are people and team members too. However, they float among different teams. Let’s take the first-level manager.

First-level managers are part of the team they manage, but not in the same way as the people doing the work of that team. First-level managers (project managers, functional managers, Scrum Masters) facilitate the team’s work. They serve the team.

In addition to the team they “manage” (no one manages people; managers decide on results and create the environment in which people/team members deliver results), these managers are also a part of other teams. Those teams might be people like them, such as functional managers who report to a Director or VP. They might be part of a team of project managers/Scrum Masters, etc. Those teams might not be explicitly defined in the org. However, effective managers use their peer group as a community of practice. They build relationships and learn what other people do.

Mid-level managers are often part of more explicit teams. They might be part of a program team, or a project portfolio team, maybe even a product line management team. They are often part of a team of the managers who report to them (their staff, “down” the hierarchy) and the managers they report to (“up” the hierarchy). Those teams might have a cadence of meetings to troubleshoot problems that prevent the first-level teams from delivering the results the org wants. These managers serve the organization, also.

Senior managers are often a team. They decide on the strategy together. They make financial decisions together. They set financial boundaries for the different work or departments. And, they also are part of their teams of managers “down” the hierarchy, their staff.

For me, team members are part of one feature team or work group. The managers use their small-world networks to build relationships and accomplish work throughout the organization. Managers are often part of several cross-functional teams, regardless of whether those teams have a name.

Hierarchy is a convenient way to organize, to draw boundaries around decision-making and financial responsibilities. I don’t have a problem with the words managers or team members. As with Bob Sutton, I have a problem with “Individual contributor” because no one works alone. We happen to pay people based on their “individual” contribution and that’s a leftover from the piece work days. Knowledge work doesn’t work like that.

We are all part of teams of some variety. If you think about names that are reasonable for your people (team members and managers), terrific. I certainly don’t have all the answers. (I wrote a little about what managers might do in agile organizations in several places here. I think the most recent post is What Development & Test Managers do in Agile Organizations.)

I only have a problem when we forget we are all people. Do let me know what you think.

12 Replies to “Thinking About What to Call Team Members and Managers”

  1. I’ve been thinking about this a lot. Hubby and I watched the movie “Sully” and it really hit me how they called the passengers “souls” – not resources! I’ve also heard of companies that call people “heart beats” to remind them that we are all living, breathing, humans. I really hope my children work in a world where no one is ever called a resource.

    1. Wow. I think the airlines call the people on planes “passengers” or “customers.” I love the idea of “souls.” (Great movie!)

      I’m a hard-boiled egg, so I’m not so sure I like the term “heartbeat” for people. Yes, we each have one. I don’t know. It seems kinda touchy-feely to me, which is not my strength.

    2. “Souls on board” is a transportation industry standard term which goes back to maritime days as a way to report the total number of passengers and crew on board.

  2. I do like and use “team members” because like you said, people do not work alone anymore and are usually on teams. This is even more prevalent when talking about pair testing, mob testing or mob programming. I usually refer to “project team members” because invariably I am referring to team members of a project. I distinguish using “stakeholders” to those who have a stake in the project’s success but I may or may not work with those people. Team members seems to give the human quality to my reference as well as being inclusive to work together. I do equate to a sports team or an athletic endeavor. Even as a figure skater competing for myself, I worked with a team of 2 coaches. I didn’t win, We won. And when a project is complete, the team wins. Just my thoughts … I do like the distinctions though in how we address people or think of people while being a part of something whether it’s a project or company. Wonderful post.
    Jean Ann Harrison

    1. Jean, thanks. I like the idea of distinguishing stakeholders who are interested but are not part of any team. (I’ve been using the words “manager/sponsor/customer” in my book. Maybe I’ll change that to stakeholder!) I don’t tend to use sports analogies because some people then think of ski teams where everyone is on his/her own, or a bicycle team where people work for the top person, not even themselves. That’s me, though. Thanks!

  3. Software people think nothing of “aborting” or “terminating” a process, yet you want to object to HR people using terms like “FTE” (which is really only meaningful when reporting a mix of people who do and don’t work full time) and project managers using “resources” (note that we also have to manage non-human resources, from hardware to meeting spaces)?

    It’s a term of art, people – respect the other professions in your work space as you would have them respect yours.

    1. Thanks for this. In my book (out for review), I don’t talk about aborting or terminating a project early. Maybe I should. (I would use the word “Stop.” 🙂 It’s true that abort and terminate are the OS terms. Until you said that, I hadn’t thought about it. That’s because I started working, we had to reboot to stop a runaway process. We did “abort” the process. I can see now how the terms might cause other people to have a bad reaction. I appreciate you for opening my eyes to this.

      Dave, the problem I have with calling people resources is that it tends to lead to other dysfunctional behaviors. One org I consulted with built—at the insistence of HR—a database of people and asked them to rank their abilities with different languages and tools. The rank was 1-5, where 1 was something like “no knowledge” and 5 was something like “could teach at university level.” At first, people were honest about their abilities. Then, the people who had 1-3 ranks on certain tools were moved out of projects back into the “pool” of “resources.”

      You and I both know this is stupid. Given what I know about you, you would never do something like this. You might ask people how they learn. You might, depending on their other skills, arrange for training because people have other skills, often more important for the work. Tool and language-based skills in software is the easiest to learn, harder to practice to get great, and only discriminatory if you have a project with one or two people who desperately need those skills.

      The org above? People caught on quite fast, within 3 months. Soon, everyone was a 4 or a 5 in everything. Even in new-to-the-org languages and tools when people had worked there for 20 years.

      It might be a term of art now. Back when I started to work it was “Personnel,” a term I happen to find more acceptable.

      I prefer to discuss project run rate (the FTE equivalent of the number of people on the project times their salaries) as a separate thing from resources. Managing the people environment is often quite different from managing hardware, desks, office space and meeting space.

      1. One of the unpleasant uses of cheap, reliable computing power has been empowering bureaucrats to waste other people’s time with the mandatory collection of imprecise data to be arbitrarily categorized and reported in fractions of a percent. I feel your pain. Still, dysfunctional behaviors arise not from terminology but from inappropriate incentives and turd-like role models. But if they re-cast my SPHR credential as “Senior Professional in Human Capital Management,” I’m outta here.

  4. Thank you for your article, it is interesting to delve into the terminology used nowadays in companies.

    Regardless of the terms, although I agree that terms make a difference, many companies forget that teams are made of people. That people have ambitions, needs and feelings.

    To give some examples, many forget to define a vision for their company or product, to create perspective for their employees and make it clear what it (company/product) is all about. The vision brings people together and gives them autonomy (powerful motivator).

    Many forget that they are welcoming people in their teams and not objects. People like to feel welcomed and part of a group and some need a bit more support in the beginning. Even the little details like having your desk and computer ready before you enter the office the first time contribute a lot to feeling welcomed and also to confirming that you made a good decision to start working there.

    Many forget that every person in a team is unique, with different aspirations and personality and that the team should be a safe environment for all of them. At the same time, the team should act as a whole, so team members should be aware of the differences, embrace them and find ways to work together in a good and somewhat predictable way.

    Many forget that there are people on both sides of the delivery pipeline. A team of people will put themselves in the shoes of their users and if they don’t like what they see, they will loose focus, interest and commitment.

    There are many things that come out of the fact that teams are made of people. Some simpler, some more complicated, discussed many times in different contexts, but still, the “industry” is lagging behind. On the plus side, there is so much to learn and improve out there! 🙂

Leave a Reply