Iyfjky

Question

I work in a programming firm where the Projects manager always overrides set goals and milestones.

He is keen to undermine issues as "doable" more than recognizing that we set out to complete a plan prior to the work, instead of following the plan and only taking advantage of plan evolution where other goals do not get jeopardized.

For instance, in our latest project, we had agreed that it would take 6 weeks to roll out and publish to the users only then and after we had trained them, but we are only in the second week, and he is insisting that we deploy and let the users test whilst we develop.

I have a history with user perceptions when you let them down once, that perception can last the rest of a project, and that's what i try to avoid with clearly laid out plans.

Most of the time we can't override or question his decisions, because he is two levels above us, but we are on the ground and he lets us plan things then agrees, and only in the heat of the moment come to oppose the very things he agrees, and holds you to account. Above him, there is another manager, a more reasonable one who gives you platform to explain yourself.

Essentially, he doesn't seem to want to adhere to project plans and best practices, like at least following one plan: e.g. Waterfall Model of a project, or at least choose Code and Test and follow that one only. He mixes and this hurts projects.

Recently, I had called him out last year on one project, which he did not properly allocate backup resources that I had formally written to him in an email warning him three months before he replied that "i have people i can ask to do this job and they will do it in a manner of hours"; the live system broke down and lost all data, no backup system was in place, and he is silently pushing other people to take it up. This is the example of a catastrophe I don't want

My Question
Is there a way to manage such a boss or such traits and still be subordinate? Or this calls for unorthodox action?

I'm thinking to formally make this a complaint to the boss above him.

Update
I decided NOT to choose an answer, because there were two respectable points of view. I prefer Kilisi's response, and so do many who up-voted it. There are other answers along these lines, I commented beneath them on how their advice applied to me. Also, blankip provided a different take focusing on the attitude of the OP towards the manager, whilst I disagree, the argument does not lose its validity. I took both sides of the argument into consideration, and decided to cover my work, but at the same time remember my role, and not be delusional simply because I generally disagree with my manager. So anyone in a similar position may take their own route, the answers below helped a lot.

If he is 2 levels above you, why is he giving you orders instead of your boss? — Jun 28 '16 at 12:28
@Jay We are able to interact with him, This is the structure <his manager> <him> - <team leader not necessarily our manager> - <us>, so he manages the projects and we are able to interact directly, or through the team leader...is this something bad? — Jun 28 '16 at 12:45
It's not necessarily bad, but affects my answer! - Use your direct boss to play interference :) — Jun 28 '16 at 12:50
You are considering complaining to a boss 3 levels up? Just program and let the PM manage and mis-manage. — Jun 28 '16 at 12:55

Pilling Fine 382213 · Accepted Answer · 2016-06-28 22:38:15Z

If he's giving you the orders in writing then your back is covered and his is squarely exposed. He's a bad project manager and unless something is very wrong with the company he will fall flat on his face eventually. Your major concern is not being his scapegoat.

Do whatever you are tasked to do (that's your role) and make sure everything that's stupid is in writing. If he orders something done verbally, send him an email outlining it for him to approve.

"Sorry boss, further to our meeting, can you clarify for me please. I need to roll out X immediately? I'm just preparing but thought I'd better make sure first."

All you need is a "Yes" answer to that and you're covered.

In terms of complaining higher up the food chain, it's not normally a good idea, because it's not something that's forgotten easily. I'd prefer to let him dig his own hole, rather than dig one for myself alongside his.

+1 Document, document, and then document some more. You are also correct about not wanting to get the reputation as an "escalator". That never goes away. — Jun 28 '16 at 12:08
Thank you! This is good advice, and i don't want to be the "escalator", it is a huge burden indeed over the life of your career at a workplace. Always comes to bite you when people perceive you to do a bad job yourself later on. Thank you for reminding me "my role", i should remember this. Every time i think of successfully delivering projects even as a team member, i try to participate as a team partner who raises problems we may face as a team even if i may not be responsible for the problem later. I will remember this, to document where i might have felt otherwise, but still execute my duty — Jun 28 '16 at 12:58
Is there ever a situation where having the documentation does squat? When you get called in to HR and they are ready to walk you out of the building, does it ever save anyone's job to have proof you were asked to do all the things you got blamed for? — Jun 28 '16 at 14:57
@AmyBlankenship You can be arbitrarily marched out for any reason whatsoever, documentation is useful when there is a dispute over facts, and yes, it has worked for me more than once, mostly in terms of disputes with clients, but in one case it got me paid off very well and given a chance to resign with an excellent reference rather than be sacked. They couldn't sack the manager because he was family. — Jun 28 '16 at 15:08
I've never had a situation where anyone cared what the facts were :). They had already decided, and that was that. — Jun 28 '16 at 15:12

score 14 · Answer 2 · 2016-06-28 19:50:22Z

He isn't unorthodox, he is calling the shots. You as an underling have a skewed opinion based on your job and what you think.

Your project is a great example. I have done the exact same things to a project about six months ago. I went a few levels below me and required customer testing in the middle of the project. The guys working on it were furious and I got a mountain of complaints and emails.

Guess what? Didn't care.

Guess what else? The project was ill conceived. I got pushed into letting the group doing it. After seeing what was developed in the alpha stages it was worse than I imagined. So I needed to give our dev team and management a dose of reality. We did customer testing and they hated every single last bit of it.

What is funny is that some developers - who sound a lot like you - complained and said that the only reason the customers didn't have more positive feedback is because the project wasn't done. So we let a couple of developers finish their parts to get full feedback and customers basically said, "Didn't we tell you we hated the whole idea? Why would I like it more in a finished or polished state? Do you guys get it?"

Either way you have a job in the project. And that job could change based on management's whim. If you don't like that and are that vocal you might want to put in for a promotion or find another place to work. If anything it is attitudes like yours that hurt projects more than managers like this.

As for your example of "not having a backup". According to you, this manager really messed up. But you don't really know. It could have been a group of managers or even his boss that said OK we understand the risks, if we have a backup we have to spend this amount of time, it isn't worth it. You could be right and it could be squarely on this one manager. He made the same calculations. Being wrong about something doesn't make him stupid, it just means he messed up.

This kind of example is like a developer sitting next to you telling you that you should write your code in a certain structure. You think XYZ will be needed so you don't want to follow his advise. XYZ aren't needed and it turns out that following his advise would have saved you a bit of time. And then he writes an empirical email to you, your boss, and peers and shows the example of you not listening to him and wasting company time. Your attitude is conveying that you are doing the exact same thing (not clear if you are or not).

Verdict: Be a person of power. Instead of focusing on what this manager does wrong, focus on how to change his mind when you have an opinion. The things you brought up in your question mark yourself as a traitor/spy looking to take him down. He works for your company. Try to win him over. If you feel that he is doing something wrong, try to influence him to do the right thing, not just bag on his idea. This may lead to conversations about why he is making those decisions. I am not trying to label the manager as "right" and you as "wrong". We simply don't know and you should treat it that way. What is clearly wrong is your approach and the results you have gotten with your approach.

Note: The OP had comments before (deleted now) stating that I was a little harsh or did not understand. I was not trying to come off that way. There is nothing more than I like than a worker-bee and the OP sure seems like a worker-bee. My second favorite feature in an employee is someone who disagrees. Tension builds companies! But the OP needs to realize that they need a mechanism to react to the management without "calling them out" or "documenting" things and showing stuff after the fact. If I am running a project I want the dissension when you feel it, not months later proving you met a milestone I originally asked for. I listen to pretty much everyone, especially devs working on the project. I might say no to something initially but after something happens I might change my mind based on a conversation 3 weeks ago with an angry dev. There is just a lot going on with big projects. I am in upper management but not the top of the food chain - there are often things that are going to happen no matter what. If my boss told me to get customer feedback (even if I disagreed), guess what you are doing the next two weeks? Doesn't make me a dumbass nor does it mean I am not listening. And for the OP - he seems to have a lot of good things going for him and feel that if he doesn't dramatically change how he deals with management, he will probably never progress how he wants.

Were your comments moderated off? I did not report them. Anyway, again, the edit you made is implying that i question his project approach decisions. That's not what I'm annoyed about. In my case, I'm reporting someone who overrides already team documented plans when he has already took part in agreeing to them. The complaint is on how this exposes goals of the project. If in the original plan (which he agrees) there is no room for him to make a drastic change to an aspect of a project, then regardless of being a boss, he becomes a risk to do so because planning is about avoiding this. — Jun 28 '16 at 21:07
Intransparent decisions, things that are not communicated, foster a hostile work environment. When someone on the board decides something that makes everything worse and the people in the level below can not convince them (based on feedback from the people again below them), then the next step is to communicate this down the food chain. Always, always, always make people understand the why for your decisions and they will follow you everywhere. Try to protect them and fight against things that make their situation worse and they will protect you as well. And then go drink a beer with them. — Jun 28 '16 at 21:14
I do not know what your project was like, but changing fundamental aspects which you had already planned with the team is a different matter. You talk about finding out that the project was ill conceived, If you were part of the conceptualisation then you failed both you and your team to communicate the path for your project. In my case, this is someone with whom we agree on fail-proof (as foreseeable) plans, taking into consideration aspects that need not be skipped to assure a given goal. For one to arbitrarily instruct such a measure "can" be skipped later on, is abject recipe for failure. — Jun 28 '16 at 21:15
@blankip you keep dodging my explanations, your example in the XYZ scenario would be factored in as a foreseen change, the difference with my boss is he isn't justifying the change with some other plan that works anyhow, the manager chooses plans that open up risks that are otherwise closed by adhering to carefully made out plans, just to "do it" because it "can" be done. This is opportunist and "can" save money and supposed time, but also does exactly what we work hard to avoid as best practice employees in analysis and planning. — Jun 28 '16 at 22:22
+1, current software thinking best practice is to have working software available for UAT every couple-week sprint; basically he's telling you to do the right thing and you don't understand so you're sad. It's why he gets paid the big bucks. — Jun 29 '16 at 4:07

brian_o 82338 · Answer 3 · 2016-06-28 15:59:36Z

I suspect that this manager may not be amendable to constructive criticism, but if you are interested in a non-adversarial approach you could attempt to schedule a short, 10-minute face-to-face meeting and outline your concerns privately.

Acknowledge that he is the decision maker who may have access to information that you (the workers) don't know about

Acknowledge that requirements can change after a plan has been made

But:

You'd like him to acknowledge that at some level, too much thrashing can damage your company's ability to complete projects and satisfy customers

You feel like your company is thrashing too much

Give at least one concrete example of effort that was expended but wasted because a requirement shifted after the completion

It's your boss's job to decide what priorities are and when to cut losses. Sometimes the right thing to do is to discard completed work and shift directions. You might gently conclude that you either have a performance problem (too much waste due to thrashing requirements) or a communication/morale problem (the in-the-trenches programmers don't understand why their effort is being wasted/ignored).

This is a level headed approach i should keep in mind. It helps understand that you can try to get your argument across in a dignified manner, and with a goal to discuss further cohesion in future work between the manager and his team. I might take this route for the benefit it has to team and the organisation. Thanks. — Jun 28 '16 at 16:29

Jay 1695 · Answer 4 · 2016-06-28 12:52:24Z

up vote
3
down vote

Like the other answers, Document, document, and cover your ***. Outline negatives in writting.

Alternately, forward everything to your direct boss. Make your boss play the bad guy and play the politics, and give you marching orders. Outline your concerns with your boss. If your boss plays ball with the manager, and asks you to do the work, you are off the hook.

This option depends on your goals and culture. If it would be better for your career to always please the manager, then keep doing so, and make sure he is aware of your concerns before you agree to carry out his commands.

answered Jun 28 '16 at 12:52

Jay

1695

Thank you! I like your last question, I am someone who who has a success minded approach. Even when i am not responsible for failure, i do not keep quiet, i play as a team member when it comes to the work itself, only to save the team problems, not to "not be responsible". But thank you, because i should do my duty to execute as per manager's instructions, but document if i feel there should have been another way.
â€“Â Pilling Fine
Jun 28 '16 at 13:01

4

I'm always a bit confused when people say document everything. From my experience, even with "documenting" it carries very little weight when defending yourself in a corporation. From my experience, if a manager is bad, he/she will simply say they told you otherwise and you'd still get knocked off for it. If you need to document stuff, then it is time to quit, in my opinion. Unless someone else got your back, it's very doubtful documenting will even work unless the person is honest to begin with.
â€“Â Dan
Jun 28 '16 at 13:16

2

@Dan; it all depends how bad it is... Sometimes documentation is just useful when someone 'doesn't remember' agreeing to something, and then having the documents to remind them and get something done. Yes, if you are doing this all the time against your own boss, it's toxic and you should leave
â€“Â Jay
Jun 28 '16 at 13:48

@Dan in this case, i got it to mean i have to document "whenever i identify and alert him kindly of how he may be overriding a decision that may fail the project at some point", so that [if] that outcome does come as a result of his direct instruction which i have evidence of warning him "kindly", i do not have to throw tantrums, but show the emails of communication leading to the decision he made in spite of my logical warnings.
â€“Â Pilling Fine
Jun 28 '16 at 14:43

suggest improvementsÂ |Â

Dan 4,752412 · Answer 5 · 2016-06-28 12:24:21Z

It sounds like this guy has been with the company for a very long time. As such he delivered projects over and over again even though you consider his method to be unorthodox.

Pretend for a moment he screwed up like last time, all the data has been lost and he's quietly pushing it up himself. He's telling upper management that it's you guys fault and he's fixing it. Suddenly you jump up screaming about he's a bad manager and this is why. How is that going to make you look?

The best advice is to let him fail on himself, which probably will never happen, or simply find a new job and quit, leaving behind such negativity and hopefully going for a positive.

Good pick up! He has been in the small company a long time. When i was hired, i thought he recognized the experience i had garnered from my previous places, of modern approaches to systematic project roll outs, so at every turn i have tried to participate and assist if its for the good of the company. But i do not see application or opening up to any of these new methods. He wants someone who does it his way. — Jun 28 '16 at 13:05

user356540 371 · Answer 6 · 2016-06-29 01:36:15Z

up vote
1
down vote

Don't rock the boat. When you see a concern report it up to your immediate supervisor via email so there's a record you informed them of a problem.

Never ever go above your bosses head. Engaging management above your pay grade will ultimately lead to resentment, bad reviews and eventual termination. Your supervisor will view it as backstabbing. What you seem to want to do is "pull rank". It's deadly for your career. If you hate the culture there, look for a new job. If you can't, for whatever reason, keep your head down, do what you are told, and make sure you document your concerns with your -immediate- supervisor. Don't copy VPs and the CEO. It's not your place to do this.

answered Jun 29 '16 at 1:36

user356540

371

Thanks you very much, this is a level headed approach. I now am concerned about the culture of not sticking to documentation throughout the course of a project, and baiting to take opportune decisions, thus essentially making me dislike this culture as a whole. It's not good for career growth in the way I wish it to. I do not want to take another job yet, for the industry within which we supply our services is of keen interest to me, and I wish to explore more technologies in it. Hence I will take your advice to lay low, do as I'm told, assisting where allowed and documenting where we may not.
â€“Â Pilling Fine
Jun 29 '16 at 11:56

One thing about waterfall... When a project is done using that SDLC approach, very often you'll run into obstacles that require changes to the spec. The key there is to amend the documentation with the changes in appendices, or whatever. How this gets done is as variable as the organizations out there are. It's important to do but often falls by the wayside. In a lot of cases the documentation/spec ends up being ineffective. That's one reason a lot of coders prefer the agile approach. Unfortunately in a lot of ISO 9xxx standards driven organizations, waterfall is required by policy...
â€“Â user356540
Jun 29 '16 at 12:08

Your point is a very good one, because we by HR are held by this standard, whenever someone goes into disciplinary hearing for things such as systems downs etc, such strict approaches are asked by management who don't care why you skipped them, because its the requirement. As such, when someone comes in the middle of a Waterfall SDLC, tells you to deploy anyhow, and yet on hearing you will be question on this because you executed an undocumented step, you fall. The irritating thing is I always quote the project spec, and as a boss he overrides it and implicates your action as adverse to "work"
â€“Â Pilling Fine
Jun 29 '16 at 12:28

Idea! Instead of quoting the spec in a meeting, send your immediate supervisor the documentation revisions that his bosses' changes required. Then not only are you covering your butt, you are a team player :-) Do it with email so there's a record. Then you are beyond reproach.
â€“Â user356540
Jun 29 '16 at 12:33

Ok, received, Thank you.
â€“Â Pilling Fine
Jun 29 '16 at 12:35

suggest improvementsÂ |Â

bobo2000 6,006113156 · Answer 7 · 2016-07-01 10:27:56Z

My Boss/CEO sounds a lot like your Boss, the difference is that he can see the work being built on a week by week bases, whereas your PM cannot.

Anyhow, I think there is a big problem with the way the project is being managed (I am a PM). It sounds like you guys have adopted the Waterfall approach, where you have a long list of requirements and promise to deliver it once they have all been done.

The problem that I am seeing here, is where your PM has to report progress to stakeholders but is then put in a situation where he has nothing to show to them, the pressure is then probably trickling down to you guys. Hence your current predicament.

If I were you, I would look into adopting Scrum, and mention the benefits to him. Plan your project in the following way:

1) Sit down with the PM at the start of the week and agree on what work needs to be delivered. Use the week to implement, test and deploy to staging, then at the start of the following week it is his job to report progress to the stakeholders. Once everyone is happy, deploy to production.

Keep on repeating this cycle until the whole product is developed.

You express the issue in better words than I did. As a young employee, i favor the modern methods, the company policies favor the more rigid ones though, this is what's just there and the reputation is old and proven by the owners for their clients. I always adhere to company policy or the document thus, since its what the company's risk and guarantee is measured on. Yet he puts pressure on us, without documenting it (essentially exposing us), instead of advocating the change at company level, and having us benefit from Agile/Scrum/Code&Test etc, with the company's blessing too. Thank you. — Jul 1 '16 at 10:47
@PillingFine have you made him aware of the agile way of doing things, if not, mention it can benefit him and make the process smoother. If he rejects the idea, well you will then have no choice but to work under that style of management. I would look for a new job. Also, what type of company is it...start up, corporate etc? — Jul 1 '16 at 13:05
Software development company, about 15 years, corporate because of the client base. Yes, the first week I was employed, I made note of gaps I thought existed, among them Agile, he did not shoot it down, but seemed not interested to seek to convince changing company policies, which I agreed with. However, I also noted we do not use any bug / version tracking application (I setup JIRA/Confluence for documentation, showed it's merits), this DID NOT need policy change, he actively shot it down. This could have cleared these disagreements, but he actively does not get involved in using it. — Jul 2 '16 at 20:59

Robert 1011 · Answer 8 · 2016-06-28 18:30:03Z

I would like to suggest you seem to be aware that he can't measure progress without a UI to look at and he seems to want to keep the client engaged, development can take a long time and people get board.

With this in mind maybe you might want to drive UI first plans and include a point where the client can be involved sooner. You bosses boss may be having his time pulled around by the client and passing it down to you (and almost certainly not maliciously).

It might be worth making time to check his views on the project (and many times throughout the project) as he might not understand what value building the foundations for the application will bring. He may even decide he can't get enough money out of the client for that and may want you to take the quickest route to a delivery even though it will make support and further development more difficult (read expensive).

On the other hand if he is just unreasonable i'd start looking for a new job.

Thank you. I wouldn't mind working with the client engaged from the onset. On the contrary, the manager in question almost always bases his decisons on whether something "can" be done, rather than whether doing it can affect other carefully planned aspects of a plan. That just is an example, where the original, laid out plan agreed with the customer in question, was to present after the sixth week, all of a sudden in the second week, the manager in spite of calls by us his team to take heed of the effect on customer perception if the prototype is not up to scratch. — Jun 28 '16 at 20:28

Pilling Fine 382213 · Accepted Answer · 2016-06-28 22:38:15Z

If he's giving you the orders in writing then your back is covered and his is squarely exposed. He's a bad project manager and unless something is very wrong with the company he will fall flat on his face eventually. Your major concern is not being his scapegoat.

Do whatever you are tasked to do (that's your role) and make sure everything that's stupid is in writing. If he orders something done verbally, send him an email outlining it for him to approve.

"Sorry boss, further to our meeting, can you clarify for me please. I need to roll out X immediately? I'm just preparing but thought I'd better make sure first."

All you need is a "Yes" answer to that and you're covered.

In terms of complaining higher up the food chain, it's not normally a good idea, because it's not something that's forgotten easily. I'd prefer to let him dig his own hole, rather than dig one for myself alongside his.

+1 Document, document, and then document some more. You are also correct about not wanting to get the reputation as an "escalator". That never goes away. — Jun 28 '16 at 12:08
Thank you! This is good advice, and i don't want to be the "escalator", it is a huge burden indeed over the life of your career at a workplace. Always comes to bite you when people perceive you to do a bad job yourself later on. Thank you for reminding me "my role", i should remember this. Every time i think of successfully delivering projects even as a team member, i try to participate as a team partner who raises problems we may face as a team even if i may not be responsible for the problem later. I will remember this, to document where i might have felt otherwise, but still execute my duty — Jun 28 '16 at 12:58
Is there ever a situation where having the documentation does squat? When you get called in to HR and they are ready to walk you out of the building, does it ever save anyone's job to have proof you were asked to do all the things you got blamed for? — Jun 28 '16 at 14:57
@AmyBlankenship You can be arbitrarily marched out for any reason whatsoever, documentation is useful when there is a dispute over facts, and yes, it has worked for me more than once, mostly in terms of disputes with clients, but in one case it got me paid off very well and given a chance to resign with an excellent reference rather than be sacked. They couldn't sack the manager because he was family. — Jun 28 '16 at 15:08
I've never had a situation where anyone cared what the facts were :). They had already decided, and that was that. — Jun 28 '16 at 15:12

score 14 · Answer 10 · 2016-06-28 19:50:22Z

He isn't unorthodox, he is calling the shots. You as an underling have a skewed opinion based on your job and what you think.

Your project is a great example. I have done the exact same things to a project about six months ago. I went a few levels below me and required customer testing in the middle of the project. The guys working on it were furious and I got a mountain of complaints and emails.

Guess what? Didn't care.

Guess what else? The project was ill conceived. I got pushed into letting the group doing it. After seeing what was developed in the alpha stages it was worse than I imagined. So I needed to give our dev team and management a dose of reality. We did customer testing and they hated every single last bit of it.

What is funny is that some developers - who sound a lot like you - complained and said that the only reason the customers didn't have more positive feedback is because the project wasn't done. So we let a couple of developers finish their parts to get full feedback and customers basically said, "Didn't we tell you we hated the whole idea? Why would I like it more in a finished or polished state? Do you guys get it?"

Either way you have a job in the project. And that job could change based on management's whim. If you don't like that and are that vocal you might want to put in for a promotion or find another place to work. If anything it is attitudes like yours that hurt projects more than managers like this.

As for your example of "not having a backup". According to you, this manager really messed up. But you don't really know. It could have been a group of managers or even his boss that said OK we understand the risks, if we have a backup we have to spend this amount of time, it isn't worth it. You could be right and it could be squarely on this one manager. He made the same calculations. Being wrong about something doesn't make him stupid, it just means he messed up.

This kind of example is like a developer sitting next to you telling you that you should write your code in a certain structure. You think XYZ will be needed so you don't want to follow his advise. XYZ aren't needed and it turns out that following his advise would have saved you a bit of time. And then he writes an empirical email to you, your boss, and peers and shows the example of you not listening to him and wasting company time. Your attitude is conveying that you are doing the exact same thing (not clear if you are or not).

Verdict: Be a person of power. Instead of focusing on what this manager does wrong, focus on how to change his mind when you have an opinion. The things you brought up in your question mark yourself as a traitor/spy looking to take him down. He works for your company. Try to win him over. If you feel that he is doing something wrong, try to influence him to do the right thing, not just bag on his idea. This may lead to conversations about why he is making those decisions. I am not trying to label the manager as "right" and you as "wrong". We simply don't know and you should treat it that way. What is clearly wrong is your approach and the results you have gotten with your approach.

Note: The OP had comments before (deleted now) stating that I was a little harsh or did not understand. I was not trying to come off that way. There is nothing more than I like than a worker-bee and the OP sure seems like a worker-bee. My second favorite feature in an employee is someone who disagrees. Tension builds companies! But the OP needs to realize that they need a mechanism to react to the management without "calling them out" or "documenting" things and showing stuff after the fact. If I am running a project I want the dissension when you feel it, not months later proving you met a milestone I originally asked for. I listen to pretty much everyone, especially devs working on the project. I might say no to something initially but after something happens I might change my mind based on a conversation 3 weeks ago with an angry dev. There is just a lot going on with big projects. I am in upper management but not the top of the food chain - there are often things that are going to happen no matter what. If my boss told me to get customer feedback (even if I disagreed), guess what you are doing the next two weeks? Doesn't make me a dumbass nor does it mean I am not listening. And for the OP - he seems to have a lot of good things going for him and feel that if he doesn't dramatically change how he deals with management, he will probably never progress how he wants.

Were your comments moderated off? I did not report them. Anyway, again, the edit you made is implying that i question his project approach decisions. That's not what I'm annoyed about. In my case, I'm reporting someone who overrides already team documented plans when he has already took part in agreeing to them. The complaint is on how this exposes goals of the project. If in the original plan (which he agrees) there is no room for him to make a drastic change to an aspect of a project, then regardless of being a boss, he becomes a risk to do so because planning is about avoiding this. — Jun 28 '16 at 21:07
Intransparent decisions, things that are not communicated, foster a hostile work environment. When someone on the board decides something that makes everything worse and the people in the level below can not convince them (based on feedback from the people again below them), then the next step is to communicate this down the food chain. Always, always, always make people understand the why for your decisions and they will follow you everywhere. Try to protect them and fight against things that make their situation worse and they will protect you as well. And then go drink a beer with them. — Jun 28 '16 at 21:14
I do not know what your project was like, but changing fundamental aspects which you had already planned with the team is a different matter. You talk about finding out that the project was ill conceived, If you were part of the conceptualisation then you failed both you and your team to communicate the path for your project. In my case, this is someone with whom we agree on fail-proof (as foreseeable) plans, taking into consideration aspects that need not be skipped to assure a given goal. For one to arbitrarily instruct such a measure "can" be skipped later on, is abject recipe for failure. — Jun 28 '16 at 21:15
@blankip you keep dodging my explanations, your example in the XYZ scenario would be factored in as a foreseen change, the difference with my boss is he isn't justifying the change with some other plan that works anyhow, the manager chooses plans that open up risks that are otherwise closed by adhering to carefully made out plans, just to "do it" because it "can" be done. This is opportunist and "can" save money and supposed time, but also does exactly what we work hard to avoid as best practice employees in analysis and planning. — Jun 28 '16 at 22:22
+1, current software thinking best practice is to have working software available for UAT every couple-week sprint; basically he's telling you to do the right thing and you don't understand so you're sad. It's why he gets paid the big bucks. — Jun 29 '16 at 4:07

brian_o 82338 · Answer 11 · 2016-06-28 15:59:36Z

I suspect that this manager may not be amendable to constructive criticism, but if you are interested in a non-adversarial approach you could attempt to schedule a short, 10-minute face-to-face meeting and outline your concerns privately.

Acknowledge that he is the decision maker who may have access to information that you (the workers) don't know about

Acknowledge that requirements can change after a plan has been made

But:

You'd like him to acknowledge that at some level, too much thrashing can damage your company's ability to complete projects and satisfy customers

You feel like your company is thrashing too much

Give at least one concrete example of effort that was expended but wasted because a requirement shifted after the completion

It's your boss's job to decide what priorities are and when to cut losses. Sometimes the right thing to do is to discard completed work and shift directions. You might gently conclude that you either have a performance problem (too much waste due to thrashing requirements) or a communication/morale problem (the in-the-trenches programmers don't understand why their effort is being wasted/ignored).

This is a level headed approach i should keep in mind. It helps understand that you can try to get your argument across in a dignified manner, and with a goal to discuss further cohesion in future work between the manager and his team. I might take this route for the benefit it has to team and the organisation. Thanks. — Jun 28 '16 at 16:29

Jay 1695 · Answer 12 · 2016-06-28 12:52:24Z

up vote
3
down vote

Like the other answers, Document, document, and cover your ***. Outline negatives in writting.

Alternately, forward everything to your direct boss. Make your boss play the bad guy and play the politics, and give you marching orders. Outline your concerns with your boss. If your boss plays ball with the manager, and asks you to do the work, you are off the hook.

This option depends on your goals and culture. If it would be better for your career to always please the manager, then keep doing so, and make sure he is aware of your concerns before you agree to carry out his commands.

answered Jun 28 '16 at 12:52

Jay

1695

Thank you! I like your last question, I am someone who who has a success minded approach. Even when i am not responsible for failure, i do not keep quiet, i play as a team member when it comes to the work itself, only to save the team problems, not to "not be responsible". But thank you, because i should do my duty to execute as per manager's instructions, but document if i feel there should have been another way.
â€“Â Pilling Fine
Jun 28 '16 at 13:01

4

I'm always a bit confused when people say document everything. From my experience, even with "documenting" it carries very little weight when defending yourself in a corporation. From my experience, if a manager is bad, he/she will simply say they told you otherwise and you'd still get knocked off for it. If you need to document stuff, then it is time to quit, in my opinion. Unless someone else got your back, it's very doubtful documenting will even work unless the person is honest to begin with.
â€“Â Dan
Jun 28 '16 at 13:16

2

@Dan; it all depends how bad it is... Sometimes documentation is just useful when someone 'doesn't remember' agreeing to something, and then having the documents to remind them and get something done. Yes, if you are doing this all the time against your own boss, it's toxic and you should leave
â€“Â Jay
Jun 28 '16 at 13:48

@Dan in this case, i got it to mean i have to document "whenever i identify and alert him kindly of how he may be overriding a decision that may fail the project at some point", so that [if] that outcome does come as a result of his direct instruction which i have evidence of warning him "kindly", i do not have to throw tantrums, but show the emails of communication leading to the decision he made in spite of my logical warnings.
â€“Â Pilling Fine
Jun 28 '16 at 14:43

suggest improvementsÂ |Â

Dan 4,752412 · Answer 13 · 2016-06-28 12:24:21Z

It sounds like this guy has been with the company for a very long time. As such he delivered projects over and over again even though you consider his method to be unorthodox.

Pretend for a moment he screwed up like last time, all the data has been lost and he's quietly pushing it up himself. He's telling upper management that it's you guys fault and he's fixing it. Suddenly you jump up screaming about he's a bad manager and this is why. How is that going to make you look?

The best advice is to let him fail on himself, which probably will never happen, or simply find a new job and quit, leaving behind such negativity and hopefully going for a positive.

Good pick up! He has been in the small company a long time. When i was hired, i thought he recognized the experience i had garnered from my previous places, of modern approaches to systematic project roll outs, so at every turn i have tried to participate and assist if its for the good of the company. But i do not see application or opening up to any of these new methods. He wants someone who does it his way. — Jun 28 '16 at 13:05

user356540 371 · Answer 14 · 2016-06-29 01:36:15Z

up vote
1
down vote

Don't rock the boat. When you see a concern report it up to your immediate supervisor via email so there's a record you informed them of a problem.

Never ever go above your bosses head. Engaging management above your pay grade will ultimately lead to resentment, bad reviews and eventual termination. Your supervisor will view it as backstabbing. What you seem to want to do is "pull rank". It's deadly for your career. If you hate the culture there, look for a new job. If you can't, for whatever reason, keep your head down, do what you are told, and make sure you document your concerns with your -immediate- supervisor. Don't copy VPs and the CEO. It's not your place to do this.

answered Jun 29 '16 at 1:36

user356540

371

Thanks you very much, this is a level headed approach. I now am concerned about the culture of not sticking to documentation throughout the course of a project, and baiting to take opportune decisions, thus essentially making me dislike this culture as a whole. It's not good for career growth in the way I wish it to. I do not want to take another job yet, for the industry within which we supply our services is of keen interest to me, and I wish to explore more technologies in it. Hence I will take your advice to lay low, do as I'm told, assisting where allowed and documenting where we may not.
â€“Â Pilling Fine
Jun 29 '16 at 11:56

One thing about waterfall... When a project is done using that SDLC approach, very often you'll run into obstacles that require changes to the spec. The key there is to amend the documentation with the changes in appendices, or whatever. How this gets done is as variable as the organizations out there are. It's important to do but often falls by the wayside. In a lot of cases the documentation/spec ends up being ineffective. That's one reason a lot of coders prefer the agile approach. Unfortunately in a lot of ISO 9xxx standards driven organizations, waterfall is required by policy...
â€“Â user356540
Jun 29 '16 at 12:08

Your point is a very good one, because we by HR are held by this standard, whenever someone goes into disciplinary hearing for things such as systems downs etc, such strict approaches are asked by management who don't care why you skipped them, because its the requirement. As such, when someone comes in the middle of a Waterfall SDLC, tells you to deploy anyhow, and yet on hearing you will be question on this because you executed an undocumented step, you fall. The irritating thing is I always quote the project spec, and as a boss he overrides it and implicates your action as adverse to "work"
â€“Â Pilling Fine
Jun 29 '16 at 12:28

Idea! Instead of quoting the spec in a meeting, send your immediate supervisor the documentation revisions that his bosses' changes required. Then not only are you covering your butt, you are a team player :-) Do it with email so there's a record. Then you are beyond reproach.
â€“Â user356540
Jun 29 '16 at 12:33

Ok, received, Thank you.
â€“Â Pilling Fine
Jun 29 '16 at 12:35

suggest improvementsÂ |Â

bobo2000 6,006113156 · Answer 15 · 2016-07-01 10:27:56Z

My Boss/CEO sounds a lot like your Boss, the difference is that he can see the work being built on a week by week bases, whereas your PM cannot.

Anyhow, I think there is a big problem with the way the project is being managed (I am a PM). It sounds like you guys have adopted the Waterfall approach, where you have a long list of requirements and promise to deliver it once they have all been done.

The problem that I am seeing here, is where your PM has to report progress to stakeholders but is then put in a situation where he has nothing to show to them, the pressure is then probably trickling down to you guys. Hence your current predicament.

If I were you, I would look into adopting Scrum, and mention the benefits to him. Plan your project in the following way:

1) Sit down with the PM at the start of the week and agree on what work needs to be delivered. Use the week to implement, test and deploy to staging, then at the start of the following week it is his job to report progress to the stakeholders. Once everyone is happy, deploy to production.

Keep on repeating this cycle until the whole product is developed.

You express the issue in better words than I did. As a young employee, i favor the modern methods, the company policies favor the more rigid ones though, this is what's just there and the reputation is old and proven by the owners for their clients. I always adhere to company policy or the document thus, since its what the company's risk and guarantee is measured on. Yet he puts pressure on us, without documenting it (essentially exposing us), instead of advocating the change at company level, and having us benefit from Agile/Scrum/Code&Test etc, with the company's blessing too. Thank you. — Jul 1 '16 at 10:47
@PillingFine have you made him aware of the agile way of doing things, if not, mention it can benefit him and make the process smoother. If he rejects the idea, well you will then have no choice but to work under that style of management. I would look for a new job. Also, what type of company is it...start up, corporate etc? — Jul 1 '16 at 13:05
Software development company, about 15 years, corporate because of the client base. Yes, the first week I was employed, I made note of gaps I thought existed, among them Agile, he did not shoot it down, but seemed not interested to seek to convince changing company policies, which I agreed with. However, I also noted we do not use any bug / version tracking application (I setup JIRA/Confluence for documentation, showed it's merits), this DID NOT need policy change, he actively shot it down. This could have cleared these disagreements, but he actively does not get involved in using it. — Jul 2 '16 at 20:59

Robert 1011 · Answer 16 · 2016-06-28 18:30:03Z

I would like to suggest you seem to be aware that he can't measure progress without a UI to look at and he seems to want to keep the client engaged, development can take a long time and people get board.

With this in mind maybe you might want to drive UI first plans and include a point where the client can be involved sooner. You bosses boss may be having his time pulled around by the client and passing it down to you (and almost certainly not maliciously).

It might be worth making time to check his views on the project (and many times throughout the project) as he might not understand what value building the foundations for the application will bring. He may even decide he can't get enough money out of the client for that and may want you to take the quickest route to a delivery even though it will make support and further development more difficult (read expensive).

On the other hand if he is just unreasonable i'd start looking for a new job.

Thank you. I wouldn't mind working with the client engaged from the onset. On the contrary, the manager in question almost always bases his decisons on whether something "can" be done, rather than whether doing it can affect other carefully planned aspects of a plan. That just is an example, where the original, laid out plan agreed with the customer in question, was to present after the sixth week, all of a sudden in the second week, the manager in spite of calls by us his team to take heed of the effect on customer perception if the prototype is not up to scratch. — Jun 28 '16 at 20:28

Search This Blog

Iyfjky

What if a boss requires supervision?

migrated from programmers.stackexchange.com Jun 28 '16 at 11:40

migrated from programmers.stackexchange.com Jun 28 '16 at 11:40

migrated from programmers.stackexchange.com Jun 28 '16 at 11:40

migrated from programmers.stackexchange.com Jun 28 '16 at 11:40

8 Answers
8

Your Answer

Post as a guest

8 Answers
8

8 Answers
8

Post as a guest

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

What if a boss requires supervision?

migrated from programmers.stackexchange.com Jun 28 '16 at 11:40

migrated from programmers.stackexchange.com Jun 28 '16 at 11:40

migrated from programmers.stackexchange.com Jun 28 '16 at 11:40

migrated from programmers.stackexchange.com Jun 28 '16 at 11:40

8 Answers 8

Your Answer

Sign up or log in

Post as a guest

Post as a guest

8 Answers 8

8 Answers 8

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

8 Answers
8

8 Answers
8

8 Answers
8

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor