Hacker News new | past | comments | ask | show | jobs | submit login
“We Don't Need a Project Manager” (freelancemag.blogspot.com)
35 points by el_programmador 9 days ago | hide | past | web | favorite | 62 comments





The problem I have with most of the "project manager" bullshit is not related to hierarchy or structure. In my opinion, the role of a boss/leader is useful and most of the time necessary.

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.


I've started seeing this pattern as well, and it really has me wondering.

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.


One thing that's really come through with Agile is how little value traditional project planning actually brings to real-world software development. You can do any amount of estimation, forecasting, scheduling... but actually the only question that's worth getting a useful answer to is "what should I work on this week?", and the amount of work you have to do to figure that one out is much smaller. What you do need is someone who can understand the priorities that different stakeholders (including engineering) have, weigh those up, and come up with overall priorities for engineering to execute on; that's an extremely valuable role, but probably not to the extent of being a full-time position for someone who contributes nothing else.

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.


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


Leaders will either be imposed, chosen, or emerge organically. Not necessarily formally/titled as such, but they will emerge.

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!


>> but there's potential for someone more malicious to simply seize power which makes me uncomfortable.

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.


Definitely some truth here, but it favours upper management benevolently choosing leaders IMO. Those with talent/ability but without the desire to lead will never compete with the actively power-hungry.

Indeed a great question! I wonder if it could be possible to prevent this to happen by not hiring, potentially, "bad" people. Which probably opens a can of worms.

Edit: grammar.


If you can solve the "don't hire 'bad' people" problem you will be a very rich person :-D

> but there's potential for someone more malicious to simply seize power

This is currently the case in my group and there is no easy way to get iout of it.


Kind of been there, done that, it ain't nice, good luck. Don't be afraid to make your own move if it's the only escape option!

Dominic Cummings in the UK for example

> We are increasingly seeing a transition (especially in the West) to a "flat hierarchy" system

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 work in the public sector, which is a large enterprise beast that has it’s reason for being outside of tech, but a reason that increasingly can’t be executed without tech. So this has obviously coloured my perspective in a way that may be strange to people in all tech teams in all tech businesses. We operate more than 500 applications from contractors, we’ve build around 200 ourselves and we utilise around 25 co-municipality open source solutions where we project lead but buy code from small local shops. We also track and benchmark everything.

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.


There is “Project management” work, like estimating how long the entire project will take, how much they will charge, tackling dependencies, holding clients accountable etc. that needs to be done. If you don’t have a Project Manager to do this, you’re probably using engineers to do it.

My opinion of professional project managers has been ruined by an experience 10 years ago where I was in a "matrix" structured organization.

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.


And yet most of the PM I have worked with are useless. They are the daily meeting host that understand nothing. They make twice your salary by producing nothing. They assign blame on people but don't even understanding what those people are working on. They are good at nothing but throwing more work in the current sprint, pushing for deadlines and saying "yes" to every stupid request from other department.

Face it : Really good PM are rare. And a team will perform better without PM than with a bad one.


Agreed 100%

> They make twice your salary by producing nothing.

this sucked the most


It’s truly mind blowing how intelligent comments can be here, but the circle jerk of engineers vs non engineers rings so loud.

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.


They are extremely rare; I've worked with exactly one competent PM ever, and they were technically trained and knew how to write code. The conclusion I'm forced to draw is that non-technical PMs are dead weight.

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

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.


The value of the skill is relative. Some places may have incredible technical talent in their engineering team, but the team doesn’t know an SEO optimization from a consistent UI architecture.

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.


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


I've had experience of working with at least 4 PjMs so far.

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.


There's a reason that Scrum Master / Agile Coach roles exist, they help train up the team to work in a self organised way. Sometime a Product Manager or Engineering Manager does it as part of their role but it's the core of what agile coaches do.

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.


Leadership de-facto means responsibility.

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.


I think we have this problem now. Too many chefs in the kitchen has led to an unorganized codebase. Lack of direction/vision. No consistency. We have a “scrum master” but they are more to facilitate meetings, the work falls to whichever developer happens to take it on which can be different than the one who previously worked in that area.

Some days we need a quarter back to call the plays. Otherwise, it’s like watching a game of six year olds playing soccer.


Whenever I've seen "organisation", "direction", "vision" or "consistency" in a codebase, it's always done more harm than good. One of the cornerstones of agile is that you ruthlessly pare away anything that isn't necessary for delivering user-facing functionality - YAGNI. If anyone is reshaping the style of an area of code, they should be able to justify that in terms of the value they're delivering in their current two-weeks-or-smaller story. Each part of the codebase ends up uniquely shaped to the business problem it actually solves, and is as simple as possible to solve that problem. You don't need architecture; what would adding it gain you?

How do you deal with all the uniquely shaped pieces of code? If they are radically different, you won't be able to use them together later. 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.

> If they are radically different, you won't be able to use them together later.

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.


There is also the case of Alices & Bobs using inconsistent variable & function names, etc. if left unchecked and make life difficult for everyone. Organization/Consistency in code is a real problem that can't be simply wished away.

Wow, so many people who lack the skills to be a manager dismissing it. I've worn several hats during my time, and doing manager stuff was the hardest. Dealing with interpersonal relations on the team, managing expectations from internal and external clients. Translating tech speak to and from marketing speak. Running code reviews, etc, etc.

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.


This conflates two different concepts: division of labour and hierarchy.

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


> Its a known fact that most techies suck at interpersonal skills and communicating with their own peers

Drivel. We just don't need people who neither understand the technology or the business getting in the way.


Indeed, once you reach a certain scale (even a small one), a separate manager is often needed. However, they can be elected as well, rather than imposed top-down.

I currently act as a lead whatever: I program, architect and coordinate a team of seven. Works quite well and is pretty enjoyable. Though I obviously program less than I would like to.

So you're PM in function, not in title...

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.


> Its a known fact that most techies suck at interpersonal skills and communicating with their own peers, let alone with other stakeholders in a project.

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


This is just a continuation of the infantilisation of development teams. I don't know whether it's because the industry is young so there are a lot of younger people working in it, or that they're the loudest as they're using social media and blogs more, but it seems pretty common at the different places I've contracted at. All these silly games they play in the scrum 'ceremonies', the need for pizza and beer and games in professional settings. I don't see it in any other business setting.

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.


Not sure how the industry ended up with it, but it's crazy. I've witnessed discussions where people point blank refuse even to interview with companies that don't have fussball table. On the other side, companies advertising ridiculous things, like bean bags, beer fridges and some other trivial shit. Seriously, there are all these smart people usually solving extremely difficult problems and yet at the same time it feels like some of them never left nursery.

Yep. I got a friend who works remotely but had to fly to New York for meetings. Showed me some pictures from his trip, They have a beer available in the fridge, along with bottled water, energy drinks and stuff... I'm not much of a drinker but he told me he thinks it's for after hours lol. but not sure what the actual rule is... or why people would even be there after-hours? I don't get it... Seems like any other jobs, drinking on the time clock you'd get fired... If you worked at a bank or Walmart and was drinking on the job, I got a feeling that wouldn't go over very well... Then I'd be worried about screwing up due to drinking but maybe you don't drink enough to get drunk...

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.


I don't agree wit that assessment. There's a difference between fun and unprofessional. You can treat your teams like adults while still encouraging them to have fun.

Of course we should go out to a proper restaurant and remember we don't order the cheapest bottle on the menu., and none of the cheap whisky JW black at the very least

> There is nothing about the software engineering that stops people from being good communicators.

There is also nothing stopping developers from writing excellent documentation, but yet that is extremely rare.


Excellent communication (edit: I meant documentation) is neither valued nor rewarded. By rewarded I mean it does not get you better salary, is not advantage when looking for job and does not bring up your social status.

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.


Writing good docs is a skill. Good communication is a skill. Not everyone has it - but it's something every can practice and get better at, regardless of your 'job title'.

For me, as a developer, programming is the art of writing instructions for a computer. Programming is writing. Writing is the difference between a good developer and an overpaid button presser.

Yes but surely you see there's a difference between writing docs and writing code?

Great non-fiction writers are not necessarily able to crank out a best selling thriller the next year.


If I could upvote you three times, I would.

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.


> 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

How many hours of their day do you suggest developers spend with the stultifying task of coordinating and communicating with management?


You’ve got my upvote. Good communication and coordination takes up a lot of time. And the more people who need to remain in communication and coordinated, the more time it takes.

Or, it’s why you have a northbridge on your motherboard, and don’t expect the CPU to handle everything by itself.


You're assuming that, outside the dev team, there's a hierarchical organization. That's not always the case and perhaps the same principle can be applied to make this less the case.

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.


If coordinating with management is time consuming and tedious then you have a problem with management as well as development. Layering more people on top (a project manager) to manage that dysfunction is a band-aid solution. It is always better to remove the root cause completely.

That's not utter crap. To have people who are both technical and can communicate well not just with people at their level but also upwards or downwards,while adjusting the way they explain things accordingly, is rare.

It's part of how programmers are turned into commodities.

You keep using that word "communist" . . . etc.

Actually in this case it makes sense, communist theory says workers should only produce what is socially necessary, and so in many cases managers are just there for nothing. However communist theorists like engels also wrote about some industries requiring management, so it's not totally out of the question, but i don't think you'd find many communists saying software is one of those industries.

Which is weird since open source at least has the properties of knowledge belonging to everyone.

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.


The means of production for a programmer is not always as simple as just a computer.

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.


No, I was referring to the knowledge you have, not to the device you are currently using. Compared to the beginning of the industrial revolution, where factories could only ever be build by extremely wealthy individuals that could afford the expensive machines, today we have a situation that the hardware becomes cheaper and cheaper and the skill set of workers become the most prominent resource. I would indeed expect your situation becoming more and more rare.

Edit: or maybe not rarer, but the costs of machine and license become smaller compared to your wage.


I concur. Most custom financial software interfaces with systems that a developer could never get access to without the sponsorship of an institution. It’s really, really hard to write good software without a test environment. Mostly because specs and docs are always riddled with errors or omissions, if they exist at all.

> Its a known fact that most techies suck at interpersonal skills and communicating with their own peers, let alone with other stakeholders in a project.

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.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: