As somebody who is currently working remotely, I think this is a decent take. A distributed culture can definitely get better results than a remote one. But there's something in the section on collaboration I want to take issue with:
> Product Management is mostly about consistent execution of plans, not painting high-level visions.
It's a common view that software developers are an output device, like a printer. You tell them what to build by sending them very detailed instructions. They follow the instructions to the letter, and their work is judged by compliance. Perfection is perfectly conforming to some one else's plan.
I think this is bunk. It might have made a little sense when releases were every 18 months to 3 years. But in an age where companies are releasing dozens of times per day [1], it's foolish. Perfectly following a plan means you believe nobody will learn anything during the time it takes to follow the plan. But if you are releasing early and often, you can learn a ton from users. You can be much more innovative and much more effective than competition.
That only happens, though, if you treat team members not as rote plan-followers but as creative professionals who are deep collaborators. Where vision isn't something a few HiPPOs hammer out in exclusive twice-annual sessions, but where everyone constantly participates and refines it. If a company's process has already shut down collaboration, then of course the difficulties of remote collaboration aren't a problem. The challenge -- still unsolved, I think -- is how to maintain both a high level of collaboration and fast iteration without having to have everyone together.
He goes in more details about product management here:
http ://blairreeves.me/2018/10/16/whats-a-senior-product-managers-job/
I don't believe his view conflicts with yours.
I think it's very possible to have someone present to help define value and priorities, and focus on the people part of getting shit built, while giving engineers a lot of creative involvement and ownership.
Ah, I read that phrase differently, but think I see your point now. There's definitely a type of "plan" that can be very micromanagey, and problematic.
I've lucked out and most plans I've worked with are super, super high level and gives everyone a lot of freedom.
Martin Fowler agrees with you in a post about Agile, https://www.martinfowler.com/articles/newMethodology.html. He says that the old way of looking at programming was to shape it after civil engineering, where there are architects and construction workers. So companies hired an "architect" or two, but most programmers were seen as the construction workers, with straightforward orders that just had to be done.
Fowler cites Jack Reeves, who said that the parallel to a construction blueprint is not some UML diagram but the source code. Therefore all programmers are designers. Programming has a parallel to construction workers, but they are not people, they are the compiler and linker.
Exactly. In contrast with manufacturing, where the goal is to make the same thing over and over, in software we are supposed to make a different thing each time. Whenever we discover that some labor is repetitive, we either automate it (as with CI, CD, and automated testing) or we generalize it (as with libraries, frameworks, and services).
Software would should, as much as possible, be design of novel things. And the only way we know whether something novel really works is to see what happens when people use it. The shorter that feedback loop, the more effective we can be.
Agree. OP's use of "Product management" is not the usual one - but many companies have fuzzy concepts/boundaries between the two so that may be the route.
Usually products without someone filling the product manager (not project manager) role in some way suffer for it.
> Product Management is mostly about consistent execution of plans, not painting high-level visions.
It's a common view that software developers are an output device, like a printer. You tell them what to build by sending them very detailed instructions. They follow the instructions to the letter, and their work is judged by compliance. Perfection is perfectly conforming to some one else's plan.
I think this is bunk. It might have made a little sense when releases were every 18 months to 3 years. But in an age where companies are releasing dozens of times per day [1], it's foolish. Perfectly following a plan means you believe nobody will learn anything during the time it takes to follow the plan. But if you are releasing early and often, you can learn a ton from users. You can be much more innovative and much more effective than competition.
That only happens, though, if you treat team members not as rote plan-followers but as creative professionals who are deep collaborators. Where vision isn't something a few HiPPOs hammer out in exclusive twice-annual sessions, but where everyone constantly participates and refines it. If a company's process has already shut down collaboration, then of course the difficulties of remote collaboration aren't a problem. The challenge -- still unsolved, I think -- is how to maintain both a high level of collaboration and fast iteration without having to have everyone together.
[1] E.g., https://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-da...