Manager blaming team for failure, how to counter

Question

I'm part of an internal software development team at a retail business. We're currently working on a major project and in all likelihood it's going to fail. It's pretty much over at this point.

Over the last two years this will be the second high profile failure the team has had, not only failure in terms of failing to delivery what was asked but in terms of delivering anything of value at all. We haven't done anything else in that time.

Several members of the development team have found out from various people around the business that the team's manager, who has only been a development manager for these past two years, is now blaming this failure on the development team to the rest of the management, including the managing director.

This is a complete mischaracterization of why this and previous projects have failed. The reasons for failure have all been due to management. These are a list of reasons that I think caused the failure of projects.

1. Business systems have been chosen by management with no thought of how/if we can integrate with them. They do not suit how the business operates and do not fit our current workflows. The rest of the business is unwilling to change workflow to fit the new systems

2. All advice from the team is ignored by the development manger. Every single senior member of the team has said from the moment the project started that it was completely unfeasible, there was simply not a technical solution that we could have implemented that would have solved the limitations of the chosen platform and enabled the business to operate as it wanted. Not only were advice and warnings ignored but were actively persecuted; people that raised warnings were punished.

3. All warnings were never surfaced beyond our team. No other member of the management team know about the serious short comings of the project. There is zero transparency in our team. Things are reported externally as being okay and on schedule despite us internally knowing for weeks that things are never going to work. External departments only know a few days in advance of missed deadlines despite us being able to warn them well in advance.

4. Project and team management is dysfunctional and outright incompetent. Tasks are vague and unspecified. Critical decisions that are needed are not taken until the last minute, which creates additional work and serious problems with existing assumed solutions. Edge cases are ignored when inconvenient. All work is done by a few core team members, so while we are all supposed to be busy, it's a situation where a few are busy and others have to keep asking for stuff to do. Communication is terrible; people that have raised problems are excluded from calls and meetings so they don't know what's going on and can't contribute productively. Knowledge of the problems and proposed solutions has been treated as top secret and kept from most people.

5. Arbitrary deadlines that are completely unmoored from the work that needs to be done.

The development team have been working to breaking point, working extra including some weekends, to try to create a solution. The failure is not due to our lack of commitment or technical ability.

How can we counter being blamed for this failure? We are thinking about collectively asking for a meeting with the managing director to put across our concerns. Is this a good idea? What would be the best way to approach a meeting like that?

Answer 1

Good managers know that blame always belongs to leadership — bad managers try to shift blame away from themselves. It makes it very easy to see because the only managers blaming anyone are bad managers.

So there are two scenarios then:

1. You upper management is good - they will see this for what it is easily and know your manager is no good. They’ll do something or nothing to him, and you and your team will be left alone and not held accountable.
2. Your upper management is bad - they will blame either your boss or your team, or both, and would have taken credit for your success had you managed to deliver despite them.

In scenario 1, you're good. In scenario 2, you were never good and should leave if at all possible.

Your managers behavior is unimportant, your upper management’s reaction to his behavior is what is important.

Answer 2

Ask for a project retrospective meeting so that you can analyze the failure of the project with your manager and senior management, so that you can learn lessons from your collective failures in order to determine what needs to change so that you don't all fail a third time. Bring any evidence you have of the points you made in the OP with you, so that you can back up the points you're making.

Additionally, you may want to do some research into Agile project management, and maybe use this an opportunity to lobby for your business to become Agile. There has been research that has shown that there is a significantly higher chance for project failure under "traditional" project management structures than under Agile structures, and the Agile process was designed to help address many of the issues you were having.

Answer 3

Direct Answers followed by some more general advice:

How can we counter being blamed for this failure? We are thinking about collectively asking for a meeting with the managing director to put across our concerns. Is this a good idea? What would be the best way to approach a meeting like that?

• Countering it is documentation, see #4
• You can do that, it will be powerful. Be very aware that it is a well known habit of coworkers to back down when in discussions with management that "Well, they're not that bad. Ask anyone who has gone to bat for a complaining coworker. People like to bitch.
• No, it's not a good idea unless you get everyone's grievances in writing, and signed by them. The "leader" of the group will be terminated as a show of what happens when you try to take action. No one should be seen as the leader.
• You should request the meeting in writing with the signed grievance document. Don't present it yourself as the leader. Essentially, you're acting like a union without being in a union. Any acts that aren't in solidarity will be capitalized on.

General Advice

1. First and foremost, don't work for free. Those weekends? 20% reduction in pay for that week. 12 hour day when you get paid for 8? 50% reduction in pay for that day. The rewards won't come to you unless you've got significant equity, and if rewards do come, you're most likely to receive a fraction of what you would have received had you been paid for all of that extra time. Your contract may say "includes overtime" with your salary, but that is generally seen as "within reason", and is generally subject to averaging rules (Canada, but many provinces have removed tech workers from this due to business assocaition lobbying to abuse workers). If they abuse these clauses, find other work. Senior devs are in demand.
2. The manager is bad, but nothing they did looks like they did anything that wasn't their responsibility. They go against your advice on tech stack? Deal with it. It wasn't your decision to make. Timelines? Not your problem to make them. You do the best you can against the tasks assigned. Setting reasonable deadlines in their responsibility. What you don't do is cover for them. Don't do extra work that meets their insane deadlines, it just makes them look like incredible motivators who can deliver when no one else could. Let them twist in the wind. Most companies won't care if you burn out. They'll just roll you over and replace you.
3. Do look for other work or another team to work with. Languishing under a shitty manager is great for that feeling of comradery, but work friends are work friends. Unless you break through those barriers in to true friendship, don't expect much backup if you attempt to stage a revolt.
4. Very important use your ticketing system/record system that the manager can't modify willy-nilly in order to track things like requests for information/clarity, work being done, estimates being made and discussed, requirements being specified, timelines being discussed (and what people's comments were). Eventually, you'll be able to point all of these things out when the hammer starts to fall. You and your team will be protected by your diligence, and your manager will be seen for a fool.