Timeline for What if a boss requires supervision?
Current License: CC BY-SA 3.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 29, 2016 at 18:44 | comment | added | blankip | You are not getting it. I have told you if your attitude doesn't change you will never get promoted. Would I love to have you as a dev on my teams? For sure! I love passionate people. But you don't get the big picture. #1 you should never be writing code that long that isn't field tested - do you trust the PMs and UX people that much? #2 Things change and when you miss a "milestone" when things change no one blames you. They will blame you if you miss the milestone because you are bitching about things changing too much. | |
| Jun 29, 2016 at 17:58 | comment | added | Pilling Fine | To the outside world, we seem to work with a plan, and yet his interjections and instructions come sometimes adverse to the plan itself, such that those instructions that have the capability to cause harm to some of the goals in the plan, will make the team look clumsy if these risks manifest. This is because to the other management, they look at the plan and ask why development would not have followed it, because these plans contain all covers to support company policy. I am more annoyed that he keeps pushing you to action his changes, just because he sees them doable, even if not documented. | |
| Jun 29, 2016 at 17:49 | comment | added | Pilling Fine | The role, contrary to what you say is to respect the plans like any of us and not be opportunistic too, however, being equipped to a greater degree with influence which he can exercise unopposed in the planning phase. After this, the plan, including all flexible changes that can be made, becomes the authority, so that no one is exploited by the individual decisions of any other. Otherwise he ought to follow proper channel to update the formalise and let us understand that we are no longer officially bound to the original plan. Currently, we end up doin one thing, whilst document says another. | |
| Jun 29, 2016 at 17:39 | comment | added | Pilling Fine | @brian_o, "which decisions"? just because he is manager does not equip him to make "any" decision is my point. I gave an example of project plans as being like constitutions, the purpose (at least in my organization) is to avoid conflict of interest influencing later decision. Each of the plans we make bind each one of us to execute it as flexibly outlined. This manager's role is NOT to override it, even if he has the upper job. Its to facilitate sound planning of a project prior (including making major decisions), communicating them and aligning them to the goal of the company. | |
| Jun 29, 2016 at 15:48 | comment | added | brian_o | @PillingFine I've removed my downvote of this answer (originally because I thought the tone was harsh) because I now believe that you seriously need a huge reality check. It's not your manager's job to play secretary. It's not your managers job to "respect plans" and "not be opportunistic." I maintain that perhaps the manager should attempt to communicate better, but the more this thread continues, the more inclined I am to side with your manager. You are not engaging in bottom-up democracy. Provide input, but your manager makes the decisions. If you can't abide by this you should be fired. | |
| Jun 29, 2016 at 11:49 | comment | added | Pilling Fine | In fact, what everyone's answer said essentially is: if possible, ideally his changes should still appear as edits made by him in the document, not just visit offices and instruct. If he is not doing so, yet instructs contradictory to the fundamentals of that document, then I should be the one to document these decisions as instructed by him, because I will be the fool to follow instructions simply because its management, when a document is in place to the contrary, originally agreed also by him. Thus: "When a manager requires supervision" to respect project plans and not be opportunistic. | |
| Jun 29, 2016 at 11:42 | comment | added | Pilling Fine | In case this gives you light in what I'm talking about: "I think you have to be clear whether you now want us to follow the project outline as carefully planned, or just wait to hear anything you say and just execute it without thought, because that instruction deviates immensely from the project outline we all have agreed on at the onset." This is an except from one communication we had with him, in response to something he insisted. | |
| Jun 29, 2016 at 11:38 | comment | added | Pilling Fine | Again, you keep implying that i'm questioning the manager's methods. This is false because that is influencing @mxyzplk too, I clearly asked consistency in approach and gave it as an example, of how changing between the Waterfall Model and Code and Test midway may have an negative on deliver-ability, taking an opportune decision that adversely affects the mission-criticals of the whole plan. | |
| Jun 29, 2016 at 11:33 | comment | added | Pilling Fine | @mxyzplk That it's "best practice" doesn't validate the action of changing to that in the manner I have explained. It has advantages that you mention, but in this case we are moving from an existing system to this new, and the 6 week time was decided to give the user everything done by the existing system in stable shape, with basics of the new functionality in place. We had to avoid giving users yet another application with faults found in the old system. | |
| Jun 29, 2016 at 6:34 | comment | added | Rui F Ribeiro | Someone that insists in keeping up with a pre-arranged plan between all parties is not a "traitor". The role of the higher up is also protecting the underlings from the internal politics, communicating and facilitating mediation with the other departments, not messing up with projects. You can bet I would find another job with a manager like this. | |
| Jun 29, 2016 at 4:51 | comment | added | blankip | @mxyzplk - I am that guy. They aren't usually wrong. I agree with them most of the time. But they usually don't understand that certain things just have to happen no matter how dumb they are. I have been commended for halting useless projects... when I try to halt 80% but actually halt 30%. | |
| Jun 29, 2016 at 4:26 | comment | added | mxyzplk | Yeah, it sounds like he could probably coach folks better, but I always find it hilarious how everyone around here always thinks "that guy two levels above me who makes twice what I do totally doesn't know anything! I disagree with his decisions so he must be wrong!" I find that... Statistically unlikely. | |
| Jun 29, 2016 at 4:19 | comment | added | blankip | @mxyzplk - BINGO! I can't imagine any of our devs even contemplating going off for months without getting feedback. This guy acts like - leave me alone and finish this over the next 2 months so it is on time. Holy crap!! And its usually not the devs "at fault", it is the client UX designers and PMs that hand them over idiotic specs. | |
| Jun 29, 2016 at 4:07 | comment | added | mxyzplk | +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, 2016 at 0:02 | comment | added | blankip | I am not dodging anything. You keep saying that your boss is changing things and opening you up to risks. The only thing you mentioned is the boss requiring customer feedback. In my opinion that is not changing anything - maybe your milestones and PM crap - but he is not changing the essence of the project at all. It seems like he is enhancing it. Also by going far along the project timeline without customer feedback seems like the risk. I think you are too stuck on timelines and deadlines - the main goal of a good project is too deliver best possible product. | |
| Jun 28, 2016 at 22:22 | comment | added | Pilling Fine | @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, 2016 at 22:09 | comment | added | blankip | @PillingFine - big companies get big budget money to do XYZ. There is often not a lot of manager input on changing XYZ at the beginning of the project. So even if I think something will fail I am not a failure for not ditching the project right away. I think you are thinking of projects as a house you are building and adding legos each day. Some projects work like that, most don't. You are saying the project will now fail because it is getting client feedback seems far fetched. Maybe your "milestone" won't be hit... who cares!! Think big picture - goal of company not small picture. | |
| Jun 28, 2016 at 21:15 | comment | added | Pilling Fine | 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, 2016 at 21:14 | comment | added | kaiser | 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, 2016 at 21:07 | comment | added | Pilling Fine | 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, 2016 at 19:50 | history | edited | blankip | CC BY-SA 3.0 |
added 1413 characters in body
|
| Jun 28, 2016 at 13:52 | history | answered | blankip | CC BY-SA 3.0 |