by el_programmador on 2/14/20, 7:23 AM with 62 comments
by stephc_int13 on 2/14/20, 10:40 AM
But we're not talking about that, we're talking about middle-management, and this is a completely different story.
Very often, managers don't have the legitimacy of a boss or leader, they're not charismatic or visionary, and they often are unable to do or even fully understand the job of those they are managing.
Their role is mostly bureaucratic and to reduce slack.
by brianmcc on 2/14/20, 10:25 AM
Sometimes an organic leader will be great for a group - best person for it - but there's potential for someone more malicious to simply seize power which makes me uncomfortable.
Whether "bad" leaders emerge more from organic situations than from organisation-selected ones is an interesting question!
by i_dont_know_ on 2/14/20, 9:44 AM
If you have a team of relative newbies, they learn from trial-by-fire and grow really fast. I guess it's up to you if you have the time/bandwidth/runway for this process. It's really messy, but 1 or 2 years of this gets you a programmer who is able to talk to customers, able to coordinate among their peers, take feedback, self-manage etc. (or the programmer gets frustrated and quits)
I'm old, so I think it's better to have a PM doing coordination so the programmers can focus on good, clean, scalable code. But, maybe the definition of 'programmer' is changing. Maybe all the above skills are also required to be a 'programmer' nowadays, and the frustrated ones who quit are something else. Code specialists?
I really don't know... I'm heavily biased against it but I'm very interested in what others have experienced with this flat PM-free structure.
by weinzierl on 2/14/20, 11:35 AM
Interesting take. I'm probably a bit older than the author and from my perspective "flat hierarchies" are thing since at least the late nineties. The cynic in me sometimes believes they were actually a thing since forever and hierarchies that seem flat from some viewpoints are just a management instrument to keep workers content.
by crispyambulance on 2/14/20, 12:10 PM
I had been warned about PM's in this company, but I didn't believe it because the PM I was working with was cool, approachable and seemed reasonable. Basically, he set insanely short deadlines always citing critical business imperatives. It was frequently impossible to actually meet the deadlines. We accepted it as a reality of the situation and didn't push back.
One day, near the end of a project, I happened to be in on a "status update" call with upper management. The call was about a dozen people, all but a few in bullshit management/coordinator roles, including the PM (BTW, high PM-to-contributor ratio in meetings in itself should be a red flag). Throughout this whole project the technical side had been always under a timeline fire. We cut corners, poured on the technical debt like there was no tomorrow, abandoned long-going efforts at cleaning up our codebase, fought bitterly with design engineering for access to extremely limited hardware-prototype resources, frequently came in on weekends. We were always late. I had expected to be chewed out by the VP. Instead, the VP graciously addressed my PM and told him "Wow, thank you <PM-name>, we're really impressed that you guys were able to bring this in so early!". I was so pissed off, it didn't even occur to me to say anything. I found out later that not only was this behavior true, it was routine and encouraged by program managers. The PM's had been scoring huge bonuses for "performance" while the teams were always led to believe they were falling behind and always assumed our modest bonuses were just largess bestowed upon us even though we were "unworthy".
I am not going to say we "don't need" project managers, but I think everyone working with them should be skeptical of whatever they say. Since then, I've gotten aggressive about making demands of project managers. If their primary concern is meeting deadlines, then it follows that you can "put them to work" for your team by making demands for resources, access, or information from other parts of the organization. If you meet the deadline, they're more than happy to oblige.
by moksly on 2/14/20, 9:56 AM
I think the biggest issue with project management, and, the agile toolkit is one that this article and a lot like it pass over a little too quickly. I don’t think there is a right answer, because every situation is different.
We have a lot of smaller projects where less than five people build a piece of software that will either be left mostly alone for 25 years, or get completely replaced after five. On those cases utilising the whole agile toolkit is silly, because the only benefit it has is controlling how we learn together, and you can do that with simple light code-reviews. If complexity is really low, building extensive testing may even be a waste of time, and you genuinely rarely need a project manager for just 3 smart co-workers.
On other projects we’re building extremely complex applications for thousands of end-users. That will have a direct impact on citizen lives. In these cases the “NASA engineering approach” is the way to go, and here project managers play a critical role connecting engineering and business. A lot of programmers can do what project managers do, but the interpersonal relationships, the historical knowledge of how to play corporate politics to get things done, and the time to do it, is not something you or your programmers really want.
We really want that assembly line process, but there is just no perfect fit for everything in the world we operate.
by asattarmd on 2/14/20, 11:33 AM
by Phenix88be on 2/14/20, 9:58 AM
Face it : Really good PM are rare. And a team will perform better without PM than with a bad one.
by ck425 on 2/14/20, 10:21 AM
The author is right that it takes skill and practise but I believe training your engineers to work this way is more effective than having a full time role do it.
by sgt101 on 2/14/20, 10:37 AM
If you take responsibility, or responsibility is thrust on you, then you should have compensation and seniority (power) to back this up. So flat heirarchies are a fantasy because without seniority we all stand back, stay quiet and don't make calls or decisions that could land us in hot water.
by speg on 2/14/20, 11:09 AM
Some days we need a quarter back to call the plays. Otherwise, it’s like watching a game of six year olds playing soccer.
by human_banana on 2/14/20, 8:18 PM
It's a hard job. And there are a lot of people that are bad at it that get put in that role anyway. A good manager does way more than you'll ever see, because he's dealing with a world of crap so work can be done.
It so much easier to sit and work on one programming task than to try to keep an eye on all the "big picture" and "small picture" stuff at once.
Once I had a programmer who had an idea for a different data structure for one of our code bases that made generating the objects faster, as the cost of slowing read time a bit. He couldn't fathom the idea that even though his new structure would be good for HIM, the other teams that process that data are not going to be happy if each read is slower.
by dintech on 2/14/20, 11:37 AM
Drivel. We just don't need people who neither understand the technology or the business getting in the way.
by epicgiga on 2/14/20, 4:48 PM
Whether you should have separate project managers and whether you should have a flat hierarchy shouldn't be connected.
As far as PMs go: from long experience, I've yet to witness a good one. I'd say at least 80% of devs are productive assets -- i.e. their work moves the project forward. Maybe 20% of PMs are. In well over half the cases, the team would be more productive, happier, and effective if you simply fired the PM. Others might scrape by with a break even.
As far as flat hierarchy goes: that's anarchy, and anarchy is conflated with chaos for a good reason. You can read a codebase and detect within 5 minutes if it was written by a flat hierarchy team. I'll take a foul mouthed Linus tyrant at the top over a flat hierarchy any day.
The problem is that due to the nature of the job of PMs (supervising & giving orders & planning work etc), they're naturally superordinate in role, no matter how many times you call them a "servant" or "facilitator". But they're also the least qualified types to lead devs. They know nothing about development, and most of what they naturally tend to do to exert control and carry out their role results in purely damaging effects.
As I see it, the only effective solution is: (a) train devs how to manage -- since that's much easier than teaching managers how to dev, (b) establish clear hierachy but with everyone subject to rules (basically replicating how states work).
I'm never one to turn my nose up at the division of labour rule, but I don't believe PM is ever truly labour that can be divided out without interfering with another rule: the wise should lead. PM is too close to a "boss" concept to be separable labour. I.e. it's never truly horizontal, but vertical. Which is why I'll never hire or create such a role, and instead train the best devs to move beyond just typing code and move towards "conductors of the code being typed".
by apt-get on 2/14/20, 9:40 AM
by sveme on 2/14/20, 10:26 AM
by underwater on 2/14/20, 10:31 AM
This is utter crap. And if you honestly believe it then you certainly shouldn't be acting in any capacity related to team performance. Engineers are allowed to make this excuse. There is nothing about the software engineering that stops people from being good communicators.
> Following the Division of Labor principle, there clearly is a space for coordinator in a software development project which cannot simply be wished away.
Coordination and communication is not a specialization. It is something critical to all roles in a team. That's what makes it a team. If you try and centralize coordination into a single person then then you're just adding overhead and extra steps to something that needs to be made as natural and seamless as possible
by m4r35n357 on 2/14/20, 9:54 AM
by tsukurimashou on 2/14/20, 11:04 AM
Actually I'd say they communicate the best with their peers, because they usually put logic and rationality before emotions. I would say that "techs" and "engineers" have the hardest time talking to people like HR, which are usually not best at logic and rationality.