The Six Deadly Sins of Technical Leaders

Introduction

I probably would not have written this post if Michał hadn’t encouraged me. Over the past few months, I’ve slowly come to terms with a realization that I was hesitant to accept, yet it is quite understandable.

The Project Reality

What is the project reality in many companies? There exists a business, often referred to as the client who doesn’t know what they want, and at the same time, they are both the generator and sponsor of projects. Typically, the business defines the project scope vaguely while expecting precise cost estimates. As a result, IT somehow estimates these costs. However, it eventually becomes clear that not everything was accounted for, and the client often changes their mind. Thus, there is usually no way to complete the project on time without overtime or deadline extensions.

Due to significant underestimation, there is “no time” for good project practices, and instead, every programming anti-pattern possible is used. Consequently, the situation worsens, becoming increasingly chaotic. It’s easy to blame the business for being disorganized and not knowing what they want, but let’s take a look at ourselves. Increasingly, examples I’ve encountered lead to conclusions about the source of problems—who is really at fault? It’s the leaders and/or managers with a technical background who struggle in the cutthroat business environment, where the problems begin.

The Six Deadly Sins

If I were to list the main sins, they would be as follows:

1. Too Focused on Technicalities
   In times of crisis, technical leaders tend to engage in what they are most familiar with instead of saving the team and project. They tackle critical issues with the latest framework instead.

2. Underestimating the Production Processes
   Unfortunately, we technical people often mistakenly believe that having a great technical concept will make everything else in the project fall into place. This is absolutely false! It requires significant effort to keep the team, client, and project under control.

3. Yielding to Business Demands
   A common explanation for why IT agreed to a project without adequate resources or time is because of business pressures. We are seen as too soft, allowing business to dictate terms because they control the budget. This is nonsense, attributed to a lack of assertiveness and the ability to find mutually beneficial solutions. Conversely, a stubborn “NO” is not a solution either.

4. Inability to Resolve Personal Issues
   I’ve often witnessed situations dragging on for months where someone in the team is offended because their opinion was disregarded. Few have the courage and skills to address and resolve such issues.

5. Isolating in Boxes
   We tend to isolate ourselves in our own spaces, content when no one disturbs us while we focus and work. Even when we become leaders, this habit persists. However, being a leader is primarily about interaction and problem-solving, which cannot be achieved while hiding in a box.

6. Lack of Communication
   The golden rule of agile design is to make project decisions as late as possible. Many people have taken this to heart, but in a different context—they often inform about problems in the project as late as possible, usually when it’s too late.

Conclusion

Addressing these issues requires a shift in mindset and capability development to navigate the business environment effectively, enabling technical leaders to better serve their teams and projects.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)