4 ms·

Entropy Crushers

47 points by fbuilesv 13y ago

lmm 13y ago
Maybe these mythical good project managers exist, but I've never seen one. I wouldn't have the first clue how to hire one. So I'd rather do a bit of less pleasant non-engineering work than lose the whole company.
- Subuatai 13y ago
  I've found with project managers more than other positions, you get what you pay for. The best project managers command exorbitant fees because of their reliability, to the point where bringing them in can be counter productive. But if you have the cash, you can definitely attract top level talent.
- casual_slacker 13y ago
  If you don't mind, what caused those project managers you've worked with to fail?
  - lmm 13y ago
    The worst was the one who was an ex-programmer and would add ridiculous technical requirements to everything. We spent 1/4 of the time writing useful product features and 3/4 of the time working around those requirements. But the best company I worked at eliminated project managers about halfway through my time there, not because they were bad per se but because they simply weren't contributing anything. Teams had good contact with clients so had an understanding of which features were wanted (the team lead did have to prioritize client feature requests, but that wasn't a whole lot of work or argument). Engineers were perfectly capable of allocating assignments with a reasonable balance of fun and not-fun (and honestly I don't see how a PM is supposed to save you time there, unless they know what everyone on the team likes and doesn't like). And written, rigid feature specs would only have slowed us down - developers were trusted to have a reasonable sense for what a feature needed to be.
  - michaelt 13y ago
    At some companies, project managers have "responsibility" for projects but no authority or engineer time to direct. They get the projects that are too important to cancel, but not important enough that anyone with real authority in the business wants to spend time pushing for them.
- lukatmyshu 13y ago
  In 11 years I've only worked with two that I thought were great. But those two have convinced me that they can add a tremendous amount of value. Think of them as oil in an engine. The best ones know how to communicate extremely well, are paragons of organization, and know how to facilitate decision making.
  - cpeterso 13y ago
    What was the background of the two great project managers you worked with? Had they always been project managers or did they transition from some other discipline?
rgrieselhuber 13y ago
In my experience, project managers are hired by executives because of their ability to communicate with them. Specifically, their ability to discuss tradeoffs in every decision is the reason that executives would prefer to speak with them over engineers. Engineers, unless they've specifically been educated otherwise, tend to see the world in very black and white terms and, as a result, try to lecture executives on what they "have to do."
- jkbyc 13y ago
  Every good engineer is able to discuss tradeoffs.
  - fbuilesv 13y ago
    Most engineers are good at discussing specific tradeoffs, especially technical ones. Finding tradeoffs that relate directly to a product's roadmap and its impact in the rest of the organization and then discussing them with the persons "outside the loop" (higher up, executives, etc.) is not a common trait.
- analog31 13y ago
  The purpose of middle management is to organize and communicate information. With that said, insulating upper management from the rank-and-file can be dangerous. Not wanting to hear what the engineers think is one thing. Not wanting to know is quite another.
tudorconstantin 13y ago
I see project managers as facilitators: - they help us, the developers, to get the job done - they are the buffer between the client and us On the project that I work for about 2 years, no PM has any experience in programming Perl - one is coming from an economic background and the other was a java dev. We get along really well - we are colleagues and partners, not in a boss/slave relationship. They have to trust us that we get the job done and we don't bullshit them and we have to trust them that they don't overpromise and they hold our back against the client when that's needed. Until now, everything works perfect.
agravier 13y ago
> By suggesting you don’t need project managers, you’re saying that you, an engineer, want to do this work and my question is, “Do you or do you not want to be an engineer?” I have a problem with that sentence. I read it as a false dichotomy. In fact, the good project managers I have met came primarily from a strong engineering background, with additional manager traits, and had more than just some interest in engineering problems: they not only understood the problems, but also were able to participate in those discussions, as they were respected by other team members for their technical ability.
- amirmc 13y ago
  What you've said fits perfectly well with the sentence you disagree with. The person who came from a strong engineering background is probably not doing much (if any) engineering work now. That's totally fine and for some teams/companies/products, is exactly the background you need.
  - agravier 13y ago
    I see your point, but I see an implicit either-or choice in it. I must ask: would it not better for team cohesion and efficacy if managers were doing 30% engineering, and engineer had the option to have their word in management? I have experienced that, and although it was maybe more tiring for the manager on the short term, he was a real part of the team, and decisions were never taken in contradiction with technical factors. Vice versa, engineering was more targeted towards real customers needs that if we had no manager. On the long term, it was less work per product, because the more integrated team ran more efficiently.
    - maibaum 13y ago
      When you are managing a 100 person project I would question how worthwhile it is to spend 30% of your time programming / engineering.
      - agravier 13y ago
cgio 13y ago
I am project manager. The issue is that usually, when you go down the "project management" path, you end up having more people managing than actually working (because no smart person wants to report to someone who is not evidently better than him/herself.) Also, the more people managing, the more management reporting artifacts the developers have to produce or at least reiterate, and the more incentive is given to the smart team members to disregard any authority and play the system. I agree with the project manager as an entropy crusher, but creativity requires entropy. The ideal PM should manage entropy, not crush it (e.g. during definition entropy has to increase, as you approach delivery it has to decrease.)
lifeisstillgood 13y ago
Aaargh - no. Crush chaos and entropy through decoupled design, through APIs that are simple and affordant, crush chaos by making it everyone's job to make the whole simpler. Don't add people who cannot code and hope they will improve things. You want to formalise it - have a checkin flag #simpler=+1 or 0 or -1. Everyone should look at a -1 and ask "what can I do to make that a +1" Simpler simpler simpler. Edit: I always come back to the idea that software is a new form of literacy - and if you see a software issue, reframe it first as "reading and writing". What we are arguing for here is there should be non-coding people running around finding out "stuff" in some super human manner and then reducing chaos with it. Reframe that software house as a newspaper - What foolishness says hire illiterates to run around discovering what the newspaper needs? Hire editors, create a process around the writing, proofing and editing of the written word. At the software house - do you need project managers - or do you need editors? Senior developers who realise their time hands on the code base is now over and they need to guide, edit, mentor. Now build respect into that. And then tell me how respected national newspaper editors will feel if the guy in the office next door, who now has as much influence on the decisions as they do - and that guy is illiterate. Treat software like written words - build organisations like newspapers, and hire no-one who cannot read.
- fbuilesv 13y ago
  > Crush chaos and entropy through decoupled design, through APIs that are simple and affordant, crush chaos by making it everyone's job to make the whole simpler. The author and yourself are talking about entirely different things. Decoupled design and APIs won't help you manage tens or hundreds of developers, it won't help you guide a team towards the same goal. It also won't help as a communication buffer between all the different areas/developers. This is where the PM comes in. The author's thinking _above_ the code level. With his 105 developers, even if they're all producing amazing software, you still need to setup a comm. and product guidance machinery [0]. > Don't add people who cannot code and hope they will improve things. I'm sorry to nitpick this specific phrase from your comment but a lot of people has expressed this "people who can't add code won't add value" thinking. The reality is that the author never mentioned bringing non developers to do the job (but from the comments on this thread it seems this has been a recurring theme for many people). Speaking from my own experience, the best PMs almost always started as developers. You don't have to bring an outsider with no technical knowledge, you can just find the right team member who's already starting to take over this and then make it "official". This prevailing "but he can't code" ideation shows that most people's experiences with PMs has been bad and us developers bring it up because code is where we excel, it's what we can understand and fix. The reality is that if the PM failed to do his job correctly it was most likely not related to his coding skills (but again, we frame it in terms of what we understand, code). [0] Keep in mind that this does not mean you need to add more layers to your company structure. Empowering current employees seems to be working just fine for companies like Valve and GitHub.

47 points by fbuilesv 13y ago

lmm 13y ago

Maybe these mythical good project managers exist, but I've never seen one. I wouldn't have the first clue how to hire one. So I'd rather do a bit of less pleasant non-engineering work than lose the whole company.

Subuatai 13y ago
I've found with project managers more than other positions, you get what you pay for. The best project managers command exorbitant fees because of their reliability, to the point where bringing them in can be counter productive. But if you have the cash, you can definitely attract top level talent.
casual_slacker 13y ago
If you don't mind, what caused those project managers you've worked with to fail?
- lmm 13y ago
  The worst was the one who was an ex-programmer and would add ridiculous technical requirements to everything. We spent 1/4 of the time writing useful product features and 3/4 of the time working around those requirements. But the best company I worked at eliminated project managers about halfway through my time there, not because they were bad per se but because they simply weren't contributing anything. Teams had good contact with clients so had an understanding of which features were wanted (the team lead did have to prioritize client feature requests, but that wasn't a whole lot of work or argument). Engineers were perfectly capable of allocating assignments with a reasonable balance of fun and not-fun (and honestly I don't see how a PM is supposed to save you time there, unless they know what everyone on the team likes and doesn't like). And written, rigid feature specs would only have slowed us down - developers were trusted to have a reasonable sense for what a feature needed to be.
- michaelt 13y ago
  At some companies, project managers have "responsibility" for projects but no authority or engineer time to direct. They get the projects that are too important to cancel, but not important enough that anyone with real authority in the business wants to spend time pushing for them.
lukatmyshu 13y ago
In 11 years I've only worked with two that I thought were great. But those two have convinced me that they can add a tremendous amount of value. Think of them as oil in an engine. The best ones know how to communicate extremely well, are paragons of organization, and know how to facilitate decision making.
- cpeterso 13y ago
  What was the background of the two great project managers you worked with? Had they always been project managers or did they transition from some other discipline?

rgrieselhuber 13y ago

In my experience, project managers are hired by executives because of their ability to communicate with them. Specifically, their ability to discuss tradeoffs in every decision is the reason that executives would prefer to speak with them over engineers. Engineers, unless they've specifically been educated otherwise, tend to see the world in very black and white terms and, as a result, try to lecture executives on what they "have to do."

jkbyc 13y ago
Every good engineer is able to discuss tradeoffs.
- fbuilesv 13y ago
  Most engineers are good at discussing specific tradeoffs, especially technical ones. Finding tradeoffs that relate directly to a product's roadmap and its impact in the rest of the organization and then discussing them with the persons "outside the loop" (higher up, executives, etc.) is not a common trait.
analog31 13y ago
The purpose of middle management is to organize and communicate information. With that said, insulating upper management from the rank-and-file can be dangerous. Not wanting to hear what the engineers think is one thing. Not wanting to know is quite another.

tudorconstantin 13y ago

I see project managers as facilitators: - they help us, the developers, to get the job done - they are the buffer between the client and us On the project that I work for about 2 years, no PM has any experience in programming Perl - one is coming from an economic background and the other was a java dev. We get along really well - we are colleagues and partners, not in a boss/slave relationship. They have to trust us that we get the job done and we don't bullshit them and we have to trust them that they don't overpromise and they hold our back against the client when that's needed. Until now, everything works perfect.

agravier 13y ago

> By suggesting you don’t need project managers, you’re saying that you, an engineer, want to do this work and my question is, “Do you or do you not want to be an engineer?” I have a problem with that sentence. I read it as a false dichotomy. In fact, the good project managers I have met came primarily from a strong engineering background, with additional manager traits, and had more than just some interest in engineering problems: they not only understood the problems, but also were able to participate in those discussions, as they were respected by other team members for their technical ability.

amirmc 13y ago
What you've said fits perfectly well with the sentence you disagree with. The person who came from a strong engineering background is probably not doing much (if any) engineering work now. That's totally fine and for some teams/companies/products, is exactly the background you need.
- agravier 13y ago
  I see your point, but I see an implicit either-or choice in it. I must ask: would it not better for team cohesion and efficacy if managers were doing 30% engineering, and engineer had the option to have their word in management? I have experienced that, and although it was maybe more tiring for the manager on the short term, he was a real part of the team, and decisions were never taken in contradiction with technical factors. Vice versa, engineering was more targeted towards real customers needs that if we had no manager. On the long term, it was less work per product, because the more integrated team ran more efficiently.
  - maibaum 13y ago
    When you are managing a 100 person project I would question how worthwhile it is to spend 30% of your time programming / engineering.
    - agravier 13y ago

cgio 13y ago

I am project manager. The issue is that usually, when you go down the "project management" path, you end up having more people managing than actually working (because no smart person wants to report to someone who is not evidently better than him/herself.) Also, the more people managing, the more management reporting artifacts the developers have to produce or at least reiterate, and the more incentive is given to the smart team members to disregard any authority and play the system. I agree with the project manager as an entropy crusher, but creativity requires entropy. The ideal PM should manage entropy, not crush it (e.g. during definition entropy has to increase, as you approach delivery it has to decrease.)

lifeisstillgood 13y ago

Aaargh - no. Crush chaos and entropy through decoupled design, through APIs that are simple and affordant, crush chaos by making it everyone's job to make the whole simpler. Don't add people who cannot code and hope they will improve things. You want to formalise it - have a checkin flag #simpler=+1 or 0 or -1. Everyone should look at a -1 and ask "what can I do to make that a +1" Simpler simpler simpler. Edit: I always come back to the idea that software is a new form of literacy - and if you see a software issue, reframe it first as "reading and writing". What we are arguing for here is there should be non-coding people running around finding out "stuff" in some super human manner and then reducing chaos with it. Reframe that software house as a newspaper - What foolishness says hire illiterates to run around discovering what the newspaper needs? Hire editors, create a process around the writing, proofing and editing of the written word. At the software house - do you need project managers - or do you need editors? Senior developers who realise their time hands on the code base is now over and they need to guide, edit, mentor. Now build respect into that. And then tell me how respected national newspaper editors will feel if the guy in the office next door, who now has as much influence on the decisions as they do - and that guy is illiterate. Treat software like written words - build organisations like newspapers, and hire no-one who cannot read.

fbuilesv 13y ago
> Crush chaos and entropy through decoupled design, through APIs that are simple and affordant, crush chaos by making it everyone's job to make the whole simpler. The author and yourself are talking about entirely different things. Decoupled design and APIs won't help you manage tens or hundreds of developers, it won't help you guide a team towards the same goal. It also won't help as a communication buffer between all the different areas/developers. This is where the PM comes in. The author's thinking _above_ the code level. With his 105 developers, even if they're all producing amazing software, you still need to setup a comm. and product guidance machinery [0]. > Don't add people who cannot code and hope they will improve things. I'm sorry to nitpick this specific phrase from your comment but a lot of people has expressed this "people who can't add code won't add value" thinking. The reality is that the author never mentioned bringing non developers to do the job (but from the comments on this thread it seems this has been a recurring theme for many people). Speaking from my own experience, the best PMs almost always started as developers. You don't have to bring an outsider with no technical knowledge, you can just find the right team member who's already starting to take over this and then make it "official". This prevailing "but he can't code" ideation shows that most people's experiences with PMs has been bad and us developers bring it up because code is where we excel, it's what we can understand and fix. The reality is that if the PM failed to do his job correctly it was most likely not related to his coding skills (but again, we frame it in terms of what we understand, code). [0] Keep in mind that this does not mean you need to add more layers to your company structure. Empowering current employees seems to be working just fine for companies like Valve and GitHub.