Is your boss making random decisions?

You’re the lead architect for your company, working on a major new product. You’ve finished designing the technical architecture, and it is looking pretty darn good. But implementation has been very slow.

You decide to join a development meeting to get a feel for what the team is thinking. You walk in on a spirited discussion. Steve, the senior developer, is arguing with Bob, another developer.

“Look”, Steve is saying. “Microsoft uses Pascal case without any type prefixes, so that’s what we should use too.”

Bob shakes his head.

“No, we should stick to Hungarian like I’m using in all my code. It’s much less error-prone.”

Then your phone beeps. It’s a message from Paul, your CTO:

Please put Steve, Bob on bug fixing asap. I demoed our product to the board and it crashed. Very embarrassing, I look like an idiot. Need it to work perfectly tomorrow morning. Whatever it takes.

Oh jeez, you’re thinking, he went and did another demo without warning the team. You send a reply:

You send a reply:

Can’t. Need both for banking integration. Only they know API specs. We’re already behind schedule.

After a few seconds, you get a new message

You’re letting me down!!! I look like an idiot. NEED BOB STEVE NOW. do it!!

Just another day as an Architect, right? Everything is on fire, as usual.

Actually, what you’re seeing here is Irrational Management and it arises out of a lack of structured leadership.

What are the symptoms?

When a patient walks into a hospital with a fever, aching joints, and a red skin rash, a good doctor will immediately recognize these symptoms and realize that a chickenpox infection is likely.

Being a tech leader is no different. Technical organizations can also get sick from afflictions like anti-patterns. Each pattern comes with its own unique list of symptoms. A good leader will recognize these symptoms, quickly identify the anti-pattern, and start working on a cure.

Here are all the symptoms from the meeting:

The first clue is in the discussion Steve and Bob are having: they are talking about coding standards. This usually happens at the start of a project and can set off a spirited discussion. Usually, the architect or the lead developer will make a final choice and then the project can start.

But here we are already deep into implementation and the developers are still arguing about coding standards. This is a clear red flag that there is a lack of technical leadership in this team.

The reason why becomes clear when the first message from the CTO arrives. Paul has a habit of running demos without informing the team. When his demo crashes, he worries that he looks bad in front of his superiors and mobilizes the team’s two top-developers to drop everything and fix the bugs.

The architect’s protests are ignored and even framed as disloyalty. Paul has a strong desire to look good in front of his bosses, he demands his team to be loyal to him, and he is willing to sacrifice the health of the project to achieve his goals.

It’s all just part of your job… or could you be dealing with an Irrational Manager?

The three root causes of Irrational Management

Let’s take a closer look at the root causes of this antipattern.

The number-one reason why this anti-pattern arises in an organization is due to a culture of fear. Paul is fearful about looking bad in front of his superiors because he operates in an unforgiving environment that does not tolerate mistakes. Therefore he demands unconditional loyalty from his architect and frequently mobilizes Bob and Steve to protect his reputation.

Paul is a weak leader because he is driven by personal power issues. He impulsively plans a demo with an incomplete product, he is very preoccupied with how his superiors perceive him, and when he messes up he uses the team to make himself look good again. Steve is also a weak leader because he is unable to settle on a coding standard with Bob.

A more mature decision-maker would have carefully planned his implementation schedule and the exact functionality to be shown during each demo. He would also have reserved team capacity before each demo, and practice the demo with the architect and team leader.

Paul is doing none of this because he is oblivious to his flaws. He doesn’t recognize his weaknesses and is therefore unable to self-improve. This keeps the team and the project in a constant state of chaos.

And finally, we’re dealing with a disempowered team. Notice how the architect’s valid objections are overruled by the CTO and even framed as disloyalty. Neither the architect nor Steve, the senior developer, have any power or mandate in this project. These people are in the trenches every day, but they are not empowered to take the lead on any technical decision.

How to fix the anti-pattern

Here’s what needs to change to fix this anti-pattern.

The first thing you need to do is tackle the culture of fear. Executives who rant, criticize, and blame will create a toxic and fearful work environment, and you should have a zero-tolerance policy for this kind of behavior.

A culture free of blame is a very interesting work environment. In the absence of blame, everybody is free to try out experiments, move outside of their comfort zone, and be secure in the knowledge that mistakes will be treated as learning opportunities. And this will also stop leaders from making knee-jerk decisions when things go wrong.

Second, Paul needs to learn to become a Servant Leader. A servant leader does not micromanage his team. He leads from behind by setting clear goals and communicating requirements and dependencies. The team is free to find its own solutions.

A good servant leader will also empower his team by delegating control over the schedule, the budget, or the functionality. An empowered team is self-steering and self-governing and takes on full responsibility for delivering the right product at the right time. Self-steering teams consistently outperform top-down managed teams in IT organizations.

And finally, a good leader will introduce a method for healthy decision-making. It’s very easy for leaders to succumb to irrational decision making when requirements constantly change. Fortunately, there are many tools that will prevent this from happening. A good starting point is to use Force Field Analysis which maps and quantifies all forces acting in favor of, and against a particular decision.

Did you ever encounter an irrational decision-maker? What did you do?