Tips from a lead developer: my own version of Rapid Decision Making

#lead #management #tips

Introduction

In 2016 I was given the opportunity to work as a lead developer in a small tech startup. This was the first time I was given the responsibility of a developer team of three people and I have learnt thousand of lessons from this experience, some the good way, by reading books on the topic, and some the hard way, by failing at doing my job properly and having to fix my mess.

I kept this position for two years and a hundred blog posts would not be enough to write all the wonderful lessons I was taught by this experience. Managing humans (even harder: managing developers !) is tough and you learn very fast.

Today I'd like to share one of these lessons with you ; I call it RDM: Rapid Decision Making.

The one hundred decisions challenge

So, if one day you start working as a team leader, one of the first thing you will notice is that suddenly you have to take hundred of decisions per day.

Yes, hundred.

Because not only your team member have lot of questions for you, other teams also consider you are the main point of contact when they need to collaborate with your team. So the day starts, you get up to grab a coffee, and in twenty seconds people come at you and ask you to tell them 1) customer A is angry and wants to kill the project, what do we do ? 2) the new intern starts today, who onboards him and what topic should he work on 3) project B is late, how can we fix that ?

At the beginning I thought that I should handle all these decisions very carefully. I thought that as the lead developer, I was responsible for giving the best answer to solve the problem. That is why I wanted, for each decision, to think it over, gather valuable informations and use these findings to craft and deliver the very best answer.

Very fast, my days were spent only doing decision making. No code review, no bugfix, nothing else than making decisions, from 9am to 7pm. Then I would rush my other assignments until 8pm or 9pm sometimes because I had my own share of work to deliver.

Obviously this strategy was not going to work on an extended period of time.

Rapid Decision Making to save the day

So I came up with the RDM strategy: Rapid Decision Making.

Whenever someone comes at me with a need, asking me to decide what he or we should do about any topic, I give myself a timebox to answer. I will schedule a 30 seconds timebox for trivial/minor matters, 1 minute for medium matters, 1 hour for important matters and one day for critical matters.

Then I try to see if I can think of a "default valid answer". What I mean is that I try to check whether there is an easy answer, not the best one, but satisfactory enough, to this problem.

For example "what should the new intern do ?" ; a default valid answer would be "read our documentation with fresh newcomer eyes and tell us what looks wrong". It might not be the best way to use his time but

this is a task that does not require to be onboarded by a team member
this is something useful (his feedback will improve the documentation)
this is easy to do
there is no risk doing it

So this solution is not bad. It's a default valid answer.

Then I try to allocate, following the criticality of the matter, time to find a better answer. However if at the end of my timebox I have not found a better answer, I give the "default valid answer".

RDM in practice at the restaurant

Here is a full example: I go to a restaurant with a group of people. We sit and are given the menu. The waiter go and could come back at any time asking what we want to eat, and I don't want to answer "sorry I have not chosen yet" (I hate having people waiting for me).

So when I am given the menu I immediately scroll through it fast, looking for something I would be happy eating. It might not be the best dish I could find, it might not be what I really wish to eat today, but it is something that I will not be disappointed of. It will be my "default valid answer". For example a default valid answer could be a burger.

When I have found my default valid dish, then I start reading the menu again slowly, looking for something that I'd really want. If the waiter comes before I find something better, I will answer my default valid dish. If I find, in the menu, a better choice, I will answer this choice.

Since I have started using RDM, I have never again answered "I'm sorry I don't know yet what I want to eat" to a waiter !

Good is almost always enough

The main idea behind the RDM strategy is that most decisions you have to make, as a team leader, do not require the very best answer. Most of the issues we encounter daily at work are solved fine when given a "good enough" answer. Keep your time and your brain juice for critical topics, the topics that will decide if your project lives or dies.

Since 2016 I keep using RDM in my professional life whenever it is relevant. Which is actually most of the daily questions I face ! And I think a lot of developers could do the same.

Sometimes we developers can spend hours on topics without much value. Arguing whether is_valid or isValid is more readable or discussing whether folder path should be App/User/Preference or App/UserPreferences for example 😄

Maybe after 10 hours exploring the question and reading books about it one could find an argument that makes answer A better than answer B. But was it worth it ? I think for most topics it was not. RDM is one way to avoid wasting time on meaningless topics. If you cannot find a great answer within the timebox, just go with the default valid answer. And most of the time it will work fine. The idea is to stay pragmatic.

I hope this blog will be useful for some struggling developers or team leaders 😊 .