People: Resilience Creators, Not Resources

I've been traveling, teaching, speaking and consulting all over the world. I keep encountering managers who talk about the “resources.” They mean people, and they say “resources.”

That makes me nuts. I blogged about that in People Are Not Resources. (I have other posts about this, too, but that's a good one.)

I finally determined what we might call people. People are “resilience creators.” They are able to recognize challenges, concerns, or problems, and adjust their behavior.

People solve problems so the project can continue and deliver the product.

People fix problems so that customer support or sales can make the user experience useful.

People deliver products and/or services (or support the people who do) so that the company can continue to employ other people, deliver the company's work, and acquire/retain customers.

We want resilient companies (and projects and environments). When we encounter a hiccup (or worse) we want the work to continue. Maybe not in the way it did before. Maybe we need to change something about what we do or how we do it. That's fine. You hired great people, right?

People can solve problems so that the company can be resilient. To me, that means that the people are resilience creators, not “resources.”

People create resilience when they have the ability to solve problems because you asked them for results.

People create resilience when they understand the goals of the work.

People create resilience when they have the ability to work together, in a holistic way, not in competition with each other.

What would you rather have in your organization: resources or resilience creators?

5 thoughts on “People: Resilience Creators, Not Resources”

  1. “Resources” is a term of art, nothing more. It enables managers to refer to people over whom they have the authority to assign a task, as opposed to those whom they do not. “Customers” are not resources, and neither are “Executives.” The number of “people” who work for a firm is immaterial if none are assigned to work on your project.

    Note that when an employee is “terminated,” they generally survive; at least, that’s the intent. Now, if you’ll excuse me, I need to abort a process …

    1. Dave, you often make me smile. Thanks.

      My issue is that when managers refer to humans as “resources,” they create problems for the people doing the work and for themselves, the managers. Some of these problems are:
      – Assuming people are interchangeable: “I need a testing resource on that project. Who’s available?” As opposed to who has worked with that team before.
      – Assuming there is no cost to create/change/dissolve a team. Knowledge work, especially software, is team-based. Whenever you add someone to a team, there is a cost. The people have to relearn how to work together. If you remove someone from a team, the team has to relearn how to work together. There is a cost.
      – Assuming they don’t need to limit the management work in progress, the number of projects ongoing (the project portfolio). If the managers have “resources,” they don’t consider how many projects in progress vs. how many projects a team can complete.

      We work as teams in software. Each team has its own mini-culture. Too often, managers assume all teams are the same, or that people are interchangeable. The term “resource” reinforces that thinking.

      I agree that it is a term of art at this point. I’d like to change that. I’ll put on my Don Quixote persona.

  2. I’m glad I got a smile out of you – I think you needed one. My consulting practice is centered on transformation projects for global firms, where software development is a smaller component. Large corporations have completely transformed the practice of staffing in the 21st century. I get to see the impact of matrixed organizations and over-dependence on contingent workers, from the perspective of someone trying to form a list of near-strangers in multiple time zones into a team. On the last four projects, I’ve averaged 20% of my time just trying to find someone to work on a task, when all of the people with the right knowledge were already assigned to several projects in addition to their regular duties. Techniques like swarming and workshopping don’t produce the same high-quality results as Scrum, but sometimes you just have to throw a frozen burrito in the microwave and dream of Chipotle.

    1. Dave, you are seeing the effects of management debt. They think of people as “FTEs”, Full Time Equivalents. It just doesn’t make sense to start a project or a program with insufficient people.

      In a large, geographically distributed program, I often do not recommend Scrum. The real-time rituals are too difficult to manage. I often recommend starting with a kanban to see where the work is.

      Best of luck with those frozen burritos 🙂

  3. Pingback: People are better in the unknown | AAAgile

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: