Slashdot Mirror
Ask Slashdot: How To Gently Keep Management From Wrecking a Project?
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?"
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.
More data, damnit!
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.
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.
Signature v3.0, now with 42% less memory usage.
Or maybe start your own (obviously that would more than just a technical challenge).
If your boss is a dick it's not going to work, unless you are much better connected in the company than he is. What's more, he's going to take all the credit if it succeeds, and blame you if it tanks. If you go over his head, it will just make him redouble his efforts to take the thing away from you. His bosses may have misgivings, but they'll conclude that the hierarchy needs to be respected, at least for the time being (i.e. too long as far as you and your project are concerned).
I've seen this movie before.
is next to the lost Ark in a warehouse.
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. :)
sysadmins and parents of newborns get the same amount of sleep.
I know exactly what you mean.
Unfortunately, your boss will do whatever he wants to do.
If he sniffs a success in the making, he will make sure it's got his name on it, not yours.
All you can do is very quietly point out the risks to the project.
Sounds like you will have all the usual ones. Read any article on "project failures" and you will see them listed.
Things like undermanning, lack of stakeholder support, consultants making off with valuable knowledge etc.
Then provide suggestions to mitigate.
Print out the email and any reply forthcoming and keep it in a lead lined box.
...it's time to start pitching for jobs elsewhere while 'your' project still has the potential to be a raging success.
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.
This is I affraid just in hands of PM. New team leaders and consultants can kill any project, no matter how well it performs. PM should explain the risk to program manager and argue with "Silver bullet" argument - adding more people to the project increases communication overhead and causes delays.
Pavel
boobies
No, they were selling t-shirts.
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.
Fugue for Aaron Swartz
Tell them some stories about microsoft and how their corporate culture dropped share prices fifty percent.
There is very little you can do; this is standard procedure. This person is trying to build their kingdom. You main goal is to not let them create more work for you since all these kinds of people do is create fictitious work. You will need to find a way to work around these barriers and ignore the nonsense without making enemies. I would give only positive feedback on the things that are useful to the project, and give no feedback (certainly no negative feedback) on anything that disrupts your work.
http://www.pacifict.com/Story/
I remember when this guy gave his demo at ATG Night at the WWDC.
He used a tablet to demonstrate it, and he got a standing ovation.
"For every complex problem there is an answer that is clear, simple, and wrong."
-H. L. Mencken
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.
Does such a thing exist?
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.
"For every complex problem there is an answer that is clear, simple, and wrong."
-H. L. Mencken
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.
Be clear on what success looks like for you, both personally and project wise. Set your self up to achieve that success and look out for pitfalls. Make sure you aren't setting success as overall project success. It sounds like that's delegated to someone else and while you should do your best to see them succeed, they may run this thing into the ground. Make sure you can be successful with or without the project succeeding.
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.
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.
'nuff said.
My experience: in large, hierarchical technology companies, managers are measured by the number of folks they manage. And if they manage managers and leaders, they get rewarded more. Thus empire building begins. MBA-types are particularly prone to falling into that pattern.
Several good suggestions have already been made around having heart to heart talks with the "MBA-type" and creating a Project plan and budget to justify a flatter organization. And when you have done that, you will have to make a decision if those recommendations are not taken: Do you stay with the project and see it through to fruition or do you move on to the next place/project? If you decide to stay on, then your next step would be to learn "leading from behind" skills. Meaning: There are ways to influence projects when you have accountability/responsibility for the project but not authority. Read up on the topic.
Pitching upper management is the same as going over your project manager's head. Never a good idea. Officially. Unofficially, establishing relationships with upper management and subtly keeping apprised on the state of the project is always a good idea. So long as you're not doing it in official meetings that get recorded.... (ie: hallway/lunch room/etc conversations are ok.) In the interest of transparency, it's also a good idea to let the PM know about the chats, in a casual kind of way.... And remember that this is about sharing information not making the PM look bad. (There's a case to be made for making the PM look good, but that's a topic for another day.)
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 of many of the people you're talking to.
If you want to win, don't tell them. It's easier to ask forgiveness than permission, and while you won't win any friends from the fillibuster crowd, I've found that good managers will find ways to reward you without becoming enmeshed in the politics. That said... don't get caught until it's ready, and don't let it leak out to anyone what you're doing. You have to get a workable solution on the table to have a chance with these people, even if it's just a shell. And don't go crazy -- minimal implimentation only. The rest you can develop later. Right now, you need to give your supporters some ammo, and nothing says "Let's do this" like a working solution on the table compared to their steaming piles of nothingness to reply with.
In the world of business, I've found you never ask for permission -- you do it, then build a case for continuing to do it once you've proven the benefits of doing what you weren't doing until they found out you'd been doing it all along. It's ass backwards, but then... so is the world of business.
#fuckbeta #iamslashdot #dicemustdie
If this person was actually good at their job you wouldn't be in this situation in the first place. Unfortunately I find that managers often feel (and their bosses do as well) that they need to be shown doing work in addition to the actual line workers (read: engineers, designers, testers, and so on). The only ways they know how to do this are metrics and meetings. So they pick an arbitrary metric like sprint velocity and compare two teams against each other on a nice shiny dashboard the execs can look at and nod their heads in agreement, failing to understand the relative nature and value of that metric. Or they track hours to make sure that every engineer is working at least eight hours a day, because as long as they log an acceptable amount of hours, progress is being made, right?
And the damn meetings. Four hour affairs that drag in everyone under the sun so "everybody knows what's going on and has input," except what it really does is divest anyone of actual responsibility and makes it seem like management is getting work done. "We had meetings over the last few weeks with all the major stakeholders." All the while preventing any actual work from getting done. All for the sake of appearance of work from people who should be getting things out of your way, not putting more roadblocks in your way.
My advice is to find some part you really want to work on so at least you might learn something from this mess. Failing that, find a work cadence that you enjoy and stick to it. Don't let these people eat into your precious free time because they committed themselves (read: you) to an unreasonable and unachieveable deadline. When they ask you "Can you please work late for the next six weeks and come in on the weekends so we can finish on time?"
"No, sir, I can't. I have a doctor's note explaining that I'm allergic to bullshit. Sorry about that."
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.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Put all of the project management records in a tool or data set they're not using. Give them only aggregate data.
Stop inviting them to meetings.
Don't use corporate e-mail.
Three good ways to get fired.
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
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.
Once one of those fuckers gets on you, he'll be harder to get off than a pit bull with rabies! Your best bets are to find a new job outside the company and negotiate a hefty pay raise in the process or find someone inside the company who's impressed with your success and transfer to their department. Of course your reasons for leaving should be "Looking for new challenges," not "I have manager herpes in this position."
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
This seems simple but people often overlook the obvious. If you've got some requirements (small r, not even SRS or CMMi level stuff, but the more the better) let those requirements drive your tasking, and therefore, your staffing. Plan what needs to be done and negotiate who's going to do what. If there's a need for the extra management, the planning should spell it out. Keep team roles clear and agreed upon. If one of the new managers is supposed to interface with the customer, give them the role of "Customer Interface Manager" and make them report on their progress on a regular basis. Invent new roles as time goes on and you need them. Delete them as they go out of scope.
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 shine......black holes will consume huge quantities of both manpower and resources but the core technology remains to power through...you will be vindicated, recognized and rewarded.
PM's then will do whatever you want.....you GURU WARRIOR you
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.
I wish I could mod you funny
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 technical and legal constraints we had. Having the technical types work with program management goes a long ways, but as long as companies hire those who have never done the work as managers, this problem will be with us.
My fix was to retire early, brought on largely by the stress associated with just these sorts of problems.
Sometimes there is a reason why companies break large projects into multiple facets, each managed by a specialist and overseen by an overall PM. This can work provided the teams consist of high quality professionals (A-list players). I've seen many projects doomed because there is a lack of strong and competent leadership overseeing a project (the last company I worked for was shut down because of this). If your company gets a lot of specialists and consultants who don't listen to input from the staff working on it, there is a high chance of failure. If leadership is too passive and doesn't get people on task and on target, there is a good chance for failure. Finding people who have a vested interest in the success of the project is vital and finding people who take pride in their work is vital. Having husks sitting at a desk doing their part without passion or caring is a recipe for disaster.
You've done your part. You've built the specs and now it's time for the other folks to do their part. Hopefully your company has quality people and strong leadership so that your project will succeed.
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 rather than becoming managed by their "help" If you don't have the skill to do so, you will need to find a mentor to give you advice. Most large companies operate as much on politics as they do on actual products. Solicit advice from senior engineers and others that you feel have the knowledge and skills to work in the political landscape. Not much else I can tell you.
/* TODO: Spawn child process, interest child in technology, have child write a new sig */
Too few indians? Sounds like the boss may try to get more H-1Bs from India.
Let the management have their pie-in-the-sky project which is doomed to fail, to keep them busy and make them think they are actually producing something.
In the meantime, keep your team sheltered and coherent while you work on the actual project in a secret "skunkworks" that will come through in the end and save the day when the "official" project crashes and burns. :)
Seriously. Large projects seldomly work out as well as they are sold in the end. You need to be "the early guy" on as many projects as possible. Leave doing the implementation (and most likely to fail parts) to some other team.
I'm absolutely serious.
You need to get out - now.
I've been on project teams from 5 people to almost 10,000 people and there is a time to get out. That time is anytime before any failure happens. Reread that statement. "Anytime before any failure happens."
The larger the project, the more likely it will fail. I've seen $500M projects cancelled after $450M was spent. The way that I found out was my contracting team interface didn't show up to work on Friday morning at 9am. At 9pm the night before, we were working hard together. At 8:30am Friday, I was still pushing for hardware vendors to make deliveries to meet our schedule. My part of the project was only $50M, so I was a small fish. Also, I was a contractor, independent, as someone who could be fired, but I'd been at the company almost a decade, so I was a known person with quality outcomes.
You need to get out - now.
Take your reputation and find a great job in another company ASAP - or even in a different department inside your current company. Get a promotion, get a raise, take a little vacation, but get away from that project.
This sort of thing happens inside big companies all the time. See - it is a "success" now, so you should use that aspect to build your career. Don't wait until it is too late.
BTW, I'm an enterprise technical architect. I see projects like this all-the-time. Don't be a sap. Don't have your career killed because you want to see it through. That attitude is for smaller, family, companies. Be smart, use this as a way to build your career, get better and higher paying gigs. I work about 150 days a year now and travel all over the world. I'm in my ideal situation. When I work, I WORK! But between projects, I'm negotiating "when" I can be available to suit my desires. I'm extremely humble with the clients - I just want to make their project(s) a success. Usually, they are in way over their heads and the internal people can't say that like I can, as an outsider.
In case you missed it -
You need to get out - now.
Looks like you are suffering under the decease named politics. When things start looking good in a project, management types will jockey for position to take credit or to submarine the effort. You can either play the game (move into management) or.... make sure you are working on pieces of the project that interest you. You can of course try tilting at windmills... Let me know how that works for you. A bitter old man
let me guess. your project probably involves multilayer architecture, that seamlessly integrates with loosely couple components built on top of spring/jpa/mvc distributed across the high performance cluster with synchronized state. count dependencies in your maven and frameworks that you use. then take another look at your manager and tell us what exactly you blame him for again.
as you mentioned, you work in hierarchical company, so you both, technology and management, should work hard to maintain a complex hierarchy of bullshit. stop whining and get to work.
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.
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.
Too many people, and most managers, feel that once they take a piss in projects they like the smell better.
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.
D
"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
Print copies of this fable for the break room and make sure your boss and the project manager read it.
http://www.slideshare.net/faisalkhadia/the-ant-fable
This is gold!
lucm, indeed.
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 to use them so they've re-invented the wheel.
Can you find out why your manager thinks it needs additional layers of human complexity? Does that manager think your time is too committed and you won't have enough left for all the work? Doing good work on QA and documentation, and making sure you manager knows it's there, might help reduce their need to add layers of consultants and extraneous testing or planning cycles.
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.
Sean
End of story. :)
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.
1. Where possible NEVER reveal experimental failures to anyone. Ever.
Experimental failures are normal learning processes for developers that management nor marketing never understand.
I was drinking the cool-aid, until you mentioned Steve Jobs :)
Not really an engineer, was he?
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.)
Ian Ameline
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 control of your project, rather than anything else. It sounds like your key skills are technical and not necessarily related to managing a project, so as an outsider looking in, I could see you in a key role on the development team, but it doesn't sound like you necessarily have the skill set to do this on your own. Budgets, schedules, resource management, coding, test plans, user and code documentation, change management, training, standards compliance, etc., etc. all require expertise that you likely don't have. Someone has to lock down the scope and keep the team on track. I personally don't have a problem with the MBA types; like any other group, there are some good ones out there that will add value and others that you likely would not want on the team.... If the project is delivered on time and on budget, everyone wins. If it is not, the company has wasted valuable resources; I would not want to be on a team that did not deliver the project, regardless of who was on the team or running it. Be realistic about your own skills and abilities; are you really the best person to run this project?
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.
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 about this project, but I don't understand why you thought you would lead the entire thing. Is your boss behaving differently to the way the rest of this large, hierarchical company functions?
Having said all of that, congratulations on producing something that clearly has a lot of potential! I echo what other posters have said about not going around management. Talk to your boss in a constructive manner and find out where he sees you fitting in this expanded project. You may or may not like what he says, but at least you'll know where you stand, with your currently great technical reputation intact, and possibly an enhanced reputation for softer skills.
Give it to them for Christmas.
As for your particular question: Know your role and the scheme of things. Managers manage, Developers develop. If your a developer, don't try and out-manage your manager, but do manage yourself and your milestones and product.
In a large company, the best way to succeed is to help your manager succeed. You may feel that his failures are your failures but his successes are only his, but a manager likes nothing better than somebody that consistently delivers quality on time. Believe me, your manager's manager knows. If this doesn't work in your particular clique, don't try and fix it, just find another clique.
For people with strong business and engineering background, when you are a manager, you are a manager with technical understanding, don't develop unless you specifically have a duel role. If you are a developer, don't try and manage anything but yourself and your product.
.
. .. 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 longer running the show, the middle managers are taking over). Consensus management. Team buy-in. Death from a thousand cuts. You're in the deep weeds already.
.
. .
"You're screwed dude"
Whatever your project is
I'm a (non-software) Engineer with an MBA who has worked in top 5 to 25 global corporations from the bottom all the way up to working with VPs and CEOs internationally. Unless that management blockade can be made to think your software project is their idea (such that they get the credit for its success, not you, you will be soon running errands for their idea) then to see any success from that project you have to spin it outside work using non-work resources (like not the company laptop) and once that company is a success then you sell it back into your previous employer for big bucks and a corner office and they put you in charge of that prior management (did you sign any patent auto-hand-over paperwork when you hired in? Check that too). But inside? Only heartache and stress is ahead and lower long term promotability - because you are now or will be a 'loose cannon' and a 'maverick' - enviable skills on the outside but career death inside.
When you are on the outside you need to focus on Sales. Only by Sales to real paying customers can you see the dream through and get that success. Real customers are looking for solutions to their problem and don't care about who thought the thing up -- they just want their problem to go away. Getting Sales and figuring out your Burn Rate minimization plan and you'll be fine for the MBA skillz you'll need. Sales...those are still hard and take longer than you think so be prepared.
Too many resources added to address issues in scheduling (usually) or in an effort to 'fast track' the project can backfire quickly. Once you add too many resources you create issues with communication both to the project manager as well as your stakeholders. Try to find out what the client wants in the way of report data and focus only on getting this information back to them weekly. Trying to add more leadership sometimes they are not satisfied with the report data they're getting on task progress. One thing to note about fast tracking- I'm not aware of a situation where adding layers of leadership will help achieve more control or faster progress toward your goal of a successful project. You add resources to tasks not management. What exactly is this person trying to achieve? Insulation from the project? Thanks for your post.
MBAs are causing the downfall of civilization. They are worse than lawyers.
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 manager and CEO start a company on the side, it isn't hard. Then you can do whatever you want with YOUR code. But the point is the project you are on and the code you write in any large company does NOT BELONG TO YOU. So don't take anything to personally and learn to drop what you are not responsible for.
I'm not saying you shouldn't care, just know your place. Few people like a whiner and it's not likely you get any credit even if they do change the direction of the project. The credit goes to everyone.
You obviously haven't worked for Intel.....
"I feel we are sliding towards a too-many-chiefs-too-few-indians scenario"
disregard all the posts from the MBAs saying that you need more managers, they're idtiots, more managers is something to add after the project has matured into a working proof of concept then let them ruin it with bureaucracy
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.
-rd
Managers can be ignored. What is a "program manager" anyway?
I am sure you have fantastic technical capabilities. You would probably be bothered if someone who was not a technical professional told you how to do your job because they thought they knew better than you. Why would you then assume it is OK to do this to a trained business manager? We all have our opinions but don't fall into hubris. It's his job, let him do it. In the meantime, do your job, do it well and you will stand out. Don't take on other people's responsibilities and don't think you know better than everyone about everything. A little humility goes a long way.
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.
ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
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 control the direction of 98% of the projects. It worked even better if the boss's bosses took interest, and kept them off the furniture.
Gently reply
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.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
don't give management an opportunity to fuck with your project. get it done before they start getting involved.
It's the only way to be sure.
Undetectable Steganography? Yep, there's an app fo
Not if you deliver.
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 their heads if you can win.
so? it's easy enough to just get another job if it comes to that. tech is a big business.
Sounds to me that perhaps this manager might just be getting in over his head. If the people being brought in are being put forward by him then just maybe there is some nepotism happening. My advice is when this happens to "give 'em enough rope to let them hang themselves"
Chances are the costs of the project are not directly under the his control and when they spiral the first thing that will get cut is the "fatass suits in chairs consultants".
Secure your job by writing the best code you can. If the person who is doing the chair filling exercise is at the top of the food chain with complete control over finances, I would start looking for another job if your skills are good because there is tons of work for skilled programmers and very little for MBAs and design consultants in the software industry.
It is an unfortunate truth but some businesses sink because of nepotism and a "take the money and run" world of consultants and Lawyers. If the person is also an owner of the firm you are employed by it could be the whole company is just a shell to "take the money and run". Hey it happens, the programming idea might even be a good and valid one, but this can also mean that the valid idea was just an investment hook and the real purpose of the firm is to get investment not produce a real product!
The bitch is that everything they do is perfectly legal and as the company hits the skids the employees and investors are left out to dry and the consultants and the owner just walk away and take a little vacation close to the stash which is usually in the Cayman Islands nowadays not Switzerland. Up here in Canada political cronies and corporate consultants that work in the financial industry have created a huge business siphoning money out of the country and building up castles in the sky in the Caymans.
If the US goes off the fiscal cliff perhaps we should consider invading the Caymans and taking over the Canadian banks down there because we have absolutely no idea how much wealth is tied up in their banks. I suspect it is in the trillions by now. Might even be be getting close to a Fort Knox level of wealth.
And hope for a redundancy package.
http://michaelsmith.id.au
If you're e developer, be a developer. If you're a manager, be a manager.
Don't attempt to be both, because that's not what your company wants of you. You may feel like they're "getting in the way," but I have news for you: it's not "your" project. It's your company's project, and management will decide what it is, where it is going, and what metrics will be measured.
The best thing for you to do is to deliver what is asked of you and in a timely and cost-effective manner. If you're afraid of voicing your opinion to your own management team, then perhaps you don't fit in as well as you think.
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 number of chiefs, go to management and tell them who, by name, within the organization you need.
The US government have made it clear that we have no inalienable rights; any we do not defend vigorously will be taken.
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.
Anecdotally, I was hired to my current position to replace a team of Indians.
Not having the ability to ask them questions as I learn their work has been a fucking nightmare. They seemed to be the only who knew what the fuck was going on in this company. Everyone else is as clueless as I am as the new guy, but I still get yelled at regularly for not delivering in time. Fuck you, this system is a steaming pile of shit waiting to catch fire.
For all you know, he may need all those consultants to sell your project to *his* boss.
Sounds to me like the real issue is that you dont want to relinquish any control of what you perceive is your brainchild.
You need to learn how to delegate upwards so you keep the MBA types busy on trivial crap while you get on with the real design/engineering work.
The secret here is to understand that all MBA types are all the same: They all know nothing about the actual products and are cluleless in every respect other than to repeatedly use the one tool they were told at MBA school, which is 'Reduce anything and everything to a well-defined process'.
This thinking was originally intended only to try and make repeat-process environments (think production lines) more efficient and doesn't work at all with any creative process (e.g. software development) however the MBA's dont understand creativity because they never had any themselves so cant identify it in others. And because they dont know anything other than their one tool, they will just repeatedly do the same thing over and over even when its clearly not working. When all you have is a hammer everything looks like a nail.
Knowing this, you can use it against them.
Actively encourage them to go down a massive time wasting project of over analyzing everything to come up with a well-defined process. It will be an easy sell because they will want to do that anyway. We already know that will inevitably fail to achieve anything positive but you will look good because you apparently cooperated with the MBAs, they will look bad because they wasted man years and failed to achieve anything productive.
The only real trick is to make sure that encouraging them doesn't take too much of your own time so you can actually still do the real work, and that you never actually implement any of their process suggestions, otherwise your time and productivity will all quickly get sucked up into just running the endless bureaucracy.
Well, it depends.
Is the company big indian, or little indian?
Put all of the project management records in a tool or data set they're not using. Give them only aggregate data.
If you don't document the actual work and records using methods approved by the org, then management may assume you didn't do the work.
Since you haven't actually divulged enough information about the nature or complexity of the proposed project, your area of expertise or involvement or the actual qualifications of the PM, there is absolutely no way (other than luck) for anyone here to offer you targeted accurate advice.
The best you can take away from the opinions offered here are from that Buddhist perspective that most of us find the reflection of ourselves in what describe as reality and we are far too attached to our desires for the future to act wisely.
So here's my [free | worthless] advice. Try to detach from your desire to view this as a personal endeavor and do your best to explore the situation in the hope that you can provide the best value possible toward advancing the project and yourself within it. It sounds as if your PM is moving forward by doing his best to ensure that "new multiple team leaders and consultants" are there to discover the nature of a project that's actually headed for development. Like it or not, you're out of your depth or he wouldn't be adding what you've judged to be, "too-many-chiefs-too-few-indians."
If you stick your neck out without understanding what you're poking your nose into, you're likely not to enjoy the outcome.
Breath... empty your mind of your attachment, and let the situation unfold. You're not in control of it, so you might as well take advantage the freedom your position avails you.
Even if you deliver. "Nice outcome Bob, but you're not really a team player so we're going to have to let you go since you are not suitable to work on the next project".
Office politics sucks. Piss off the wrong people (which may even be an inexperienced 18 year old receptionist that a manager finds cute) and it's time to look for another job or a way to get transferred.
Neither does the young MBA, and you'll probably find that the developer is frustrated with the young MBA precisely because the developer is considering the good of the company when they are objecting to the proposed waste suggested by the young MBA.
New managers can lose focus badly in their rush up the tree.
In reading through the comments there is several thingd missing:
1. The assumption that there is a solution. Possibly not. Maybe find another job.
2. The assumption that the PM places the company interest above his own interests.
3. The possibilty the PM may want a much bigger empire.
4. The possibility that management may think of employees as being in two classes. One class is manager the other class is technical and the two classes will _never_ be allowed to overlap and employees are not allowed to switch!
5. It may be way way too late to change course. Managment sometimes would rathet kill people then admit they made a mistake.
Yes I would talk with the PM but be very careful. Let them do most of the talking. Do _not_ let them know you want the project to go differently until you have a better understanding of their vision. Try and understand the politics of the organization. Avoid saying anything negative about anyone. Possibly say things like. "I am new to working with PM X. He seems like a nice guy. What is your experiance in dealing with him?". If you find out the PM is a back stabbing weasel then, continue to be nice, but put your resume out.
OK, I got that last bit wrong, the summary does indicate that he's having trouble with his superior, but it's worth mentioning that typically the duty is to the company and not some feudal bullshit of fealty to who you report to directly in all circumstances. I've worked in a place where middle management wanted to temporarily shut down a process line where production was valued at well over a million an hour and the guys on the line had to dig in and say no unless they wanted to get sacked in a job lot with that middle manager.
With new managers you sometimes need to remind them that their duty is to the people that pay them and not their career advancement. I had to do that frequently some years ago with a guy running another department when he'd done nothing previously apart from sales and found himself in charge of a non-destructive testing department. An MBA in shouting appears to teach that you need to pretend to know everything, pretend to always be in control, and never take advice from people under your control - which limits communication to side channels (like management of another department, or less safely over their head) when conflicts occur. He wasn't actually a bad guy but he did lose a lot of people their jobs and cost the company five or six million before he started to get a clue. Thank God he wasn't my boss.
Employee input is a problem. Most companies really lack the funding to compete and they often also lack a good product to take to market. Meetings have a tendency to dig into situations and uncover the defect as being with the leadership of the company. Usually the leadership beats up the sales staff. Then the best salesmen vanish. Next on the list are people that make the actual product. Insisting on ever more sizzle in packaging and advertising simply stalls the inevitable. Most people can not get jobs with the companies with the best funding and best products. The odds against second tier companies providing any kind of future for any employee are poor to nonexistent. Take a look at industries that have more age than the software industry. Pullman was once the largest company in America selling their rail cars. The auto industry is not the power that it once was. Free TV is pretty much dead. Radio is on its death bed. the theater industry is a shadow of its former self and the big box department stores have not held up well either. Even banks are now a circus like industry.
Finding a company that can win, long term is not easy and determining a good path for them is not as easy thing to do either.
Begin by asking questions like "How can I be of more help to you in your role? How can I best prepare to provide you with what you need to provide senior management?" Until you understand your PM's needs and even wants and can articulate them back to him in a way he agrees with, you don't have a chance. Shouting your wants and needs to him is exactly the wrong way to a common understanding and is not an effective persuasion technique.
Putting the best set of specs together is useless unless senior management understands the purpose, sees the profits and the timeline for those profits, agrees to the funding and staffing etc. So you have to help sell upwards and preparing to be successful doing that means you have to understand what your friend the PM needs in terms of organizational needs satisfaction. It will do your project no good if at a management meeting your guy is the only one advocating for your project and competing projects are more widely understood and supported by those present. We hope your PM understands that and is building understanding in multiple areas so that when he brings up your project and its needs everyone feels comfortable with it enough to nod in agreement so the big man feels support enough to OK your project.
Good luck.
In my experience, this may well indicate that someone up the food chain has some different ideas or vision about your project. Often consultants are brought in to recommend what upper management wants to happen, rather than come up with real findings. It saves them having to directly disagree with their own staff. In other words, "Look, these outside (unbiased!?) experts said we should do it this way instead." The problem is that they are often far from unbiased. One of my friends who has been a consultant to some pretty big players was often surprised at how often the 'results' were handed to him by the client after they did their analysis.
Hopefully, that isn't the situation here, but it isn't uncommon. It's something you should keep in mind.
Here is my re-statement of your situation:
You care very deeply about your project. Your Program Manager has recently made a decision to bring on new people. You are concerned that these new people are not necessary, and may be detrimental to the project.
More to the point, you do not understand the reason why your PM feels that more people are necessary at this time.
Since you have a good working relationship with your PM, that is your starting point - ask why the change is a good idea. Do not respond immediately - listen to the response you are given, spend some time thinking about, and THEN make a decision. Your PM could be spot on (example: "I believe that you will need more people in about 8 months, and it takes 6 months to actually get them in place. I figure we have about 2 months of wiggle room if I start the process, now. I do not need to waste your valuable time handling what are essentially HR duties...") or could be making a mistake ("I want a bigger office, so I am growing my empire..."), or could be acting upon orders ("The owner is concerned that if you leave or get hit by abus, we're screwed. We need to have a back-up for you in place, just in case...").
Currently, you do not have enough information. If you get stonewalled by the PM, then go over his or her head.
Chivalry is not dead, it's just frequently misspelt. - M. Langley
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.
I get that you consider it your success, and you attribute success of the project so far to your technical abilities, and you see yourself as a chief.
But creating a personal success for you, or career-building for you, is likely not the priority for the organization. The manager is obviously seeking to add leadership, to help ensure the project's success; and in particular, that the project meets management business objectives.
If you see yourself as managing the project, and your boss both sees themselves as managing the project, sorry, but you lose. Ultimately, it is up to the PM how to manage their project.
Meeting business objectives is more complicated than technical considerations; there are also concerns about things like oh, cost.
So it may be sensible that additional leaders and consultants become involved, to help the business set the business objectives priorities, expectations, and milestones the business will have for the project.
The technical abilities are one thing -- the choice of priorities, what things the technical resources are spent on, are management decisions. Don't neglect your boss' management abilities in enabling the business to conduct the project in the first place, staff it appropriately, and get the staff spending the man hours on the tasks that will help best meet the business objectives as rapidly as possible.
From the way your post is worded, this is the first impression I get. You feel this is your baby, and that someone else is going to get the credit for pulling off the project.
I agree with the other posters about approaching the project manager, but if you do feel the way I think you do (and please be honest with yourself) then you need to be very careful. If you approach the project manager in that head space, it will be immediately detectable, and then you become a liability. You will possibly be seen as a Maverick who is not a team player, someone who cares more about themselves than they do they project, someone who is a risk to the project as they may work against what is best for the project to ensure their personal needs are met.
So please do approach the project manager, but keep your ego well away. Make sure that you are presenting what is best for the project, and more importantly listen to the PM. Try talking to friend before hand and doing a little role playing. You may be surprised how you come across.
This is not your project. This is a team project.
In the high tech fields, the manager works for you. Not the other way around. His jobs is to make sure you have the tools to do your job. And removing obstacles that hinders your work.
Bad bosses (micro)manage their own people.
The problem is that MBA are trained as managers. They are being taugh that pressing the lemon is good. That pitching workers again each others is good. The best employees get a pat in the back (no raise, doesn't allow for it.) and the "worse" get a pay cut or a letter of termination. In short, workers in the tech field are like socks: you wear them off then you replace them. They are not trained as high tech field managers where the rules are completely different.
As for the article question... Bombs, nuclear weapons and orbital strikes lacks in gentleness. Try food poisoning.
If you stay, all the blame for problems will be heaped on you. All the success will be because of his great leadership. You will not be given a chance to be in charge of anything, even if you publicly grovel.
MBA types have tech envy. They know they are not capable of that kind of creative thinking and it makes them resentful. The way they deal with this is by making sure that all the technical people work for them. The higher pay grade and executive perks reassure them that technical ability is a commodity, while management is an irreplaceable skill.
Your presence on the project will be a continual reminder that he is not ultimately a creative person. He will do whatever it takes to show that you are inferior to him. Staying will be a very painful experience.
Prepare your resume. You'll need it.
Why is Snark Required?
The damage has already been done to the project, there is no resurrecting it. You are done, it is over. Sorry to say it. But once you get a textbook MBA into the matter, it is over and there is no Resurrection for project. You will do well in your further endeavors, however this one has reached it's conclusion.
Some time back I was sent on 'manager training' to learn how to have difficult conversations. I was expecting it to be a load of crap, but was surprised to actually learn quite a lot from it. I recommend reading the book it was based on: Crucial Conversations - Tools for Talking When Stakes Are High .
Believing something doesn't make it true. Not believing something doesn't make it false.
TLDR:
1) make graphics that the PM can show to senior management claiming your work as his own. Don't mind this, every manager does it.
2) give a few bullshit problems that you fully control so you can keep him off your back by "making progress" as required
3) get him to include you in the management chain, and are assigned control of "resources"
4) get him to introduce you to his bosses
5) don't forget, managers are extremely insecure, if you can convince them they convinced "a techie" to play the management game (with them as mentor), they see that as much more important than their job
6) if you can actually build a report chain below yourself (and thus below him), they will worship you
tell them off and open your company. huge money ballast will keep fat bureaucratic fks afloat anyways. the only way you can make a difference is by stopping to work for some chmoe
Something I've never tried but might work, but consultants are usually a sign that your "technical" manager is way out of his depth when it comes to understanding the project. If you can figure out a way of educating the manager maybe he or she will feel less insecure about the project? It would also demonstrate that you know what you're doing.
Honestly, every single time I run into that situation you're just screwed. Its not just going to be as bad as you're afraid it's going to turn out, it's going to be far far worse, with months of fighting over stupid points and some commitee designed product that adiquately solves all the wrong problems is in your destiny.
You have just encountered your first (of many) self serving, conniving, worthless PMs. The first clue was the MBA. I have run up against these types before. This person is there to pad their resume and doesn't give a shit about the success of the project. These types of people don't want to do any actual work they just want to appear to have done actual work. They will take credit for the work of others. He's already got his head up your bosses's ass so forget about going to him about it. Making waves will just backfire on you. Best thing you can do is keep your head low and pretend that you don't hate his guts. If there are a lot of people like that in your organization my advise would be to find another job.
So - in scoping this problem, recognize that this is a political problem, not an engineering problem. You are likely an engineer. So basically, I'm saying that you are fucked. Yes, 20 years of industry experience. IMNSHO - you just can't win this. Ever. If you think you've won, you're just waiting for some backstabbing motherfucker to do you in. These guys are ruthless and brutal, and they do not give a shit about doing what is technically "right" - or even what is "right" for the customer, or better for the company in the long run. They want THIS quarter's numbers to look good. Period. The best you can do is to understand the coin-operated nature of the MBA, and use that to try to manipulate them.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Convince the manager that bringing in too many external people before significant progress has been achieved will result in ideas/credit being stolen. Therefore it is important to keep it under the radar till success is clearly attributable to the PM and his team. In a highly hierarchical and political environment this should generally work. Worked for me in the past.
O this learning! What a thing it is - William Shakespeare
Interesting how many people advocate working within the system even if said system is broken. Successful types, the truly successful ones, didn't get there by worrying too much about making "friends". Not saying OP should actively make enemies, but putting the "friendship" first isn't always the right thing to do. Sometimes if you know you're right, you gotta ruffle a few feathers, albeit in a tactful way.
Know the business, know the users (study existing systems), know what they are familiar with, know the design options, and have counter arguments ready for each option before the consultants do.
If you make them look stupid and like fish-out-of-water often enough, they will eventually be sent away. Don't gloat, don't rub it in, don't fit the asperger stereotype; just be factual, professional, and prepared with accurate information and clear clean counter-arguments.
Be prepared to work long hours to get ready when it counts. This doesn't mean you have to work long hours all the time, just at key points.
Table-ized A.I.
All my experience with this has been in startups. And the solution that has always worked was to just code up a prototype when no one's looking, and present it once you've got enough of it together to show whatever it is that most illustrates your ideas that otherwise might be having difficulty with the rest of the team. Generally, code in the hand is worth two in the bush. This technique can be used to solve several problems, such as getting the design going your way, using your favorite development tools instead of the crap they're proposing, etc. Initiative is usually appreciated and gets you credibility. If you're stuck in a constipated dinosaur though, it could be a big waste of time, you might be better off just collecting your paycheck and waiting for them to figure out what the heck they think they want, and giving whatever that is to them.
I've been through this and I'd suggest you go with the flow. The project might be much bigger than even you can see. Don't kid yourself that it might be a clunker but if you can deliver and the guy you are working for isn't a bully or other type of impaired management style what have you got to loose?
You can loose the ego and accept that you a playing on a different level now or you can just leave.
If you want to stay just be cool about everything. If this is happening then the business has probably, surprisingly, recognised the business value in your "specification". Sounds like you are being installed in an elevated position in the hierarchy so have a one on one with the "MBA type" and just ask him about his vision for your role. If you don't like it, you can leave. If he's a jerk, you can leave. Seriously though, loose the ego, right now, that is what will kill your viability on this project. Be prepared to give up everything you have achieved there, accept that your role will change (probably more than once) and if you can't then the project will probably be canned, learn as much as you can that will be useful elsewhere but understand that the project has to have a business value. Remember that once the project is running you are expendable. Be adaptable.
Some people don't have the balls and vision to swim that deep, if that's the case, you can just leave.
Ask questions, make suggestions. Try to get the people you need involved in the project, you'll need them too. Choose wisely, once the project budget is spent - it's over. Frankly, you look like you are in a no loose situation where you can leave when you want.
The "MBA type" that you now report to is probably just as ambitious but in a non-technical way. They have to deliver successful outcomes to be recognised. if you want to be considered the guy on this project then demonstrate that you have a good understanding of the business issue and foster a relationship. If you don't know it by now then you will probably need a "MBA type" to be your eyes on the commercial horizon. If you work well enough together and deliver you may even find that he asks for you to be involved in his project because you achieve results.
Just make sure there aren't knives in the hands of those who pat you on the back.
Is it an issue, or just setting up structure to hang capability off to do what needs to be done. If you have concerns then frame it in a "I'm just trying to understand..." question
Just don't don't be a jerk. Make "suggestions based on observations that you think are important and may benefit the project", if he doesn't listen or you don't like the outcome, then you can just leave.
The project I did is still in use nearly 7 years after I left, 5 years after I started. I considered it a failure as not all of the facilities that it offered were being used, yet it saves them dollars and is still being used. The real reward is the unexpected respect I am still regarded with. I though it was an awesome ride, but it's not for everyone.
You can just leave, or you can just go with the flow.
My ism, it's full of beliefs.
Agreed. Software companies are the wrong environment to be secretive and manipulative. Those are only useful in a toxic environment (fight fire with fire) eg some types of academia.
You say you have a good relationship with the PM? Then you're home and hosed if he's any good and has some balls.
Among other things I'm a software PM who manages external contractors and coordinates these with internal dev leads and QA for eg. As far as I'm concerned it's a part of the job to push back on unreasonable crap from senior management, with whom I try very hard to keep a good relationship. I'm the layer between management and the guys that do the code on the projects I do, internally and externally, and I push both ways and respond both ways.
The only time I might find myself unable to fight management on something stupid is if the CEO gets a big hard-on about something silly - he can be difficult to contact to defuse. While I have worked closely with him before, I have little to do with him these days as the company has grown. Now I'm insulated from him by a thick layer of VPs. Once I could have called him and just explained why he shouldn't do something, not so now. However, I do have strong relationships with the VPs who matter (ie who have clout) and a hard-earned reputation for persistence, diligence and getting milestones landed. The devs used to think I was a wanker because I do not come from a dev background (though I am a BS and I do write code for my own amusement). The sw team leads manage their own teams, technically we are on the same level, but it's their heads I bang together if need be.
Hi,
Since you developed a project, you must be edutated and intelligent. Since your are working in a company, you know that company.
How can you expect me to give a solid advice to an educated, intellingent company man?
After some thinking only one way is open, but then you are not a 'company man': go underground with the people you trust. This is already dangerous. Who can you trust?
Good luck!
.. that management does not want you to hold all the marbles and becoming essentially un-fireable. A team means that no single player is essential and maintains the worker bee paradigm. It's also likely that the MBA is inserting his "necessary and important" contribution to the project.. that's why he gets paid the big bucks.
That will work two, three, maybe even four times if you're really good. Then you finally start running into hiring managers who are wary of job hoppers or who get bad references about you. Then you're flipping burgers.
1. The people who have the gold make the rules.
2. The people who have the gold are only concerned about keeping the gold.
3. In order to hoard the gold, control everyone and everything.
4. Place qualified people on dangerous, high risk projects. If they fail, it's good for the people who have gold because then they won't challenge authority later. Continue to push people to the brink, then we have the next step.
5. Place incompetent, deranged, and stupid people as managers. Every manager knows this in his or her heart. If you think otherwise, then you're fooling yourself. Took me a long time to realize that. It's a bonus when managers don't do anything at all!
6. When the manager realizes the error of his or her ways, people who have the gold either fire the manager or ignore this behavior. Nothing changes.
7. All the while, people are wasting enormous amounts of time. Create systems that truncate development and squash success of people who are not wealthy.
8. People who have the gold can let them eat cake.
Extra credit:
Make a whole system of propaganda making people feel special, never telling the truth.
Use a self-help book to guide you in creating an elaborate system of doublespeak and call it professionalism.
Once I realized this, it was a lot easier to not take things personally.
Forget it. You and your project are doomed. There is nothing more fatal to your influence and stature, nothing more unforgivable, nothing more inflammatory to the organizational immune system than disrespecting the hierarchy.
Polish your resume and get out. Your organization does not WANT you to innovate. You are a square peg and, as you will soon see, you are surrounded by round holes. You no longer fit and soon everyone will know it. Get out while you can do so on your own terms.
Voice of experience here. I'm very serious. Your career, your happiness and your health are in great peril.
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.
Those are adjectives, you idiot (noun).
a former HR / Pepsico honcho, now a proff at some biz-school,
Michael Feiner wrote on this ( & lots else ) years ago...
it'd save alot of our lives from political damage...
http://www.amazon.com/The-Feiner-Points-Leadership-Perform/dp/0446695750/
Seriously, many of us in this discussion would sleep better & go further
if we understood the principles he gives us, better...
Cheers
"Idiotic" is an adjective. "Idiotically" is an adverb.
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
There, FTFY. HAND.