The Six Deadly Sins of Technical Leaders

Table of Contents

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.)

Related Posts

Building Knowledge in Teams: Main Mistakes and Strategies

Building Knowledge in Teams: Main Mistakes and Strategies

The topic of knowledge management in teams is largely overlooked by IT leaders. There is a silent assumption that it happens automatically. To some extent, it does, as programmers are accustomed to constantly learning to stay ahead. However, this is not sufficient. It’s not enough for everyone (or realistically, half) to learn individually. If the team is to be effective, cohesive and up-to-date knowledge is needed. Knowledge of new technologies or solutions holds limited value compared to this.

Read More

Don't Be Fooled by What Others Say...

Don’t Be Fooled by What Others Say…

A few days ago, as a conscientious citizen concerned about my health, I decided to have some preventive tests to determine my current health status. Initially, I chose a doctor funded by the NFZ (National Health Fund), as I wanted to maximize the value of the 250 PLN the state collects for my healthcare (I won’t delve into discussions on the efficiency of fund management in state institutions). Of course, I had done some research on which tests might make sense at my age, printed a list of potential tests, and presented it to my doctor.

Read More

Simple, Complicated, Complex, and Chaotic Systems: The Cynefin Framework

Perhaps you’ve previously encountered concepts such as complex systems, complicated systems, or complex adaptive systems, for instance when reading Jurgen Appelo’s Management 3.0, or when considering Ken Schwaber’s thoughts on the applicability of Scrum. This might sound intriguing, but it can be difficult to find logical sense in it if one lacks a certain theoretical foundation. This is where it’s worthwhile to examine Dave Snowden’s concept called Cynefin, which is based on complex systems theory, anthropology, evolutionary psychology, and cognitive psychology.

Read More