Something random the other day make me think of an old email I’ve kept stuck in the archive folder, and I thought people might find it amusing. Many years ago, a coworker sent around an entirely tongue-in-cheek email on “How to be a PM” in which he covered the many underhanded ways that a Program Manager could get a developer to do their bidding (not surprisingly, the author was a PM). So I crafted a response on how, as a developer, to deal with the underhanded tricks that PMs can play. Here it is for your enjoyment…
(Obligitory caveat: Remember, this is just a humor piece. No one I’ve ever known at Microsoft has ever done anything like this. It’s all entirely theoretical. Caveat emptor. Your mileage may vary. No warranties express or implied.)
How to be a PM (and how to deal with PMs)
1. Always ask for more than you want, a ratio of one bogus request for every 4 or 5 real requests is usually a good ratio. Too many bogus requests and you’ll be laughed at (even more than usual), too few and something you really want might get cut. Act depressed when the bogus feature is cut.
Dev response: Always overestimate the time it will take you to do a task by at least a factor of two or three. No task takes less than half a day, even if it will take you five minutes. If there’s something you really don’t want to do because it’s hard or you don’t like the PM, start your estimate at a week. If the PM argues with you, keep saying “Oh, I forgot about case x.” and add a week to your estimate. Repeat until the PM stops arguing.
Alternate Dev passive-agressive response: Do as many of the bogus requests as possible and tell as many people about them as possible. When people ask “who told you to do such a stupid thing?” indicate the PM. Soon everyone will be laughing about the PM behind their back.
2. Divide the feature as many different ways as you can to get the lowest possible dev estimate. For example, if a, b, c, d, and e are the parts of the feature be prepared with options like “What if we do a, c, and part of d?” Initially developers will put up defenses like “doing c requires that we do b.” Pause thoughtfully and give them another combination. If you’re determined eventually you will win.
Dev response: First, make sure that no combination of parts adds up to anything less than a week and a half. Figure out the one part of the feature that is absolutely critial (usually a), but smarter PMs will make it c) or d)) and estimate it at a week. As above, keep upping estimate until PM leaves.
3. Ask another developer. While it’s good to get a second opinion, feel free to go for a 3rd or a 4th. The more times you ask the better chance for that bold “I can do that in half a day” estimate. Sometimes called the Fru method [Ed note: named after a PM on the team at the time].
Dev response: None really necessary. If the PM comes back and says “y says it should only take half a day,” then just reply “fine, then y can do it.” Problem solved.
4. Many different ways exist to get tasks to developers, use them all. If you stick to one it’s too easy for them to develop a good defense. Add things to the spec, push something through [the design change process], enter a bug that doesn’t actually state the problem but exposes it in such a way that the developer will find it, have someone else enter the bug, ask a 3rd party to pretend they had the idea for the new feature (most effective when it comes from outside the company through a manager type but that’s harder to orchestrate), get another product to do the same feature (good trick within [the org I was in at the time]). In short, be creative as you make work for other people.
Dev response: As much as possible, don’t play their silly games. Your single most potent weapon (if you haven’t figured it out by now) is your estimation as to how much time it would take to do something. Most PMs have no clue how much time it takes to do anything, so you can say the most outlandish things and they will believe you. For example, PM: “Dev, I need to you change the menu item “Exit” to “Quit”.” Dev: “I’m sorry, but there’s a lot of code that depends on that, so it’ll take me at least a week to change it and it will probably completely destabilize the product.” PM: “Oh, I see. But y said that he could do it in five minutes.” Dev: “Well, then, have y do it.” OR Dev: “Unfortunatly, y doesn’t completely understand the complexities of our menu system, so his estimate is wrong.”
5. Only spec 75% of the feature. All developers will finish the last 25% of the feature even if they don’t have the time in the schedule.
Dev response: First of all, since usually PMs really don’t understand what they’re asking for anyway, always do exactly what is in the spec because nothing you do is going to be right anyway — at least this way you can say “but it’s in the spec!” and make the PM look like an idiot. If the spec is unclear, don’t ask the PM about it, just interpret it in a way that is the easiest for you, even if it makes no sense. If you don’t like part of the spec, ignore it and later say “I must have been working off an earlier version of the spec that didn’t have that feature in it.” If the PM challenges you about something they say was in the spec, imply that if they’d written the spec properly you would have understood what they wanted.
6. Drug your developers on candy and other treats.
Dev response: If a PM really wants a feature, say “I’ll do it if you give me a six-pack of beer.” If the PM readily agrees, ask for a case instead.
7. When describing new features, write up their descriptions as if other new features already exist. If the developer gets half way into feature A and realizes that they need feature B to complete it chances of accepting feature B go up.
Dev response: If you fall for this, you get what you deserve.