How to Make the Dev Team Hate You!

W hat do you see in this  picture? Yeah, the two hate each other. Is this also happening in your team? As a project manager, do you know what make Dev teams hate you? Let's go through  the 10 tips.

1. Talk with the Dev team on upcoming product features only after the design team is done, without any input from engineering at all.
2. Hold the design team to a really low standard , and the programmers can handle the UI.
3. Do NOT write specifications. Make comments on the design and send them to the Dev team.
4. In the case you do write it, don’t bother with formatting and screenshots, or go over the specs with the programmers until they absolutely have to start work on the feature.
5. Ignore the estimation on features done by the Dev team and force them to a lower estimation.
6. Keep adding to the specs and design up until the last minute. If Dev team ask you to prioritize, refer to 7-9.
   

7. Do NOT prioritize features. Tell the Dev team “Just try to get it done”.

8. Once specifications are done, don’t check in . It is the Dev team’s problem now.
9. Do NOT do release readiness testing. It is QA’s problem now.
   
10. Say “You write in PHP? That’s not even a language!”

Find it hilarious? It could be really terrible in reality. Actually, it is not the role that developers hate but the poor  performance.

P roject managers take a few roles in company, which can vary based on how independently the people below you are able to work, how well they get along with each other, how overloaded they are with work, and other aspects of the organization itself.

If you can’t perform roles , you are probably going to come off as a bad manager, and your team are going to hate you. But don't panic, here are the advice from experienced PMs.

• The manager has to protect their teams from undue pressures from other in the company. This is easy to fail at, by:
• Saying “yes” to all requests for work from other departments
• Not trusting their work estimates
• Not scaling those estimates into realism — all coders have a scaling factor between what they think they can do, and what they actually can do, in a given amount of time
• Not saying “no” to stupid ideas

• The manager has to represent the interests of their team to the rest of the company. This is easy to fail at, by:
• Not obtaining necessary resources; this could be head count ; but for a coder, a lot of times, hardware
• Not pushing to satisfy organizational dependencies. For example, if you can’t move forward without another department doing their job, they are dragging you

There are certainly more to do to be a competent project managers, and the Dev team should behave and produce at the same time . Anyways, g ood luck with being a PM! Keep Calm and Scrum ON!