4 key moments to leading your team

#51, Mar 6 2024

Once upon a time, in a tech org not far away, there was a leader…

A leader was annoyed by what he thought were stubborn people on his team. In particular, there was a senior developer who was highly disagreeable. This developer just didn’t commit to technical solutions suggested by others. It was either his way or the highway. The leader was so angry at the senior developer…

Hi 🙂 Hari here.

/* started writing this newsletter while my 8yo boy, who’s not at school today, is reading a comic out loud to practice his reading skills */

Today’s tale is focused on 4 key moments leaders in tech overlook.

4 key moments that if not handled well will make your job as a leader tough. Even painful…

1. When people disagree

Disagreements are not bad for your team.
Disagreements are great for your team if you handle them well.

/* btw, we’ve seen 5 stages of team conflict */

The leader in today’s tale did the worst thing at this moment.
He pushed back on the senior dev’s opinion.
He asked the senior to follow what most people on the team suggested.

He rushed into asking the senior to commit to the team’s decision.
But there was no decision made yet!

Not in a clear way.

When someone disagrees:
1) you listen
2) you understand
3) you show them you understand
4) you make sure they feel heard & their opinion is taken into account

When people disagree – your goal is to keep the discussion open.
Your goal is to get everyone’s opinion visible to the team.

2. When everyone is heard

Most team discussions suck.
We’ve assessed the dynamics of hundreds of dev teams, and we’ve seen first-hand what happens when you lack structure.

/* btw, we’ve replicated our approach into the TReE Team Scan tool I recently talked about on the HackCast podcast */

One often overlooked moment is when you stop hearing arguments. And you start seeing preaching.

If you’ve already gathered all the options to solve the problem you’re discussing – just write them down and visualize them to everyone.

/* showing their ideas on a whiteboard sends a belonging cue and people feel included */

Then ask one last time if there is something else that’s missing on the list.

Afterward, clearly state that the discussion is over.
Clearly state that you’ll now go into decision-making.

When everyone is heard – clearly indicate the discussion is over and you’ll now decide.

2. When everyone is heard (& you’ve stopped discussing)

This is the same key moment, but there’s something important to note.
Something crucial if you want people to commit.

If you ask dev people if they have a clear decision-making approach in their team, and we have asked hundreds, they’ll just smile awkwardly.

That’s why I keep saying that the most important decision a team should make is how to make decisions.

Going back to today’s tale: the leader implied to the senior that their decision-making is by majority voting.
While this is a valid and sometimes a great decision method, it was not a clear one on this team.

/* you can see 15 decision methods here */

The senior hadn’t agreed that he would commit to decisions made by majority voting. He hadn’t been informed about this approach either.

It was an implicit thing. An unspoken rule.
And that’s probably the case on your team as well.

That’s a pitfall, though.

What I’ve seen work well is to make the approach explicit.
You either inform people or even better – have a separate meeting and define your decision-making approach together, as a means.

/* you can follow our Decision Matrix approach we do in a workshop with dev teams */

But you should do this separately from any discussion on a current problem.
You have to do your homework beforehand.

And if you’ve done your homework, then this section would be just the following sentence.

When everyone is heard & you’ve stopped the discussion – just follow your clear decision-making approach.

3. When you’ve made a team decision

A big problem I’ve seen with some leaders is they tell once and expect everyone to understand.

Having a mutual understanding is not a moment. It’s a stage. It requires you to manage it.

What I do in these situations is:
1) I overcommunicate the agreement.
2) I remind the agreement when it’s not followed.
3) I ask everyone to hold each other accountable with the intent to have clarity, not with the intent to finger-point.

Keep in mind that the moment you are sick and tired of repeating the same message is the moment people start listening.

/* holding each other accountable is essential when you have a clear agreement and is part of the aspect of team responsibility in the TReE Team Model for high-performing dev teams; the average score of dev teams we’ve scanned on team responsibility is an acceptable 64/100, one of the lowest average scores from all aspects */

Referring to a team agreement will make sure you actually do what you’ve agreed.

People are not doing what you expect from them not because they are sabotaging the team. No. Most of the time it’s because they don’t have clarity.

When you’ve made a team decision – overcommunicate it so that you actually start doing it.

4. When you face your first obstacle

If you’ve reached this step – kudos!
Most teams fail long before this moment.

But then you face some obstacles.
And in today’s tale, when an obstacle occurs, you hear the uncommitted senior developer saying ‘I told you so!’

This phrase is usually an indicator that the previous steps have not been followed. The stage was not set right.

Even if you don’t hear the phrase, people have the tendency to revert back or change. And they quickly rush to change, which leads to being slow.

/* making changes too quickly will cause a series of microevents which will slow you down */

To make your team resilient, you have to teach them how to cope with setbacks and obstacles.

What I do in these situations is to:
1) frame the solution we’ve chosen as an experiment
2) set a timeframe for the experiment – to observe without changes
3) measure the outcome of the solution we’ve chosen

I usually do this before we start applying the solution.

The most disagreeable people I’ve worked with (myself included 😀 ) are willing to follow an idea when they know there’s an end date.

Having this date in the minds of people allows them more easily to persist on the same solution before reverting or changing.

And when you measure the solution – at the end of the experiment you’ll have data.
This data will convince the disagreeable people that you should continue with this solution.
This data could also change the minds of people who were initially very confident the solution would work.

When your team faces their first obstacle – remind them this is an experiment that should be carried on until the chosen date.

The 4 key moments: a leadership checklist

When people disagree
↳ keep the discussion open and make sure everyone feels heard

When everyone is heard
↳ indicate a stop of the discussion and decide using your decision-making approach

When you’ve made a team decision
↳ overcommunicate the agreement so that everyone has a clear mutual understanding

When you face your first obstacle
↳ remind people this is an experiment that should be carried on until a chosen date

… and the team lived happily ever after.

Get a leader's tale

leadership insights
directly in your inbox!

Learn more...