Deciding to decide when the time is right

Never before in history were so many people required to make decisions so often and of such far-reaching consequences. Where only a handful of wise men used to choose for everybody else, today we’re all decision makers. From the CEO to the junior programmer, everyone’s decisions can send ripples across the globe. We have to learn when and how to decide.

See just how significantly mentions of “decision” have increased since the outset of World War II.

Times when our days were pre-defined, we knew how to crank a widget and how many we were expected to crank to make a day’s pay, are over. Many of us in IT and elsewhere work with systems used by millions, where one bad decision could start mayhem. Welcome to the twenty first century – the age of empowerment and decisions.

Decision road sign

decision
noun
A conclusion or resolution reached after consideration.

Oxford Dictionary

I especially like the bit saying “after consideration“. Without proper consideration a decision is a gamble taken at the mercy of mere chance. Consideration requires data – facts, figures, the knowns and the unknowns, and enough of it to make a decent judgment. Nobody said this better than Sherlock Holmes:

It is a capital mistake to theorise before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.

Sherlock Holmes, Adventures of Sherlock Holmes

But we can’t be sitting there all day, collecting facts, while the world moves on. Our competitors surely will come up with something that’ll sweep the rug from under our feet and before we know it we’ll be out of business!

Not necessarily.

Nowhere are timely decisions so important as in the military. Making one too early will give your enemy ample time to prepare. Making it too late will have you overrun by their forces. In either case lives will be lost and destruction will ensue. General Colin Powell, former United States Secretary of State and Chairman of the Joint Chiefs of Staff says decisions should be made as late as possible, but not later.

Don’t rush into decisions – make them timely and correct.

Time management is an essential feature of decision-making. One of the first questions a commander considers when faced with a mission on the battlefield is “How much time do I have before I execute?” Take a third of that time to analyze and decide. Leave two-thirds of the time for subordinates to do their analysis and make their plans. Use all the time you have. Don’t make a snap decision. Think about it, do your analysis, let your staff do their analysis. Gather all the information you can. When you enter the range of 40 to 70 percent of all available information, think about making your decision. Above all, never wait too long, never run out of time.

In the Army we had an expression, OBE—overtaken by events. In bureaucratic terms being OBE is a felonious offense. You blew it. If you took too much time to study the issue, to staff it, or to think about it, you became OBE. The issue has moved on or an autopilot decision has been made. No one cares what you think anymore – the train has left the station. [emphasis mine]

Colin Powell, It Worked for Me

Further down Powell shares the steps of collecting data:

  • tell me what you know
  • tell me what you don’t know
  • tell me what you think
  • always distinguish which from which

Colin Powell, It Worked for Me

These should be printed out on large sheets, posted next to every manager’s desk, facing anybody coming in with a report or request.

Return to the world of software, where bad decision-making may not kill anybody, but “merely” derail companies, sending hordes of people into unemployment. Any sort of Agile methodology preaches making important decisions at the right time.

  • what is the next most valuable thing we should build?
  • whom are we building this for? what problem are we solving?
  • how will we measure success?
  • what are we not going to build?
  • when should we release this to users?

The worst thing one can do is what, unfortunately, comes most naturally to programmers: jump straight into coding. Programmers hate discussing, debating and researching. They want to code already!. Which leads to messy, unwanted products, delivered too late to the wrong people.

Take time to ask questions, research answers and make decisions when they need to be made.

  • Order your stories, use cases or requests into a backlog, find out which of them are the most important and take the time to decide on how to build those correctly. Postpone any decisions on the remaining items until the first ones get done. Delivering them will change the value of all the other requests and spending time debating things other than immediate work will likely turn to waste.
  • Be very open about what you don’t know. Not sure how a business process looks like? How to work with some technology? State it explicitly, refuse to accept the story into the iteration and create a spike instead. This should allow you to spend a time-boxed amount of work on researching missing pieces. In our current process we even created a specific type of sub-task that represents Questions and Concerns, just to have them prominently visible.
  • Prototype with proofs of concept. Building any serious piece of software is a test for how suitable the chosen technology is. Start out by building a minimal, full-flow, disposable Proof of Concept piece that will test the critical portions. Put some pressure on it to see how it scales, so that if it fails, it does so early. And by the way: make sure everybody is aware that it’s disposable and will be built again correctly, right after disposal.

Keep asking yourself whether you have enough data and work to verify whether what you think you know is true. Learn and practice how to make decisions. If you avoid them, somebody else will step in and their decisions may not be to your liking.

Not everyone knows what they’re talking about

I can’t watch presentations anymore. Having been an active Toastmaster for some time, I notice all the speakers’ mistakes. The “uhm” sounds, the non-purposeful fidgeting, the illogical sequence of ideas, the obsolete information. I can barely hear what the speaker is saying.

A layperson watching the same presentation might notice that something’s wrong with it. It’s boring or just not resonating. But they can’t really put their finger on it. Once I explain: “he mixed up presenting an abstract concept with giving concrete advice” they go “ah!”, and confirm “you nailed it!”

Switch to a company doing an employee satisfaction survey. Its results are miserable, so the participants are asked to work out concrete recommendations for what should change. Ask that question separately to line employees and to managers and you’ll get distinctly different answers. Worlds apart.

The employees will tell you all kinds of things, that could be jointly labeled as: more money. Not necessarily in monetary form. The managers will come back with flowed processes, working conditions, credibility, vision, communication flaws, and lastly perhaps compensation, but only as one of many factors.

It’s not that the first group is dumb or greedy. It’s that they cannot really put their finger on what they feel is a problem. Perception takes training, and training takes time and appetite for learning. Not everybody wants to think broadly.

When you set out to improve morale, by all means do include all of the affected employees in the conversation, but:

  • drill down past the first answers (symptoms) to the root cause of issues, don’t just take requests and throw some money at them,
  • explain how the results fit into the broader picture of work, taking the time to educate the people you work with.

It’s democracy with a healthy dose of moderation.

A side effect of such surveys could be discoveries of talent. An employee who speaks, demonstrating an understanding of the broader context, is a good candidate to develop and promote. A manager who does not speak this way, may in turn be in the wrong position.

Feed it back

How am I doing?” He was with the company for 2 months by then, with his team leader located abroad. For some reason, unrelated to his work, we sat down to talk – he and two of us team leaders. We finished a topic and then he started: since he was already there with us, maybe we could help. Nobody gave him any feedback regarding his performance.

Moments like these make my brain form a couple of new neural connections. There he was, a young software engineer, with decent experience, not merely interested but desperate to get some evaluation of his work. Many like him never speak out. Whom else have we been neglecting?

And so I set out to meet every one of my team members in private once a month, just to talk out how we feel about each other’s work and performance. Not formally, not in a framework, but openly and candidly. Beginnings are awkward, because people aren’t used to being able to speak freely. You see them sweating and avoiding eye contact. So you, the superior, start talking about yourself and your own mistakes. Then you make space. They will follow. And they will tell you what’s been wrong, often things you haven’t noticed at all.

Once you show yourself open to their criticism, they will open to yours. Turns out, they really do want to be better, and do want to stay on course of your expectations. While it’s inevitable that they’ll be drifting apart once in awhile, when you explain yourself and your motivations properly, they’ll quickly change and you can continue sailing at full speed.

An army of sheep led by a lion

I’ve yet to see a company that, having sound leadership, failed. I’ve also never seen one to succeed with bad leaders. And the surprise is that being a “good” or “bad” leader has nothing to do with how you treat people around you. You can be a tyrant (Steve Jobs), a bully (Bill Gates), a corsair (Larry Ellisson) or a friendly, passionate geek (Larry Page, Sergey Brin) and succeed nonetheless. But if you lead in the wrong direction, then boy, you’ll hit an iceberg sooner than you can spell “Titanic”.

This isn’t to say that you should immediately burn your copy of How to Win Friends and Influence People and start screaming around at your team like a drill instructor. But it does mean that if you’re not naturally a social, likeable person, trying to change yourself is probably a misallocated effort. You may rather want to spend time getting to know your market and learning as much as you can about your domain. Put a lot of work into becoming the best expert in your field.

Being a great leader may motivate people to row faster, but it won’t help anyone if you’re all heading for a cliff.

Don’t tell me what to do

Eat your broccoli!“, “Clean your room!“, “Brush your teeth!” Sounds familiar? It’s the tune of the past, when your parents controlled each and every aspect of your life. With the exception of toilet use, perhaps. For many people however, the past lives on. Parents turned into line managers, while kids remained kids, but with fancy titles: Senior Software Engineer, Enterprise Architect, etc. “Send that e-mail“, “call that guy“, “re-estimate that plan.” Smart managers turn orders into questions: “can you send that e-mail, please?” Sure, boss.

Parents order their offspring around assuming that children don’t have the required knowledge and experience to decide what to do, when and how. Many managers think along the same lines: if I don’t tell them what to do they’ll surely do it wrong. Great intentions with lousy results:

  • makes the employees unhappy – after all they went through a whole recruitment process, assessment centers and whatnot, emerged victoriously from among a dozen brilliant candidates, just to be treated like 3-year-olds.
  • makes for ineffective work – even if employees really do make mistakes, they can learn better only by seeing them for themselves. Any direct micromanagement will sabotage the learning process, causing the same situations to repeat over and over again.

A manager is not super-human. He makes mistakes just like any other bloke and there’s absolutely no guarantee that his procedures and decisions are in any way more effective than anyone else’s. Managers are there to set goals and provide their subordinates with resources to move forward as they see fit. Any other form of management is just a waste of brainpower.