5 ms·

To me you seem to be describing some sort of ideal world. Your vision fails to describe why information is withheld from engineers that would help them do thei

To me you seem to be describing some sort of ideal world. Your vision fails to describe why information is withheld from engineers that would help them do their job. We wont even talk about why doublespeak and so often what seem to be outright lies are told to trusted members of the team. The world you describe is some rational honest place where people are trying to build a system they understand. In an engineering project when we're doing that, you don't withhold information or surprise people, because that causes all sorts of conflicts and false starts, and robs people of the power to contribute. That deliberate lack of communication, which steals perspective and the ability to think about your situation, is the hallmark of the division between management and workers in a growing company. And the only explanation for it is a paternalistic disrespect for the underlings who 'can't handle the truth'.

DigitalJack 13y ago
I'd say his description fits where I work quite well. Essentially the only lack of communication I've ever experienced that hindered my work was from the end customer, or occasionally we have a communication breakdown between teams.
benwerd 13y ago
I call it the "fog of war", and it's a signal that you need to get the hell out. Not all companies have it.
- deleted 13y ago
  [deleted]
aturek 13y ago
I see the job of a dev manager (i.e. his direct reports are mostly engineers) as the following: (1) Filter requests for work to his team to avoid them having to constantly task-switch, with the associated loss of productivity and job satisfaction. (2) Provide his team with the business context for the work he asks them to do, and trust them to handle details. (3) Get his team the support they need to do their jobs. These all involve tradeoffs. If you constantly tell your team every part of every business discussion that takes place as part of (2), you can fail at (1) and distract them from their long term goals and work. I've worked with managers that didn't protect their team at all, and who constantly forwarded emails and repeated conversations to us until we could barely get anything done before having to switch to a new task. I've also worked with managers who didn't tell anyone anything, and let their reports toil in the dark for months before letting them know that most of their work was wasted. A good manager will sometimes fall on either side of the line; a bad manager will consistently err to one side. Managers are just like engineers - there are a lot of bad ones, and some good ones, and size of the company is pretty orthogonal.
- yaddayadda 13y ago
  This, except that it applies to all managers not just dev managers.
calinet6 13y ago
"Never attribute to malice that which is adequately explained by stupidity."
- rday 13y ago
  I cringe each time I read this quote. It isn't helpful. I have had too many people take advantage of "second chances" by pleading ignorance. Maybe I'm just too cynical. The only take away here is that you have to treat malice and stupidity the same. The person in question either messed up intentionally, or is too stupid to do their job. You should fire them, or quit, whichever position you happen to be in.
  - cgore 13y ago
    "Any sufficiently advanced incompetence is indistinguishable from malice."
    - jfolkins 13y ago
      Heyyyyyy, no bogarting Clarke's third law. http://en.wikipedia.org/wiki/Clarke's_three_laws http://en.wikipedia.org/wiki/Clarke's_three_laws
      - cgore 13y ago
        Grey's Law: http://www.johndcook.com/blog/2009/08/21/magic-stupidity-malice/ http://www.johndcook.com/blog/2009/08/21/magic-stupidity-mal...
  - calinet6 13y ago
    It helps you frame your point of view and, true, avoid cynicism. Stupidity can also be more subtle. It's not always clear cut idiocy, there's a continuum between total and absolute head-desk stupidity, and ignorance or information blindness that's outside one's control. Whereas malice is much less a continuum: the only question is, to what degree is this person an asshole, and when will they strike next? Intentionally and willfully hurting others is another world from anything unintentional. The law treats it the same way. Hence, I believe it is helpful. In any case, it's a razor: it separates illogical conceptual rabbit-holes from that which is more likely to be true.

DigitalJack 13y ago

I'd say his description fits where I work quite well. Essentially the only lack of communication I've ever experienced that hindered my work was from the end customer, or occasionally we have a communication breakdown between teams.

benwerd 13y ago

I call it the "fog of war", and it's a signal that you need to get the hell out. Not all companies have it.

deleted 13y ago
[deleted]

aturek 13y ago

I see the job of a dev manager (i.e. his direct reports are mostly engineers) as the following: (1) Filter requests for work to his team to avoid them having to constantly task-switch, with the associated loss of productivity and job satisfaction. (2) Provide his team with the business context for the work he asks them to do, and trust them to handle details. (3) Get his team the support they need to do their jobs. These all involve tradeoffs. If you constantly tell your team every part of every business discussion that takes place as part of (2), you can fail at (1) and distract them from their long term goals and work. I've worked with managers that didn't protect their team at all, and who constantly forwarded emails and repeated conversations to us until we could barely get anything done before having to switch to a new task. I've also worked with managers who didn't tell anyone anything, and let their reports toil in the dark for months before letting them know that most of their work was wasted. A good manager will sometimes fall on either side of the line; a bad manager will consistently err to one side. Managers are just like engineers - there are a lot of bad ones, and some good ones, and size of the company is pretty orthogonal.

yaddayadda 13y ago
This, except that it applies to all managers not just dev managers.

calinet6 13y ago

"Never attribute to malice that which is adequately explained by stupidity."

rday 13y ago
I cringe each time I read this quote. It isn't helpful. I have had too many people take advantage of "second chances" by pleading ignorance. Maybe I'm just too cynical. The only take away here is that you have to treat malice and stupidity the same. The person in question either messed up intentionally, or is too stupid to do their job. You should fire them, or quit, whichever position you happen to be in.
- cgore 13y ago
  "Any sufficiently advanced incompetence is indistinguishable from malice."
  - jfolkins 13y ago
    Heyyyyyy, no bogarting Clarke's third law. http://en.wikipedia.org/wiki/Clarke's_three_laws http://en.wikipedia.org/wiki/Clarke's_three_laws
    - cgore 13y ago
      Grey's Law: http://www.johndcook.com/blog/2009/08/21/magic-stupidity-malice/ http://www.johndcook.com/blog/2009/08/21/magic-stupidity-mal...
- calinet6 13y ago
  It helps you frame your point of view and, true, avoid cynicism. Stupidity can also be more subtle. It's not always clear cut idiocy, there's a continuum between total and absolute head-desk stupidity, and ignorance or information blindness that's outside one's control. Whereas malice is much less a continuum: the only question is, to what degree is this person an asshole, and when will they strike next? Intentionally and willfully hurting others is another world from anything unintentional. The law treats it the same way. Hence, I believe it is helpful. In any case, it's a razor: it separates illogical conceptual rabbit-holes from that which is more likely to be true.