
Ask HN: Should I fire my PM, my engineer, or myself? - abrax3141
Purely hypothetical (of course): Small early startup. PM is driving the engineer crazy by being hyper-agile -- changing design (not architecture) as he gets an idea into his head. (Using appropriate issue management and kanban, but on a daily -- or faster! -- not bi-weekly basis.) Meanwhile, engineer is griping and complaining about this -- wants a project plan, or at least a few days worth of one. OT1H, one could say to the engineer, this is how small early startups are. OT2H, one could tell the PM to work on a more deliberate plan&#x2F;pace. OT3H, I could become a woodworker. What do you recommend?
======
gtvwill
Mate your PM isn't managing very well if he can't get his thoughts on the same
path for more than a few days. Tell your PM to sit down...work his shit
out...if he thinks he needs to change his mind tomorrow...tell him he better
have bloody good reason a. to change his mind. and b. why he didnt think of
that reason the day before when he put the plan in place. Your PM is screwing
you.

------
greenyoda
Changing the design on a daily basis doesn't seem like a winning strategy -
the engineer will never be able to complete anything since they're chasing a
moving target, and so you'll never get an MVP that you can actually give to
customers and get feedback on.

I don't think you necessarily need to fire your PM, but sit down with him and
ask him to slow down. New ideas are great, but if he thinks about them for a
while before suggesting them to the engineer, it will weed out some of the bad
ideas before they get implemented. (Maybe the PM should switch to decaf coffee
or get more sleep?)

If this continues, your engineer will burn out and/or quit.

~~~
cimmanom
This. I’m not usually a fan of scrum, but this is one of the problems it can
help solve. You can decide to zig or zag every couple weeks at the end of a
sprint, but for those couple weeks you’ll hold steady in one direction so that
you can make reliable progress (and force the people making changes to sleep
on them and bundle them up.)

Frankly, though, your PM sounds ineffective - especially in a kanban system.
Part of their job is making sure there’s a shippable MVP SOON that you can
THEN iterate on IF improving it at that point will have more business impact
than building the next feature will. And they’re clearly undermining that
effort.

------
lhorie
Is it just the 3 of you? Why do you have one PM for one engineer? What is your
role? What value do frequent changes bring? Is there profitability in sight
when sticking with a plan?

Ask yourself hard questions. If you're coming on an online forum to offload
the responsibility of having a hard conversation with a team member due to a
fear of hurting someone's feelings, maybe you should fire yourself.

~~~
abrax3141
I’m not avoiding the conversation. I’m trying to decide which is right. Seems
like everyone agrees that the PM is wrong. Now I can have the hard
conversation.

------
dman
What is your role in the startup?

~~~
abrax3141
Hypothetical startup (of course): I conceived the product, hacked the (fully
working!) prototype co-founded the company, hired the engineer to harden the
“easy” part of the product. I do the AI.

~~~
dman
I mean organizationally - do you see yourself as the CEO? The other two people
have clearly defined hats (PM / engineer), but it is unclear what hat you are
wearing.

~~~
abrax3141
I would like to devolve to being the AI engineer in an engineering team that I
(initially) build around me. Eventually someone else - a CTO - would build it
up further. Thus the PM, who is supposed to be working with the engineering
team (at the moment just a MERN engineer and me) and first users to turn my
(fully working, but ugly) prototype into a scalable, usable product.

