Have you considered what the work of an IT project manager actually involves and which risks come with it? This article looks at the role, the selection of promising junior specialists, conflict within a team and preparation for disruptive situations.
The IT project manager’s profession
An IT project manager works with very different projects, often in conditions of high variability—especially when a customer’s expectations change. The technology market is also highly dynamic and new business models emerge quickly. A project manager must therefore adapt to changing market conditions, use non-standard ways of solving problems, work through the team and communicate changes in a constructive way.
Important hard skills include the ability to work with several connected IT resources, understand AI algorithms and know the principles of UX design. These capabilities, like knowledge of the customer’s domain and the subject of the project, can be developed through study, training and experience. Work becomes much harder, however, without strong soft skills.
A project manager needs:
- an energetic, inquisitive intellect;
- clear communication;
- the ability to manage a team;
- the ability to work with customers;
- rapid decision-making—sometimes within seconds.
Every project manager should also want to understand the subject deeply. Do not be afraid of technical detail: a capable team will help you obtain the information needed to ask sound questions and make a responsible decision.
Preparing for disruptive situations
The atmosphere in the team matters first. Many developers prefer stability and need time to adjust to abrupt changes.
When a new requirement appears, do not immediately rush to demand its implementation. First analyse what the request means, how critical it is and whether it can wait without harming the result. Unnecessary interruption can damage other work that is no less important.
If a change is genuinely urgent, explain its importance in an accessible way. Help people absorb the change with as little avoidable stress as possible. Do not spread your own frustration: show the team that you accept the decision as its leader and that the situation remains under control.
Disruptions occur in every project; no project develops under perfect conditions. In one client project, the entire management team was replaced when about two thirds of the work had been completed. Product priorities changed, and the delivery team was moved to a different area of work. The new managers used another approach and different requirements for task definition, so the project manager had to agree the requirements again.
Tasks were being issued verbally, while success criteria and baseline requirements were not documented on time. Work then had to be redone: the team delivered what it had understood rather than what was actually needed. Only long negotiations eventually produced a shared understanding.
I remembered that case for life and drew a firm conclusion: requirements must always be recorded, however urgent a launch or task may seem.
Recognising potential in a junior specialist
I have long noticed that many people first enter IT because they expect financial success. During training, some become genuinely interested in creative and demanding work, while many others move into different professions.
Among those who remain and complete their studies, a manager still needs to distinguish empty confidence from real potential. A practical assignment during the interview helps. It should be combined with an assessment of the candidate’s willingness to develop, accept new information and keep learning.
The exercise should contain both difficult cases and simple routine tasks. This makes it easier to see how deeply the candidate engages with the process and whether their working rhythm is compatible with the team.
Working as a team
Once a person has joined and is contributing, a manager still cannot relax. A strong specialist is difficult to retain with money alone. Without interesting work and a responsive team, an IT professional will eventually look elsewhere.
The project manager is responsible for creating a healthy working climate in which people feel comfortable. A cohesive team reduces avoidable turnover and makes collaboration more dependable.
Communication with colleagues requires balance. If the project manager’s view is consistently ignored, something is wrong: the manager must build legitimate authority and act as a leader for the team.
One-to-one meetings help maintain discipline and connection by creating space to discuss a person’s plans, mood and obstacles. Informal gatherings can also support balance—for example, sharing pizza on a Friday.
A small recommendation: give every team activity an educational element. Study something current in the industry or discuss an interesting case together. In addition to retrospectives, run short learning sessions. A frontend developer might present how browser HTML is processed, while a salesperson or account manager might explain a useful approach to persuading customers.
Such exchanges are an excellent way to discover improvements in collaboration. Another option is to watch a worthwhile TED talk or another professional session together and then work through how its idea could apply to a product or initiative.
What to do when conflict occurs
I support direct communication. When conflict appears, first speak to the participants one to one. If the disagreement has become public and affected the group, bring the relevant people together and address it openly.
In one of my projects, a conflict between two programmers became personal and seriously interfered with teamwork. Identifying the source and discussing it did not resolve the situation, so both people had to be removed from the project team before the conflict spread further. Several sprints were delayed, but the rest of the group soon became more focused and the project was ultimately delivered successfully.
In another case, a team member concluded that the new project manager was weak and that he could do the job better. The situation was gradually becoming a conflict. A firm conversation and an explicit discussion of the rules with both people worked: within a week the tension had subsided and the team became much more effective.
Resolving communication problems in a project team
Consider a common situation: developers cannot understand what an account manager expects. The account manager says that the customer’s website needs a modal window, but the task does not explain its behaviour, content, states or acceptance criteria. Developers need a properly described assignment; otherwise the customer receives not what was intended, but what the programmer inferred.
This is where the project manager steps in. They clarify the details needed by the customer, account manager and developer, then describe the task precisely. Deadlines and responsible people are assigned, along with any dependencies and acceptance conditions.
The project manager’s work does not end when the task is written. They remain responsible for monitoring time, resolving issues that emerge during delivery and, depending on the project and company, organising decision meetings, reviews and workshops.
Gender balance in IT
When I was studying programming and beginning my career, women programmers and project managers were rare and sometimes entirely absent from a team. This has changed considerably. Today many women work as developers and project managers, performing no worse than men and often examining details with exceptional care.
Candidates should be assessed on competence, potential and behaviour, regardless of gender. Stereotypes only narrow the talent pool and weaken hiring decisions.
Using the project method in everyday life
I follow the principle that much of life can be viewed as a series of projects: education, renovation, travel and celebrations. A project approach helps with decisions, risk assessment and budgeting.
For me, tasks are a path to progress and results. But apparent multitasking is misleading. If you believe that you are doing five tasks at the same moment, in practice you are not properly doing any of them. At a given instant, attention is on one task; after completing a step, you switch to another.
I use two Scrum-style boards with three columns—To Do, In Progress and Done:
- one for work;
- one for personal tasks outside work.
I take one task and do not begin another until the current task or a meaningful part of it is complete. This produces deeper work. Moving tasks one by one into “Done” also creates a much stronger sense of progress and is less psychologically exhausting.
There is another simple practice: every day, or once every few days, spend 15–20 minutes planning the next one to three days. Write down longer-term goals as well, divide them into small tasks and schedule those smaller actions.
To organise goals and tasks, I recommend practical checklists and planners such as “Goals using SMARTER,” “My tasks,” “A successful month” and “Achievement calendar.” They help not only to structure work, but also to make progress visible in both professional and personal life. They are available in the checklists and worksheets section.
