Who is this aimed at?

Product managers, team leads, and senior engineers: People who need to provide clarity, direction and decision making for a group of people.

Key Takeaways

• Communicate the 'pillars' of your project to scale decision making beyond you
• You need to find ways to not be involved in everything
• Your most important job is to grow the team to execute

You (the human) don't scale

How does your team decide what to work on? Or what to prioritise?

You can go to all the meetings, and provide all the context, and be involved in every decision.

This will be fast initially, and you'll feel super productive. You're a 'go-getter'. You the one who gets things done.

But eventually a few decisions will get made that weren't right. You'll have to handle some fires, take some remedial action. Maybe a bit of work needs to be redone.

The team falls a little behind, everyone is a little stressed. People keep coming to you for what you think are pretty basic decisions. You just have to keep more of a handle on everything, make sure you're at all the decision making points. That will help.

So how to start scaling you?

Your teams needs a way to evaluate decisions

Perhaps you've always known how to work out whats next: You have an internal rubric or tree-pruning capability to rapidly make decisions, created from years of experience or being embedded deeply in the context.

But there's only one you. People need a frame or guidelines to confidently make decisions. They don't need to create the frame initially, that's your job.

You need to comunicate the 'big pointing arrow', and then initially provide a mechanism for allowing others to answer 'what should I do?'. Pushing the decision making elsewhere is the fastest way to an independant, high performing team.

Easy to say, the hard part is providing conscious feedback and improvement loops for your reports.

You need to grow decision making confidence

Every 'what should we do?' is a chance

Lots of questions coming your way is a signal that reports either lack clarity, confidence or agency to be able to make decisions on their own. They're not sure what to do, and they dont wanna mess up - so they're coming to you as the safe, easy option.

• Do they not know what the choices are?
• Do they not know how to figure out how to make the choice?
• Are they afraid of making the wrong choice?

You can grow technical capability, you should put the same effort into growing decision-making capability.

Timebox research or decisions

It's easy to fall into the classic 'bikeshedding' trap: Spending a lot of time talking about and unpacking relatively minor issues.

See the Law of triviality: (Wikipedia)

Imperfect decisions are okay. It's the best one we could have made at this time with our given constraints. Not making a decision isn't okay.

Having 'another meeting', or 'bringing in another SME' is important sometimes. But at some point a decision has to be made so we can all continue forwards.

Standing by the process

Maybe the decisions won't be what you would have done, but you need to uphold them regardless. Your team needs to succeed at applying decision-making logic continuously in order to become more independent.

They need to practice the conscious behaviour of having a fork in the road, and logically evaluating against known critieria (the pillars), and then in the face of ambiguity making a decision.

The Socratic method (more effort for you)

Socratic questioning (Wikipedia) is a method of education where the teacher mostly asks questions rather than providing answers in order to promote more cross-examination and self-identifying of logic holes or unknowns in the students argument or statement.

You reap what you sow. If you always provide answers, all you will ever receive are questions.

Example 1: Question: "We need to update our global error handler (React app), how should we do it?"

Engineering Answer: "We can use a higher level ErrorBoundary to catch the common cases, and then lower level ones for specific component handling"

Or

Socratic Answer: "What are our options? What cases do we need to cover? What experience do we want the users to have?"

Example 2: "Here is my SQL schema, what do you think?"

Engineering Answer: "You've got the right indexes and fields, looks good to me!"

Socratic Answer: "How do we know if we've covered the query patterns, what do we want to support? How can we definitively say 'yes this will work'?"

One set of answers will lead to no change: continuous low-level interruptions for you, and one will lead to a more autonomous team. The autonomy progression of an employee engaged with the socratic method over time typically follows this path:

1. Stuck often with many questions
2. Stuck with questions, but have some options
3. Stuck with some questions, but has options and a preferred option
4. Rarely stuck with questions, have researched options and a recommendation with logic reasoning
5. Fully autonomous

Closing

Growing people through the socratic method is slower in the short term, and demands more energy, time and discipline from you. (It's easy to fall into the trap of 'providing the answer' means that you're being helpful!). But in the long run it pays off!

For this to work, its essential to change the expectations your team has of you. They must expect that you will not provide simple answers, and require them to input more effort or thinking into the process.

You should also tell them what you're doing! Tell them about the socratic method, explain why you're doing what you're doing. Make them a meta part of the process, keep them engaged and start them thinking more explictly about their behaviour.