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.
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.
...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.
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
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.
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.
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
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.
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.
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 */
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
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
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.
.
. .. 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.
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.
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
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
It's the only way to be sure.
Undetectable Steganography? Yep, there's an app fo
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
Right, support the PM at every turn or he may not support you. He doesn't have to have deep knowledge of the technology or the code. But you do! Brief him, explain how things work, and win his trust.
If he has been put in that role, presumably he has the experience or the potential (as management see him) to get the milestones landed, which is the primary mission of any PM. He also probably has much more influence upstairs than he appears to at first glance, since management have entrusted him with delivering, so if you piss him off you might find him talking to your supervisor about fucking you to death.
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.
"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."