Skip to content
Home » Decision boundaries

Decision boundaries

scalingthescaleup - decision boundaries

What I notice quite often in growing companies, or leaders stepping up in their careers, it is difficult to find a balance between giving your team the freedom to find a solution and telling them how to deliver exactly what you need or want. How do you define the decision boundaries? Which decisions do you make as a leader, and which decisions you can delegate to the team, while still getting the desired outcome.

Sounds familiar? Let’s dive into it then.

To make it very simple and easy to understand let’s consider a hypothetical situation (in my case it is not that hypothetical): your company built a product, an amazing web platform that solves some particular problem for your customers and it is just amazing. But there is no audit logs implemented, which means you cannot really say which user did what in the system. And any issue with messed up setup is very tricky to investigate, because there is simply no trail available.

For you, as a technical leader (a CTO, VP etc.) it is important that the platform is compliant with all security regulations and that any incidents is easily investigated and addressed. So what do you do?

You have several options:

  1. Tell your tech team, that audit logging needs to be implemented, and it becomes their next priority. You can go even one step further, if you are technically equipped, and lay it all out, how exactly it should be implemented.
  2. You can wait for the next incident to happen and then ask for the report on what exactly happened and when you get no details you can ask your “Why?” questions, and “How can we prevent it from happening again?”.
  3. You can involve some of your senior stuff in the next security due diligence process for one of your customers and let them answer multiple questions targeting auditing and logging in the platform, to get their heads spinning.

and probably gazillion other options. But which one to choose? A simple answer – it depends.

Three simple rules in decision boundaries setting

Tell people what to do and how to do it. This is a perfect choice when you work with young, inexperienced people. Of course, you can give more context. Explain why we need this particular functionality in the system, and why this technical solution is a perfect fit. But in this case, they just do what you tell them to do. And it is perfectly fine, because they are too junior. If you let them to find the best possible solution, it might take weeks or even months. And the result still would be far from even decent.

Tell people what to do, but don’t tell them how to do it. If you work with strong, experienced team, who are good at what they do, just give them the problem and let them find the solution. If finding the solution is their area of expertise – they’ll enjoy the process and will get satisfaction of knocking off another challenge. All problems may have multiple different solutions. Think about setting some constraints to prevent them from golden plating (trying to make a perfect solution). Could be time constraints, or some technical requirement.

Tell people what is the problem and let them figure out what to do. Now we are talking about personal growth and trust. This is where you may get into the situation that the solution provided is far off from what you had in mind. If you are flexible enough and get adjust your plans and strategy if the solution doesn’t fit well – this is great. If it needs to be somewhere close to your vision, here you need to be a little bit more creative when you communicate the problem, if you really want to leave room to your team to find a solution. This is the most challenging scenario, but it’ll offer the best learning curve to your team. Still want to keep them on track – same story. Introduce constraints, make them accountable for the solution, challenge their ideas to push them a bit further. And of course give them credit for their solutions after.

Conclusions

There is no one approach that would fit all companies. Check the pulse of your team, how ambitious are they? Are they ready to take the risk? Are they okay with making mistakes and taking the responsibility for them? Can you actually invest time and efforts into your team at this particular moment? If most of the answers are “yes” then you are in a great spot. And both your team and you will learn a lot from this experience.