62

I am a tech lead on a project with a Project Manager (PM) and a developer team. The leadership frequently stresses that I'm responsible for the project success.

I am discovering that I have to organize and coordinate because otherwise I can't lead the team technically. E.g. user stories aren't documented the way they should, team members don't come to sprint meetings, etc. Risks aren't communicated or tackled. Basically, any work, technical or not, is very difficult or impossible to complete.

I'm tired of doing PM's job and yet if I stop, the project will probably fail. I did bring it up to my manager, but he ignored it. What should I say to make sure I'm not blamed for the possible disaster?

3
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – motosubatsu
    Jul 15 at 15:12
  • Many sentences here have multiple black/white words - "can't, aren't, don't, aren't, any work, impossible". While using these words is helpful in stressing your situation to others, in reality, most of them are likely tempered by 'in my consider opinion based on my experience and understanding of good practices" along with "i frequently see". Others may come to different conclusions about the severity of, or in some cases even need for, certain activities. Most people care and want to do a good job so I would ask more about what the underlying issues are that may be affecting them personally. Jul 16 at 18:00
  • Remember also that everyone has a burden to carry. Jul 16 at 18:00
127

I'm tired of doing PM's job and yet if I stop, the project will probably fail.

Then let it fail. As soon as possible. By doing other people's jobs, you are becoming an enabler. You enable them to do a bad job and not get any feedback on it. And on a personal level, if you are doing two people's jobs, you are twice as likely to be made the scapegoat, because no matter what fails first in the project, it was you who worked on it. And nobody will care if it should have been you. It was you.

Document everything that is missing to do your job properly.

Warn about anything you see that would hinder the projects success.

Only if something fails, the PM will get the feedback from their boss that they need to do a better job. As long as you cover for them, they will never get this feedback and they will never improve.

So make sure something fails early enough to change things and bring the project back on track.

The worst thing you could do is cover for them and do their job until it's no longer possible for you, because then it will be too late to change anything and it will be seen as your fault. It does not matter whether it's the PMs job to write user stories, once you wrote the first batch, nobody will even remember it should be the PMs job and when you tell people that you cannot write more and do your own job, too, it sounds like your failure.

Don't do that to the project and don't do that to yourself.

Failure is important feedback. People and Organizations learn through failure. Do not cover it up. It deprives everybody of feedback and opportunities for improvement. Fail early and openly. Then suggest improvements and help fix it.

9
  • 47
    Well, I would not escalate it. Or only to the level that you got orders from. Whoever told you to make this project a success, report to them what you need and that it's currently missing and that project success is in danger. Do not go over their head. If they don't provide, let them fail, don't do their job on top of yours.
    – nvoigt
    Jul 13 at 11:47
  • 11
    I would add to @nvoigt to make sure that all your escalations are in writing with timestamps, like in an email. Archive them. All the typical CYA documentation to show that you did blow the whistle, and nothing was done about it. Jul 14 at 0:59
  • 9
    And if you have in-person conversations, just recap them, in an email. "Just to re-iterate our conversation earlier, we discussed how X needs to happen for the team to work effectively..." stuff like that. CC your manager, so that if it's your problem, it becomes their problem. Jul 14 at 1:04
  • 14
    Just to reiterate: Document, document, DOCUMENT all communication in writing and be very explicit about what you and your team are waiting for. Be sure to CC your manager so somebody can't come back later and say "But you didn't let anybody know".
    – FreeMan
    Jul 14 at 11:29
  • 4
    I find this answer to be extremely passive and aggressive (passive aggressive?) For example, what if nothing fails immediately, but continues indefinitely? It should be stressed this approach will work in some company cultures but will utterly backfire in others. If OP does not have a good feel for the culture I would strongly advise against this approach. Instead, I believe the correct approach is already summarized in a comment above: " Are you able to fire / reallocate the PM? If not, then you're not really responsible, but only a scapegoat."
    – ldog
    Jul 14 at 19:23
77

Go talk to(!) that project manager. Go talk to your manager. Maybe ask all three of you to meet in your manager's office. Once there, tell them your concerns.

And then ... l i s t e n .

Don't say anything. You've had your five minutes to say your piece, now give each of them equal chance to say theirs. Don't spend that time formulating your rebuttal. Instead, listen attentively, and be prepared to learn something you hadn't thought about until then. All three of you are "stakeholders." All of you are being paid to have the common purpose of achieving the project's success. Communication between the three has obviously broken down somehow.

1
  • 8
    This. Communication is the key. Just make sure to communicate clearly in a way that the others can't misunderstand.
    – Polygorial
    Jul 13 at 21:45
31

I do not recommend you let the project fail, to teach a lesson or whatever.

People have the misguided assumption that those that are punished for projects failing are always the people that are to blame. It's like they've never worked in the real world.

In addition, the fail fast mentality that some people think are broadly applicable is just simply wrong. Some failures can cause severe professional damage.

Because you've been charged with the projects success, you need to highlight problems to the person who has given you this responsibility. It looks like this isn't your manager.

If your manager is not giving you appropriate support, you should consider complaining to the HR team. They may not understand the context of the issue, but they can make your boss elaborate on why he is refusing to support you.

HR are generally interested in communication failures between employees of an organisation which would cause damage to the organisation.

I would generally not encourage people to go over their boss's head, but as the leadership is interfacing with you directly, it seems in this instance it would be suitable to go to them too if you are not getting resolution of issues.

13
  • 1
    Not sure I agree with you that the people suggesting to let if fail don't live in the real world. They may have just accepted that sometimes employees are in a no win situations in the real world. Where the supervisors/bosses/HR/etc are unwilling to help. The rest of the other answers did encourage communication, and cya actions that may mitigate the problmle , a chat HR may also help. I think the encouragement to let it fail is so the person doesn't get overly stressed, work unpaid overtime, or something like that.
    – Zoredache
    Jul 13 at 22:44
  • 5
    @GregoryCurrie Keep in mind that "fail fast" isn't usually about the project as a whole, but instead about the sprints or smaller bits of it. It is about putting the broken piece in evidence, fixing or replacing it, then trying again. It isn't "fail fast and give up".
    – T. Sar
    Jul 14 at 11:28
  • 6
    @GregoryCurrie No, it isn't. Nobody sells it as "fail fast and give up". Failing fast is always part of the concept of learning and iterating your process. The principle can't pay for the ignorance of its users.
    – T. Sar
    Jul 14 at 12:01
  • 5
    @GregoryCurrie You are missing the point over the overall idea of fail fast. I'll refer you to this Forbes article on the overall idea. It isn't the best, but it helps understanding the concept and why it helps nowadays.
    – T. Sar
    Jul 14 at 13:06
  • 6
    I agree with everything except the go to HR, to add more moving parts to the project you're both losing focus and assuming that HR is going to give a meaningful contribute.
    – DrDread
    Jul 14 at 13:24
7

Document, document, document. Put everything in writing and keep copies.

If you do not have hire/fire authority, then you are not responsible for the project success. That is the responsibility of the team management. Your job is simply to give them the information they need to make the hiring decisions.

No matter what happens, you might be blamed. That is just part of life. But, you can document so that when the blame comes, you have the documentation to show that you warned people before hand.

What are you responsible for? Your own health. Take enough time to keep yourself healthy. In any job, there are far more things to be done than can be done without killing yourself. So, make a list of the 20 things that have to be done and only work on the top five most important. When people ask about the others, point to you doing the most important. Let the rest of the tasks fail. If management says they are important, they can hire to get them done.

5

All the answers so far, are good ones. But they are not put together as I would suggest.

@nvoigt is spot on,pretty much. Do not be an enabler. Do not prevent feedback arising. Do not take on every job that someone else abdicates, as your job. Do not paper over cracks, or act in a way that you cannot sustain, if it becomes "the normal". Even for best intentions.

But that isn't the whole of the answer, for me.

You have two priorities. First, to attempt to get this fixed, so the problem is resolved. Second as you rightly say, not to get blamed totally, if it isn't resolved.

That project manager is answerable to someone. That person needs to know what's going on. The project as a whole is answerable to someone (above or beyond you). That person needs to know what's going on.

Those are the people who have decision making power over the problem. Of they don't, they are still the people who decide whether to escalate it or not.

Your job is to do your job. If your job is perceived as making the project succeed, then you need the right tools and they need to work well. A productive effective PM is such a tool. If secretly, you don't have one, and that's impacting the project, it isn't your decision what should happen. Managers may decide to talk to them, fire them, support them, change peoples tasks or roles, formally give you more control, or indeed (as sadly often happens) ignore it until it goes boom, then wonder what happened. Which of those is right, is not your executive role to decide.

Your job therefore is to make those 1 or 2 individuals aware, that your PM is not effective, and its impacting the project. Present your documented evidence of the issue. Then ask them what they would like you to do. Then do it.

Its for that reason that nvoigt and David R, are both right. Document it. Both to cover yourself, and to present strongly about the issue. What you document are incidents that show the problem behaviour, and the impact on the project - which should not be just "so I did their job for them". Consider what motivates those people - deadlines, profit, team motivation, customer quality, whatever it is. Make sure your presentation isn't about poor you. Its about how there is a problem, and it's impacting the things they care about - or risks doing so. If you can, come with 2 solutions and their cost/impact/feasibility, to help solve it. Imagine they asked "So what do you want" or "What do you think we should do".

Additionally, allow the failure to happen. If they don't project manage, there will be an impact. Document it. Your role is tech lead. "Our teams PM isn't PMing, and this was today's fallout. Its not the first time, by a long way. We need this solved,or we.risk missing deadlines/profit/bug costs/reputation/whatever." If team members need tasks, or whatever the PMs job is, tell them to talk to the PM, sorry, that's his job, mine is tech lead. Tough, and people will push back, but do it anyway. Set boundaries! A key skill.

Do not take it to HR directly. Again, that's not your call. You have been given a job to do, by someone in tech, the PM has been given their job to do by someone in tech, the issue is tech management of its team. The person/s responsible, their call is whether or not to go outside tech. The only exception I can see is if the top person in tech isn't doing their job, in which case ask to meet someone even higher - and be very very sure of your ground. But HR is still the wrong place for your angle on the PM, which is about tech tasks not done, not their employment status.

Also, as Mike Robinson says, talk to the PM - and listen! If you escalate this, and never talked or listened to them, they will feel strongly that you were high handed. Give them a chance to explain the issue. You depend on them, what went on when X happened? And Y? Use that and think hard what to make of it. It may change nothing. It may influence what you present as "the problem" or "my recommended solution/s", or how you shade them.

Last look up the many excellent posts here about how to document a problem, raise it, and protect yourself. Put things in email, and after meetings email thanking them for their time, and noting the outcomes or what they said that's important.

If they said something that seems a problem, "I understand you feel this is not an issue, and do not plan to take action. I am concerned this is underestimating the impact on the team, its work and our deadlines, and our efficiency. I draw your attention to the following impacts I mentioned at our meeting, that have already arisen. Before dropping it, I'd like to check for my own professional certainty, are you sure that you wish me to do nothing, and that the situation is to be left as it is?" Or wording like that. Document that its a concern to you, but that having raised it, you defer to their decision. Document so that both parts are clear - that you definitely raised it, and explained the effect, and they definitely made a decision that you followed.

Last, if they imply or say that you need to do both your job and someone else's (or part of someone else's), then of course, you are only one person. If you take on another half role, then your designated work will take twice as long. Again, that's their choice, if you feel it will impact your work, then same as above. "I understand that you feel I can fit project management into my workload. I'm not comfortable that this can be done without considerable impact to my own work - which as we discussed is a full workload in itself. I can do either my own work 100%, or my work to a lesser extent and part of someone elses - which I may also be less well trained for. If its more important to cover for project management at a cost to my own workload, then I hope this will be speedily resolved so that my own work suffers for as short a time as possible. I would like to review the situation in a month if that's the case, to assess if it's working acceptably." Then document if it isn't, or the impacts. Do not be tempted to be pressured to compensate by extra unpaid hours.

0

My role isn't focused on organization or coordination, but I am considered the most senior team member, so the leadership frequently stresses that I'm responsible for the project success.

Personally after reading the above bit I'm left surprised, in a really bad way. I think you described the issue here, because as yourself have said: you should not have coordinative roles in the project. Yet you appear to be doing that. Stop immediately, this is a clear boundary violation. There's no way you'd be held responsible for the project's success only because you're "senior". That's utter nonsense, from a logical point of view. You're not an octopus. You've got specific roles on a project, and you stick to them by written agreement. This is clearly a problem for upper management that apparently wants to turn a blind eye to it, because:

I did bring it up to my manager, but he ignored it.

This is slimy at best. Your manager should have helped you clarify his expectations, but YOU on the other hand, should have told him your boundaries first, instead of getting your hands in roles outside your focus. This is irrespective of how good you may be, that's not the issue here.

In conclusion, I strongly suggest to stick to your duty roles, and raise your voice (figuratively) with your manager. You're being mistreated and overworked beyond your roles, as I understand from your question.

1
  • I strongly disagree with 'There's no way you'd be held responsible for the project's success only because you're "senior".' I don't think there is any way we can say that with utter confidence. These things happen, and happen often, in many organizations, whether or not it is logical.
    – Basya
    Jul 16 at 12:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .