How to make everyone quit - part 2

Why process should be used sparingly

Yesterday we left our hero Alex with a struggling engineering team.

First of all, it was great to see how many of you replied to let me know what you would have done. Thank you! I'm sure Alex's ears are ringing šŸ˜€ 

Alex made two, process-related mistakes.

  1. He used process instead of analysis.

  2. He used process enforcement instead of outcomes enforcement.

Letā€™s dive into the first one today.

Analysis vs process

ā

Peopleā€™s problems are rarely solved with ā€œone size fits allā€ approaches

People and teams are all different and unique. That means peopleā€™s problems are often complex and composed of smaller sub-problems.

Because of this, our first instinct as captains should always be to do analysis first. By digging into the data and talking to people we can better understand the various sub-problems. Then, we can devise specific solutions to each one of them. Specific solutions cater to the natural differences between people and teams. I like to call sub-problem solutions surgical interventions.

While surgical interventions are often more effective and less disruptive than process, they have a downside. They donā€™t scale well. Sometimes we donā€™t have time to troubleshoot all the sub-problems alone.

A good first step here is to seek some help first. If we are troubleshooting many sub-problems at the same time, we could delegate analysis of some to others. Youā€™ll be surprised what a team of captains doing analysis together can achieve.

As the number of sub-problems grows, there is a point where the cost of doing analysis becomes too high. Thatā€™s where process usually comes into play.

Process should be used sparingly. We should save it for problems for which surgical interventions are really, really, really impossible. Why? Because process is easy to devise but hard on the people subjected to it. It is one more thing people need to worry about while doing their job. Moreover, process reduces peopleā€™s agency. Reduced agency often leads to unhappiness.

ā

Analysis is hard for the captain.

Process is hard for the team.

The right thing to do

Alex wasnā€™t a good captain in our scenario because he immediately went for the process. Alex should have applied analysis first. Doing that would have revealed why only some of the teams were struggling. With that data, Alex could have then planned a series of surgical interventions. Each aimed at solving a specific team's problem. Alex chickened out on doing the hard work himself. Instead, he went for the process which was expedient for him but hard on his team.

Captainship is all about helping others achieve their goals remember? In this scenario, Alex failed to do that. He wasnā€™t able to help his low-performing teams achieve their goals. At the same time, his actions made it harder for his high-performing teams to do the same. That is not the behavior of a good captain.

Tomorrow weā€™ll look at the second mistake that Alex made: focusing on process vs outcomes.

-Ale

P.S. What did you think about this post? Reply to let me know!