How to handle bosses who ask for suggestions but then becomes offended if those suggestions aren't aligned with the way they want stuff done?
Posted by Murky_Moment@reddit | ExperiencedDevs | View on Reddit | 54 comments
Hi all,
My boss gets super opinionated on "how" things need to be done.
I've never really figured out the "right" way to deal with this. It becomes increasingly difficult not to become a "yes man" and just accept everything that comes out of her mouth. In meetings, I tended to start just sit quietly and nod at everything because it's not worth the additional scrutiny for the next couple of weeks.
A recent example, we got feedback from our internal customers that our SQL Server to MongoDB migration documentation needed some examples. My boss asked me for suggestions on how we could try to fix that problem. I recommended we could add some step-by-step recommendations on a sample dataset migration. She was okay with that. So that's what I updated our documentation with.
She came back a week later saying that she wanted a Confluence document with a database migration plan with screenshots and videos including instructions on things like how to download MongoDB and install it on a local computer.
I added references to several official documents into my document in a "reference" section. She disliked that and told me to do it over by embedding actual videos into the document. I took embeddable videos from official MongoDB documentation and put them into the document. She also disliked that. She wanted me screen record my own laptop, doing each step and then include those videos in the document. She gave me a list of 32 things I had to screen record and provide instructions for - stuff that's super easy to Google.
It ended up taking me a two whole weeks to build a document I could've done in a day. When I tried bringing it up and saying how it impacted my productivity, she went ballistic and started scrutinizing every line in the document.
It's been 2 months since we published that document, and a grand total of 11 people in an org of 300 people have read it. :/
I brought up the incident to her boss in my skip-level, he just shrugged it off and deflected to how I could be taking feedback more openly and show vulnerability in accepting advice.
lonelymoon57@reddit
From the specific example you gave, I have to side with your boss on that.
What your boss describe is very common especially in big enterprises: detailed step-by-step guide on the things your team provide. You can't say "just Google it" or "check the official doc" because a) if people could, people would and b) they use your service, not MongoDB's. It's also a CYA thing, because when people mess up on the little things, your boss can point to the doc and "we told you to do it this way".
Many moons ago I was doing this exact same thing. "All I do is following the official docs, why make me redo their documentation" - then got reamed out by the client who was kind enough to let me know the reasons: "I don't pay you to give me youtube links that {vendor} made, my 12yo can do the same thing". It's my team job to deliver a working system, not parroting a tutorial.
One other thing, you really can't tell your boss that the task she gave you impact your productivity - it's just nonsensical. Your productivity is by definition how fast you can do the task she gave you. How could doing the thing you do slows down the thing you do? She was quite right to re-examine the work you did.
The root cause of this is that you are thinking as an individual engineer (and if I may, a junior one) - not as a cog in the corporate machine. That's just how things are done; and you should evaluate if you are a good fit for that kind of environment. Nothing wrong with wanting to work in smaller orgs with fewer red tapes.
Murky_Moment@reddit (OP)
I talked to my Senior Director about this and he agreed it was not a beneficial use of my time to replicate like-for-like instructions from MongoDB's documentation into my own Confluence documentation.
He explained a technical writer costs roughly a third of what I am being paid and he'd like to see more efficient deployment of my time on development work - not documentation that can be easily referred to elsewhere.
He's going to have a chat with both my senior manager and my immediate manager, as he feels our resources were "grossly misaligned" with what he would have expected here.
lonelymoon57@reddit
Well to be fair, from what you described your boss did not ask you to copy the docs - you yourself keep referring to it.
Secondly, the point about technical writer - I call bullshit on your Director. Nobody hires technical writers for internal work, period. And in an org with 300 people, nobody is rockstar enough to be exempted from documentation work, let alone docs about your own tooling that you provide to other team. My position on that still stands.
But anyway, let's leave it to your Director to hear from both sides.
Murky_Moment@reddit (OP)
I mean my boss directly asked me to create videos showing step by step activities like creating a MongoDB Atlas account, downloading MongoDB from the MongoDB website, running the MongoDB installer, writing basic search queries with a sample dataset, downloading and installing DataGrip etc.
Linking official documentation demonstrating exactly those things were not enough for her.
Of the 32 things she asked me to do, my Director agreed that 29 of those things were better left as references to official documentation elsewhere rather than me recreating those materials.
I don't know about the technical writer comment, as I haven't worked with one before, but I see the premise of his point: my "time" yields more favorable outcomes if I spent that time writing code versus having a video editor open for 2 weeks.
LogicRaven_@reddit
Sounds like your manager has specific ideas about how things should be done. Right or wrong, doesn't really matter - those will be the expectations you will be measured on.
Your skip level manager seems to support this way of working.
Disagree and commit. You proposed another way, but your manager decided on the recordings. Do that and move on.
In retrospective, your proposal was right and it was not necessary to put so much effort into the videos. But not all environments are able to retro and adjust based on experience.
Your options are to accept the disagree and commit way of working or to find another team that is more consensus driven.
If you keep escalating issues instead of committing in this environment, you might end up in conflict with your manager and skip manager.
ihatesilverfish1000@reddit
Why does this sound like an ai wrote it based on Amazon’s leadership principles and whatever else other bullshit they push on people.
The_Axolot@reddit
What's funny is that both this and the top comment mention "disagree and commit". Not saying it's AI, but it's funny to see people unironically refer to those principles outside the company.
LogicRaven_@reddit
Because OP's environment sounds like they have corporate/Amazon type of issues.
I don't know if I should take "Al wrote it" as a compliment or offence. :)
HowTheStoryEnds@reddit
The secret sauce behind chatgpt: it's fully trained on Reddit top 1% ers only.
Ok-Yogurt2360@reddit
There is another option i think. Sometimes the problem is not the message itself but the way you communicate that message. A lot of developers tend to communicate like "this won't work because reason A,B,C". This can become a problem when there is a difference in goals between the manager and the developer. Instead it might pay off to ask the manager to explain their reasoning as you assumed that this was their request. Also explain that what she wants might be a bad idea if it's for developers so she might need to give some extra information in order for you to properly apply her feedback.
Sometimes you first need to show people that you listened before continuing the conversation.
LogicRaven_@reddit
I like that suggestion, thanks!
This could be done early, for example when discussing scope or when OP's manager came back requesting the changes.
TheGratitudeBot@reddit
Just wanted to say thank you for being grateful
Empty_Geologist9645@reddit
You are trying to bare minimum and she wants you to do a whole damn course
Murky_Moment@reddit (OP)
I wouldn't say my original document was doing the bare minimum.
It was pretty concise and focused on what was required for the data migration (installing and running our migration tool, validating a migration, how to troubleshoot the migration tool, etc.) without the extra fluff.
The extra fluff I was forced to add were stuff like:
- How to create a MongoDB account and download MongoDB
- How to install MongoDB on your local machine
- Basics on writing queries for MongoDB to interact with data
- How to uninstall MongoDB from your local machine
etc.
roger_ducky@reddit
Your boss wanted a document a production support intern that just started 1 hour ago could pick up and run with without too many issues.
You were expecting it to be for an experienced developer.
Not sure who is right, but I think that’s the main disconnect.
Murky_Moment@reddit (OP)
Yeah, you're right about the disconnect.
The concern from my is and was that the additional information she wanted me to add watered down the primary objective of the document.
If I'm expecting documentation about a Chrome plugin, for example, and the first 30% of the documentation is about downloading Chrome, installing it on my machine, the benefits of using Chrome, etc. I'm going to think it's trash documentation.
Unfortunately, bringing that concern up with my managers results in me being lectured on not being "vulnerable" on the "advice" I get.
hippydipster@reddit
Feedback is a one way street in your organization, probably because your bosses are too vulnerable to hear it in a professional manner.
roger_ducky@reddit
The way I did it was to use “collapsible” sections that defaults to “collapsed” - Section heading is the high level description usable by experienced people, but the details are there if it’s needed.
Only the sections that are tricky for even experienced people would be expanded by default, but is still collapsible if it’s you doing it for the 30th time.
Even if your manager tells you to expand everything by default, you can still collapse the distracting parts when you use it yourself.
Murky_Moment@reddit (OP)
Good idea. I'll start to use collapsible sections.
mirodk45@reddit
Who were you developing the documentation for? If it was operation users that don't have experience with programming, it really should be as dumbed down as possible.
Again, that depends on who you are developing it for. You'd be looking at it with a biased POV to say it would be trash documentation if it was for users that have a very different skillset than you. Maybe you could've asked more questions around this?
A lot of this situation depends on how you provided the feedback to them, or how did you ask around about what you were doing, which only you know.
You seem to be spiteful or holding a grudge for this. Try to reflect on how the communication could be better because it kind of sounds like you assumed something that was different than what your manager expected. If you just hold a grudge over this it won't be productive or healthy for you at all.
Again, hard to tell from the post alone because the only source of information is you which will always be biased torwards yourself.
Capable_Hamster_4597@reddit
Given her additions the primary objective here is a Work Instruction for some operations guy, because that is what all of them look like.
You just wrote some weird design/process document.
Wide-Pop6050@reddit
I think all of this is quite reasonable. It may be obvious to you now, but it might not be to a new hire or an intern or just far in the future. Adding all of this is not something to get this upset about.
Murky_Moment@reddit (OP)
I see where you're coming from.
My own confusion in all of this is though - my task was to document the functionality of the migration tool that I built so that people could use it to port over data from SQL Server into MongoDB.
My documentation task wasn't about setting up and using MongoDB.
I presented the example to my boss through an analogy - if I want instructions on how to use a new blender I just bought and the first half of the instruction manual is about how to wash and peel vegetables before I put them inside the blender, then I wouldn't want to read those instructions.
I don't know if my perspective tackling that documentation task is wrong or what, but I still feel the surplus information is irrelevant to the document.
Wide-Pop6050@reddit
I don't see where you were penalized for it? It's of course fine to bring up this concern but it's also fine to tell you to do it.
A lot of products have recipes on them. They are not required to have recipes, but having the recipe right there makes it easier for customers to use the product. That's what your boss is having you do.
You might not read the vegetables instructions but other people might find it helpful to have the information right there.
Basically, be open to having this interaction and don't be hostile about it. In any case, your task was to build this documentation and your boss knew how much time you were spending on it. While it sounds like there are other things that have to be fixed, creating documentation is also important and sometimes you do have to complete what you've been assigned to the level expected.
PragmaticBoredom@reddit
To some degree, it is your boss’ job to direct and shape the work. There is an idealized version of the workplace that gets parroted online where managers define the what and engineers define the how, but in practice managers really are involved in the how.
Different managers have different expectations for how much they’re going to direct and control the how. Your manager appears to be deep into the range where they want to control a lot of the how.
Fighting this at every turn is a losing battle. Your options are:
1) Learn to work with your boss. Your job is to understand your boss’ intent, ask questions to clarify, and then execute. It’s not becoming a “yes man” to do this. It’s the job. If you have different ideas then you can propose them, but you have to ready to disagree and commit.
2) Change to another team, department or company where your boss is more hands off. You can’t completely change how your boss operates. If you can’t accept it, you need to move.
hippydipster@reddit
OP did all that. Did everything the way the boss requested.
The problem occurred when OP provided feedback on the impacts of the work - the cost to productivity and the usage levels of the resulting document. Providing that feedback is a vital part of the job since people can't make good decisions in a vacuum.
The response to that feedback was anger and hostility, and then the hypocritical gaslighting response that OP should take feedback more openly and showing more vulnerability.
And you think that's the job.
LiamTheHuman@reddit
Ya this is a good answer. As frustrating as it is they get to decide what gets done, your purview is just how it gets done. If you've provided all of the reasons you think your idea is better and they still want theirs, then you just have to try and understand their way as much as you can and implement it.
thekwoka@reddit
Well, you could not migrate your database to a document store...
doberdevil@reddit
So disappointing when you write docs and nobody reads them. Whether you send a link for something to review or get feedback on, or you write a nice how-to for people to get up to speed. You come back a week later, see the stats, and wonder whether it's worth the effort.
Hziak@reddit
Effective managers will give you clear directions and receive desired results. Normal managers will give you clear directions and not get the results they wanted and work with you to improve the results as needed but not stress you out. Force-divider managers will give you vague instructions, tell you to figure it out for yourself, berate you for not being a self starter, then berate you for not doing it EXACTLY the way they envisioned it.
My friend, your manager is somewhere between a force divider and a regular manager. My condolences.
My strategy is to repeat back the request with more details and then constantly update them with progress along the way. This way, when they go ballistic, they do so in a minor way. You know, agile-like. Explode often at your employee, explode small, lol. But it’s better than wasting your time, finding out it was “wrong” and then doing it again. Just waste your time on their BS once and move on. There’s no winning with someone like that :(
Scarface74@reddit
No good managers will hire well and make sure they have true senior developers and tell them the business objectives. The senior developer will then be trusted to talk to the right people to disambiguate and the manager will delegate the “how” to the employees and if it meets the business objectives, byte their tongue a little bit and if it isn’t the way they would have done it, let it side
rebel_cdn@reddit
Listen here, my friend. You're fighting the wrong fucking war. This isn't about documentation or MongoDB. This is about power. Pure and simple.
Your boss is a weak leader marking her territory like a frightened animal. And her boss? That patronizing prick talking about "vulnerability"? They're in the same tribe.
Machiavelli said "Never attempt to win by force what can be won by deception." That's your playbook right there.
Here's what you do. You become the most enthusiastic motherfucker they've ever seen. You document everything. Every meeting. Every request. Every change of direction. You CC relevant stakeholders. Be clinical about it. Be precise.
Send follow-up emails after every conversation. "As discussed, you'd like me to create 32 screen recordings showing basic MongoDB setup. Timeline estimate is 2 weeks and will delay delivery of Project X. Please confirm this aligns with your vision."
Then, track the hours spent on useless tasks. Measure the lack of page views and user engagement. Become a goddamn metrics machine.
Build relationships with those internal customers. Take them to lunch. Learn their pain points. Get them to submit detailed feedback tickets about what they actually need. Create a paper trail of their real requirements.
The kill shot comes later. When you have allies. When you have data. When her bosses sees the waste. You don't swing the axe. You just position it above her neck and let gravity do its work.
In three months when some VP asks why project velocity is down, you have the data. When someone questions resource allocation, you have the numbers. When people wonder why other projects are behind schedule, you have the receipts.
Remember, this is not about winning the battle. This is about winning the fucking war. And sometimes you win by letting the other person dig their own grave. And remember: the best knife in the back is the one they never see coming.
joelypolly@reddit
This reads like a passive aggressive keyboard warrior fever dream. Just do the job and move on
nonsense1989@reddit
He actually suggested to do the job, and gather evidence, gain political capital.
This is what people should do if they want a more fruitful successful corporate life
joelypolly@reddit
Yeah I am going to have to disagree here, if you are having these types adversarial thoughts where you are calling your manager an animal marking her territory I don’t see how anything positive can come from it.
arfath99@reddit
Damn How can I become a stronger person like you. Thanks a lot, recently I got similar issues with revolving tasks which never ends, which later got blamed on me for delays.
rebel_cdn@reddit
Most people will tell you to let it go. Fuck that. Anger is rocket fuel. Let it burn hot and clean and use it.
Your anger is telling you something important: this is bullshit and you deserve better. Listen to it. Use it. Let it drive you to be more organized, more strategic, more patient than they could ever imagine.
Channel that rage into perfect fucking execution. When they give you meaningless tasks, do them flawlessly. Document everything. Build your case like you're planning a murder. Every email. Every status update. Every wasted hour.
The best revenge isn't served cold. It's served with a spreadsheet that shows exactly how much money they pissed away. It's served with metrics that prove their incompetence. It's served with a paper trail so clear that even the dumbest executive can connect the dots.
The cold satisfaction of watching a micromanaging asshole explain to their boss why they spent six figures on dead-end projects is better than any meditation app.
mirodk45@reddit
Damn I was going to say that this is spiteful but sometimes I like being angry lol (who isn't spiteful in some way anyway)
Murky_Moment@reddit (OP)
Dude, I love this. Thank you. This is the best thing I've read ever.
Wide-Pop6050@reddit
Please don't internalize this. There are some good points in there about building internal power, but I also do think you're missing something about actual business needs.
marmot1101@reddit
The phrase "disagree and commit" comes to mind. It's worth saying something abuot requests you don't agree with and providing the information about why. That's the disagree part. The commit part is just going and doing it. When those things come up I mentally glance at my paycheck and think "if they want to pay me x to do this, it's their money". Like the specifics you mentioned: valueless to anyone actually doing the work(hopefully) because they know it already. But if someone on the street said "I'll pay you $500 to write me a doc on mongodb 097, you in?" I'd give them an emphatic yes and go start copy/pasting.
Counterpoint is that "disagree and commit" is usually a strategy for group decisions. Top down decisions aren't a sign of a healthy culture. But it's hard to change that without boss replacement.
joelypolly@reddit
It sounds like your manager asked for step by step instructions with video (probably because she knows people are lazy) and you were like hey people can Google it and work it out themselves. So I am not surprised that it was not to "spec" in her mind since there is no alignment with what you delivered.
But also if it took two week to put together such a document it will get reviewed as to why it took so long.
flavius-as@reddit
11 out of 300 is quite a good score.
I'd say you did great.
Trick-Interaction396@reddit
Just be the yes man. Way easier. It’s not your company or money.
ventilazer@reddit
You had the opportunity to troll them with 'webscale' and you let it pass? NOOOoooooo!
fnbr@reddit
If they pay me enough, I’m a yes man. Otherwise I get a new job.
serial_crusher@reddit
Your boss is more or less right in this case.
Your users are asking questions that they could have easily googled. Telling them to google it, or just pointing them at the MongoDB documentation and telling them to RTFM, isn’t going to work for them, otherwise they would have already done it.
“Get different users” is generally not a feasible course of action, but “hire a technical writer to document this stuff” sounds like what your company needs. Until that person is hired, sorry to say it’s your job.
Sometimes the only way to get management buy in to hire a specific skill set is to show the cost of having other people spend their time doing that work. This has to be a sustained cost over a long enough period of time for them to take note, not a random one off hell project.
safetytrick@reddit
>It's been 2 months since we published that document, and a grand total of 11 people in an org of 300 people have read it. :/
You have a total audience size of 300 and links to the official MongoDB docs aren't sufficient? That's unfortunate.
Maybe this is a problem that needs a 2 week solution in your organization. It's hard to say because I don't know your organization, but some of my best managers have been very thoughtful about making sure the work they assign is appropriate to the impact and to our business needs.
Good documentation can have a great impact but also... there are other things to weigh, like whether or not your documentation keeps up with the official docs.
Capable_Hamster_4597@reddit
Given her additions what she wanted was a "work instruction" for some operations guy, because that is what all of them look like.
You just wrote some weird design/process document. The problem here is not your boss, but that you've never been exposed to Ops work.
DingBat99999@reddit
A few thoughts:
Murky_Moment@reddit (OP)
Agreed. That's what I would've liked to focus on instead of working on screen recording stuff like:
- How to create a MongoDB account and download MongoDB
- How to install MongoDB on your local machine
- Basics on writing queries for MongoDB to interact with data
- How to uninstall MongoDB from your local machine
- What is NoSQL & benefits of using MongoDB
BeenThere11@reddit
In the long run this will not work. You will always try to be concise while she wants essays and novels which noone likes. There might be an angle which she is trying to cover which you don't know. But she needs to tell you that . But this is a battle you will lose over and over. If I were you , I would either just do what she says without even questioning or quit. No use suggesting anything as she has a set way
farfaraway@reddit
Long, silent stare.
mirodk45@reddit
Well, if your skipper didn't take your side then I'd say you should just yes man it out. I don't know how you provided this feedback to him or for her.
Some things to reflect on, but did you bring this up continuously during the developmnet of the document or did you just bring it up when it was finished due to it taking more time?
If you brought it up continuously and she signed off to do it this way or another, then you provided the concern and she took the decision to commit to her choices, it's pretty normal for that to happen.
Yeah unfortunately I feel like people put a lot of pressure on lack of documentation and eventually someone is asigned to write it, but after it's done nobody reads it or reviews it lol