3 ms·

Unfortunately this article is totally useless. A non-technical manager is going to read this: > When someone on your team says… >> “I’m making a generic versio

Unfortunately this article is totally useless. A non-technical manager is going to read this: > When someone on your team says… >> “I’m making a generic version of…” >> “I’m creating a framework to…” >> “It’s platform independent.” >> “I’m adding this to make sure it’s future proof.” >> “I really need to refactor this bit…” and then assume that they should fire anyone that mentions these words. In reality, it's always dependent on context and the article specifically does not talk about the technical details that non-technical managers need to learn, in order to judge these situations correctly.

sverige 9y ago
I worked for a really outstanding manager. She told me stories of a previous job where she managed a help desk group for a database application. She does not know how to code, but she does know how to motivate people to do their jobs. She got the team to reduce the average time to close tickets by 75%. Customer satisfaction ratings vastly improved at the same time. The stories of the kinds of things she had to do in order to get a bunch of sullen, lazy, overpaid programmers to do their fucking jobs (her words) were hilarious. I learned a lot from those stories. And btw, she has never again wanted to manage "technical" people again. Every time one of these "how to" articles for middle managers pops up here, a variation of this response almost automatically appears. The truth is that most technical people know nothing about the nuts and bolts of management, but think somehow that they either do know or are exempt by virtue of knowing how to code. The only group that is worse for this sort of ignorance is lawyers, in my experience. I know it is somewhat unpopular to champion the value of having competent management, especially when companies reach a certain size. It's a lot easier for those who have never been managers to simply curse all of them as roadblocks to realizing the fruits of their genius.
- Bartweiss 9y ago
  I don't disagree with you, but I don't really understand how this relates to the parent comment? It's certainly true that good management is a complex skillset, and if managers underestimate programmer's skills then the reverse is also likely. It's true that in some contexts non-technical managers can manage technical teams (and in some contexts they certainly can't). But... none of that makes this article good or useful. It doesn't negate the parent comment at all. This article is bad, and it's aimed at non-technical managers who aren't functional. I suspect your outstanding manager didn't use "what are the memory constraints?" like a magic spell of management, because despite the article's sweeping generalizations ("most common... any system"), there are a lot of contexts where that's literal gibberish. I'm willing to bet she didn't keep a list of words to interpret as "I'm a useless hack". That's basically what this article advocates. Like... "Generic version" translates to "I don't understand the problem"? Really? Last time I said that, it was "I'm making a generic version of our branded UI so the new clients can put their logo in it". That's not even a technical answer, but it still goes on the 'red flag checklist'. I could keep that list going. And the obvious reply is "these are just tips, don't overuse them where they don't apply!" But then what was the point? Knowing when to ask these questions is the entire task of management, and this article is aimed at people who can't do that.
- tboyd47 9y ago
  Totally agree with you on the value of good managers, but I can't imagine how someone with such a negative outlook on their workers can be considered an "outstanding manager," unless it was just tough love. If I worked for a supervisor who spoke about my team that way, I would take it as a sign to start floating my resume (assuming she was serious and not just ragging on them). And if she was so talented, why didn't she stick with it?
caseydurfee 9y ago
Yeah, the article would be much more effective and useful if the advice was "if you hear these phrases, don't assume the developers are lying/bad at their jobs/etc. but do take it as a cue to ask about the business/customer value of doing ____". Being technical or nontechnical is orthogonal to being able to ask the right questions about customer value. Nontechnical managers will go "framework? well if you say so" because they don't understand the tech. Technical managers will go "new framework? well if you say so" if the plan is technically well thought out, ignoring whether or not it actually creates business value.
- infinity0 9y ago
  It's not orthogonal. Being technical, gives you the necessary knowledge to judge whether a claim that uses technical terminology to argue a business case, actually properly argues that business case or not. There's an implicit misunderstanding here that engineers making technical arguments, are not making business cases. That is not correct. Good managers know how to interpret engineer arguments in a business context. Bad non-technical managers, will dismiss technical arguments because they aren't able to translate these arguments into a business context. Sometimes good non-technical managers will nevertheless still do a good job by delegating this judgement based on people they trust. Someone with extra technical knowledge however, would have done an even better job.

sverige 9y ago

I worked for a really outstanding manager. She told me stories of a previous job where she managed a help desk group for a database application. She does not know how to code, but she does know how to motivate people to do their jobs. She got the team to reduce the average time to close tickets by 75%. Customer satisfaction ratings vastly improved at the same time. The stories of the kinds of things she had to do in order to get a bunch of sullen, lazy, overpaid programmers to do their fucking jobs (her words) were hilarious. I learned a lot from those stories. And btw, she has never again wanted to manage "technical" people again. Every time one of these "how to" articles for middle managers pops up here, a variation of this response almost automatically appears. The truth is that most technical people know nothing about the nuts and bolts of management, but think somehow that they either do know or are exempt by virtue of knowing how to code. The only group that is worse for this sort of ignorance is lawyers, in my experience. I know it is somewhat unpopular to champion the value of having competent management, especially when companies reach a certain size. It's a lot easier for those who have never been managers to simply curse all of them as roadblocks to realizing the fruits of their genius.

Bartweiss 9y ago
I don't disagree with you, but I don't really understand how this relates to the parent comment? It's certainly true that good management is a complex skillset, and if managers underestimate programmer's skills then the reverse is also likely. It's true that in some contexts non-technical managers can manage technical teams (and in some contexts they certainly can't). But... none of that makes this article good or useful. It doesn't negate the parent comment at all. This article is bad, and it's aimed at non-technical managers who aren't functional. I suspect your outstanding manager didn't use "what are the memory constraints?" like a magic spell of management, because despite the article's sweeping generalizations ("most common... any system"), there are a lot of contexts where that's literal gibberish. I'm willing to bet she didn't keep a list of words to interpret as "I'm a useless hack". That's basically what this article advocates. Like... "Generic version" translates to "I don't understand the problem"? Really? Last time I said that, it was "I'm making a generic version of our branded UI so the new clients can put their logo in it". That's not even a technical answer, but it still goes on the 'red flag checklist'. I could keep that list going. And the obvious reply is "these are just tips, don't overuse them where they don't apply!" But then what was the point? Knowing when to ask these questions is the entire task of management, and this article is aimed at people who can't do that.
tboyd47 9y ago
Totally agree with you on the value of good managers, but I can't imagine how someone with such a negative outlook on their workers can be considered an "outstanding manager," unless it was just tough love. If I worked for a supervisor who spoke about my team that way, I would take it as a sign to start floating my resume (assuming she was serious and not just ragging on them). And if she was so talented, why didn't she stick with it?

caseydurfee 9y ago

Yeah, the article would be much more effective and useful if the advice was "if you hear these phrases, don't assume the developers are lying/bad at their jobs/etc. but do take it as a cue to ask about the business/customer value of doing ____". Being technical or nontechnical is orthogonal to being able to ask the right questions about customer value. Nontechnical managers will go "framework? well if you say so" because they don't understand the tech. Technical managers will go "new framework? well if you say so" if the plan is technically well thought out, ignoring whether or not it actually creates business value.

infinity0 9y ago
It's not orthogonal. Being technical, gives you the necessary knowledge to judge whether a claim that uses technical terminology to argue a business case, actually properly argues that business case or not. There's an implicit misunderstanding here that engineers making technical arguments, are not making business cases. That is not correct. Good managers know how to interpret engineer arguments in a business context. Bad non-technical managers, will dismiss technical arguments because they aren't able to translate these arguments into a business context. Sometimes good non-technical managers will nevertheless still do a good job by delegating this judgement based on people they trust. Someone with extra technical knowledge however, would have done an even better job.