Troubleshooting isn’t only for technology things

One of the hardest parts of any project is getting the Quality Assurance aspects right. How do you really QA a consulting report or check a research report? Troubleshooting non-procedural activities is a fundamental issue.

The problem is, troubleshooting non-technology activities is more important than doing so in technology. Once a system is set up, it usually has controls in place to keep it between the rails. Non-technology can go wrong in any number of ways. Sometimes those ways are subtle and unobvious. Errors can creep in and take up shop for years before anyone notices an issue.

This softer side of QA is where good managers differentiate themselves. Sometimes knowing the right questions to ask and then asking them goes further than anything else. A report that no one cares enough about to challenge probably doesn’t have enough value to continue being run.

Step one is stopping to ask questions. It doesn’t matter whether the process is online or offline, automated or manual, data-based or a manual process. Stopping to think is what troubleshooting and QA are all about.


There’s a difference between people and institutions.

It’s easy for us to fall into the trap of thinking that one person represents a whole institution. When you get a bad customer service representative, it’s really easy to think that they are all bad. When the cashier who checks you out, doesn’t know the difference between a tomato and a potato, it’s easy to think that all cashiers are at the same level. Even inside our own companies, it’s easy to forget that one person that we struggle to work with is not necessarily representative of the group.

Similarly, a good experience doesn’t mean that all experiences will be good. But like with poker, we rarely remember the good outcomes. We are much more likely to remember the bad beats.

Yes, sometimes people are a product of their environment. But just as often, they aren’t. Beauracracy is real and painful but sometimes we think it exists when it doesn’t actually.

The simplest processes are usually the best ones.

I’ve got simple on the brain. KISS is such a great acronym for just about anything in life. Keep it Simple Stupid! I say it to myself all the time. Why complicate things needlessly?

Processes are such a great place for simplicity. However, there are two ways to get simple in a process that can conflict with each other:

  1. Minimize the number of steps involved.
  2. Make each step intuitive.

To minimize steps, you often need to include a few complicated ones. The caveat here is that complicated may not be complicated today. It may, in fact, be simpler than the current process. But is that complicated step more complicated than you want it in the future? Does the complication make it impossible to automate?

I once was involved in a process automation project. We spent months trying to make an online system replace the manual excel spreadsheets that were in place. The sticking point became that the client refused to remove “highlight the cells a specific color based on a complicated set of rules” as a requirement. There was no possible way of turning this overcomplicated requirement into something simple enough to automate – or even hand over to non-specialized resources.

To make each step intuitive, you end up with the long-form process description of “how to make a peanut butter and jelly sandwich.” Each step, by itself, is intuitive and natural but collectively the process grows a bit unwieldy. There’s nothing simple about a process for making a sandwich that involved 20 easy steps.

As with anything, the answer lies in balancing the various needs of both process and users. Making things simple can actually be quite complicated.

The simplest outcomes are usually the best ones.

The work we do is usually focused on delivering certain outcomes. Some in finance make sure the right invoices are processed at the right time. Some in IT make sure that business applications are securely available. Some in real estate make sure the right workplace is available.

Outcomes with simple descriptions are the easiest to work toward. If you can articulate your outcomes, you can define a path for getting to it. If you cannot articulate your outcome, you will struggle to achieve it.

All of this may be self-evident. On the surface, it would even appear that way. But somehow, along the way, we allow modifiers to creep into our outcome statements that include the words “but”, “not”,  “or”, and “except for.” Each modifier makes the outcome more difficult to evaluate. The modifiers come because we try to support specific situations but in doing so we actually make it more difficult.

Simplify the things you do because that will almost always give you the best result.

Can you describe the process in plain language?

To test whether you really know something, try to explain it to someone with no knowledge of the process at all. If you can explain it to a 6th grader, you’ve got it down.

Some people pride themselves on the ability to explain things to other experts and do not care to explain it to anyone else. They believe that the details are best left out. Why bother simplifying something that everyone else already understands?

Here’s the thing, people who think they understand things often have fundamental knowledge gaps. This gap may not actually be a problem day-to-day. The person likely doesn’t come to a situation where it matters. However, if their explanation is built around fitting this gap in, there may be trickle-down issues.

Take finance systems as an example. Almost no one understands how Wall Street works. Do you really understand what makes a stock price go up or down? How many people does it take to make it happen? What impact do shorts and longs have on the price? To most people, simply understanding that “the Market” dictates the price is enough. But if you were asked to model it, you better know how “the Market” actually works.

Describing a process in plain language forces you to confront the details. “The Market” is not plain language, it is shorthand for a very complicated series of activities. A process built around “The Market” can very easily be shown to be incomplete.

I come across issues all the time caused by experts who think they understand something but actually have a very fundamental gap in their knowledge. Never assume that experts actually get everything, that’s one of those process gaps.

“Technology” is not a valid substitution for “Process”

Any sufficiently advanced technology is indistinguishable from magic. -Arthur C. Clarke

It can be very easy to think that a new technology is going to solve your process problems. This is a drastic mistake. Technology can do a lot of things, but it cannot remove the human element entirely from any problem it is being put toward.

Many systems have developed a reputation for solving process:

  • Slack solves the communication process.
  • Google solves the search process.
  • SAP solves the finance process (or just makes it worse?).
  • Oracle solves your database processes.

Slack can actually lead to new and more complex communications issues. Google still requires you to know what you are searching for and type in phrases that will give you the right results. Finance is not a process that can be solved by technology. And Lord knows, databases are not clean or easy.

Process involves everything before, during, and after the particular actions being performed by technology. Process includes the humans involved in clicking buttons, submitting data, or running reports. Process includes understanding the outputs and making sure things are happening as intended.

Technology can do a lot but it is always a mistake to believe that Technology is the same as process.


Word of the day: Oblivescence.

Definition: The process of forgetting.

When I heard this word and read the definition, it sparked a highly visual response in my head. There is a process for forgetting and someone had coined a word for it. Brilliant!