I don't read the article like that: it's not a list of (all) things your manager doesn't know, it's a list of (some) things your manager might not know. In other words, these are all things your manager should know, but they might not know some of them. And then the advice is to tell them. (But with concrete examples and more worked out.)

> I don't read the article like that: it's not a list of (all) things your manager doesn't know, it's a list of (some) things your manager might not know.

I have a feeling this is the same core truth, but worded differently and with less distaste for managers.

> In other words, these are all things your manager should know, but they might not know some of them.

Should, but don't, is not doing their job. Most engineers don't have the luxury of using this defense their day to day job. Yeah, I should be doing testing, but I don't know. I should be writing clean code, but I don't know. I should be communicating with my colleagues, but I don't know. I should know what weight this bridge can hold, but I don't know.

Most of these examples wouldn't work with just 'tell them'.

> And then the advice is to tell them

Tell them what? Manager, this isn't working? I'd be laughed at for this kind of approach. Maybe it would work if I went in a structured approach, with my homework done, with actionable items in the context of the company, but then I'd end up doing their job.

----

I don't want my point to be that managers shouldn't be told what issues might exist, I hope the point I get across is that we shouldn't be doing their jobs and it's their responsibility to get this information through the numerous tools they hold under their belt, and not depend on engineers to spoon feed them.

Imagine if this is the only way a manager gets the know how. If I'm an engineer with a loud mouth I can crash the entire department by feeding my manager select information.

> Should, but don't, is not doing their job. Most engineers don't have the luxury of using this defense their day to day job. Yeah, I should be doing testing, but I don't know. I should be writing clean code, but I don't know. I should be communicating with my colleagues, but I don't know.

This is needlessly antagonistic. All teams have gaps, but effective teams help each other out. For instance, a good manager will give you air cover when things are underestimated or unforeseen difficulties arrive. Similarly, good engineers will point out risks and potential problems even if it is not directly in their execution path.

The most toxic teams are ones where everyone keeps their head down and looks for every opportunity to say "not my job" whenever any larger or unusual challenges are identified. Based on your comment it seems like you think that ICs can't get away with this, but managers can, and I assure you that neither is true.

Yes, but in order to do the level of management you are asking, it necessitates they become micro managers. This is a considerably worse state of affairs, as you allude. Managing is about helping you grow as an employee, helping you with your career and helping you do your job. The best managers are the ones that stand in the way of things that block these. How do you suppose they do this without you telling them what you need?

I gave the article another read and found some advice even weirder. I'm not going to go through all of it, but this bit stood out to me.

> I’ve found it really valuable to start out conversations about compensation / promotions in a fact-finding way – instead of saying ”hello, i want a raise”, it’s a lot easier for everyone to start with “hey, how does this work? can you explain it to me?”.

How does what work? If I want to learn more about compensation / promotions, I ask about that. If I want a raise, I want to discuss the raise. We can conflate them, but why?

But the conclusion I would like to summarize my point:

> Being good at telling your manager the right information at the right time and asking for what you need is a superpower. It makes you way more valuable to have on a team (because your manager knows they can trust you to give them the information they need), and it’s more likely that you’ll get what you want (because you’re making it easy for them to do that!).

Flipping this upside down, "being good at asking your team the right questions at the right time and asking for what you need is a superpower. [...]". This is great advice! Both for a team member and for a manager. The difference is that the team member has to deal with the actual production also, while the manager's 'production' is the actual thing being flipped. So if things are flipped and I end up micro-managing myself, is the manager actually doing his job?

Of course when there are issue that makes sense to bring it up, we should do it, but I'd argue that it's more of the manager's job to be on top of things and ask the right questions, at the right time, without micromanaging, because that's his job, and it's why it's such a hard job to do right. It's a lot easier in my opinion to find good engineers than to find good managers, and I believe this advice is good for engineers that have bad managers and it's worth calling it out.

I think this is a much clearer take, well, at least to me! The key here, and if I'm mistaken - forgive me, is that a good manager needs to be a good communicator, but doesn't get in your way. By the same token, it can be said that to help them help you, communicating with them is essential. It may seem obvious, but I'm sure lots of us have experienced bad managers that don't do this...