6 ms·
Thank you for reminding me how much I dislike working with PMs I especially can't imagine working with this one. Imagine constantly having to revise estimates
by opportune 7y ago
Thank you for reminding me how much I dislike working with PMs
I especially can't imagine working with this one. Imagine constantly having to revise estimates and getting micromanaged by someone who isn't your manager. The "role responsibilities" conversation would happen very quickly
I find it especially ridiculous that this person is interrupting people two times a day for fresh updates on top of a daily standup. And they even admit their technical knowledge is not good enough to actually be able to help much if there is an issue. If you are bothering and interrupting every single person on your team multiple times a day just in case you need to increment a number in a JIRA board now instead of tomorrow morning, you are wasting people's time. Leave it to the standup.
Your job as a PM is not to micromanage engineers. If that is anybody's job, that is the engineers' managers. Your job is to make the engineers more productive and make sure they're working on the right things - but not at an hourly granularity.
- dilyevsky 7y agoI mean this is from a company that forces pair programming down everyone’s throat (so that you don’t space out on hn as one of stated reasons) so what did you expect? =)
- jacques_chester 7y agoI don't know how you get the idea that it's forced. We're known for it, it's part of the interviewing process for Labs and most of R&D. Folks who don't want to pair generally don't apply. Of those who apply, some try it during the interview process and decide it's not for them. That is a good thing. Besides which, solo work is common too. Most of the field org works solo, Spring folks mostly work solo, I love pairing but currently I'm working solo. If a pair decides they should work solo, they do. Lots of pairs have a rotating arrangement where somebody different works solo for a day or two. I know of teams where they are solo in the morning to review PRs and pair in the afternoon to work on new contributions. None of this is enforced. There is no manual, no rulebook for The One True Way. Nobody tells you how to work. The way works is: the people are nice and smart and want to do the right thing. The rest is largely details.
- p1necone 7y ago>>> Folks who don't want to pair generally don't apply. Of those who apply, some try it during the interview process and decide it's not for them. That... sounds like forced to me?
- jacques_chester 7y agoIt doesn't to me, so this might be a disagreement about the meaning of forced. Nobody is surprised that the default mode is fulltime pairing, we make a point of having candidates experience it beforehand. And as I noted above, pairing isn't mandated. Teams are free to adopt any process they please, but most folks at Pivotal like the defaults and we tend to gravitate to them.
- nfrbc 7y agoI've been in such a team. Pairing was optional, but the team chose to do it, so everyone on the team had to do it. It wasn't "forced" because I "always had the option to quit the job". It was hell.
- jacques_chester 7y agoI'm sorry that your experience was hell. My experience has been different. That doesn't detract from yours.
- nfrbc 7y agoIt's alright. I had great experiences with pairing when it wasn't forced on me and I had autonomy.
- PhasmaFelis 7y agoIf you interview with a company known for making widgets, you don't get to say they "forced" you to make widgets to keep your job.
- isoskeles 7y agoI agree with everything you wrote, but I also wonder if this is less of a distraction in the case of Pivotal since their engineers work in pairs.
- jacques_chester 7y agoSpeaking for myself, I would give feedback to a product manager that asking during the day is unnecessary. I'd try to understand why the PM feels they need to. But yes, pairing is very helpful for maintaining context when interruptions occur.
- rxhernandez 7y agoLess distraction? Unless you are doing cookie cutter crap, you sometimes need to be able to walk away from your workplace for an hour or two to have good ideas; frankly, I've worked with some of the best scientists on this planet and it was common to see them leave their desk for an hour and walk around the block to clear their mind once a day or so. Moreover, I recently fell into the trap of working for an entire week nonstop to solve a really hard problem. Took a few hours off one day to clear my mind and when I came back, I had the problem solved inside of an hour. If I continued down the route I was going down before that time off I can guarantee you it would be more days wasted.
- isoskeles 7y agoI don’t understand how your comment relates to mine.
- pjm331 7y agoUntil recently, I shared your sentiment about product managers, but recent experience has refined my point of view. IMO a good product manager does not focus on trying to understand _why_ things are hard, but rather _what_ things are hard. With this understanding they can either 1) work to change scope/requirements so that the bigggest user pain points are solved ASAP or 2) accept that more time than anticipated is required to solve user problems. Implicit in all of this is the trust that when engineers say something is hard, it is actually hard. When I see the author talking about paranoia, trust is the first thing that comes to mind. To be fair, I don’t think that trust is easy. But I also don’t think that effective product management is possible without it
- FridgeSeal 7y agoEverything is hard if someone is interrupting me too much. Edit: why is the trust so one way? I’m just expected to trust them, but I have to earn theirs like some kind of untrustworthy child?