
“We Don't Need a Project Manager” - el_programmador
https://freelancemag.blogspot.com/2020/02/we-dont-need-project-manager-agile-of.html
======
stephc_int13
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.

------
brianmcc
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!

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

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

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

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

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

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

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

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

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

~~~
kamalhm
Agreed 100%

> They make twice your salary by producing nothing.

this sucked the most

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

