[aantix]

A top-notch VP of Engineering who knew when and how to reduce scope (because he was an active contributor to the code base) and was also one of the best coders in the room.

1) Pair programming, with the VP stopping by every couple of days asking "where are you guys stuck" and would actively try to solve our problem.

2) Story prioritization - each PM would write product stories for the backlog in an effort to get them in the next sprint. The same VP (above) would review each of those stories in front of the PMs and developers. If it were really lazily written, the PM was shamed, it was thrown out, and could be resubmitted for the next week. Developers got to ask questions, add tidbits regarding prior work that may need to be studied to complete the story.

3) If a bug made it out in the release, it was no-one's fault. Everyone worked as quickly as possible to either create a patch or roll back the feature completely.

P.S. That VP of Engineering is Andres Camacho. He's in San Francisco. And he's amazing. Work with him if you have a chance. He's well known for hiring Jr developers, training them via pairing with them intensively, getting them up to speed quickly and having them contribute meaningful code within a few days. He's now the CTO of Better Therapeutics.

[rammy1234]

"the PM was shamed, " this does not sound right. does it ? why to shame, ignore it and move on. shaming has to be a private affair not public.

[rahimnathwani]

I'm a PM and didn't have any negative feeling when I read that part of the comment. I was reflecting a bit on why. I think it's three things:

1. If I've not done my job as a PM, then it's much better to figure it out earlier rather than later. If engineers struggle on without the right support from a PM (whether that's stories/requirements, oral clarification, ...) then that can slow things down or create worse outcomes. So I'd rather someone call out holes in my work at the earliest possible opportunity, then be polite so the problem can get larger.

2. In a high trust environment, people can take criticism of their work without taking it personally. It's hard to achieve this type of relationship (with specific people) or environment (with a group of people), but can make things much smoother.

3. I feel the job of the PM is to make the team successful through whatever means possible. Feedback/criticism directed at me is a valuable source of information to support that, whether or not I am the correct target.

[eitally]

Agreed. Often the most challenging part of being a PM (besides coercing xfn collaborators to care about your priorities) is getting agreement on the amount of research that needs to have been done to justify a new feature, product or user journey. This is usually either business case development + ethnographic user research OR confronting of technical debt and engineering limitations/opportunities ... and it's rare to get everything right the first time. It's also rare to work in a place where a PM has the luxury of dedicating enough time & resource to create a complete requirement before the tech teams start working.

I also read "shot down" as a constructive and expected feedback mechanism. In small teams, it might be the TL or eng mgr who provide this feedback, but for larger product business cases are often required for review by executive stakeholders, and they will always be terse, hopefully constructive, but frequently come across as overly negative. Why? Because they're gatekeepers and it's their job to ensure the best opportunities are pursued and the rest are either back burnered or sent to the graveyard.

[rammy1234]

shaming is not criticism. criticism is an expression of disapproval of an idea not the person. But shaming is personal. This is not constructive to improve.

[rahimnathwani]

You are, of course, correct.

But people often choose whether or not to take something personally, and their reaction determines the outcome. Consider the following situations:

A. (Bad case) You criticise my idea/proposal, and I interpret that as you criticising/shaming/blaming me (i.e. I take it personally). I then decide to ignore your criticism, because I feel it is based on your personal opinion of me, which I know is incorrect.

B. (Better case) You criticise me personally (e.g. "you're a bad PM, as evidenced by X"), and I take it dispassionately, trying to understand why you feel that way, use that to inform my understanding of the situation, and find a way to make things better.

In A, my idea was criticised, and there was no positive outcome.

In B, I was personally shamed, but there was a positive outcome.

I cannot change how people communicate (at least in the short term) but I can change how I react, and hence what impact I have on the outcome.

[rammy1234]

people reacting to situations is about individual. but we know every individual is unique and different. Team should be encompassing and not assuming. CEO or Project Director's boundary is only with the idea and not the individual.

Idea can be criticised, never individual. Your argument may sound right, but it is not considering everyone. Your argument is saying how one should react, but is not answering what if one reacts differently. How can we mend it.

Leader is one who is compassionate and has ability to differentiate idea from individual. Work is not entirety. Idea will never define a person. whenever we critique, it is best to keep it till the idea and never to person. my few cents.

[rahimnathwani]

As I said before, you are correct :)

And I always aim to criticise the work/behaviour and not the person.

However:

- When I criticise a piece of work, someone can still choose to interpret it as shaming or a personal attack.

- When someone criticises me personally, I can still choose to focus on the useful part. I don't have to feel offended/upset.

[PeterisP]

If a proposal is bad because the idea has flaws, it's appropriate to express disapproval of the idea.

If a proposal is bad because a decent idea is lazily written (as the original post states), it's appropriate to express disapproval at the person - if the only thing that was needed to change in order to make this proposal better was the person's attitude (do your homework properly before submitting the proposal instead of wasting everyone else's time), then it is constructive to target that attitude.

[WhompingWindows]

Can you explain more about how/when he reduced scope?

[blumomo]

Sounds like a very good role model for engineers. Thanks for sharing your story.