“We Don't Need a Project Manager”
freelancemag.blogspot.com
freelancemag.blogspot.com
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.
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!
Edit: grammar.
Best leaders are those who don't "want" to be leaders but have leadership thrust upon them. I think if everyone follows this basic principle then it should be good in all settings irrespective of organic/chosen/imposed.
This is currently the case in my group and there is no easy way to get iout of it.
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.
Anecdotally I've experienced it for the most part not working, especially when you have a lot of juniors to coordinate. I have however once in my career been lucky enough to work on an extremely small (4 developers) but also very experienced team that was able to self coordinate and move very quickly without any PM or overly complex structure in place.
The other side is that it's very difficult to evaluate a coordinator's performance, as an outstanding team poorly coordinated will look much the same as a poor team outstandingly coordinated. As an engineer, if I see a non-technical PM then there's a significant chance that they're contributing nothing but bullshit, and presumably someone from the business side would be equally skeptical of a PM with no business experience.
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.
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.
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.
Face it : Really good PM are rare. And a team will perform better without PM than with a bad one.
> They make twice your salary by producing nothing.
this sucked the most
Good PMs know how to gatekeeper from other departments and leadership, identify engineers strengths and defer to their expertise, and remember answers to the same technical questions so they can at least build upon their knowledge of the craft. I have no clue how rare they are, but those are what I try to do on a regular basis on top of disseminating information as it changes from product stakeholders to engineering.
I can list a whole host of reasons why engineers can flounder without a mediator between product and marketing leadership to make sense of requests. I’m also acutely aware that great engineers can make things work in lieu of someone who owns that process.
I’m not going to bash engineers as a whole though. I’m not ignorant.
Good PM, yes, they can. But how does that required any kind of skill than have more value than an engineer skill ? I haven't met any good PM in 7 years and 3 jobs... It's kind of sad really.
In my opinion, a PM is a jack of all trades, and a master at communication and organization. Engineers on Team A who can identify why Feature A has dependencies on Feature B that Team B is building is awesome; but that’s the accepted exception. I’d also argue there’s a case that an engineer’s time should be spent building and writing code, not managing the release schedule to best meet business goals. Leave that to the PMs.
They will manage the schedule based on what the engineers estimations (and try to push for a better release date).
Any way, good PM must exist and add value to a team. But most of them don't know what they are doing... It's really painful.
Once accused me of lying, in which I showed screenshots of the bugtracker proving otherwise. She has a habit of being disrespectful, particularly to staff from one side of an acquisition (it was really acquisition in name only). Her reputation goes far and wide.
One was frigging awesome. She helped shield our department from problems created by other department. She knows which decisions should be decided by whom. I'd kill to have her on the team again.
Third one claimed that the test teams were wasting their time discussing a certain topic; one in which at least three tests leads with way more experience in testing are reluctant to make a hard call on. She came from the same place as the first one.
Fourth is alright, not as great as the second PjM I've worked with.
I've probably encountered more and forgotten the experience.
I've seen my share of bad ones, and the bad ones can sour your culture pretty quick.
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.
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.
Some days we need a quarter back to call the plays. Otherwise, it’s like watching a game of six year olds playing soccer.
Why would you want to use them together? Their differences reflect differences in the underlying business areas. If those businesses need to somehow be combined, their representatives will have to come to a common understanding of how to translate between them, and then that business understanding can be reflected in a corresponding way in the code.
> Bob doesn't grok what Alice did when he goes to implement something in that area, and ends up introducing a bug of his own.
The biggest barriers to understanding are length and indirection, and they're the only way to make code consistent. It's easier to understand code that describes the unique problem that it solves in a unique way than code that tries to force that solution into some generalised framework.
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.
Drivel. We just don't need people who neither understand the technology or the business getting in the way.
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".
This is what happens if you're lucky when you have teams without a PM. One person will end up taking the lead. I've seen this go completely off the rails too, where nobody took the lead and the project went nowhere.
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
Its unsurprising businesses feel like they need a mediator between the childish way a lot of development teams want to behave and people working as actual professionals within businesses. It would make sense that in smaller pure tech companies where the 'culture' is that everyone behaves like that it may be less necessary, but it certainly is in a more classical business setting.
Maybe I'm misunderstanding something but doesn't make sense to this whole thing lol. Soda, Water and energy drinks and snacks is cool idea though but the whole alcohol drinking part is just confusing to me. I wonder how much they spend on these perks extra, well some people might use it much more than others... I guess that's probably a good reason to buy in bulk though. but I know some of that stuff isn't even healthy and some people with unknown heart conditions died from drinking too much caffeine too... I feel like unlimited energy drinks some people would go overboard.
There is also nothing stopping developers from writing excellent documentation, but yet that is extremely rare.
Great non-fiction writers are not necessarily able to crank out a best selling thriller the next year.
It also takes significant time, even if you are professional technical writer. They do take multiple iterations at writing it too.
If you are good at both writing documentation and developing, you are better off if nobody finds out and dont try to push you toward doing it too much.
How many hours of their day do you suggest developers spend with the stultifying task of coordinating and communicating with management?
Or, it’s why you have a northbridge on your motherboard, and don’t expect the CPU to handle everything by itself.
But ignoring that: Most coordination and communication is within the dev team, or horizontally. As for the rest - as much as a single group manager would; or less; or more. But it will be divvied up between the group's members. And they will have to coordinate this kind of communication and rotations of duty amongst themselves.
To add, you know who really sucks at communication with "technical peers"? It is non technical management. The biggest communication issues are all along this gap.
Also programmers are the owners of their means of production. Most artists too, but for some reasons they are often paid very badly if they aren't get excessively popular by accident.
I think there were a lot of changes since the beginning of the industrial revolution and if knowledge and abilities increasingly keep being the primary ressource of production, the theory could fit at some point.
At my last job I wrote a driver for a proprietary framework to talk to closed hardware units, which made lots of money. I could not have done this without the company's license as a developer for the framework, or without the protocol specification for the hardware units. In this case, the company I worked for owned the means of production, not me, so it's perhaps unsurprising that I got a very tiny cut of the fruits of my labour.
Edit: or maybe not rarer, but the costs of machine and license become smaller compared to your wage.
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.