We had 15 minutes with Rob Chandra before class and Bianca posed a simple question. As we grow, we specialise what makes sense. However, things that used to take 1-2 internal meetings to close now take 5+ meetings. There are many people involved and decisions slow down. What should we do?
- Assume you’ve hired smart people
- Assume fast decisions is the right optimisation
- Remove cooks from the kitchen by pushing decision making regarding an Initiative across to those that are as closest to the context as possible (“Decision Makers”)
- Assign a team member to assist/guide the Decision Makers (“Supervisor”)
Collectively the “Initiative Team”.
In practice, this means that for any initiative, you organise around a team that is fully autonomous to make a decision and execute, e.g. PMs, Devs, TL will be the Decision Makers. They are accountable and responsible for success. In the event that the Decision Makers need assistance for whatever reason to make a decision and execute, they may seek counsel from the Supervisor to make the final decision). It’s up to the Decision Makers to figure out the right answer and escalate to the Supervisor as needed. It’s also up to the Decision Makers to get the right feedback. Once the Initiative Team makes a decision, it is final (barring founders veto rights which always exist). Everybody executes with gusto.
For example, we had a recent product decision. The final decision took longer than needed, because:
- Decision was made by consensus
- New people were then involved, another different decision was made
- A DM then wanted to revert back to the original decision
- Turns out additional people who were originally involved weren’t and so another idea was proposed.
The way we’ll implement this at Xendit will depend on your team. I’ll talk to our product teams as this is most of the organisation. For the near term, all supervisors will stick with Moses. Yes, I don’t have much time. So what we are solving for here is to push decision making as low as possible. Our leaders should act as advisors, but for now shouldn’t be mandaiting decisions. The supervisor will change over time but for now we want to train product teams to make decision.
According to this framework, in this example, we should:
- Identify and define the Initiative – this doesn’t need to be a long document. Just knowing we are building a remittance API is enough.
- Pre-assign the Initiative Team, e.g. a PM and TL may be the Decision Makers. The Supervisor may be someone from either the Engineering or Business Team, e.g. Bo or Moses. The Decision Makers are responsible to do all the work to gather inputs into decision and make the call. Let’s say in this example that the TL believes the PM is off. They may choose to escalate the decision to the Supervisor. The Supervisor makes the call and it is final. We all move on. If someone wants to have a meeting after that, cancel it. We’re moving on
- Execute the decision
The easiest trade-off is that sometimes we’ll make the “wrong” call. That’s ok. Generally, a good plan executed today is better than a perfect plan executed far from today. I think part of learning at Xendit is that we’re OK with people failing. We just have to learn from our mistakes.
We also have to lose our ego. There are many times I think a team has made the wrong call but I don’t intervene. Much better they learn from it than me keep saving them. Learning to swim is long term success. Anyways, we’re millennials, if I tell you the right answer, you probably don’t want to do it. If you discover it yourself, it’s a lesson learnt for life.