This text was originally published on my blog in Polish 🇵🇱 "Źle zarządzany projekt IT – to nie Twoja odpowiedzialność" (if you have any comments, please leave it bellow! thank you in advance)
Poorly managed IT project – it's not your responsibility
..unless you are the Project Manager, Product Manager, Product Owner, etc. 😉 In other words, if you're not the project manager, then stop taking on responsibility that isn't yours.
Lately, on social medias, I've been reading a lot of posts about being overworked in projects, taking overtime, delivering something that was sold, the business accepted, the client expects, and the developer has to conjure up. Sometimes that's how it looks, and there's nothing we can do about it.
Is it really true that we, as a dev team, can't do anything?
As a team that delivers the solution and is responsible for it from an engineering perspective, we have the right and even the obligation to inform what is possible to achieve within the given timeframe.
Of course, in an ideal world, the team should estimate the tasks and provide the delivery time. But few of us live in an ideal world.
Often, even in a well-managed project, there comes a time when the business wants something "right now," "yesterday," or in a more optimistic scenario: someone non-technical has estimated the delivery time without asking the developers for their opinion and comes with the information – "this needs to be done – when? – for next quarter."
Sounds like a lot of time?
As always: it depends…
It depends on what needs to be delivered.
- A new landing page, a small SPA (Single Page Application) on a ready framework – sure.
- Rebuilding a site with a 10-year history and data migration… hmm, not necessarily.
That's why it's important for a dev team to be aware of their role and communicate what is realistically achievable in the given time.
One could argue that the role of a programmer or engineer is not limited to coding but also involves active participation in the life of the project. Ultimately, it's our ability to communicate clearly that determines whether we can avoid overwork and frustration in the project.
However, often the decision is made outside the development team.
At the same time, members of the development team often take on the responsibility or have the responsibility thrust upon them for the project's shortcomings.
Nevertheless, it's important to understand the limits of this responsibility.
Are you not a PM, PMO, or PO? Then why should you bear the burden that is not yours to carry?
Many people forget to ask themselves this question.
Worse, they accumulate frustrations from the failure of projects. Often projects that were doomed from the start (I mean, of course, failure in terms of delivery time 😉).
No matter how much we want our project to succeed. Regardless of our level of advancement, degree of experience, and position. It is important to remember common sense and our own limits. Working overtime, stressful deadlines, attempts to deliver the impossible – all this can do more harm than good. Both for the project and for our own health.
What can we do when it's not too late yet?
First of all: communication
I'll repeat myself, but communication is essential for understanding expectations and realistic possibilities. An open conversation with the project manager, presenting realistic time estimates, as well as indicating potential problems and challenges, is fundamental. These matters cannot be left to the last moment, hoping that things will somehow work out. Proactivity and honesty in communication. Miracles won't happen, but it's also about being honest with ourselves.
Second, education
Sometimes project managers or clients do not fully understand the technical aspects of the project. It's our role, as experts, to explain why certain solutions require more time, and why some changes can be costly or risky. Educating others about our work not only builds mutual respect but also helps in better planning and managing expectations.
Finally: assertiveness
The art of saying "no" or "this is impossible in the given timeframe" is not a sign of weakness or lack of commitment. It's a sign of professionalism and a realistic approach to the project. Not every request or requirement is realistic, and it's our job to ensure that the project is carried out in a way that is both feasible and does not harm the team or leave a problem for future generations.
Management is a separate skill. The team works towards success, and each team member has their role and responsibility.
We did what we could – we communicated the problems, explained where the risks come from, and said that the expected solution is not achievable in the allocated time.
We go back to our work, not taking on excessive burdens. Ultimately, if the above efforts did not help, it is no longer our responsibility.
Top comments (0)