Manager Decisions Guide

One of the most important abilities for any manager is to take decisions. Bad managers don't master the techniques, don't have the needed technical abilities or expertise. This is: a bad technical manager doesn't understand all the edges, variables and implications for every alternative.

The last point in this article presents three scenarios, with three hypothetical (or not hypothetical) problems in a fictional enterprise where you, as a manager, have to do (or don't do) something. You can give your opinion in the replies of this article and we can discuss a little in the thread.

Technical decisions share all properties of the usual decisions and have some special ones (well, every field has their own, hasn't it?)

One problem here is that expertise is built with time and errors. We learn to ride a bike with some accidents. With a good trainer, you will fail a little, and when you are alone you fail a lot.

So this led us to an important concept:

A good leader (manager) first and most important objective should be to create leaders.

This topic worths a whole book, but I will try to comment on some important ideas in this small (and for sure, incomplete) article.

What's a decision?

To decide is "make a choice from a number of alternatives. A decision is to reduce options". So, in the end, you are choosing to do something by not executing the other possible options.

The key concept here is this: when you reduce alternatives, you avoid some things to happen; some of them could be bad, but usually not all are bad, there are trade-offs you have to consider.

In a manager role, there is another important issue: there are people! You may have to reject some ideas from your team, and engineers and developers have big egos, so you have to manage well the communication and your social skills to explain that.

When the decision is reversible or has a little impact you can delegate the decision. But when it's a big deal, the manager has more context, more information, more expertise, maybe a plan or a budget or just,... is her responsibility.

Decisions could be reversible or irreversible

Reversible decisions are the most: you can change on some moment. Maybe is cheap, or not (that's the next point, about impact) but usually you can change.

But there are also irreversible decisions. Very expensive decisions are in some way irreversible. As I said, all irreversible decisions (so all "big-impact" ones) should be taken by responsible, smart and expert people, and democracy is not the best idea.

Having a person that is responsible for decisions is no, I will repeat, IS NOT, to not ask, listen and have a lot of conversations and involve your team. Is just, at the end, to have a person that at the end, decide: what, when, how,... this person is named, usually, the manager (or the boss).

Decisions have a different impact

Decisions can be cheap and easy, or can be so hard or expensive so they are in the end irreversible. On big impact decisions, expert and smart people should take responsibility.

This is why in a democracy we vote for leaders, and very often vote for the specific idea, or saying it in another way: we choose strategy and delegate tactics to the leaders. Another example is the Supreme Courts in every country: a small set of smart, senior and expert judges, not a jury.

Mistakes and errors

Of course, a manager can have errors and bad ideas. The thing is that a good leader/manager has few mistakes. The team trusts her, and her decisions just because she, usually, has the best ideas and doesn't fail.

Anyway, an error in a reversible issue, or in a low-impact thing is not as important and you can manage that. So again, context is important.

Agile software development is about making reversible decisions with low impact, and generating iterations with adaptative and evolving versions. Errors and mistakes can be tolerable if you revert soon without a high cost. However, not all decisions have these parameters. And as projects advance, the decisions usually are more expensive.

Decisions are constrains

Decisions reduce the set of options but also, almost always a solution to a problem creates a new set of problems. A good decision should create "better problems" but, is imposible to have zero problems.

• Micro-services architectures are a solution for more scalable software. This kind of architectures reduce technical options and they introduce other problems (the network is not reliable, monitoring, etc.). You have to choose your problems. That's a decision.
• A bad worker can anyway do some work, maybe not perfect but will work. Firing him will reduce some productivity. Not firing him can cause other problems, maybe in the team, that don't see a culture for professional and quality standards. Again, select your problem, it's a decision.

Give some fresh air in technical decisions, if possible.

Be careful to do not constrain too much on technical decisions.

As it is good to do not allow all the possible alternatives, it is not to don't allow some kind of freedom to your technical teams.

You need to remove anarchy and at the same time, allow creativity and freedom.

When do NOT decide (that is actually a decision)

When decisions are not made, you are deciding.

You can decide not to have a "coding standard" but that's a decision: you choose to allow all posible coding standard. Every developer will code in his/her style and code will not be "the code of the team" but "every developer code". That's not bad (I prefer to have a policy) but at the end, you choose by not choosen.

When you don't decide, your decision is "all the things are valid". This could be perfect,... or an epic failure. At the end, decisions will be made and the "status quo" or "implicit" decisions are dangerous.

As a general rule, you don't decide (now) because you are waiting to have more information, as we explain in the next point.

When to decide

If there is a master law on decisions is: "take the decision on the very last responsible moment". This allows you to have all the information, all possible variants, and options.

But as I said, "a solution is almost always just a new set of problems", the point here is when is this responsible moment?

For technical decisions, and in the software field, Mary Poppendiesk present some techniques in her classic book(*) to manage with this "last responsible moment": share partial design information, improving the response time for new stories, or absorb changes.

Anyway, the thing here is that the first irresponsible moment is just one second after the last responsible one; when decisions are too late and create more problems or are impossible to implement yet.

And we should mention that not all people agree with the "last responsible moment"; Alistair Cockburn doesn't. Sometimes adapt and evolve could be better (decide as soon as possible and change as soon as you notice you are wrong) if possible, is sometimes an alternative. So for reversible decisions, you can embrace this other approach.

As deciding as later as possible could be a Lean principle, and "adapt and evolve" is an eXtreme Programming one, WHEN you have to decide is sometimes much more an art than a science.

(*) Lean Software Development: An Agile Toolkit; Addison-Wesley Professional.

Three problems that need a decision...

As I said, this is a little game so we can have an argue in the comments.

Each problem is reversible or irreversible, with high or low impact in the company, and can or not be delayed to get more information...

1. Your teams work with GIT as the SCM. You have any policy on that, so every project has a different branch schema and versioning. Will you enforce a policy (features branches, trunk, both,... any,..)? Will you take this decision or delegate it to the team? Will you decide asap or wait to have more information?
2. Your company works on-premise. Now it is time to go to the cloud. Will you decide on AWS, Azure, IBM (I'm joking!) or Google? How will you communicate? How will you enroll your team in the decision and will delegate to the teams the decision?
3. Your patience with Anthony has come to an end. All the other people in the company have complain about him, he is rude, and doesn't finish their projects on time. Will you decide to fire him? Have another meeting with him? Maybe tell the team to vote on this decision?