Technical Leadership in IT Projects
Some thoughts on leadership within IT projects.
One observation that is becoming more apparent to me is that more often than not, people with a non-technical background are put in charge of a software project. Many of these people try, intentionally or not, to manage a project ‘by the book’. They attempt to manage a project by applying techniques and other methodologies they might’ve learned in previous management trainings or from plain experience.This attempt is by no means bad in my opinion. However, it is the extend to which some managers go (or don’t go) when put in charge.
Some people come in, convinced, or, are overly optimistic that, “their” approach would be the most successful way to manage a project. One concrete example of a approach I’ve seen being used is the concept of “self-organizing teams”. While this approach, if applied and practiced correctly, can be very beneficial to the continuity of a project, many people use this approach and tend to make the mistake of believing that a self-organizing team does not need to be managed at all. Some people believe that, after going for this approach, they don’t need to worry at all about the other aspects, such as, the technical part of the project, as the self organizing teams will “deal with these issues anyway”.
This is where the lack of technical leadership becomes apparent to me.
In a perfect world, or whatever positive-but-unrealistic world, everyone is knowledgeable in all topics and everybody can work, collaborate and produce at work with maximum output for their employers. However, in the real world, things don’t go like that obviously. Features need to be discussed. Knowledge needs to be shared. Unclear matters need to be clarified. The wants and needs of clients need to be clarified and repeated.
The part I want to focus on is technical knowledge.
Non-technical managers need to become technically knowledgeable to a certain degree within the context of the project. Knowledgeable enough anyway to be able to understand the technical challenges and get a grasp on how critical these technical challenges are.
A manager that does not grasp these points will not be able to manage deadlines correctly, communicate technical urgency to other decisive members of the management team and lastly, run the risk of underestimating the amount of actual work that needs to be done in within a project. Ultimately risking the success of the entire project.
I believe that if a manager wants to be successful within a given project, especially one with a non-technical background, he or she needs to immerse oneself in the technicalities of the project. Even though it isn’t necessarily the responsibility of the manager, he or she needs to be able to understand the language being spoken among the technical members of the team so that the manager can determine whether the focus of the team is set in the right direction. This way, the manager will also be able to better understand the challenges that can plague a project and will be less likely to down play or underestimate the necessary work required to implement a feature, make a product or execute a service as part of a project. Increasing the odds of executing a successful project.
This is one of the things I believe a manager should strive do to successfully demonstrate technical leadership within an IT project.
And I believe we all want that.