Entropy Crushers
randsinrepose.com
randsinrepose.com
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.
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.
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.
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."
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.
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.
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.
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.
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
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 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
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.