4 ms·

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

by aantix 8y ago

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.

blumomo 8y ago
Sounds like a very good role model for engineers. Thanks for sharing your story.
WhompingWindows 8y ago
Can you explain more about how/when he reduced scope?
rammy1234 8y ago
"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 8y ago
  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 8y ago
    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 8y ago
    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 8y ago
      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.

by aantix 8y ago

blumomo 8y ago

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

WhompingWindows 8y ago

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

rammy1234 8y ago

"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 8y ago
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 8y ago
  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 8y ago
  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 8y ago
    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.