There is a tendency in discussions of staffing and organizational structure to speak of people, especially software engineers, as being fungible—or not. What an exceedingly unpleasant choice of words! People are not fungible. People fungibility is an inappropriate concept. Let’s see how the underpinning issues can be discussed more fruitfully.
What is Fungibility?
What is People Fungibility?
Aside from the extreme offensiveness of implicitly comparing people, even engineers, to crude oil or pork bellies, fungibility is poorly chosen as a management concept. First of all, it completely ignores the developmental stages through which all professionals go.
To oversimplify, there are people who are learning the ropes and need to work under direct supervision. There are people who can work independently but their results needs to be controlled. Some can work very reliably in an independent way. And there are people capable, in addition, of supervising, leading and encouraging others. So, whereas fungibility is an attribute of a static object, people constantly evolve along many different axes.
What is more, the skills we need are constantly evolving. Consequently, each person may be in a different developmental phase with respect to each skill. A person could be a brilliant C++ coder and, at the same time, a neophyte in R or Python. On top of that, organizations regularly change the technologies they use. So peoples’ skills regularly change on a slippery slope of changing need. There are so many variables, so many changing requirements and skills, so many aptitudes to acquiring new skills, that it is hard to imagine how we could ever call two engineers “fungible”.
Whence Comes the Idea of People Fungibility?
What are the roots of calling people “fungible”? One thread leading to this obscenity is the idea of the “full-time equivalent”. An FTE is a concept promulgated by human resource and finance departments as a way of managing personnel in the aggregate (see Fig. 2). Another basis for the concept is the idea of professional qualifications, attested to by a piece of paper stating that you have passed an examination, thereby demonstrating your professional qualifications. For some people, one Microsoft Certified Engineer is thought of as the equivalent of another Microsoft Certified Engineer. Anyone with a Cisco CCNP Cloud certification will do the trick, eh? Only hire help desk agents with ITIL Foundation certificates.1 And so forth, thinks the manager who accepts the concept of people fungibility.
But wait, you may say. Something is wrong with that! These certifications are entirely theoretical in nature. They show that you can pass an examination, that you can memorize a certain number of facts. But that is not the same as being an effective and efficient collaborator in an organization. Just so. It is a problem to treat certifications as if they were hallmarks on ingots of gold.
So human fungibility is a concept in the mind of the hirer. Don’t hire “permanent” employees if you can help it, think some hiring organizations. They are hard to fire when you need to save money. Much better to hire fungible contractors with short-term, renewable contracts!2
Another source of this concept is the idea of the perfectibility of work.
This concept owes much to the work of Frederick W. Taylor and his principles of scientific management. The assumption is that there is a single best way of performing a certain type of work. A role of management is to discover this method and to ensure that all laborers do their work in that way. The result of achieving this goal is the fungibility of the people working in a uniform way. I will come back to this issue below when I discuss robots and fungibility.
People Fungibility or Resource Liquidity?
Rather than simply pooh-poohing the whole idea of people fungibility, we should recognize that there are some important issues underlying it. A much better way of thinking about these issues is through the concept of “resource liquidity”. Resource liquidity, like fungibility, is a term borrowed from economics. The liquidity of an asset is a measurement of how easily that asset can be converted into another type of asset. Thus, cash is extremely liquid. You can almost always use it to buy something else (so long as you have enough of it). Real estate tends to be illiquid. It might take a long time to find a buyer at a mutually agreeable price.
In the context of people doing work, resource liquidity refers to the degree to which a person is available to perform a task when that task is ready to be performed. Liquidity can be measured as a percentage of cases, given a certain context. Thus, we might say that someone is available to test a solution when it is ready to be tested 80% of the time. Or we might go one step farther and define availability within a given range of time. Thus, some qualified person might be available to diagnose an incident within 10 minutes 90% of the time. This is the essence of probabilistic management, the idea that some predicted value will fall within a given range a certain percentage of the time. It contrasts with deterministic management, such as defining a rule for the maximum time it must take to start performing a task.
Note that we are not talking about the virtual “conversion” of one human resource into another human resource. We are instead talking about the conversion of the human potential to do work—the initial asset—into some type of useful transformation or assembly of the inputs to work, which results in another type of asset.
Specialists and Generalists
People Fungibility & Resource Liquidity Metrics
The obvious difference between people fungibility and resource liquidity is that the former is an all or nothing concept. Two people are either fungible or not. Statistically speaking, the data is of the categorical type. Fungibility leads to thinking of people in the aggregate. Liquidity, on the other hand, is measurable along a continuous scale. In statistics, it is numerical data.
As we saw above, fungibility refers to static, intrinsic properties, whereas liquidity refers to behavior within collaboration and the flow of work. Liquidity encourages us to think of people as individuals. When we address people problems in terms of how individuals work together, we can start asking the questions that lead to durable improvements. Problems defined in the aggregate lead to solutions meant change aggregate statistics.
For example, if you treat people as fungible then you might measure the percentage of a team that has a certain professional qualification. You think in terms of additional training and fix a KPI of a higher percentage of qualifications. But there is a missing link in this logic. Jill has a certificate plus 15 years experience with the system. Will getting Jack a certificate solve the problem of liquidity when, in fact, much of the problem with Jack is a chronic lack of sleep, short temper and difficulty in communicating with his colleagues? But which statistic looks better on the annual performance review of the manager:
- She instituted a professional training program and raised the percentage of certified employees from 33% to 67%; or
- She helped Jack with some personal issues to ensure that he was getting enough sleep, thereby making him a better colleague to his teammates.
People, Fungibility and Robots
The concept of fungibility plays a role in the current debate about the respective roles of people and robots. In this case, however, people are concerned about their replaceability by robots rather than by fungible, human colleagues.
Capitalization and Automation
Some might object that people performing highly standardized manual tasks should be treated as fungibles. One may take pride in such work and excel in its performance. I do not mean to disrespect people who perform such work. In economies with low levels of capitalization, many such roles might exist. However, in economies with high capitalization, such roles tend to be performed by robots. If not, they are likely to be so performed in the near future. Thus, the more work can be performed by a fungible agent, the more it is susceptible to being performed by a robot.
Learning
Fungibility is a factor distinguishing people from robots. Two robots coming off the same assembly line are fungible. But, with the rise of robots using machine learning, do we not have more and more robots that are distinct, one from the other? As an individual robot goes through multiple iterations of learning, does it not develop unique, non-fungible attributes? Some might even speak of robots having their own personalities.
While this might be true, it points out that the concept of fungibility for software cannot be the same as fungibility for hardware. If two ingots of gold are fungible, it is because they share the same intrinsic qualities that make gold ingots economically valuable. Two robots, with different machine learning experience, are intrinsically different, so how can they be fungible? The answer is that robot experience is realized in software—data and algorithms that can be easily copied from one robot to another. Once so copied, the robots become highly fungible.
This distinguishes robots from people. It is extremely difficult to reproduce in a second person the learning that one person has acquired. Indeed, making a carbon copy of one person’s learning is undesirable. It is more beneficial to allow each person to bring together their different experiences and learning so as to encourage new perspectives and innovation.
Diversity and Performance
We may close this discussion by referring to the issue of diversity in teams. Is it conceivable that team members be fungible and, at the same time, be diverse? To what sort of diversity am I referring?
The past few decades have seen extensive research by sociologists and psychologists into the impact of team diversity on the performance of work. Many of these studies concern diversity on the basis of skill sets, race, gender, social categories, values, experience and so forth. The results of the studies are hardly uniform and are difficult to reproduce. It is difficult to make generalizations about the impact of diversity on a team’s performance.
That being said, cases have been identified where a mixture of senior, experienced people with neophytes give better results than teams composed of “experts” alone. Similarly, cases where teams combines fundamentally different jobs, such as architects, marketers, designers, artists and engineers, have shown improvements in performance.
So, should we aim at making people more similar to each other, making them as interchangeable as possible, or should we aim at improving how dissimilar people collaborate? The obvious answer is that we should find ways of making our resources more liquid and ways to improve collaboration. But these are only attempts at strategies for achieving our real goals, and should not be goals in and of themselves. The real goals are for workers to find pleasure and fulfillment in doing work, for that work to deliver its results when its customers need them and for the work to be done efficiently and effectively.
The article People are not fungible by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Bibliography
Works concerning workgroup diversity:
[a] Jehn, Karen A., Gregory B. Northcraft, Margaret A. Neale, “Why Differences Make a Difference: A Field Study of Diversity, Conflict and Performance in Workgroups” Administrative Science Quarterly 44/4 (1999).
[b] Neale, Margaret A., Gregory B. Northcraft, Karen A. Jehn, “Exploring Pandora’s Box; The Impact of Diversity and Conflict on Work Group Performance” Performance Improvement Quarterly
[c] Pelled, L. H., “Demographic diversity, conflict, and work group outcomes: An intervening process theory” Organization Science, 7 (1996) 615-631.
[d] Watson, W. E., K. Kumar, and L. K. Michaelsen, “Cultural diversity’s impact on interaction process and performance: Comparing homogeneous and diverse task groups.” Academy of Management Journal, 36/3 (1993) 590-602.
[e] Williams, K. Y. and C. A. O’Reilly, “Demography and diversity in organizations: A review of 40 years of research.” Organizational Behavior 20 (1998) 77-140.
Notes
1 A recent report (unfortunately made unavailable on 2019.03.12 and not archived ) gives an incoherent view of how the respondents feel about certifications for help desk agents. Two-thirds of the respondent felt that ITIL qualifications have some value. On the other hand, only 7% of the respondents felt that something was more important than professional certifications for hiring and promotion. Whatever that might be was not clearly revealed.
Credits
Unless otherwise indicated here, the diagrams are the work of the author.
Fig. 1: By Deirdre 13:59, 24 January 2007 (UTC) – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1595898
Figs. 7 & 8: Images from “I, Robot” 2004. Copyright Twentieth Century Fox Film Corporation.
Minton Brooks says
8 October 2018 at 12:15Excellent article and contribution to the Lean Kanban community Robert — thank you! This is a very important topic, and it might be useful to bring these parameters into appraisal of an organization’s Kanban maturity.
Robert Falkowitz says
8 October 2018 at 12:53That’s a good point about the issue of maturity, Minton. On the one hand, I think it straight-forward that high resource liquidity is a sign of maturity. It’s not clear to me, though, how the gradient of specialization or “fungibility” might relate to maturity. If we look at this from a static point of view, then we might say that there is no single configuration of skills that is best for all cases. But if we look at it from a dynamic point of view, whether organizations need to invest in personal development over the long term, then the aspect of maturity becomes clearer. In other words, can we say that an organization that only looks at the current situation and chooses its resources based on what was needed yesterday is less mature than the organization that has attempted to plan for future needs by developing “square-shaped” people? Maybe, but at the cost of being less agile. And this in a realm where skill needs evolve terribly rapidly.