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
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?
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.
That... sounds like forced to me?
Especially to those on a visa, the only one forcing you to remain in the USA / Bay Area / x company is yourself. To put it bluntly, no one is entitled to a job, and this applies to every person. In this scenario, it's not like strangers are being pulled off the streets by Pivotal to pair program.
Suppose an employer asks a loved one to have sex with them or they lose their job. I mean, no one is putting a gun to your loved one's head to have sex with their employer, but something is clearly very wrong at this level right? Suppose they have an expensive debilitating medical condition that can really only be treated with good insurance (I have seen this firsthand where a medication can cost hundreds a month even with insurance (not great insurance but I was an intern, it was all I could afford)). Suppose they tried searching for a job with comparable insurance for years but always come up empty. Now when it's between whether or not you will go homeless with a debilitating medical condition or basically being raped, what would you choose? Frankly, I would rather be raped. I have been in the hospital with great insurance as well, when my condition was at its worst, and even morphine and norco did nothing to make the pain go away; I can only imagine how much worse it would have been on the streets with that kind of unending pain; I can only imagine never being able to find a job like that ever again because I will always be in unending pain and never be able to interview well. Fortunately, I got really really lucky in that I am an engineer who is an American citizen that can find jobs easily that dont require me to physically be there but, most people are not in my position. Back to the point, if someone is more willing to be raped than to not be raped out of fear of the consequences, that's pretty damned close to forced right?
But if I worked for Company X and then one day Thou Shalt Pair Or Else, then yeah, it would feel shitty. Labs developers pair with client developers on engagements and sometimes it feels like they've been dropped from a very great height.
Most of the time it works out fine: people are people and we work in the same industry and share many of the same experiences and passions. Sometimes it just doesn't work for everyone, which is also fine.
But insofar as anyone from Pivotal is explicitly or implicitly saying "or else!", I think they are making a mistake and hope they get feedback about it.
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.
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.
What I meant is since Pivotal is known for uh voluntary-enforced? subscription to XP religious practices you can’t really expect it not to bleed into all aspects of dev process.
Btw I have nothing against pairing in general, just not the way Pivotal does this.
R&D leadership otherwise pretty much don't interfere. Their main business is explaining our strategy, keeping the lights on and teams connected and adjusting allocations between different product and component teams.
We totally did force pairing on client developers, though.
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.
But yes, pairing is very helpful for maintaining context when interruptions occur.
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.