The show man

Or why the worst managers succeed.

There’s this kind of team in each company that everyone knows. Not because it’s a successful team. But because that team is famous for big escalations, production problems and an architecture that evolved badly with no way out of the mess.

And then there’s the manager of this team. Highly successful.

Why? Simple. He is the one who gets recognized by the customers.

He’s constantly visiting. Fighting fire. His weeks are turbulent. Full of de-escalations, workarounds, meetings. Resulting in an action plan and a promise to do better. He leaves for the weekend with a big thank you from the customer. In the end, he was the only one who was visible to the customer that week. And he’s the only one who gets mentioned in customer’s reports seen by the leadership team.

Two kinds of batteries

There are two kinds of batteries. Those that come fully charged and can be used once. And those that come half-charged and are meant to be used many times.

I was surprised those very same approaches exist for trust.

My world view assumed that trust starts neutral (or half-charged). You do good things together, and trust builds up. And it goes down when things go bad. Once you have charged the trust battery close to 100%, projects succeed, no matter what. If it’s down to 30% or less, projects start to fail.

Recently I learned from a close co-worker, that his world view assumes full trust at the start. That is, 100% charged. Everytime the other person screws up, it goes down a bit. Never up.

It’s useful to me to understand that this other world view exists. It’s also useful for those to understand that most others think differently.


I started to develop a principles-oriented way of working. Those have paid off in my team, and I believe are applicable broader. With principles-oriented way I mean that “those are the inner believes of the team” and manifests in behavior such as “we don’t discuss about those, but this is the very nature how we develop our software”.

Here are my current two principles, easy to understand, hard to get there, but then easy to maintain and provide a true accelerator to the team by reducing errors on production software:

  1. No errors in production. True, we’ll always have errors. But we do everything to detect them early, fix them before the customer notices them, and iterate towards very stable software.
  2. Automate everything. Again, we won’t automate 100%. But my team’s cloud account has only 3 things that have been manually created (and those are fully documented). A specific outcome of that is that hitting the “merge button” on a pull request will automatically deploy a service to production (while we drink a cup of coffee, or more likely, already work on the next task).

The long-term

Imagine the following scene. You’re at the Friday after-work beer. You tell one of your co-workers about your side project. You’re excited.

Then your co-worker provides you feedback. Honest feedback. The feedback you need to get better. It’s not a confirmation or alignment. It’s a brutally honest critique to make you better. Not to make you feel cozy.

You’re destroyed. Someone isn’t in agreement with your passion.

You defend. You raise your voice. You shut down the person who provides the valuable feedback. End of conversation.

That’s the short-term. Shutting down opinions of others. Avoiding people who are not agreeing with you.

A better short-term is to listen to the feedback. Acknowledge it. Take it home. It just made you better.

The long-term however is to focus on the conversation. To build a relationship with your co-worker. To ask and listen to the excitements of your co-worker. To see the content of the conversation as a side-product while aiming for a long-term relationship.

The long-term will bring more candid feedback, honesty, and shared excitement. You wanted this to happen today. But today is not the long-term.