It’s your responsibility to challenge the decisions you are asked to make.

There’s has never been a publicly renowned rubber-stamper. Yes-men do not have songs of praise written about them. Brown-nosing your way to the top is not often a good approach for long-term success. At some point, you will have the responsibility to be the bad guy.

As someone responsible for making decisions, you will sometimes be handed bad ones by the people in charge. Sometimes you will have to go along with those bad ideas whether you like it or not. Sometimes you must speak up and say no. Knowing the difference is called politics.

Challenging the decisions you are asked to make does a few things. First, it teaches your team that they have to think through the decision before they bring it to you. If you ask them questions they aren’t equipped to answer, they weren’t ready for a decision to be made. Second, it shows that the decision process has at least some rigor to it. People will learn that bad ideas will be challenged. Finally, it forces you to think through related aspects of the decision. Any given decision is not made in a vacuum, it can have trickle down effects.

Making decisions is why you get paid the big bucks. Respect the process and do it right.


Things can go wrong even when you do everything right.

It’s not good enough to just be right. To a very real extent, the phrase “the ends justify the means” can feel too close to the truth. 

Let’s start over. Outcomes are sometimes independent from process. What this means is that sometimes everything works out perfectly even when everything goes wrong, all the wrong people say no, every step of the way has issues, and the schedule and budget are mismanaged. Even then, sometimes things works out. Similarly, sometimes everything falls apart even when the process was perfect.

When everything falls apart for no reason, it can be easy to justify shortcuts or doing things the wrong way to fix the outcome. Surely, this time you can stray to get the outcome that should have happened. 

In reality, both process and outcomes matter. Doing things the right way is important. Achieving your objectives is important. Plenty of important people have been found out in the cold because only one or the other didn’t happen for them. 

All this to say, sometimes things don’t work out and there was nothing you could do about it. Don’t let it get you down, sometimes you lose when you shouldn’t. 

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.