Programmers often joke that it is enough not to know how to program and like meetings to become a project manager. At first glance, the IT industry looks pretty technical, but this is no longer true.
Technical skills are needed when creating software, but the real advantage on the market comes from a well-coordinated project team. It’s like in football. In the past, teams won the World Cup thanks to their stars, but in 2004, the Greeks showed that you can win the Euro with a well-coordinated team without any star in the squad. This changed the way of thinking about teamwork, and now, it is more important to have a good team as a whole, not as individual stars.
As an experienced IT Project Manager who has experienced more project crises than the average football player with injuries, I know that technical skills are the tip of the iceberg of success in IT project management.
Many people who move to the position of IT Project Manager from a technical role are surprised to discover that knowing the latest framers will not help when the team starts to fall apart under the influence of conflict and the deadline is dangerously close. Yes, technology is like a good road bike, but one bike is not enough to win the Tour de France. You need to have a good team ready to face any problematic situation.
In this article, I’ll introduce you to seven non-technical superpowers that distinguish mediocre PMs from outstanding ones, who lead teams to success even when everything seems to go against the project.
Article Shortcuts
Empathy
Empathy in a world of tight deadlines and tight roadmaps sounds quite abstract. It’s like baristas in a cafe adding a free lecture on astrophysics to every coffee. Such cafes may exist, but they are probably not something we would expect from a cafe.
However, in the relatively harsh world of IT, empathy can be the superpower that will allow you to pick out small nuances in the project team and thus react a little earlier to a potential problem. It is better to diagnose the problem early than to find out at a status meeting that key project team members are leaving because they are fed up with the constant pressure from the business.
Empathy is the ability to sense the team’s unspoken problems and emotions before they negatively affect the project. Let me tell you right away that it’s easier when the team works together in one office, or at least on one floor. It is a bit more complicated if the team is dispersed, but it is still possible to catch some symptoms of later problems earlier and thus react in advance.
Returning to the Tour de France, if you imagine a team tackling a mountain section, it may seem that there is nothing to discuss at first glance. The team works evenly, and everyone contributes to the common goal. Still, an experienced observer can catch symptoms well in advance that indicate that one of the players is overburdened, which puts the entire team’s success at risk. Similarly, you should learn to use your empathy to diagnose potential problems in the project team. Often, the project team members will tell you everything is fine, but you should be able to sense whether they say this only out of politeness or fear or whether everything is excellent in the project.
One of the ways to get to know people better, and thus to diagnose their moods better later, is to talk one-on-one. It can take a long time if the project team is large, but on the other hand, exchanging a few sentences with each person in the project now and then is one of the best investments a Project Manager can make. In addition, you get to know people better, so you work better, it’s hard to find disadvantages, except for the lack of time.
There’s one more thing you can look out for: changes in how project team members communicate. Usually, at the beginning of a project, everyone is themselves, deadlines are far away, and stress levels are low. So, people will communicate in a way that is natural to them. Observe how they communicate, and then be vigilant if how they communicate changes.
Strategic Improvisation
You can be a master of planning and creating schedules, but if you can’t react appropriately to a critical throw-in from a client, the goal of the project is at risk. Perhaps I’m the only one who has it that a week, two weeks at the most, after we establish an action plan with the client, he comes with an ultra-important functionality that needs to be implemented immediately, at the latest, before the first milestone is completed. However, even if it’s just an affliction of the projects I run, I’ll still share a few comments on Strategic Improvisation.
Let’s start with what this skill is.
Strategic Improvisation is the ability to stay the course while changing the previously agreed route. Let’s imagine that you are a mountain guide and leading a group to a shelter, but there is a problem on the route because, during a night storm, the bridge over a rushing stream broke. You still have to bring the group to the shelter because that’s what you have in your contract, but at the same time, you have to find a new way that will lead you to this goal and, at the same time, won’t cause a drastic delay in reaching the shelter, where a hot meal is already waiting for guests.
In other words, as one well-known boxer said, “Everyone has a plan until they get punched in the face,” in an IT project, the Project Manager gets slapped in the face on average several times a day. It just depends on how many projects he runs at once.
How do you become a master of strategic Improvisation?
There are two approaches: plan or practice quick response in crises.
The first approach is a better solution, but it takes time to plan your actions and requires lots of creativity to determine what can go wrong.
The second approach is very extreme. If you have nerves of steel and are not afraid of making decisions in an atmosphere of disaster, it will be a natural solution for you. Still, you don’t always have enough time to perform corrective actions correctly.
What do I propose when it comes to Strategic Improvisation?
There is a middle ground between the two approaches. On the one hand, it is worth managing risk actively, and before the project starts, look for potential problems and propose some solutions to them. If you’re not good at coming up with issues like me, you can ask the project team to share their insights and outline potential risks. Usually, there will be at least one person in the project team who is highly creative. It is worth noting all risks and proposing actions about them, even if this action is “risk acceptance”.
On the other hand, it will never be possible to predict all the risks in the project. It is impossible. Therefore, practicing decision-making under pressure is part of the IT Project Manager’s workshop. You can learn it in any workshop, but the longer you work in this position, the easier it is for you to work under pressure. If working under pressure is not your forte, then the IT Project Manager profession is probably not for you.
There is one more “pro-tip” for strategic Improvisation – don’t improvise if you don’t have to.
What do I mean? If you have some “difficult” operations to perform in the project team, such as changing a key functionality, moving data between databases, changing the logic of some element in the system, and the like, always simulate the implementation of this change in a test environment. Write down what needs to be done with the project team, then add a responsible person to each step and go through this process at least once in the test environment before going through it in the production environment.
I know that nothing raises adrenaline in your veins like testing in production, but on the other hand, it’s pretty expensive fun and can end badly for the project, the project team, and you.
Diplomatic assertiveness
How do you say “no” without using the word “no”? Beginner PMs often fall into the trap of being friendly and agreeing to everything. How this can end, I wrote in the article “Hidden costs of design changes“. Experienced Project Managers can say “no” to not upset the project stakeholders and always leave the door to cooperation ajar.
I will not hide that this is a complex art, especially if the project structure is “asymmetrical,” i.e. when one of the stakeholders is an indirect or direct supervisor of the IT Project Manager. You must have the courage to say “no” to such a stakeholder.
I know that the project’s cost is lower than the cost of a career in a given organization, but these are only appearances. If your most important goal is to deliver projects in a specific scope, time, and cost, you will earn a reputation as an effective IT Project Manager. However, you should often agree to changes made to the project outside the established procedure. In that case, it may quickly turn out that you will earn a reputation as an ineffective person who fails to manage projects because you constantly fail to deliver something.
Okay, but how to say “no” without being labeled a whiner or an eternal pessimist?
Let’s start by saying “no” and that it should always be based on facts and data. So, if you feel that something is impossible, but you don’t have “hard data” at hand, it would be best if you asked for time to analyze this proposal and the opportunity to present it to the steering committee. Remember that, in an IT project, the Project Manager has limited space to make decisions. Therefore, whenever you feel that a proposed change will impact the course of the project or product, discuss such changes with the steering committee.
When preparing a proposal for a change to a steering committee, always present it in the context of other possibilities. Never stand in open opposition to this proposal, nor do you stand in the position of an ambassador of the proposal. It isn’t easy because you can feel responsible for the products provided as an IT Project Manager. Still, your role in the project is to deliver a specific product on time, with quality and cost, not decide what shape the product should have.
Suppose any of the stakeholders is pushing you or any project team member to make a change to the project, arguing that this change is good and desirable. Still, there is no point in discussing it on the steering committee. In that case, you should respond by recalling the change management procedure adopted in the project as a mantra and a signpost for fruitful cooperation.
Contextual Translator
Imagine you are at an international conference without an interpreter, where half of the participants speak Chinese, and the other half speak Polish. This is precisely the situation we have in projects. Developers speak Chinese, and business speaks Polish, or vice versa.
Only two people in the project can translate the language of one into the language of the other: the business analyst and the IT Project Manager. The slight difference is that the Business Analyst is paid for this translation, and the IT Project Manager should be able to translate issues both ways. In the article “From developer to IT Project Manager” I wrote more about what an IT Project Manager should be able to do.
To clarify, I will also say that I do not mean that you should be fluent in technical language because that is what a business analyst is for, but I mean that you should be like a sports commentator who can explain to a broad audience what the rules of the game are in a given competition. Business people may wonder why it is impossible to perform some operations in the system, and you should be able to explain to them that this is a technological limitation and nothing can be done about it.
On the other hand, you should be able to explain to developers that a business cannot make money on their brilliant idea for a new feature.
How do you develop the ability to translate complex technological phrases? The easiest way is to tell your child or grandmother about what the project team is working on if secrecy clauses do not cover the project. You can also ask AI to help you explain complicated technological phrases to non-technical people.
The ability to explain the business legitimacy of the functionalities produced usually comes easier to us. It is enough to ask developers how it is supposed to work and what benefits it will bring, and we have a ready narrative.
Regarding project communication, there’s another important tip that helps ensure that everyone at that party understands what’s going on in the project. Well, it is enough to ask at a project meeting: is everything apparent, or does an issue need to be discussed in more detail? Even if someone doesn’t want to ask a question openly during the meeting, most often outside the meeting, they will ask for an explanation of some “problematic” issue, and this will be a clear signal to you that you need to discuss some technical element in more detail because if one person didn’t understand, there’s a good chance that other people didn’t understand it either.
Still, they don’t want to admit it. Alternatively, you will hear there is no need to discuss this issue at the meeting because it is clear. It is better to hear such a comment than to find out later that bad decisions were made in the project because something was incomprehensible.
Proactive anticipation
The average PM reacts to problems that arise in the project. A good PM anticipates issues before they happen. Proactive anticipation is predicting the future without using a crystal ball. How is this possible?
Usually, you must go through the project schedule and think about what could go wrong. If you are starting your adventure with project management, it may seem not easy to you, which is understandable. However, you can predict what can go wrong if you have already completed a few or a dozen projects.
Contrary to appearances, project situations are repetitive, and although the project team, project environment, or project goal change, most of the situations in the project are repetitive, so it is relatively easy to predict what will happen.
Predicting the future of projects is like predicting the outcome of your favorite team’s match. We know what the team is capable of, where its weak points are, and what it is strong in, and although each game is different, it is more or less clear what to expect from a given team. It’s the same in projects; every project is different, but if you’re already running another project in a given area, you know more or less what to expect. You more or less know what can surprise you.
How do we learn to predict the future?
To get started, you can engage the project team to identify risks. The more heads, the better. After all, every head has some ideas; if you multiply these ideas by the number of heads, the result can overwhelm you. However, don’t worry about the number of invented risks; after the creative part, take care of the assessment of each of the invented risks, and it quickly turns out that most of the dangers qualify as those that are unlikely to occur. The focus should be on those that seem likely to happen, and action should be taken if possible.
Learn from design experiences. The more projects you complete, the more you learn, and the faster you spot problems in the project environment. This process cannot be accelerated, although if there is a culture of knowledge sharing in the company, I encourage you to study documentation from other projects, especially the risk register, because this is where you can learn more about the risks encountered in projects and how to deal with them.
Build a “network of informants”. As a PM, you should be well informed and you should be interested in everything that is happening in the company. You never know if the activities carried out in other organizational units in the company will impact your project. It may quickly turn out that this is the case. Therefore, the more contacts you have in the company, the more you know about what is happening in the project environment, and the faster you can catch potential problems that may affect your project.
Orchestration of team energy
Currently, managing the work of a team or teams is nothing extraordinary. If you can’t do it, the IT Project Manager profession is not for you. Unless you know how to use the tools to manage the team’s work perfectly, you can do it, too. However, this will not make you an outstanding IT Project Manager.
Today, to stand out in the industry, you need to learn how to direct human potential. The concept of directing human potential goes far beyond the ability to motivate. Directing human potential means sensing when the team needs challenges and when it is overtired and needs to slow down. It can be compared to being a personal trainer who knows perfectly well when to add more exercise during the session and when to give you a little more space to rest. As a result, you make regular progress.
The difference between a personal trainer and you will be that a personal trainer takes care of you only during the session, and you take care of the whole team and, in some projects, teams. This is a big difference because each team consists of at least a few people with different potential, different characters, and a different approach to work. However, the results will be surprisingly good if you learn to manage and harmonize the team’s energy.
How do we learn team energy orchestration?
Start by introducing diversity into the rhythm of work. In addition to providing value for the business, the team should also have time to eliminate technical debt, recognize new technological opportunities, or optimize the code. At first glance, it may seem that such teamwork does not give business value, but this is untrue.
First, the technical debt incurred always has to be repaid, only if we pretend that we don’t have to. We pay it off quietly during a failure or the development of new functionality when it turns out that the old part of the code needs to be rewritten because it is impossible to develop new functionality without it. Secondly, suppose the team has time to look for new technological solutions. In that case, it may find a solution that will improve the system’s operation or enable development in a direction in which this development was not possible before, or the development of new software will become easier.
Even if the team does not find a solution that will have a positive impact on the business within a certain period, such an investment is still worth it because such a break from routine work allows you to “rest your mind,” and thanks to this, developers can look at the code from a different perspective and with a different level of motivation when they return.
Listen to the individual needs of your development team members. You don’t necessarily have to meet all the needs reported by the team at once. Just hearing means a lot to people. Of course, it’s true that listening is hard, but you need to learn the skill and be an active listener. In addition, if you can meet some of the needs reported by the development team, they will be satisfied and more effective at work. It pays off for each party.
The last element and, simultaneously, the most challenging element, is attentiveness to dangerous signals coming from the team. We are often surprised that “suddenly” there is a crisis in the team. The truth is, however, that no crisis comes by surprise. We ignored the signals from the team before, and the problem grew so much that we finally noticed it.
The easiest way to catch subtle signals from the development team is during retrospectives. The condition is to create a safe atmosphere where individuals are not afraid to say what they do not like. There are different approaches to retro, and these meetings are often downplayed or organized after something in the project goes wrong. It is too late. Retro meetings should occur regularly, and we should meticulously note and take care of all comments. This will build trust between the IT Project Manager and the team, thanks to which all problems will be addressed on an ongoing basis, and we will significantly reduce the risk of a crisis when we least expect it.
Ability to manage paradoxes
Project management is an endless balancing act on the edge. Theoretically, a project is a time-limited undertaking to deliver the assumed product within a specific time, quality, and budget. Based on this definition, a project triangle was created, where we can manage only two of the three elements (time, quality, and cost).
As you can see, the very definition shows that the life of an IT Project Manager is a constant balance, a constant management of paradoxes. The sponsor wants the product faster but will not provide additional resources. The Quality Manager complains about the quality but does not influence the project team. The project budget was underestimated, but the client does not want to hear about it because he has already agreed to a certain amount and does not intend to pay a penny more. Finally, the Business Owner gets a new functionality, and it turns out that this is not how he imagined it.
A good IT Project Manager is like a Surfer: he never fights the wave, but he adapts perfectly, catches the perfect balance point, and uses the energy of the wave to deliver the project product to the shore in the assumed time, at the lowest possible cost and acceptable quality.
How do we learn paradox management?
Start by giving up thinking “either, or”. It’s a very intuitive way of thinking, so it comes quickly to us, but in the long run, it doesn’t serve the project, the design environment, or even you. This approach puts you in open conflict with project stakeholders, and the IT Project Manager should be neutral to stakeholders.So, if stakeholders report any project needs, you must prepare a solution with the project team and show how much this solution will cost and what risks this task entails if you can also find synergy elements to already working or planned functionalities.
Swapping or at least trying to turn design problems into design opportunities.
The change of attitude causes us to look at what is happening in the project differently; thus, we have a different attitude and react differently. I know some project situations can make an IT Project Manager gastric churn, but I still recommend changing your point of view. As soon as your nerves let go, it’s worth looking at this problem as a project opportunity, at least for a moment. You won’t be able to change your thinking right away or always be able to turn a problem into opportunities, but I still think it’s worth trying, if only for your mental health.
Summary
Non-technical skills are not a soft addition to the hard work of an IT Project Manager. Soft skills are a key advantage in today’s IT project management market.
IT Project Managers, who limit their work to building schedules and holding the team accountable for timely product delivery, will quickly be replaced by artificial intelligence. Moreover, it will do it better and faster than a human.
If you want to manage projects and achieve outstanding results with teams, you should start developing your soft skills as soon as possible if you are not already doing so.
Novice IT Project Managers often think the key to success in this profession is knowledge of project management tools, techniques, and methodologies. These are all extras. A real IT Project Manager can work with people, be attentive to their needs, negotiate with stakeholders ideally, and always ride the project wave.
Now it’s time for you. Let us know in the comments what the most essential IT Project Manager skill is for you. What is helpful for you at work, and what makes you a great specialist in what you do?