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.

Advertisements

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.

Oblivescence

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!

“The system has detected no errors other than the type is was programmed to detect”

It is not uncommon for systems to return an “All Normal” status even while things are going down flames all around it. Just because a system reports 100% success for the things that it was taught to track doesn’t mean that the real success rate is anywhere near 100%.

This is because a system can only do what it was taught to do. If you build a system to count the number of lines of data submitted, it will count the number of lines of data that it receives. However, it cannot count the number of lines of data that it never receives. If the process fails due to an external cause, the system cannot report it. The system will believe that it has successfully processed all data but in reality, it has only processed the data which is actually received. Somewhere in a room far removed some poor user is screaming at their computer for not doing what it is supposed to do.

As a rule, I have limited trust for any automatically generated system reports. I’ve seen systems which don’t correctly log user log-ins because it had an incorrect handling of usernames. I’ve seen systems with audit reports that multi-counted everything because it tried to audit itself recursively. I’ve seen processes that were highly manual but the reporting only covered the system side of things.

(Most) Systems can only do what they are told to do. That doesn’t mean that we actually understand what the system is doing. Sometimes the code is incorrect. Sometimes the handling of a situation is executed differently than planned. Sometimes the process has evolved to no longer align with what the system was designed for.