Ask Slashdot: How To Gently Keep Management From Wrecking a Project? 276
New submitter miserly_content writes "I work in a large, hierarchical technology company. I have been developing technical specs for a new strategic and challenging software project, and the project is slowly gathering steam and support. This is already a career building success for me, and everyone acknowledges my technical capabilities. But the program manager is an MBA-type, and wants to bring in new multiple team leaders and consultants. This is not really a surprise, but I feel we are sliding towards a too-many-chiefs-too-few-indians scenario, especially at this early stage. How can I pitch upper management about this issue, without appearing selfish or disruptive? What positive approach can I try with the PM, with whom I have a good working relationship?"
Specs are career building? (Score:5, Interesting)
WTF? I have a distinct feeling you think far more of yourself than you are actually worth. Gathering specs makes a career now? I don't think so.
Perhaps you don't actually know as much as you think you do and someone else realizes the project may be a fuckton bigger than you realize?
The fact that you're asking 'how do I play well with others' on slashdot leads me to believe you're just a young whipper-snapper that doesnt' really realize how small of a part you have to play.
You certainly are arrogant enough.
QA budget suckers (Score:5, Interesting)
Years ago I was happily working on a project where I basically dealt with the client. But our QA department just lost a big contract and saw my good sized budget and weaseled in. The head of the QA department did his damnedest to get more and more people onto the project and then started communicating with the client which somehow was being then communicated to me as we need more testing. So after a few weeks I was having to deal with 5 QA people, a QA manager, and the client. Productivity dropped like a stone. So I met on the side with the client who demanded that they approve any billable time for any employee ahead of time. So the QA manager would send in a huge complicated (30 pages) request for this and that and the client would send back a note, "At this time I will only accept billable time on programming, at the end of the project we will re-examine the need for QA." Then the next time the QA manager phoned him he answered the call with, "the time on this call had better not be billable."
A week later the QA manager had an all-hands-onboard management meeting where he demanded that all projects have a set minimum percentage of QA. This failed and he then layed off half of his QA staff.
The best part of all this is that I made some good money. The QA Manager was hired by a huge tech company (2000 bubble) and I played the options market to basically short the crap out of that company as he had been hired for a very senior position and my logic was that any company that could not filter out this waste product was doomed. Their share price went from $120 to around $10 in a couple of months and he basically moved there and was then laid off.
So insist on a single reporting person which will then result in your MBA type having to stack his MBA underling on top of you. This will be so obviously silly that it is doomed. If you do end up reporting to more than one person get the resume cooking as the stress of reporting to more than one person on a project is just not worth it. If you have 3 MBA types all piling on with their own perverse desires(TPA reports) then they will each demand 40 plust hours of work from you per week so either you will die trying to feed their stupid requests or you will fail and they will all sabotage you as they will need someone to blame and they are higher up the information food chain than you.
Bail. (Score:4, Interesting)
The company is hierarchical.
The PM fits the religion.
You do not.
You will not change their religion.
It will not get better.
Manure, lightly spread where needed, is the best fuel for growth and prosperity. Too much, too close together is just a heap of shit.
Consider the other side (Score:2, Interesting)
Sometimes there are more use cases, and more stakeholders, than you realize. Your skill as a technician doesn't automatically mean you know enough about the business needs to ensure that you meet them. The same can be true of technical needs, despite your skill and knowledge. I have worked with young developers who had an excellent core engine that they wrote in their spare time and were declaring ready for production, but upon review it became clear that there were a few serious security holes and also some scalability issues. It would have worked fine for the first few clients, but once the load increased we would have been up the creek without a paddle.
Maybe these are true of your project, and maybe they are not. But your manager, being not a technician himself, has no way of making this determination. The only way he can be sure that your project is actually production-ready is to solicit some involvement from other, already-proven technicians.
I understand how frustrating that can be, because I have exactly been there myself. And I have been on the other side of that table as well. As interested as you are in seeing your shining vision be made manifest your way, the fact is the business you want to serve absolutely must exercise due diligence on behalf of their clients. You must let your pride take second seat to that.
Re:About "M.B.A." (Score:5, Interesting)
Amen. Read Voltaire's Bastards [amazon.com]. I read it when it came out in the 90's, and over time I have become increasingly convinced of its accuracy. In essence, MBA's and their simplistic ideologies are driving our civilization into the ground.
First rule: (Score:3, Interesting)
1. Where possible NEVER reveal experimental failures to anyone. Ever.
Experimental failures are normal learning processes for developers that management nor marketing never understand.
You seem a bit naive (Score:3, Interesting)
Realize that humans MUST organize themselves into hierarchies, and that humans MUST hold and exercise power over others.
It is popular to imagine that a population of largely competent people, lacking in malice, can cooperate and thrive with very few (if any) rules or governance. The fact is, this works, but only when the population density is very low.
The reason is simple: humans experience a disutility of labor. Given the choice, humans would rather luxuriate than work. Without malice, humans will (when presented with the option) completely innocently avoid work, with little regard to the other humans who must now do that work.
Before you jump down my throat...yes, some humans are good at and enjoy specific types of work. But that does not change this principle. Also, there are some types of work (toilet-cleaning, for example) that nobody likes and that people will not do without sufficient incentive.
In a city, basically everyone wants to rise up and do the elegant fun interesting work that pays a lot, leaving others to do the mundane laborious work that everybody hates. And such a state is impossible: we can't all do the knowledge work. The greater set of our needs is for the dirty work.
Furthermore, the people relegated to doing this dirty work are generally the ones who lack the keenness of mind to avoid it, and as such they are completely reliant on others to organize their efforts. They need people to have power over them, or their efforts address needs that do not exist while failing to address the needs that do exist.
I could go on, but I won't bother. It should be clear that:
1) people must be made to do the work that everyone hates.
2) of all types of work, the efforts must be organized by people who have devoted their efforts at learning where the needs are.
for this, we need governance, both political and economic.
While it may seem petty for people to seek power for the sake of having power...the ones who are really good at it must be delivering something of value (otherwise their reign will be short-lived, and a more competent contender will arise to take their place).
Rant all you want, history has proven that this is how humans do things, and you are silly if you think this will change any time soon.
Re:Cheap Fast Good (Score:4, Interesting)
You can only get 2 of the 3 on any project.
I very much disagree. You usually get either all three (fast, cheap and good) or you get none of them. When a skilled individual or small team produces something quickly and within the budget, it is usually a clean, elegant solution. When a big mismanaged group delivers late and over-budget, the result is usually a bloated monstrosity.
Re:Don't go above your manager (Score:5, Interesting)
He was an incompetent jerk, to the point where the other managers refused to even talk to him. He screwed me out of a company-wide benefit ("summer hours"; half day off per week during summer) for no reason I could discern. He was so bad, if we passed in the hallway and he said "Hello", I would follow it up with an email explaining what happened so he couldn't lie about it later.
I put up with it as long as I could, and then I quit. At my exit interview, I calmly explained what had happened, and asked them not to take my word, but to ask everyone else about it.
Less than a week later, they fired him. The guard escorted him out, and someone else packed up his things to ship to him.
The best part was that my former coworkers had a going-away party in his honor (to which I was invited), but they didn't invite him.
Re:About "M.B.A." (Score:4, Interesting)
Their "A good manager can manage anything" is the equivalent of "A good developer can develop anything", it doesn't mean that everyone will be good at it, or even can be taught how to be good at it, or that they can do it without learning anything domain-specific. People who think they can simply because they have an MBA degree are typical examples of bad managers, and there's plenty of those just like there are plenty bad developers who somehow got a degree. Yes, you need a "tech hierarchy" from team leads to a chief architect - size depending on your product - that makes sure that everything fits together and that the product delivers the solution. The worst you can have is a PHB making tech decisions, the second worst thing is a developer promoted to manager who thinks that's his only - or even primary - job as a manager.
Managers are about people management, you have say 20 individuals that have their own personal wants and needs and motivations and personality quirks - and whatever else you might have to deal with. You want the to improve as individuals and also want them to work together as a group, trying to improve how they communicate, collaborate, make decisions and so on. You have to bring new people up to speed, handle transitions as people leave and keep it functioning well. And then there's communicating both up and down in the chain of command, not just relaying but trying to keep the demands reasonable both ways. Finally you often have to deal with external issues so it isn't wasting the team's time. Most of this is actually rather generic stuff no matter who you're managing, just like there's good software development practices there's good people management.
Personally, I've seen enough from management work that I've figured it's not for me. It doesn't mean I'm not fond of a good manager who tries to fight the good fight, and the qualities I look for typically change very little even if my job duties change a lot. In particular I don't expect my boss to be an expert in my field, he can't be clueless either but enough that he can understand a high level description of an issue and figure out how to deal with it - not necessarily how to solve it. And the essence of a poor manager doesn't change much either it's someone how drops all the crap from above on those under and cracks the whip harder, leaving you do deal with every problem yourself. Bad managers are just bad, good managers are good and sadly they follow Sturgeon's law.
Re:solve your problem small (Score:4, Interesting)
> You have to appeal to the PM's self interest.
You have to give him a duck.
Here's the lore of putting a "duck" in your software development:
This started as a piece of Interplay corporate lore. It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn't, they weren't adding value.
The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen's animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the "actual" animation.
Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, "that looks great. Just one thing - get rid of the duck."
This is on the Battle Chess Wikipedia page though:
The true story about the duck: It originated at Interplay before Battle Chess. It was a running joke that our Electronic Arts producer - who was fond of meddling while simultaneously being clueless about game design - needed to have his ego stroked by being channeled into harmless changes that made him feel empowered. There was no actual duck originally - that was just a metaphor for anything that could be used as a red herring to keep him distracted. Battle Chess never needed a duck since we jettisoned EA specifically because of the aforementioned (but not named) producer unintentionally convincing Interplay to go independent of EA (there were no outside influences to that needed subtle manipulation). But the duck lore had started and it remained something we constantly joked about and eventually began sneaking into the games. Why a duck? Hey, if it was good enough for Groucho and Chico...Two-Tonic Knight