IT culture: 3 ways leaders inadvertently hurt it

Many leaders may be guilty of one of these three decision-making mistakes without even realizing it. Here's how to avoid them - and protect your team's culture, morale, and efficiency
276 readers like this.
remote security policy

In today’s fast-paced and uncertain world, leaders often need to make decisions quickly, without fully thinking through how those decisions may affect company culture or employee trust. Here are three examples of common decision-making strategies that harm culture and destroy morale.

Leaders, you may be guilty of these mistakes without even realizing it. Read on to see if any of these strategies sounds familiar - and advice on what to do instead to ensure decision-making is more inclusive, responsible, and thoughtful. 

1. Keeping employees out of decision-making

You might think that by shielding customer questions or making scope-related decisions without consulting your team for feedback, you are saving them time and protecting them from dealing with organizational politics.

[ Want to spur innovation in your team? Read How to hire for culture add vs. culture fit. ]

But this sends your team the message that they are not able to handle important decisions and/or that their input is not valuable. In truth, employees at all levels of the organization have valuable insights that can help even the best leaders make timely and accurate decisions the first time. Not including your team disempowers them, sets the tone for a more hierarchical culture, and leaves room for errors that will catch up to you later.

Do this instead: Involve your team early and often on important decisions. The more important the decision, the more important it is to involve them. Empower them to make the decisions that they are best able to make and let them take the ownership and credit for helping your clients and your organization succeed.

2. Overvaluing outsiders' opinions

When you’re facing a fast-moving and ever-changing technical landscape, it can be tempting to put too much weight on the opinions of outside consultants or vendors. The true story of how you got into your current situation and how you will move forward is always much more nuanced than outsiders are likely to understand or address. Don’t fall for the idea that Cloud Product X will solve all your problems, or the notion that if only your team had not been so incompetent/naive/lazy you wouldn’t have these problems in the first place.

Technical debt happens over time and often results from organizational pressures and challenges. Recall Conway’s law and the fact that the systems that get built reflect the organizational structure, priorities, and leadership decision-making, not the architectural abilities of your developers.

An off-the-shelf solution or new style of development is not going to be a silver bullet. You’re going to need developers with domain-specific knowledge to help translate your current system to the new system or development style, so don’t alienate them or undervalue their opinions and insights.

Empower team members to bring solutions to the table before you ask someone else to do their job.

The technical talent you are looking for is almost always already underneath your own roof. You just need to create a culture that encourages sharing ideas, good communication, time to experiment, and trust in your people. Empower team members to bring solutions to the table before you ask someone else to do their job. You paid for the solutions you’re looking for when you hired your team. Bringing in consultants without first tapping the talent of your own team can cost you many times over in lost morale and turnover, so give it careful thought.

Do this instead: Think carefully about which consultants and vendors to bring into your organization, and weigh their ideas and suggestions on moving forward based on the merit of those ideas. When internal criticism from your team inevitably comes up, take that into consideration in the same way. If you aren’t getting internal criticism, your team is trained to know that you don’t value it (review #1 for the reason).

3. Making decisions in a silo

When budgets are tight or you face executive pressures, it can be tempting to dig into your fiefdom and focus solely on making your corner of the business look good while undervaluing collaboration with other departments and teams. Your team, other teams, and other departments within your organization will see through this tactic, and it will crush morale over time.

This strategy also leaves serious room for error, as all the parts of an organization are connected and have either a long-term or immediate impact on each other. This means that it is critical for all your teams and other departments to work toward the same end.

If your team can’t trust you to make the right long-term decisions for the organization, they will quickly lose faith in your ability to lead effectively. They may not challenge you directly, but they will likely start actively seeking new opportunities. Before you know it, your team may dwindle, due to “growth opportunities,” when in fact people are leaving to escape your poor leadership.

Do this instead: Make decisions based on the best interest of the organization – you have a fiduciary responsibility to do so. Your three clients – your employees, your vendors, and your paying customers – are also counting on you to do so. Resist the urge to make yourself look good in the short run at the cost of hurting the organization over time.

Keep these considerations in mind the next time you face a decision, big or small, in your organization. Above all, avoid these critical mistakes to improve your leadership and the overall efficacy of your organization and team.

[ Culture change is the hardest part of digital transformation. Get the digital transformation eBook: Teaching an elephant to dance. ]

Todd Deshane is chief automation and proof of concept specialist at Computer Task Group. He is a generalist with cloud-native skills working on some of the most exciting problems in the world across software, hardware, and scientific boundaries.