Select Page

Why managers are generally afraid to take risks

For the longest time, I always wondered why managers with a development background seem to lose their zeal for new things and become their worst enemy. I’ve heard the same people who once developed express frustration at their managers for preventing the use of newer technologies, then turn around and do the same thing as a manager to their developers! Where is this aversion to new things coming from?

Recently I learned the answer, and it comes down to responsibility.

My brother-in-law (who is a minister) shared some stories with me of members in his congregation that always come to him with a desire to bring their pet project to the church. It may involve bringing in an independent, not-well-known organization or their friends. My brother-in-law has to repeatedly turn them down in many instances because he knows that his boss is going to hold him responsible for any undesirable outcomes. As a result, he must stay ahead of the curve and not always give in to the latest opportunity without researching.

As I have taken on more leadership roles, I find my mindset changing as well. Managers are responsible for the actions of their reports. This results in more risk-averse managers. I have witnessed firsthand my managers cover for the faults of their reports, and it is one of the worst experiences a manager ever has to go through. To avoid going through this again, sticking to the tried-and-true is the best formula to avoid uncomfortable and damaging situations.

Having finally coming across this answer, I have nothing but respect for the people that have covered for me in the past.

With that being said, this approach can easily be taken to an extreme. It can lead a team to become stagnant, passionless, and robotic.

Despite being the most cautious, safest way – these benefits are only felt in the short term. A team can be safe all the way to oblivion. So how should a team manage being safe while still moving forward?

Gather data

As a manager, do some research on your team. Is the push for doing new things coming from the team as a whole, or a few vocal people? Cross reference this with past developments – has the team implemented new techniques that they are unaware of in the present? Identify past behaviors that may indicate that implementing new things is no stranger to the team’s DNA. This will make the process easier as the team will be traversing familiar territory.

In addition, do some self-introspection. When did the switch between ambition and caution occur for you? When was the turning point? Was it a negative encounter or set of circumstances? Or were you trained to be cautious when you transitioned to a more leadership role? Knowing when/if such an event occurred will provide time to minimize the impact of potential future circumstances that exhibit similar tendencies.

Define a vision

Saying “no” repeatedly to your reports when they have the latest and greatest idea (that is either high risk or not useful) becomes burdensome. Why are you spending your time engaging in the same conversation over and over again? If your reports keep coming to you with ideas that you know will not work for the long term health of the project, why should they keep coming to you? Make this job easier for them and outline a vision for the team. Where is the team heading? What is the overall goal of the team? Communicating answers to these questions will help transition your team from a fixed mindset to a growth mindset. You’ve laid the foundation for them to self-manage.

Implement a strategy

To avoid the fate of oblivion, provision should be made for the testing of new technologies/concepts in a low-risk environment. For example, we want to keep libraries on our team updated so we can take advantage of the latest optimizations/bugfixes/etc. Our internal team policy is to make these updates in a separate branch, and let them sit on internal builds for a couple of months. If no immediate issues are identified, then we release them. If you do not have a low-risk environment (do you develop in production?), make one! This allows your team to take the lead for themselves in testing new things, so if it does not work they will find this out on their own. With an openness towards being innovative, while providing a workflow that allows for testing of new things while preserving stability, you can ensure that the team continues to be innovative. Furthermore, they will better understand your responsibility of keeping the project on track.

Encourage wins and losses

If you only encourage innovative techniques that result in a win, you subliminally pressure your team to only speak up when they are almost ready to deliver something innovative. Here are the side effects to such an approach:

  1. You prevent communication in the early stages of a process. Why should people speak up about ideas they’ve been pondering if you require and reinforce a “don’t talk to me unless you have a solution you can prove will work?” This will lead your team to¬†hunker down and work independently (or with one or two other trusted peers) on a solution that others may have tried and failed to do.
  2. You kill ambition. If there’s a 50/50 chance of success/failure, but the consequences of failing during an experiment are high, your team will give up. They may conclude that it is easier to coast instead of trying something new and potentially being negatively perceived. A culture of coasting is hard to break, and when the environment changes that requires rapid innovation your team will not be ready.
  3. You eliminate collective discovery. With no ambition to try, there are fewer opportunities to identify ground-breaking solutions. Suppose a team endures a hard failure together. If this occurred in a low-risk environment, the consequences are small. However, your team can do a retrospective and avoid making the same mistakes (if applicable) in the future.

Despite the colossal failure of the Amazon fire phone, the company used the experience to develop more innovative products later on. Even though it was a big loss, focusing on moving forward (as opposed to moving on) led to bigger hits such as the Echo line of products.

I am not advocating for anarchy, nor am I saying that we should stop being safe. It is a delicate balancing act between being safe and being innovative. Oftentimes we wait for catastrophe before we attempt to find innovative solutions, but teams can only endure so many before losing motivation. Managers have priorities that must be met, and they are responsible for the actions of their reports. This fact should strongly be communicated to your reports. In addition, reports should learn that the latest and greatest is not always the best for the team. How can they determine if something is best for the team? Here is when the manager must provide an answer. Show your team the way forward, provide a peek at your role, and that increased understanding will lead to more intelligent processing when determining ways to benefit the team – and you – in the long run.