Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How To Gently Keep Management From Wrecking a Project?

Comments Filter:
  • by edmudama ( 155475 ) on Saturday December 22, 2012 @12:24PM (#42369561)

    In these situations, I think you have to solve this problem as small as possible, with the program manager themselves. Figure out what that person feels isn't being delivered or executed on, and make sure you address that manager's needs.

    Escalating around the chain of command doesn't usually work in these scenarios, especially if you're relatively new.

    • In these situations, I think you have to solve this problem as small as possible, with the program manager themselves.

      Exactly. If there's a good working relationship with the PM, an honest and open conversation with them about why these recommendations/decisions are being made is almost certainly the best place to start.

    • by beelsebob ( 529313 ) on Saturday December 22, 2012 @12:45PM (#42369755)

      Yep, this can be applied to almost all cases where you don't understand why someone is doing something, or why someone is arguing for something that you don't want.

      Rather than going to them and saying "don't do that, it's idiotic", go to them and find out *why* they want those things. Then explain the reasons you don't want them, and come to the solution that satisfies both sets of needs.

      It amazes me how few people are able to do this, and instead bang on and on about how their solution is the one true solution without ever understanding all the competing needs.

      • by rgbe ( 310525 ) on Saturday December 22, 2012 @01:27PM (#42370051)

        I agreed with all the parent posts. Don't escalate without having discussed it with the program manager.

        See it from their perspective, they also want what is best for the project. They want to ensure the project is on time and on budget... and a success. So you need to explain how your approach is better and how it will lead to a successful approach. A program manager will often do this because they don't understand the product/solution being developed. So explain what a good set up would be and why, and include examples of where this has worked for you before.

        Also be aware that you may not get your way. Create a strategy for this situation. Ensure that you are in a position lead the technical piece. Ensure you have your ass covered when the shit hits the fan due to the PMs approach by documenting your approach.

        First I would take the verbal approach with the PM. They may take a lot of talking to. Then if you think you have resistance follow up with and email. The email does not need to be pages, just short and sweet. Explain your position with 3 or 4 points, and how it would lead to a successful project.

        • by Anonymous Coward on Saturday December 22, 2012 @04:08PM (#42371113)

          Parent is close -- except for the assumption that the PM wants what's best for the project -- the PM wants what's best for the PM's career; one of your jobs is to figure out how to make success of the project support the PM's goals.

      • by Anonymous Coward on Saturday December 22, 2012 @01:39PM (#42370143)

        You're in a difficult situation. I tell you how we dealt with this scenario successfully in my organization. We had a project manager who I originally wanted to be closely involved in the production process only to realize he intended to take over the management of our entire program. Well, that wasn't going to happen because we owned the development part of the project and had no use for him.

        We stopped CC'ing him on all emails regarding the development project. Every time he had his name added to the CC list we removed it.

        He went to his bosses boss (my boss through a different chain of command) to complain. He looked petty. I explained to my boss that his role was to assist with projects once they were in the production phase. With this particular project we were working on development which was outside his purview of expertise - which he readily admitted because he was not an engineer. Including the PM in the process would just increase paperwork and increase costs with no value add. My boss agreed.

        He quit about two weeks later. Actually, he didn't even give notice. One day he just stopped showing up for work. Went to work for a competitor which is now bankrupt.

        Perhaps there's a strategy hidden in this story depending on your situation: pigeon hole him into a very confined domain where he can actually be helpful to the project. If his career aspirations and ego outweigh his ability he will leave soon.

      • by TaoPhoenix ( 980487 ) <> on Saturday December 22, 2012 @03:43PM (#42370955) Journal

        I'll say you had a good first phrase that can be useful.

        Managers rely on the tech team to know what not to do. The mistake in "don't do that, it's idiotic" is that the last word suddenly makes it Ad Hominem. It stops being informative and becomes an attack. "Don't do that, it (making up something here, don't hurt me) interferes with the nightly backup integrity which means you might not be able log onto the system at all if any other glitch happens" is informative. With a few minutes to think they can realize that's a Bad Thing. Bad Things cost money. So maybe a rule of thumb is to avoid Adverbs. If you find a sentence about to end in an Adverb, maybe replace it with an extended noun clause. I know, all fancy English grammar, but a Factoid is what it is, that's what the techies do. Adverbs are judgemental.

    • Escalating is probably not going to help, and in most likeliness will hurt your career at that company.

      1. This could be an opportunity for you to climb the ladder so to speak, even becoming one of the chiefs. At some point you'll need to angle things to become chiefs-of-chiefs between the other chiefs and your PM. However make sure the project can succeed with the setup, otherwise you'll get the blame.

      2. You could also try to stay an indian, but that might mean you get canned with the rest of the team if th

    • by Anonymous Coward

      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

    • by raymorris ( 2726007 ) on Saturday December 22, 2012 @02:07PM (#42370355) Journal
      I wish I had my mid points beach that I used yesterday because this is far more useful than any other comment. Until you understand his reasoning, not just hear it but understand it, the PM is probably doing the right thing. In other words, the OP is most likely wrong. Of two people disagree, there is a 50/50 chance each is wrong. Except here we have a programmer disagreeing with a project manager about project management. Most likely, the PM knows their job better than you do. (Just as the programmer knows their own job.) Until you truly understand what they are doing and why, and can then with full understanding disagree, you're just bring arrogant. Go talk to them. First understand them, then make your concerns clear.
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Invite your PM out for a coffee break or lunch break offsite once a week. You don't have to talk about work, but do talk about non technical interests and null value stuff like sports (Nothing from your personal life). Your PM does not understand the tech and cannot relate to you so you must give him/her a warm fuzzy feeling so he/she does not need to hire the security blanket (er team leaders and consultants).

    • Mod parent up. I never realized how much good a PM could do, until I worked with one that was good at his job.

      The PM should be the one to put the kaibash on the creeps, both management and feature.
  • CYA (Score:2, Insightful)

    by Anonymous Coward

    Your manager is covering his ass. Inserting layers of management between you and him so when/if things to go wrong, he can scapegoat consultants and team leaders.

    • by rtb61 ( 674572 )

      You also left out the bit where the manager takes credit for all the work done by consultants and team leaders while actually doing nothing much at all. Interfering with this will run you head first into corporate politics, likely the manager is far more competent at getting promoted than at actually doing anything, as such will seek revenge for upsetting the modus operandi, blame others for failure and take credit for all successes.

  • Do Nothing (Score:2, Insightful)

    by gigne ( 990887 )

    ot at the very least very little. Have a water cooler chat to the MBA type. Explain what you want.
    I know it is your baby and you don't want to lose it, but business is business. It will either work or it won't. No point making too much noise.

    • Honestly, it seems more like the OP and manager need to sit down and talk through the project plan and determine manpower needs for the project duration.

      Scaling up is hard, and you do need to get the sub-managers on board before you add worker-bees so the project objectives remain clearly communicated. Often the scale-up ramp is uncomfortable.

  • You can only get 2 of the 3 on any project. The more cooks in the kitchen, the less likely you will get the project done fast or cheap. Management should understand the value of meeting deadlines and budget. :)
    • Re:Cheap Fast Good (Score:4, Interesting)

      by ShanghaiBill ( 739463 ) * on Saturday December 22, 2012 @04:05PM (#42371099)

      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.

  •'s time to start pitching for jobs elsewhere while 'your' project still has the potential to be a raging success.
  • by drinkmoreyuengling ( 2768737 ) on Saturday December 22, 2012 @12:29PM (#42369605)
    One of the problems with taking your position is you might be wrong. I know it's popular on /. to trash anyone with a business degree as a know nothing douchebag, but sometimes perspective outside of the core engineering effort can pay dividends. Instead of trashing the guy and trying to go over his head to torpedo his job, try working with him. You might be surprised what happens if you take a constructive tone.
    • Re: (Score:3, Funny)

      by Alex Belits ( 437 ) *

      I know it's popular on /. to trash anyone with a business degree as a know nothing douchebag, but sometimes perspective outside of the core engineering effort can pay dividends.

      Managers who can't rise up by replacing ones above themselves, try to rise up by hiring more flunkies under themselves to crack the whip at. This is an equivalent of cancerous growth in organization, and the reason why middle management is often incompetent.

    • About "M.B.A." (Score:5, Insightful)

      by Anonymous Coward on Saturday December 22, 2012 @01:02PM (#42369887)

      MBA programs are full of pseudoscience and hard-science envy. Most of that social science crap is about dumbing-down things so that they nicely fit into a simpleton math theory. Worker qualification and experience cannot be "measured", so it is ignored. Workers are slaves who must be replaceable any time just like capital goods. MBA theory hates every expert who cannot be replaced quickly and cheaply, because it threatens the power position of the social science people.

      See the sorry state of the nation that invented "MBA". Compare that to a nation led by engineers which propelled itself from crapbin to #2 in 30 years time. See the sorry state of M$ and compare that to Google or Apple. A unique person like Steve Jobs does not fit in their dumb-down pseudo-science theories. "A good manager can manage anything" is their motto, because that is the basis of POWER. And that is what they want - power at all cost for THEM.

      Let's wait and see how the dominance of the social science crappers works out for the western world. So far, the future looks very dark with pitchforks, Guillotines and more on the horizon.

      • Re: (Score:2, Offtopic)

        by MightyYar ( 622222 )

        Jobs was very susceptible to pseudo-science. He even delayed his treatment due to it.

      • Re:About "M.B.A." (Score:5, Interesting)

        by catchblue22 ( 1004569 ) on Saturday December 22, 2012 @01:57PM (#42370289) Homepage

        Amen. Read Voltaire's Bastards []. 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.

      • I was drinking the cool-aid, until you mentioned Steve Jobs :)
        Not really an engineer, was he?
        • Re: (Score:2, Insightful)

          by Anonymous Coward

          No, Steve Jobs was no engineer - but he had vision, and knew how to get his engineers to buy into that vision.

          He was a lousy manager from Apple's inception, and it bit him in the ass. He had to learn how to manage effectively to get the results he wanted. And get them he did, so don't dismiss him lightly. He had qualities that were unique, valuable, and unquantifiable.

          The problem is, managers are not there to pull wheat from the chaff and elevate people to positions of power. They are there to keep people i

      • You seem a bit naive (Score:3, Interesting)

        by Anonymous Coward

        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

        • Re: (Score:3, Insightful)

          1) people must be made to do the work that everyone hates.

          And that's exactly the problem with MBA types. They see jobs that they have to force people to do. .So they have to find ways of enslaving people without calling it slavery. ( Cause we know slavery is bad, so if we engage in it we can't call it that.) Furthermore they have to make people who will do it-- ie a social class to enslave.

          Of course once they create the social class they have to find ways to keep the jobs around to employ these people they created to do the job in the first place!

          The economist or

      • Re:About "M.B.A." (Score:4, Interesting)

        by Kjella ( 173770 ) on Saturday December 22, 2012 @06:23PM (#42371785) Homepage

        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.

    • by Tyler Durden ( 136036 ) on Saturday December 22, 2012 @01:09PM (#42369923)

      Sorry, but I'm thinking that the subject line of your post is beyond the comprehension of the average Slashdot poster.

    • When someone's reaction to building software is "bring in new multiple team leaders and consultants" without input from the current tech lead, then, yes, they are a know nothing douchebag.

  • Your job is to promote your career, find a niche to do that in the new order. The exec is now working on getting his cred, and that means having more people to manage.
    • Re: (Score:3, Insightful)

      by tokencode ( 1952944 )
      This is right on point. Who cares as long as management is happy? One of the biggest mistakes developers can make is being too idealistic about a project. It's easy to get caught up in something you're developing but unless it's your company or you own the project, sometimes it's best just to do what is asked. If you know it will fail, just make sure you have a solution readily available when it does.
      • Fluidity is important. The OP made progress on their career by breaking technical ground, now the challenge is to become a valuable member of the team, communicating the key principles of the design work to date. "No question of technical skills" is code for "we don't want you managing."
  • by MichaelPenne ( 605299 ) on Saturday December 22, 2012 @12:39PM (#42369711) Homepage
    I like large projects to have their own business plan- with resource costs (staff, office, etc.), and budget, and expected operating margin for the project as the resulting product/products are sold. Ideally inclide marketing and sales commission costs. This is a big deal to developer, but one of the benefits is that one can show to upper mgt. The effects of overstaffing on the margins. Also a good business plan would include the reason for all project roles, for all the people on the project (since their salaries all subtract from the profit margin). Then with a formal plan its much harder for an inexperienced manager to pad the resources for some pointy haired reason of his/her own as he/she should need to justify the reduced margins, etc.
  • by Anonymous Coward on Saturday December 22, 2012 @12:41PM (#42369725)

    Does such a thing exist?

  • As A Boss... (Score:5, Insightful)

    by ios and web coder ( 2552484 ) on Saturday December 22, 2012 @12:42PM (#42369733) Journal

    I feel a large part of my job is to stay out of the way of my developers.

    However, we are part of a much larger, ISO-9001 process machine, so it is very difficult to remove the process overhead.

    I try to take on as much as I can, so the engineers don't have to weather it, but the process demands that they all have their part checking boxes and attending meetings.

    The good thing about a process-driven organization, is that everyone knows exactly who will be sticking their nose in, where, and when. You can't just stuff extra clowns into the car whenever you feel like it.

  • by Anonymous Coward on Saturday December 22, 2012 @12:48PM (#42369767)

    Whatever you do, do NOT go above your manager. It never ends well. And don't ask me how many times I've learned this lesson, but at the time I didn't care. Bosses are usually more clever, savvy, political, and better at justifying their tenuous position. They will always crucify you, no matter how good you are. Unless the boss is doing something literally criminal or otherwise worthy of employment termination, just don't do it.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Usually this is how it goes:

      You try to go to upper management, and no matter how good your stuff is, even if you can break up the problem into Powerpoint slides and charts with a large pop quotient, the higher-ups promptly tell you to stop trying to go above your PHB's head, and then notify the PHB about the attempt.

      Things will only go downhill from there. Middle management tends to not be able to do much, but they can hold their jobs, and they are extremely adept at firing people, because there is always

    • Whatever you do, do NOT go above your manager ... Unless the boss is doing something literally criminal or otherwise worthy of employment termination, just don't do it.

      You should be hesitant to report your boss even if he is a criminal. Our society is not kind to whistleblowers [].

    • by Anonymous Coward on Saturday December 22, 2012 @05:14PM (#42371433)
      I got my boss fired for incompetence. But it was the week after I left, so only benefitted my coworkers.

      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.
  • by Chemisor ( 97276 ) on Saturday December 22, 2012 @12:51PM (#42369801)

    Go to your program manager's boss and ask to him to assign more program managers to the project. Once the PM finds out what that's like he'll never suggest such a thing again.

  • Start with the PM (Score:3, Insightful)

    by DarthVaderDave ( 978825 ) on Saturday December 22, 2012 @12:53PM (#42369813)
    Constructively find out what your PM wants from these other types. You don't hire new people unless you're getting rid of the old ones or there's more work to do. If he won't tell you with a straight up question you have a problem. Whether you face it right then or not is up to you. So, Is it something that you're supposed to be doing? IF you're not , fix that. If that's not it & it's something you didn't think of, find out how you're supposed to play with these new players.
  • I'm totally serious. If you truly feel that whatever project you're working on can benefit the company and there's people and politics in the way, do it but don't tell anyone. Work on your own until you have something usable. Because the thing is, it's easy to shoot something down when it's on the drawing board. They'll say it isn't possible. They'll add all kinds of requirements that aren't necessary and put everyone over your shoulder. It'll implode on the launch pad and make no mistake: That is the goal

  • by BitZtream ( 692029 ) on Saturday December 22, 2012 @01:04PM (#42369895)

    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.

  • by Anonymous Coward on Saturday December 22, 2012 @01:09PM (#42369927)

    I am a Program Manager that's worked for a number of leading global companies delivering multi-million $ global IT projects over the last 15 years.

    Part of my role is building relationships and facilitating collaboration to achieve success - not just of the projects but also of the individuals on my projects. Both are very important to me and usually the companies I work for and with e.g. suppliers, SIs, customers, etc.

    Have a good conversation with your PM, I'd suggest go for lunch/coffee so you've longer to talk. I've used 'him' below so apologies if its a 'her' ;-)

    Tell him;

    How much the project means to you and what you've put in personally so far.
    What the possible successes are - not just of this project but what it could lead to for your company, your customers, etc.
    Show him your plan for what the tasks are, when they will be done and who will do them. If you can build a basic time line/table in a spreadsheet showing what will happen by day/week/month. If your using Agile then show the sprints, etc. If you know/learn how to build a basic Gannt chart in MS Project or a spreadsheet - you'll probably blow him away!
    Talk about resources - you might not need more generals but most projects can deliver better with more soldiers. Work with him to identify what resources you need. Also don't be afraid of bringing in outside help e.g. expert contractors, professional services, data processors, etc.
    Tell him what the key blocks are - what Issues need to be resolved now.
    Tell him what your concerns are for the rest of the project - what Risks have you identified.
    For both the above - always consider the people issues, who are you concerned about? (the customer changing requirements, senior management killing the project, etc.). This is one massive area where PMs are there to help you - this is their key skill.
    If you've done any financials on what the project is/will cost - definitely include these too.

    If you talk through these things - any PM worth anything should be very impressed by your commitment and understanding of what's required to make the project a success. You should also be on a great start to your relationship - basically because you've given him all the tools he will need to do his job.

    If things are going well, tell him you really want to be the architect/technical lead/head of development - what ever job title your looking for on the project. And if you need resources then ask if they can be report to you in some way (that includes contractors and SI resources, etc.)

    Also ask if he can show you what a project or program manager does, learn the skills and perhaps get to attend some of his meetings with senior management.
    You never know - you might like it and decide you want to be a project or program manager one day!

    If you start something like this then you have every chance of both being very successful and delivering a great project for which you'll both be well recognised by your company, your customers and your suppliers.

    Perhaps your PM will then move to another bigger project at the same or bigger & better company - then who do you think will be the 1st person he calls when he needs development help?

    I've seen this many times in my career - not just on my own projects and programs but every successful project I've ever seen.

    And finally, as PM - seeing your junior team members be successful is far, far, far more personally rewarding than delivering projects.

    Good luck for your discussion with your PM and your project

  • QA budget suckers (Score:5, Interesting)

    by EmperorOfCanada ( 1332175 ) on Saturday December 22, 2012 @01:09PM (#42369929)
    Insist on a one person reporting structure. The moment you are reporting to more that one person all is lost as each then is competing for your time and will try to shove in more features or reporting demand than the other.

    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.
    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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.

      This is what killed our company.

      When we were a bunch of cowboy coders, it was chaotic, but we knew what individuals could get things done, and what interact

    • by PPH ( 736903 )

      Insist on a one person reporting structure. The moment you are reporting to more that one person all is lost as each then is competing for your time and will try to shove in more features or reporting demand than the other.

      This is a good point. Have all of the consultants' requests for info. go through your program manager. It will keep demands on your time channeled through him/her and give the PM visibility of your work load. The more consultant crap you get, the further the primary project will slide.

      If that doesn't work, you can always game the system. When one consultant asks you to do something, you can always claim to be working on something for another. Let them fight it out. But that might be burning bridges, so ha

  • by jiteo ( 964572 ) on Saturday December 22, 2012 @01:12PM (#42369945)

    Pretend you don't understand and ask him questions. "I need to work with this team leader, can you explain his role please?" "I need to know what I can and can't ask of this consultant, can you clarify his mandate?"

    He'll either give rational logical answers - in which case you can accept them or counter with more questions - or by trying to answer your questions he'll realize his reasons for doing all those things weren't as great as they first seemed to him - in which case you win - or he's a politician and changing his mind is flip flopping, so he'll dig in and defend himself at all costs - in which case you're screwed, but if that's the case you're screwed regardless.

    • by csumpi ( 2258986 )
      So let me get this straight. They are bringing in a consultant because they think the job is bigger than you can handle. And your suggestion is to be passive aggressive and play dumb?
      • by jiteo ( 964572 )
        I said ask questions, not be a prick. If the PM is a reasonable human being, he'll either convince the OP that what he's doing is necessary or reconsider his position. If he's not a reasonable human being, I can be of no help.
        • by csumpi ( 2258986 )
          But you are suggesting to ask the wrong question.

          There is nothing worse than dealing with passive aggressive people at the workplace. Period. (Of course not counting criminal behavior.)

          This will get you your pink slip faster than the sharpie dries on it. At least at every company I worked for and on every project I managed.
      • Asking questions is not "playing dumb" - asking questions is a great way to communicate and make a point without being confrontational. I know that it is an entirely different context, but as a teacher, asking students questions is much more effective than pushing them around - if they are wandering around the class when they should be in their seat, you can either say some variant of "Sit your ass back down" or ask a question like "Do you need me to help you find something?" In the first case, the student
  • Refocus on requirements, refine the ' engine' core to the technology and relaunch when it won't matter how badly a PM fucks up the implementation, rollout and rampup......the core engine is defined, stable and sufficiently abstracted to weather the educated PM who's fancy certification and cadre of developers are deadset on changing the world.

    Stars will holes will consume huge quantities of both manpower and resources but the core technology remains to power will be vindicated

  • A large hierarchical tech company. I was in the security systems side and we had a perfectly functional, mature, expandable system in place. But when we got bought by another security company and then finally the big tech company they decided they needed to go with something new and unproven.

    They'll lose about $20 million to $80 million over that little cluster fuck.
  • An old question goes like this: "do you manage what you don't understand, or understand what you don't manage?"

    It's entirely too easy for companies to hire managers on the basis of an MBA, who really don't understand the practical considerations of what they are managing. I'm not sure there is a "fix" for these situations that is palatable to higher management.

    During my days in program management, I watched programs get severely damaged, because our vice-president simply did not understand the technica

  • I'd suggest reading Mythical Man Month and then going to talk with the program manager. You can point out that it will take more time to bring all these new people on board rather than continuing to build out the project yourself. The book should provide you with a bit of ammunition.

    It does sound like the program manager is trying to get his/her name associated with the project, ie riding on you coat tails. There isn't anything particularly wrong with this, but it requires you to manage the resource r

  • Bail. (Score:4, Interesting)

    by mevets ( 322601 ) on Saturday December 22, 2012 @01:36PM (#42370117)

    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.

  • by jacobsm ( 661831 )

    Too many people, and most managers, feel that once they take a piss in projects they like the smell better.

  • by DLG ( 14172 ) on Saturday December 22, 2012 @01:45PM (#42370203)

    I would speak to whoever your direct supervisor is and ask to learn about how the company manages project of this size. Maybe point you towards any documentation in the SDLC. Clearly you don't understand what the program manager is doing. If they are traditional PMI type program manager, than they exist because what you are doing is called a program, not a project, wherein there are multiple projects that make up the program.

    A program manager with multiple projects running concurrently is going to be trying to determine how many project managers there needs to be. Given that traditional programs have multiple deadlines, might have multiple development teams, qa teams, deployment teams, and a wide range of stakeholders, you may be underestimating what is necessary for the project management side of things. A program manager who underestimates what they need is failing. A project manager who underestimates what they need is failing. As a developer, you give estimates and the project managers try to understand how to use those estimates to determine resource needs. As a project manager, you have to include not just development work, but project management itself. Project managers who are programmers tend to try to close gaps by programming rather than project managing. The program manager doesn't have any recourse there. They can't dive into detail level. Its actually important that they don't. A project manager should be helping identify tasks, so that they can prioritize work based on dependencies. They need to be able to continually communicate resource gaps. A program manager should be taking oversight over multiple projects.

    So basically if this project is simple enough that a single person can manage the teams necessary, with all communication being handled in a timely way, change control, qa, and deployment teams all easy to manage, then sure, smallest team necessary is best.

    But if the issue here is that you just don't like the culture of enterprise development software development life cycle, then you are in the wrong company based on what you describe.

    Having spent a lot of time running a small fast software company and a freelance programmer, and 5 years watching a small company get absorbed into a large company, I know a lot about how this works. Personally I am a better project manager than most people I know, but I hate it and since i am also a better design/architect/programmer, my bosses agree to try not to make me project manage. That being said, because the very large corporation I work for is extremely resource tight, and believed in flattening their management, we have very few project managers and we have suffered a lot. If your company has drank the ITIL/PMI coolaid and are willing to actually allocate the right qualified team members to fill those roles, than you are very lucky. Mostly I have seen companies whose leadership is trying to enforce those things, and doesn't invest in the necessary resources to make it work (so that too few lead chefs mean everyone has to do work they aren't good at)

    Before you assume that your MBA type program manager sucks, consider that good project/program manager is a skill independent of the goal. A good project manager can figure out how to get you to the moon without knowing anything about aerodynamics. If you can learn a bit of that, then at worst you may be better at communicating to project managers and the people who hire them, and you may even be better at hiring project managers in the future.

    If you treat it as a case where the guy is not valuable because his knowledge isn't based on software development skills, well I have news for you. None of the expert programmers I know can project manage worth a damn. Guys with 30 years of experience don't know how to think about projects in a way that is constructive. They may be problem solvers in their domain, but project management is its own puzzle. If you don't respect it, then don't expect to work well in the modern offshore heavy, PMI/ITIL driven enterprise world.

    So yeah, if all you are making is broth, then too many cooks is bad.

    I assume you want to do something a little bigger than broth in your life.


  • "without appearing selfish"

    But it sounds like you are in fact selfish. What do you think trying to hide it will get you?

    "What positive approach can I try with the PM, with whom I have a good working relationship?"

    So you want to dump some more oil on the fire. Your peers will hate you. Your boss will hate you. You will hate your job (although you might already). There are three possible long term outcomes:

    a) you get with the plan
    b) you quit
    c) you get fired
  • The Ant Fable (Score:5, Insightful)

    by lucm ( 889690 ) on Saturday December 22, 2012 @01:49PM (#42370245)

    Print copies of this fable for the break room and make sure your boss and the project manager read it. []

    This is gold!

  • There can be many reasons for this, such as empire building (where a manager's pay scale and promotions depend on the number of people they manage). Getting outside review can also sometimes stabilize a project: I, and my colleagues, have sometimes _been_ the consultants brought in to help integrate a new project. There are few projects as doomed to failure as exciting technical innovations that were actually done better years ago, are already available in their existing tools, and they just didn't know how

  • by jafo ( 11982 ) on Saturday December 22, 2012 @02:04PM (#42370337) Homepage

    Your program manager probably wants this project to succeed as much as you do. Keep that in mind.

    Be mature and communicate with them. Tell them your concerns, something like "This project is very important professionally and personally to me, and I want to work with you to make sure that it succeeds. However, I'm concerned that bringing in new team leads and consultants be done in a way that most improves the project. We've all heard the stories of new people being added to a project and causing problems . So how can we work together to make sure that this is a success."

    Keep away from phrasing that is too accusatory, stay more neutral like I have above. For example, I said that I was concerned about new team members being the most successful, rather than saying "I am concerned about the new people you are bringing in will cause problems". Also, try to work with the program manager rather than being sure that they're just going to wreck things and you are the only hope.

    If your program manager is any good, you can almost certainly accomplish more together than either of you can apart. Remember that and work together.


  • First rule: (Score:3, Interesting)

    by 109 97 116 116 ( 191581 ) on Saturday December 22, 2012 @02:11PM (#42370377) Homepage

    1. Where possible NEVER reveal experimental failures to anyone. Ever.
              Experimental failures are normal learning processes for developers that management nor marketing never understand.

  • Introduce Kanban + CI -> CI + Kanban Makes "plans" superfluos -> Kanban Makes it possible to use Good Team input
  • Speaking as someone who, without realizing it, has become one of those old fart programmers;

    The key to not appearing selfish is not being selfish.

    (I'll also let you in on my secret of weight loss -- *whispering silently* eat less, exercise more.)

  • I'm sorry to disagree with your premise, but having delivered a number of large projects, having a good solid project team increases the likelihood of success, Running something complex on your own is more likely to have the opposite result. That being said, a poor project management team can sink a project quickly to, but if you work for a large technology company, chances are they know how to deliver successful projects. It seems to me that your real issue is that you are afraid of losing ownership and c
  • Maybe I'm not understanding something here. You don't say that saw the strategic need for this project and developed the idea from the ground up. So I'm assuming you were asked to produce some tech specs for an idea which wasn't originally yours. I don't doubt that developing the specs involved a high degree of skill and ingenuity from you.

    Now your boss deems your work to be sufficiently successful to allocate serious resources to it. I'm getting that you feel a very strong sense of technical ownership

  • .
    "You're screwed dude"
    Whatever your project is .. it is change and challenges the existing power structures. Large corporate organizations develop clear methods and core skills at suppressing anything that creates change. The whole organization fears any mistake is far far far worse than the potential upside for brilliance. That is why committees and groups will revert to the mean, it's why bland products exist. It's why companies like Apple are ultimately doomed (centralized change agent Jobs is no lon
  • One of the things a lot of good developers forget is that they don't own the company they work for. They also are NOT the MBA that was assigned to the project. While I know every good developer wants to see a finished polished project that works perfectly, the point is that is NOT just up to you.

    If you want to keep your sanity, know your responsibilities and stick to them. Express your opinion to your immediate boss. If they don't agree then you should probably drop it. If you want to be your own manage
  • by runningduck ( 810975 ) on Saturday December 22, 2012 @03:15PM (#42370777)

    If the project has momentum then the absolute worst thing that you can do is resist adding additional people to the project. If you do not understand how additional people can increase project velocity and add value then you are not experienced enough to make that decision and it will show to all of management. What you need to do is be strategic about how the team grows.

    First you need to think deeply about what you do not know. What are the organizational hurdles you are likely to face? At what stages of the project will you be over-allocated as a resource? How many presentations and one-on-one conversation will be necessary keep momentum? How will this project be monetized? How will the end product integrated into an existing offering? Or how will the end product be marketed and sold?

    Once you have a good inventory of what you will need, sit down with management and talk about how to address these needs--this alone will earn you a lot of respect. Ask who will likely be assigned to the project. Start taking these people out to lunch to discuss the project. If they are more senior they will generally offer to pay. Don't hesitate to pay even if out of your own pocket. It will show how committed you are to the project and organization. During these lunches ask questions about the process other successful projects have gone through and the types of problems your project is likely to face. NOTE, it is critical to not be defensive or offer too many pre-baked solutions during these meetings--it will come of arrogant, dismissive and impulsive. It is much better to say things such as, "I have some thoughts around this, but need to vet the ideas with people who can really help shape them." You will have opportunities to solve the problem in due time, or even better to have other people "solve the problems" with your solutions.

    Ask if you can be a part of the decision making process for attaching additional people to the project. If you are included, be very judicious using any perceived veto power. It is better to raise concerns and shape involvement than to try to establish a front. Of course, there are always cases where lines should be drawn, but if you have voiced realistic concerns then you can keep management up to date if you seen things going awry. If you are not included, accept that decision maturely and remain engage in the process. You will likely have more influence on the side lines than you realize.

    As the project grows you will need to find an exit from your technical role. You will need to own the vision, but you will not have time to execute all the technical details. Mentor people to take over the details and build as many documented repeatable processes as possible.

    Learn how to present your ideas. You will likely be invited to more presentations. Know your place in these presentations. You have more to lose than gain if you say too much. Be there as the "guru with upside" instead of being the "one-hit wonder" or the "wild card."

    Good luck! I hope you do well. Don't be afraid of not knowing something. Nobody knows everything. Embrace other people's capabilities especially when you don't understand what they do or who they can help. These are generally the people you really need.

  • by bidule ( 173941 ) on Saturday December 22, 2012 @03:31PM (#42370875) Homepage

    This hat might not fit, but I am compelled to present you with this anti-pattern.

    I've work for 8 years with a visionary guy who could come up with incredible prototypes in 3-6 months. And you know how prototypes become the product. We started working on a 2-3 years project and he would feed us tasks as needed. It worked well the first year.

    Then the team grew to 5ish and he couldn't feed us enough: he could not develop his architectural ideas without delving in and thinking code. Documentation, comments, planning were anathema to him and he never mastered the art of leading large teams.

    Now we're going through this prototype, implementing modules which work just enough to show what should be there but there's no intent visible, no idea if it was a first draft or if that way was necessary for some other reason. At least what is done is well done, which is an improvement to the other lone-wolves that I worked with in my carrer.

    That might be what the manager rightly fears. Just as you have to brainstorm with him what will be the role of everyone in the team he's building, you need others to brainstorm, and document, and plan, how the pieces of your software will work together. I know they're consultants, but try to learn from them how to do more than code rather than fear the loss of control.

  • As a manager in my 20s I learned that I could not stop top management from interfering in my 6m budget. But I learned which parts of the budget they gave high priority (e.g. media outreach), and learned to always budget a $50k component they were sure to want control of. I would then act like I was very interesteed in it and be sure to fight for control. Admittedly this was public sector, state management. But these were Harvard and MIT managers, and they'd usually Chase the Dog Toy log enough for me to
  • It's the only way to be sure.
  • During the merger between two large organisations the CEO held "Town Hall" style meetings which requested that if anyone has ideas which would help with the merger suggest contact him via email.
    ICT was made up of idiot middle manager who were trying to work their way up the food chain at the expense of the organisation, in short, the CEO took the concept on and ran with it.
    Project was completed, I've since moved on as a consultant with a significant organisational reengineering project under my belt.

    Go over

  • And hope for a redundancy package.

  • Let some of those chiefs know that once the project gets underway they are likely to be relegated to indian status. Tell the lousy ones that they will be downgraded since there are other managers who are more capable, make it clear that they will be subordinate. If that doesn't shed enough dead wood then start telling the good ones that because of the importance of the project they are the ones who will be downgraded because they are more proficient in the lower level skill set. When you have the right n
  • by PJ6 ( 1151747 ) on Saturday December 22, 2012 @05:25PM (#42371485)
    This situation is like a religious debate - it's a social thing that has nothing to do with who has the best arguments. If you go down the route of explaining your point of view in a well-reasoned way, don't be surprised when you're ignored for reasons that seem to not make any sense, or at least have nothing to do with the well-being of the project.

    Look around the ponderously inefficient, devastated landscape of medium to large-scale engineering. There are no meritocracies.

    In no uncertain terms, this will be a pissing contest - let it be known IMMEDIATELY that you are on the warpath and you must get your way. Even if it is completely against your nature... be the asshole. Be the alpha type you may hate. FIGHT AND WIN according to the stupid and predictable primate rules of social structure and power that we all live by - power is taken, not given.

Never worry about theory as long as the machinery does what it's supposed to do. -- R. A. Heinlein