People in our field like to cite various maxims or laws. To name a few, there are Conway’s Law, Hyrum’s Law,
Brooks’ Law, the Peter Principle, Hofstadter’s Law, the 90-90 Rule, Parkinson’s Law, Sayre’s Law, Eagleson’s Law, Postel’s Law (a.k.a. the Robustness Principle), Linus’ Law, the Dunning-Kruger Effect, the Principle of Least Astonishment, Hanlon’s Razor and it’s notable parent, Occam’s Razor, and of course the ever-popular Murphy’s Law.
I’d like to consider a couple of maxims today: the Law of Diminishing Returns and the Pareto Principle, or 80/20 Rule, in relation to the idea of multi-skilled team members on a cross-functional team.
A debate
There’s an ongoing debate about the advisability of generalists vs. specialists in software development. There’s value in having a team of people who can address any and all (well, most) challenges that come up. There’s value in having individual specialists who have deep knowledge of particular technologies, practices, or methods. I think both those perspectives are valid.
But there’s a problem, and the problem is us. We have a tendency to be dogmatic and absolutist in everything we say. No, no, that’s not just my opinion. That’s the absolute, universal truth.
Computers operate in binary, but humans aren’t supposed to. Yet, whenever someone mentions generalists, others leap to the conclusion that they mean no one should ever bother to develop deep, specialized knowledge in any single area. Whenever someone mentions the value of specialists for getting things done properly, others leap to the conclusion that they mean we should become mindless automatons who can only perform the same task over and over again all day long.
The first of the two principles I mentioned now comes to the fore: We tend to forget there is a point of diminishing returns in just about everything (I started to write in everything, and then I remembered nachos.) If you become so much a generalist that you forget how to do anything particularly well, that may not be such a great thing. Similarly, if you specialize so single-mindedly that you can’t perceive the context of your work, and you become a bottleneck when your skill is needed and dead weight the rest of the time, that may not be such a great thing.
In praise of generalists
There are those who advocate for T-Shaped People; individuals with strong skills in one or two areas and basic competency in several others, and a willingness to learn and expand their skillsets. The idea originated with Tim Brown, a co-founder of IDEO, in or around 2010. For several years, it was an unavoidable buzz-term in Agile circles.
Some, like David Clifford (video), aren’t satisfied with a T. They want X-Shaped People. The idea is that workers have been conditioned to specialize in just one skill because organizations generally operated as “factories” of one kind or another, and to be successful (where success == favorable performance review), people had to perform one step in an assembly-line process with a minimum of errors.
It’s becoming more common for work in the software field (and any other creative activity that involves design thinking) to require multiple skills and close collaboration with colleagues who have disparate backgrounds. The old “I-Shaped Person,” able to perform a single task over and over again with great precision and only occasionally burning out, doesn’t fit this mode of work.
Clifford’s notion of an X-Shaped Person is more far-reaching than just software-related skillsets. It’s about achieving our full potential as humans, both individually and collectively. X-Shaped People have four attributes: Stories, Strengths, Skills, and Stance. They apply all four in a balanced way to function as embodied, purposeful, self-aware, creative, and ethical humans.
Wow. Let’s pause for a moment to bask in the glow of all that stuff.
Ah, yes. Lovely.
Okay, enough basking. Snap out of it!
In the mundane world of day-to-day work we sometimes refer to such people as “polyskilled,” “multi-skilled,” or “full-stack.” We’re thinking mainly of their tech-related skills, and not necessarily of their development as humans (except sometimes).
Yeah, okay, but why?
There’s a feeling in our line of work that we must go faster faster faster; deliver more more more. We read books with titles like Accelerate, Ship It!, and Deliver! (they forgot the exclamation point on that first title, but it’s impled). People adopt “agile” and “lean” ideas with the goal of going faster and delivering more, and only rarely with the goal of learning and applying “agile” or “lean” thinking to help them achieve meaningful outcomes.
When we apply Lean thinking to the challenges of software development and delivery, we tend to focus on maximizing throughput and cycle efficiency while minimizing mean cycle time and cycle time variation. We do this by managing buffers and limiting work in process to achieve continuous flow, or as near as we can get.
Two of the things that pop out as problematic are cross-team dependencies and hand-offs between specialists. Those things cause all the eight wastes of Lean.
If we could eliminate cross-team dependencies and hand-offs within a team, we could achieve smooth flow, high throughput, short lead times, and stable cycle times while improving cycle efficiency. If every individual on a team can perform all the tasks the team normally performs, then there are no “speed bumps” in the team’s work flow. It’s a Lean Dream Team.
I suspect, but can’t prove, that our present emphasis on speed and our present fascination with Lean Thinking has led us to emphasize T- or X-Shaped team members to an extent that may go beyond the point of diminishing returns.
And it may not even be possible.
So, is it possible, or what?
It may not be.
Consider the popular notion of the full-stack developer. When the kids say this, they’re thinking strictly about webapps. A webapp stack comprises front-end technologies like JavaScript, CSS (and supersets), HTML (and supersets); mid-tier technologies like web servers and application servers, with applications typically written in Java, C#, Python, PHP, or Ruby; (possibly) a lightweight database management system, and (possibly) the client side of APIs that connect all this stuff to the “real” enterprise back-end, which the kids see as an opaque box.
The problem here is webapps are just one general category of business applications, and business applications are just one general category of software systems. There are many companies whose software services are entirely handled by webapps and mobile apps, but there are also many companies that have substantially more information resources than just those.
I’ve already mentioned nachos, so there’s precedent for introducing food analogies. Consider a layer cake. It has several layers of cake with thin layers of icing between them. The whole is covered in yet more icing, and the outer icing may be decorated with various frills and doo-dads, and maybe a birthday wish or congratulations upon your graduation or wedding or retirement or whatever-it-is.
Now consider the IT assets of a large, longstanding corporation that started using computers in its business operations in, say, the 1960s. What do you suppose that layer cake looks like? Way back in aught and fifteen, when the millennium was yet a poopy baby, I wrote about the challenges of vertical slicing of work and full-stack developers in a large enterprise IT environment. In a nutshell, the challenge is that there are just too many different skills to master in that sort of environment for any single individual to be a true “full-stack” developer. Indeed, there are so many different technologies in play that we couldn’t put together a cross-functional team of specialists to cover them all without exceeding the maximum practical size of a “team” in the full sense of the word.
A webapp full-stack developer, working on that kind of layer cake, only penetrates the outer layer of icing. A true “vertical slice” of functionality has to slice through the cake all the way to the plate.
It ain’t happenin’.
In praise of specialists
So, we should just forget the whole idea of X-Shaped or polyskilled people, right? Some would say “yes,” but I think that would be another “point of diminishing returns” problem.
In the Industrial Era, software organizations operated like assembly lines. There was the belief that maximizing resource utilization was key to efficient operations, and also the belief that humans were merely “resources.”
Now that we’ve been cured of those mental illnesses, we’re free to think about throughput over utilization and about self-actualization over mechanical efficiency in performing tasks.
Yet, there are things about our work that are sufficiently unique and complicated that a generalist would never be able to keep their skills up to a reasonable level of competence. I’m thinking of things like cybersecurity, user experience including accessibility and localization, data analysis, sophisticated technical infrastructure to support massively-scaled microservice architectures, performance tuning of database systems, and more. In addition, larger enterprises almost always have a number of third-party packages in play, and many of those are sufficiently difficult to live with that they require dedicated teams of specialists who do nothing else.
There are valid reasons to have specialists in the organization. But the arguments against generalists aren’t usually based on those reasons. They tend to take the shape of “rants” against the idea of generalists. It’s “impossible” for a programmer to think like a tester. It’s “impossible” for a tester to update the build script. It’s “impossible” for an infrastructure engineer to learn software engineering principles. It’s “impossible” for a front-end developer to work on back-end code, and vice versa. In extreme cases, programmers will insist it’s “impossible” to learn more than one programming language.
Well, maybe it would be difficult for someone with only Java or C# experience to pick up a task to modify a COBOL program, even if not impossible. (Guess how I know it’s possible, and then try to argue against it.) But within a broad technology area, the various skills involved with software are all pretty closely related, after all. Is it really “impossible” for a back-end developer to learn front-end technologies? Nah. And can a programmer learn effective testing skills? Sure.
That’s a far cry from asking someone to be an expert with fully up-to-date skills in (for instance) both JavaScript/React and mainframe assembly language at the same time. On the other hand, JavaScript/React plus Java or C# plus SQL is certainly within range for any programmer; and mainframe assembly language plus COBOL plus CICS plus JCL plus VSAM is within range for (possibly) a different programmer.
So, why do people insist that this relatively modest range of skills is “impossible” for tech workers, who (rumor has it) possess average or higher intelligence?
I think the translation of their arguments is this: “I, personally, don’t want to spend more than a couple of minutes a day doing any task that I don’t absolutely love to do. I don’t want to say ‘me’ because then it will sound as if I’m not smart, so I’ll say ‘anyone’ instead. Therefore, it’s impossible for anyone to possess adequate skills in both [insert preferred activity here] and [insert disliked activity here] at the same time.”
Enter Pareto
I said I was going to talk about the Pareto Principle, but then I didn’t. Let’s talk about it now. What does it have to do with the work of a software team?
It’s sensible to have specialists in certain areas because it isn’t reasonable to expect generalists to maintain up-to-date skills in those areas along with all their other skillsets. At the same time, it’s reasonable for the majority of people who work with software to develop a broad range of skills. “Cybersecurity” is a meaningful area of specialization, but “Ruby, and only with Rails, and relational databases but only with ActiveRecord, not with raw SQL because it’s impossible for anyone to know both” isn’t.
There are a lot of words between “meaningful” and “isn’t” in that sentence, aren’t there? Sorry about that. But it isn’t my fault. It’s impossible for anyone to possess adquate skills in both programming and writing at the same time. Everyone knows that.
Where were we? Oh yeah – Pareto. So, you’re a T-Shaped or X-Shaped person on a cross-functional software team. Before joining the team you specialized in, say, front-end development for webapps. Good for you! That’s a great skill to have!
You used to spend all day every day on front-end development, and you love it. With your new cross-functional team, you like to whine whenever you’re asked to work on mid-tier code, the database schema, the build script, test automation, or production support tickets. That isn’t what you’d prefer to do all day. Your team mates know that very well, thanks to all your whining. You’re a good communicator!
The Pareto Principle or 80/20 Rule applies to your work in a couple of ways.
First, you don’t have to become a deep expert in every aspect of software-related work. The majority of the work a team has to perform in any given area (the 80 part) is routine and only requires basic competency. Some of the work (the 20 part) may call for deep expertise. Someone else on your team (or on a dedicated team of specialists) has that expertise, just as you have the deep expertise in front-end development.
Second, you don’t have to spend most of your time on tasks you don’t enjoy. You can spend most of the work day (the 80 part) doing the front-end development you love. You only have to spend some of your time (the 20 part) doing other tasks. It really isn’t much of a personal burden to support your team, your organization, and your customers.
So, stop whining, already. JFDI.