Let’s Be Frank: Specialization May Not Be the Answer

“Business and human endeavors are systems... We tend to focus on snapshots of isolated parts of the system. And wonder why our deepest problems never get solved.”

- Peter Senge, author of The Fifth Discipline: The Art & Practice of the Learning Organization

I am finding as I progress through my working career that, for the past 15 years or so, specialization seems to be more and more prevalent and is becoming expected. This can be a good thing. I have met RBI experts and others who impressed me with the minutiae of information they have in their heads and their ability to run those programs. However, I have also seen some of these same people paralyzed when asked to deal with other areas in our field or with operating conditions and damage that is poorly laid out in API -- so rare that it isn’t in many (or any) published works or doesn’t seem to exist based on what can be researched.

While the process of becoming a true subject matter expert (SME) is impressive, and the outcome can provide for a very useful member of a team, it can have a side effect of providing the said expert with very narrow views of the world or minimizing the ability to problem solve. It can also occasionally create an arrogance as well.

Specialization tends to promote a hierarchal and bureaucratic structure that can alienate younger or less experienced people who may actually have great ideas. Or it may make someone from a different field scared to “overstep” and share the great idea he has from looking at the problem from a different view.

Sometimes, it seems to be fairly junior people who are given or take on the title of SME, and I am not sure what to think of that or the organization that promotes it. The hierarchal structure that tends to be favored by specialists can also create a very high degree of bureaucratic function that can stifle free thinking and creative processes.

This isn’t an argument against intellectualism or against generating SMEs in your workplace to help handle the very technical issues that arise; rather, it is a comment on the pitfalls that can and will occur. And that as we get more “niche” driven, we run some very real risks, especially around integrity problem-solving.

In my perfect world, I would like to have more generalists around in the integrity field. Firstly, it makes for someone who can drop into multiple roles and execute them -- maybe not as effectively as an expert, but well enough. We no longer exist in a work environment where employees stay in positions for their whole careers. The ability to have a flexible workforce in your company is critical to being able to work through those personnel changes as they happen.

I know, I know. Some of you are saying in your head right now, “Inspector Frank, that’s why we create procedures for everything. That’s why we use codes, standards, and specifications.”

I don’t disagree. But take your facility’s head RBI expert and ask him to run QC on an emergency piping repair job after handing him the pertinent ASME, National Board, and API codes; and then also dumping on him all the company-specific specifications and standards. Then, throw in some geometries where the traditional NDE for QC won’t work. And maybe it’s on some acid plant materials that aren’t recognized by ASME. Maybe it needed a heat treatment to get to hardness requirements, and the heat treat isn’t working to get the material soft enough for sour service applications… You get my point, I think.

The second thing that a team of specialists tends to do is become very bureaucratic, with personnel stuck in their roles and “swim lanes.” This stifles thinking and free thought processes. And again, it makes your team less flexible from a personnel standpoint.

As an example, consider failures that don’t fit into the API or NACE guidance documents. In a previous article, I mentioned fatigue. It accounts for the majority of industrial failures yet is one of the most poorly laid out mechanisms in the standards that we as an industry tend to turn to. Sometimes, to solve problems that aren’t clear in the standards and specifications, you need some free-thinking people who aren’t scared to exit their “lanes.”

But I digress (as usual); let’s look at something relevant that has fascinated me since I first read about it as a kid. It is a way to take SMEs and form a cohesive team where everyone is also learning about everything else, becoming more of a generalist in the process.

When the allies “tooled up” to fight World War II in the early 1940s, there was the need to transform civilian industries into war production. The USA famously became the industrial “arsenal” of the free world. But this obviously came with a host of complex problems that needed to be overcome and new technologies that needed to be developed to meet the changing face of modern maneuver warfare.

I am sure many of you have heard of Lockheed Martin’s Skunk Works division. In 1943, the skies over Europe had something new happening and it scared the pants off the allies. What was new was the appearance of German jet fighters, specifically the first flights of the ME-262. It was faster than anything the allies had in the sky. Lockheed was approached because of previous works with prototype jet planes.

The government said they wanted a prototype in 150 days. Lockheed selected Clarence “Kelly” Johnson, a young engineer, to lead the Jet program, which became the development of the XP-80 prototype.

To take on this project in a short time, Clarence realized he had to get a team of experts together and run them in a way that cut through a lot of the bureaucratic BS they normally ran in.

What he created eventually became known as the “14 Rules of Skunk Works.” I am not going to go through them, but if you need to set up teams to get things done quickly and outside the box, they are worth reviewing in detail. They give some methodologies for taking a group of people outside the bureaucratic norm of your company and have some tools to operate quickly towards a specific goal.

One of the other interesting things that was created in the process of creating the Skunk Works and given an incredibly short window to solve a problem was the concept of team meetings without a hierarchy. In these meetings, everyone on the team attended. They were posed with a question or problem and, in rapid-fire, moved around the group. People had to answer quickly with what first came to mind.

These initial thoughts would be written down and assessed, and then, if they showed promise, may be broken out into small teams to first take a stab at. In this type of process, everyone from an SME to someone who knows little about the problem is forced to comment on said problem. They will tend to come up with what their first instinct is. What I have always liked most about this idea is the fact that it overcomes the shyness that junior people can have, and the speed can also overcome the hesitancy that an SME may have on talking about something that falls under another’s scope or outside of that SME’s core knowledge.

Does this work in all situations? No, obviously not. But it can and does have power, especially around problems that are new to your organization or outside the comfort areas of your existing team or system.

As an interesting aside, it was originally called the “Skonk Works” after the Skonk Oil Factory appeared in the “Li’l Abner” comic strip. Apparently, there was no room for the project, so Clarence Johnson rented a tent that was placed beside an operating plastic factory and was thereby filled with an unpleasant odor. Later, the owners of the comic strip took Lockheed up in a copyright lawsuit, and the spelling was changed to skunk.

Let me get back to my argument for more generalists in our industry. I do feel that this problem is starting to hinder many of the organizations I work with. In fact, I could successfully argue one of the things I get hired for is my more generalist approach. I have to take this approach as I am by no means an SME in anything. But I know just enough about a lot of things that every once in a while, I do come up with a good idea or solution.

This problem, as I see it, has some fixes you can start applying right now:

1. If you are in charge of helping guide someone’s career development, put some thought into keeping them well-rounded, even if you need a specialist. This would include having them spend time with unit operations training or at least getting physical walkthroughs of the units and how they work by process experts. Or consider having them spend some time with the maintenance repair crews as well so they start seeing the problems and solutions that the crews who actually fix the equipment deal with day to day. A broader understanding of your facility and processes as a whole is always helpful for someone involved in keeping that facility running safely.
2. When creating teams (or work groups, or departments, or whatever the current trendy word is), think about balancing them out with experts from different areas or backgrounds or maybe even including some more “generalists.” Consider the lessons learned from Lockheed’s Skunk Works and try to fight getting bogged down by bureaucratic teams who are very hung up on their own specialization. Maybe consider doing something a little different in problem-solving meetings, especially if it’s a new problem for your organization.
3. Don’t be afraid to gently remind people that being an expert in one area doesn’t make you an expert in all. Also, remind people that when you are troubleshooting an unknown or poorly understood issue, there are no dumb ideas, just ideas not worth pursuing.
4. For yourself, if you are an SME, stay humble.

Mr. Johnson is famously quoted as stating:

“We are not defined by the technologies that we create, but by the process in which we create them.”

– Lockheed Chief Engineer (and founder of the Skunk Works), Clarence ‘Kelly’ Johnson

To paraphrase, “we are not defined by the problems we face, but by the processes we use to solve them.”