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!
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.
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.
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.
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.
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.
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)