Entropy Crushers(randsinrepose.com)
randsinrepose.com
Entropy Crushers
http://www.randsinrepose.com/archives/2013/07/15/entropy_crushers.html
6 comments
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.
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.
When you are managing a 100 person project I would question how worthwhile it is to spend 30% of your time programming / engineering.
I would question it too, as well as question other things. But I have no answer, answer, though. It's a hard ball of questions, a 100-people-block team...
>*"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?"
False dichotomy indeed. Here's my answer. Yes, I want to do this work, and yes I want to be an engineer. I think this work is an engineers work, and belongs with his other duties.
False dichotomy indeed. Here's my answer. Yes, I want to do this work, and yes I want to be an engineer. I think this work is an engineers work, and belongs with his other duties.
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.)
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.
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.
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."
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."
Every good engineer is able to discuss tradeoffs.
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.
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.
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.
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.
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.
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?
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.
If you don't mind, what caused those project managers you've worked with to fail?
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.
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.
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.
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.
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.
> 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.
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.
An email list, and a hierarchy of committers through whom changes bubble up will help a lot more than any number of project managers - list(s) can set priorities, explain rationales and keep everyone informed. And committer hierarchies work really well for splitting teams up along code lines
Yes ex-developers promoted into positions in that committeer Hierarchy will do less development and more "steering". But they know that - as do editors at newspapers. Junio Hamano even writes interesting notes on it. But again only a fool hires an illiterate for that position. And only a fool creates a seperate parallel organisation to keep an eye on / communicate with, the software teams. Once upon a time there were few developers and software was a strategic project to reduce costs. Now it is everywhere - like literacy, it infects everything with outsized leverage. And you cannot maintain two parallel organisations - one that does the business and one that then goes off and imements it. It's insanity.
Again I like to use the newspaper analogy - it makes it clear where we need to go. It is probably true that project managers are needed for an organisation that is illiterate at the board level, in the sales force and in the marketing dept.
But companies like GitHub are not showing us how to overlay old illiterate management styles on company with mostly developers - They are showing how to run a company when everyone in it can read and write.
Honestly I do not know how companies prior to printing press organised themselves - but I bet it was different after literacy was widespread - and I bet the old companies did not survive the new
Yes ex-developers promoted into positions in that committeer Hierarchy will do less development and more "steering". But they know that - as do editors at newspapers. Junio Hamano even writes interesting notes on it. But again only a fool hires an illiterate for that position. And only a fool creates a seperate parallel organisation to keep an eye on / communicate with, the software teams. Once upon a time there were few developers and software was a strategic project to reduce costs. Now it is everywhere - like literacy, it infects everything with outsized leverage. And you cannot maintain two parallel organisations - one that does the business and one that then goes off and imements it. It's insanity.
Again I like to use the newspaper analogy - it makes it clear where we need to go. It is probably true that project managers are needed for an organisation that is illiterate at the board level, in the sales force and in the marketing dept.
But companies like GitHub are not showing us how to overlay old illiterate management styles on company with mostly developers - They are showing how to run a company when everyone in it can read and write.
Honestly I do not know how companies prior to printing press organised themselves - but I bet it was different after literacy was widespread - and I bet the old companies did not survive the new
It's interesting that you mention Mr. Hamano since I was thinking about how Git or Linux works while writing my comment. I think we both agree that having someone who steers the ship is then fine, call it PM, higher-ups in the commit hierarchy, etc. The Linux kernel has people like like GregKH or even Linus who I'd call PMs, their main jobs are communication and reviews, not writing code. You don't need a parallel organization for this but you need to create some structure to support a big number of people working in different projects under the same umbrella.
I think your comments are targeted more towards having someone "illiterate" steering the ship and that is a whole different thing that's not mentioned anywhere in the article. I won't argue anything in this regard since I think it's really dependent on the person and not the abstract role, but it seems (judging from the other comments in the thread) that most people have been burned by people with no knowledge giving direct orders on how to proceed.
I think your comments are targeted more towards having someone "illiterate" steering the ship and that is a whole different thing that's not mentioned anywhere in the article. I won't argue anything in this regard since I think it's really dependent on the person and not the abstract role, but it seems (judging from the other comments in the thread) that most people have been burned by people with no knowledge giving direct orders on how to proceed.
so we have highly skilled technical practitioners, intimately familiar with the codebase, such as that found in the "commit hierarchy" of Linux/git.
i cannot equate them with PRoject/product/programme managers, especially not with the overriding focus on planned dates.
We have a industrial management system based on the physical needs of large scale factory style production. And it is ignoring the management styles of the creAtive industries - where there is always a commit hierarchy and this not in it are ignored or supply finan e
i cannot equate them with PRoject/product/programme managers, especially not with the overriding focus on planned dates.
We have a industrial management system based on the physical needs of large scale factory style production. And it is ignoring the management styles of the creAtive industries - where there is always a commit hierarchy and this not in it are ignored or supply finan e
I like your last paragraph. I don't know what the future will bring but I totally agree that today's world works mostly under an old school, factory-style management regime, which is not efficient in industries like ours.
Having said that, I personally still see value in some of those old practices. As [lukatmyshu] mentioned in this thread:
Think of [PMs] 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.
Instead of getting in the way they make life easier for everybody. I do understand that's not the typical experience for most people in our line of work.
Having said that, I personally still see value in some of those old practices. As [lukatmyshu] mentioned in this thread:
Think of [PMs] 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.
Instead of getting in the way they make life easier for everybody. I do understand that's not the typical experience for most people in our line of work.
At the risk of dragging on a thread, I would suggest that a job function that requires "the best" before it adds significant value, and otherwise is anecdotally a -1 sounds like a job function it's risky to hire for.
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.