A rather long time ago I was in a meeting with a fairly senior development director and we were talking about annual roadmap planning. He was complaining about things. One of the things he brought up several times was race horses. He kept saying –

Bob, we simply don’t have enough race horses.

I became confused and a bit frustrated and I sort of lashed out saying –

What do race horses have to do with us meeting our software product goals for next year?

He said – no Bob, I’m talking about resources, not race horses.

After all these years, I still find this story both amusing and troubling at the same time. I think we often overuse the term resources as leaders, managers and project managers in software discussions.

Let me be clear. If you’re talking about people…say people. If you’re talking about facilities, equipment, and tools, then say resources. But don’t mix up the two.

Resources are often fungible. One chair is the same as another or one desk or one computer. You can list them on a spreadsheet and easily calculate how many of them you need to fill a specific space in your office. That’s fairly simple.

But people aren’t…so simple.

They’re unique. Uniquely skilled, experienced, enabled, empowered, and understood. No two are exactly alike. Oh you may think that developers, for example, are all introverted, but that’s a gross generalization that insults every software developer on your teams. And people are certainly not fungible.

You want to get away from thinking of people (or teams) as if they can simply be added or grouped together.

Another Distinction

Around 2005 I was a very seasoned software development manager who found himself looking for work. I’d been developing some highly sophisticated distributed trading system software for the global financial community—some really complex stuff. And to be clear, I was not only a good leader, but also a very good developer and architect.

But due to timing, I couldn’t find a leadership role in software development. Instead, a senior QA manager role came up at EMC and, long story short, I took it.

I remember in my first week I was invited to a design review for a complex piece of software that they were developing. I was the head of the QA team, so they wanted me to review and weigh-in on the system requirements and design.

But something strange happened in the meeting, something quite unexpected that took me aback.

The first thing I noticed that people stopped using my name. Instead they started calling me “QA” as in—what does QA think about that design decision? And how does QA plan on testing that component? It felt strange and demeaning in some way. I actually replied back that—

I didn’t know what “QA” thought about it, but here is what “Bob” thinks about it.

In that same meeting I noticed another thing. That folks were talking slowly when they tried to explain the ins and outs of their new product technically. And I mean v-e-r-y  s-l-o-w-l-y. As if I’d dropped quite a few brain cells when I took the QA role or forgetting that I had a very strong product development background

Again, I attributed this to everyone laying my functional role on top of me and disassociating with the person. Now I look back and laugh about it. But at the time, it too was demeaning and frustrating. Particularly setting a bad tone for a new hire in a new culture.

And it is harder than it seems…

I remember when I was leading our teams at iContact. I tried very hard to refer to individuals or teams over functional silos. But every so often, I would refer to a function in an example or in one of my stories. I guess old habits are simply hard to break.

I would often catch myself and immediately apologize for the oversight to the group I was speaking with. I would literally correct myself right then and there.

I came up with an internal metric that I still try to hold to today. For every time I spoke to or about a “functional silo”, such as QA, I had to talk about individuals and the team for 9 times to undo the damage that the one misstatement caused.

You see I firmly believe our language matters a great deal. If we’re looking to foster highly collaborative, performing, and engaged agile teams, then we can’t talk about resources or “QA” or ‘Development”. It just reinforces silos, hand-offs, gates, and a lack of x-team collaboration.

Wrapping up

To wrap-up this article, I want to share some guidelines that might prove helpful in your interactions. While most of my stories were pre-Agile, I think the lessons and advice applies across methodologies and cultures.

1. Stop using the term resources to apply to people. You should charge and collect a “fine” every time someone does it. Then treat folks to lunch with the proceeds.
2. Stop referring to groups by their functional name, as in QA or Development or Architectures or Management.
3. Stop considering individuals as being fungible in any way. Consider and discuss everyone is an individual.
4. Stop using “magic numbers” to calculate team member availability, for example everyone is planned at 70% of their availability. Instead, ask individuals for their capacity.
5. Stop considering one or two voices as being representative of the “opinions” of an entire group. For example, I like Planning Poker dynamics because it encourages everyone to voice their opinion.
6. Stop allowing one group, developers in the team, to be considered done with their work independent of the entire team. Done-ness should be cross-team and cross-functional in nature. It’s a team output.
7. When you’re approaching a near shore or outsourcing partner, don’t think in terms of resources and staff augmentation. Think in terms of partnership and put the same care as you do in hiring your own team members as your do with your partner.

The real point is that teams are composed of individuals. Let’s consider that in all of our interactions and not lose sight of the individual. I expect agile teams to behave respectfully in that way and everyone outside of the team should too.

Stay agile my friends,

Bob.