It’s extremely easy to confuse people with subject matter expertise with people who really only have business process expertise. In other words, it’s easy for a person who knows nothing about hammers to mistake a hammer salesman for a carpenter. This type of mistake is common, and is detrimental to data and software projects.
There were two events that led to me writing this article. The idea for it came to me after a layoff at a previous job. Layoffs are almost always nonsensical when you look at the individual people who get laid off. But if you abstract up from trying to figure out why one person was laid off and not another, you’ll see some trends when you look at the people who survived and the job function they were performing.
Further motivation to write this came from a post on a popular tech community, where somebody said “I work as a developer for a software company in a particular industry. One major frustration I have is we don’t have anybody at this company who seems to know much about the industry we are building software for. So I don’t get real feedback on how useful things are. I wish we would stop hiring so many engineers and hire some industry experts.” I think this is a great idea, but it’s a bit naive about how hard it is to find an industry expert who can actually give you useful information, as opposed to giving you general industry knowledge, which is hard to build any specific solutions for.
This post is loosely tied to my previous one about Business Domain Expertise. You don’t have to read it to understand this article, but parts of that one lead into this one.
The Birth of a Business Process Expert
Imagine one day you start a new a job at a residential construction company supervising the process of building houses. When a home buyer wants to build a house, there are various steps that need to happen. The buyer select a plan, a blueprint is created, the materials are ordered, the different parts of the house are built (e.g. first the foundation, then the frame, then the pipes/wires, and etc), and so on. For every step of the way, there are various actions that need to be checked for completion and signed off on. Your job is not to own any individual part of this, but to ensure the checks are done, signatures are completed, and the right people are involved in every conversation and any escalations. There are a lot of teams and vendors involved in building a house, so it’s essential somebody is there to enforce the process around this, and to ensure big issues are properly tracked and do not fall between the cracks in process steps.
You do this for a few years and your reputation grows as an employee. You’re seen an expert in this business process, and you’re the go-to person to get issues resolved when there’s a problem. If somebody asks you about building houses, you’re able to eloquently talk about the whole process, pulling in things you’ve learned second or third hand about each individual step.
One day somebody reaches out to you from a software company. They build software for the residential construction industry, and they are hiring industry experts in residential construction to help guide them in product decisions and customer interactions. During your interviews, you meet a lot of people with a software background, none of which have any background in construction. When they ask you about your construction background, you describe the steps of the business process you own with a lot of detail. During your interviews, you’re clearly perceived as an expert on residential construction and you get the job. At this software company, you’re introduced as the residential construction industry expert, and your job title reflect this.
The only problem is, you’re not really an expert on residential construction. If somebody asks you how construction workers use blueprint software, you don’t really know. If somebody asks for detailed explanations on how vendors are paid, you can’t really provide much detail. If you’re asked how materials are ordered and how to simplify that particular process, you can’t really provide specific answers. You’re an expert in a particular business process in the residential construction industry, not really an expert in a specific part of the process.
If this software company is building a tool to streamline (e.g. to digitize the steps typically done by paper) the process you owned when you worked at the construction company, then you are the right expert. However, if the software company is building a tool for a specific part of the process, you can only provide second or third hand knowledge. You’re going to get questions outside of your expertise fairly quickly. If the software company wants to succeed, both sides need to recognize different knowledge is needed than what you can provide. They need different expertise.
To explain what I mean by this, let’s go back to the carpenter example. Modern construction uses prefabricated pieces, and the carpenter is responsible for assembly and making any necessary adjustments to install them. Let’s say under normal circumstances the time for installing one section is 3 hours. One day, however, a carpenter finds a discrepancy between the plans and the prefabricated materials, resulting in the work taking 7 hours. The first time this happens they just make the change, but then they start seeing this issue at other houses.
They raise this issue with their site manager. The site manager sees other carpenters at other houses are also having similar issues. The carpenters use their experience to provide ideas of which previous process steps could be the cause of the issue. They escalate to you, the process owner. You bring together all the relevant teams from previous steps (e.g. a different set of carpenters, the architects, the designers of the prefabricated pieces, etc) of the process and they figure out where the issue started. You then come up with a plan and timeline to fix the issue, you assign tasks to different people to ensure the fix is completed, and you communicate these changes to relevant teams.
In this scenario, your job as the business process owner is to make sure the right teams are involved in the discussion to find the cause of the issue, and to ensure a proper plan is put into place to execute the fix. It’s also your job to own this plan, ensuring every step is completed properly. It’s not your job to actually identify the cause and create a solution. The technical teams are responsible for determining which step in the overall construction process is causing the issue, and they need to provide the solution as well.
Since you own this overall process, you are the only one who understands all the steps and the overall goals. But you don’t understand the the fine detail of every process step. The details of each process step are only understood by the technicians in each step. This is what makes you the business process expert, and what makes the carpenters the subject matter experts.
My point here is not to criticize or throw shade at business process expertise. I’m just trying to illustrate the difference between a process expert and somebody who is an expert at a particular step of that process. When enough people are involved, business process people are needed. If you see the process as a train, somebody has to care (or be paid to care) about the train, otherwise it’s guaranteed to go off the rails.
The Visibility of Business Process Enforcers
Let’s tell another story. You are the CEO of a company manufacturing nuts and bolts. Your nuts and bolts are used in a lot of different products made by many customers. One day a wizard appears in your office at 8 AM and says they are going to make 75% of your employees disappear. You have till 4 PM to choose who goes.
As the CEO, how do you prioritize who goes? If you want your company to survive, your goal should be to ensure the business keeps running and your customers get their nuts and bolts. So anybody who’s not involved in making and getting stuff to customers is going to get cut. Teams like new customer acquisition and Research and Development can all go.
Since you are being forced to hack off parts of your company with a blunt object, something occurs to you. You might end up cutting out an essential part of your company and won’t realize until it’s too late. What you need to do is ensure the people who understand your operational processes don’t disappear. That way, if you lose an important team and part of your manufacturing and distribution process breaks, the business process person can quickly recognize this and you can try to find people to fill that broken link.
You reach out to all your upper level managers to figure out who the critical operational business process people are. At least in my experience, managers of managers don’t spend a lot of time reviewing the day-to-day details of what individual contributors are doing. Instead, they spend a lot of their time with process oriented people, focusing on longer term goals (e.g. is program X on track). While their job as a manager of managers might not be to enforce a business process, they certainly need to be oriented around business processes. And just like business process people, they don’t always understand the fine details of what is really done in each step of the process. As an end result, they might not have the ability to accurately discern a business process expert from a person who understands a single step of the process in enough detail to rebuild it.
This is where you see a flaw in this selection process. When someone is trying to figure out who can rebuild a particular step of the process, they might not know enough details to really understand what and who is required to rebuild something. The end result is when identifying the experts, process oriented people tend to see other business process people as experts because they don’t have the right experience and mental models to differentiate process experts from subject matter experts.
The consequence of this is while business process people can recognize when parts of the process are broken, they can’t always recognize why or how it’s broken and how to to fix it. You need subject matter experts in each process step to tell you how their part of the process is broken, and why other parts of the process are making this break better or worse.
What is the Point of This Article?
Obviously this CEO story is an exaggeration. Many companies have been in the situation where they have to fire a significant number of their staff in a short period, However, even in fraud, bankruptcy, or private equity buyouts, it’s not something that happens in a day. Evil wizards probably have more dastardly things to use their magic for.
This article is mostly a reflection on how easy is it to misjudge expertise. There’s this concept called Gell-Mann Amnesia which presents the idea that while people think critically about a domain they understand well, as soon as they review information from a domain they do not know, they stop thinking critically and take stuff at face value.
If you’re trying to fix a specific, clearly identified, problem, it’s easier to find the right expert to fix it. But when you have a problem which crosses multiple team boundaries, it can be hard to tell the difference between somebody who is describing symptoms from somebody who has identified the actual cause(s).
If you are in this situation, in the best case there is a champion who genuinely wants to own the situation and fix problems. In the common case, people complain a lot and the work to “fix” it is mostly just moving charts around until a higher power intervenes. In the worst case, the business process owner is actively making things worse because their diagnosis of the issue is incorrect and they are solving imagined problems instead of the actual ones.
The leads back to the beginning of the article. Visibility is important, and business process owners have a lot of visibility. They are among the few people who regularly interact with everyone, and they are supposed to be the ones cleaning up the messes and misalignments. Everyone assumes they have some larger perspective no one else has.
Which is a shaky assumption if you’ve been in any job for long enough (e.g. 3+ years) and seen the reality of a business process. The are plenty of projects where almost every single person, including the process owner, has changed, sometimes more than once. Everybody can see the process they have to use and maintain, but nobody, including the process owner, knows why it was built that way in the first place or why it can’t be changed now. We just assume the train driver knows exactly what they are doing and really understands why they are doing it.
When people can speak authoritatively and they have visibility, we assume they understand everything they are talking about. Compared to someone who understands a single part of a process, an overall process owner seems more knowledgeable. They’ve certainly got the ears of more people.
Maybe in the grand scheme of things it doesn’t matter. If you work for a 6 billion dollar company and a 10 million dollar project is going off the rails, it can make more business sense to let it derail than to waste time fixing it. Some types of friction in multi-team projects spanning multiple business orgs are unavoidable, and you can’t fix them with infinite time, money, or people.
But if you really want to understand if the friction in that 10 million dollar project is fixable, you need someone who genuinely understands the causes of friction. Asking the person with the most visibility simply because they have the most visibility, and letting them lean into your lack of understanding of the situation, isn’t going to give you the right answer. You need to dig deeper to understand if what they are telling you is really true. Talk to the people who deal with the pain of that friction every single day, not the people who only feel pain in their ears and ego when some status indicator on a Gantt chart is red.