

Entropy Crushers - fbuilesv
http://www.randsinrepose.com/archives/2013/07/15/entropy_crushers.html

======
agravier
> 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
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
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
When you are managing a 100 person project I would question how worthwhile it
is to spend 30% of your time programming / engineering.

~~~
agravier
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...

------
cgio
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.)

------
tudorconstantin
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.

------
rgrieselhuber
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
Every good engineer is able to discuss tradeoffs.

~~~
fbuilesv
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.

------
lmm
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.

~~~
casual_slacker
If you don't mind, what caused those project managers you've worked with to
fail?

~~~
lmm
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.

------
lifeisstillgood
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
> _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.

~~~
lifeisstillgood
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

~~~
fbuilesv
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.

~~~
lifeisstillgood
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

~~~
fbuilesv
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.

~~~
lifeisstillgood
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.

