That's a junior approach thinking you know more than your pm and have no respect if they didn't come from your ranks.
In the end if you are difficult you become easy to replace.
In the end if you are difficult you become easy to replace.
One was a CEO who hadn't any technical background, but he knew what ICT could and could not do for his company.
One day we rewired all of our network, a massive weekend job. He was there, even if the only thing he could do was pulling network cables out of bags and straightening them. He saw who and what worked or not, he saw where we struggled even if he didn't understand a word of our technical mumbo jumbo.
I found out he was always there on the ground for every major operation in his company, not only ICT. The result was he knew the company inside out. Nobody ever tried bullshitting him. I still have massive respect for him, years later.
Then there is exhibit B, a manager from the 'you dont have to understand ICT to manage it' school. Everybody under him spends 3/4 of the time in meetings or filing useless forms. Nobody dares touching important things, so hard decisions get pushed in the future. It happens urgent work needs doing and the only person capable of doing it sits twiddling thumbs as the spreadsheet says maximum team capacity has already been reached. He redefined the words 'major incident' as there were to many under the old definition. His teams keep losing important members, everybody hates each other, work that should take 10 minutes takes months. But he always has a spreadsheet demonstrating it is not his fault.
I know who gets the respect.
The first example must be a small company.
2. This sounds like a manager in an enterprise level company
If you choose to work where a multi-level manager structure exists you should give that manager respect because he has to navigate a political landscape that takes certain skills.
Besides managing people and knowing what customers want have nothing to do with knowing your specific skills. Should the CEO know marketing, accounting, legal, etc as well as the experts in their positions?
Considering 2,this demonstrates what is wrong with big enterprise. If the politics are more important than the work, the work won't get done. Just like I don't have respect for Trump just because he managed to rule the most powerfull country in the world, I don't have to respect a manager who's team fails again and again, after which they get thrown under the bus just to save the face of a higher up.
Note how the CEO mentioned had no ICT knowledge, he just knew enough to knew where he stood. Same for marketing, accounting etc..
You seem to have completely missed my point, which is that technical leads and PMs should have domain knowledge and that this is why DevOps is not in danger of failing at competent companies.
That technical pm is a luxury and will move on at some point. You don't need him your team with a strong lead or more senior developers could work with a regular pm and get the job done.
Let me show you where this slippery slope ends: Teams with a strong lead or more senior developers could work without any PMs and still get the job done.
Oh. Wait a second. This happens all the time! Does this mean those teams achieved their success without any management happening? Or does it mean that technical people in those teams who did do the management work did it without the title?
IME, far more often, it's the latter.
We are talking about what is the most efficient. One of the point of Agile was to attempt to lower the division of tasks (and I'm saying that even if I don't like the way it was attempted nor the overall effect 20 years later) because having a broader vision of things is more efficient than trying to communicate (to what I would add: IF the project scale is reasonable enough to do that...); thus: a little bit of PM tasks, a little bit of working with customer, etc -- at least more involvement than if crappy requirements were produced after crappy contracts were signed, and neither of them could be revised.
So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem? You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.
It isn't, and I'm not going to go there. But discussion about work activities does need appropriate and accurate labels, for it to be effective.
> So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem?
Who said it's not good or that there's a problem? I didn't.
> You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.
I don't know what I wrote that leads you to believe this, but I said nothing like this. You seem to be reading too far into things I wrote; or worse, things I never wrote.
----
To try and clarify what I meant and where I was going: I was talking about accurately identifying the work that actually happens. Specifically, I was trying to show my parent commenter, ipaddr, how their erasure of such work leads to poor results for everyone involved, including the people trying to even talk about it.
I'm not trying to argue for a better salary or title — I've already got too much and too many of those, as you hope. But I've seen this very discussion happen too many times with clients of mine, with the same devolution. People think their problems will be solved if they get a good "PM". If said PM lacks technical background, they think they can just pair them with a good senior engineer and all will be good. I've seen this fail enough to know that's not how it works; and not because the senior engineer wasn't "senior" enough or "good" enough. As I said elsewhere[1] in this thread: There does exist a big difference between "lead or senior developers" who are good at development and those who are also good at using their technical knowledge to manage a team's work. A non-technical PM lacks that essential latter part, and if they have to rely on a "developer" to step up and fill that role, they're still a PM, but they're not the sole person doing PM any more.
Failure to identify when there's more than one person fulfilling management responsibilities can and does lead to poor planning and hindered execution.
No, that is not the point your parent seems to be making. Your parent talks about "earning respect by learning on the job", but you are stuck at "having respect because of background".
Your parent leaves open the possibility that a PM without technical background can still become a good PM, and even lays out what they think is required for that to happen. You're stuck at "you don't respect them, got it".
----
I'd like to remind you of this point from the HN guidelines: Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
In the end if you are difficult you become easy to ignore. Or worse, worked-around.
The "strong lead or senior developers" you're talking about: I call them TMs. Technical Managers. Because that's what their job becomes when the PM isn't technical enough. In the end, it's not the PM who "turns out fine" when paired with TMs; it's the combo of PM and TM who turn out fine.
There does exist a big difference between "lead or senior developers" who are good at development and those who are also good at using their technical knowledge to manage a team's work. A non-technical PM lacks that essential latter part, and if they have to rely on a "developer" to step up and fill that role, they're still a PM, but they're not the sole person doing PM any more.
They turned out fine if somebody else do that technical management work. Except that if not recognized as such, that someone else is not paid appropriately, does not have official authority nor ctual support of boss nor is he present at higher ups meetings to speak for himself. It makes the leading part much harder and is breathing ground for resentment or simply getting tired and giving up. And then it all starts failing.
It is kind of like saying that senior developer does not have to know all that much, if juniors are very good. Sure, but then your juniors are actually on underpaid senior positions. And it ki d of works, until junior senior figures and finds better place to work at.