6 ms·

The challenge I've had with that model is that as a company gets more complex, having someone whose sole job is to focus on the business <> technology interface

The challenge I've had with that model is that as a company gets more complex, having someone whose sole job is to focus on the business <> technology interface is invaluable as people start to specialize. It's often more valuable to have engineers with (say) 6/10 expertise in the business and 10/10 expertise in their technology domain, working alongside PMs with 10/10 expertise in the business and 6/10 expertise in the technology. It's simply very hard to be 10/10 in both domains. I agree that PMs are largely overhead in the early days of a company, provided that you have strong product-minded engineers/designers. (Also just my 2c from heading a PM department / being a former engineer)

DamilolaA 6y ago
I agree but I don't think an individual can be 10/10 in both domains like you inferred. I think there will always be the need for a product person outside the engineers and developers.
- staysaasy 6y ago
  Maybe I wasn't clear, but I specifically do not think that getting people to be 10/10 in all domains should be the goal – I agree with you. This is why you need PMs IMO. Thanks for writing this post and generating this discussion.
  - DamilolaA 6y ago
    Haha, I understand now. Thanks for reading.
deleted 6y ago
[deleted]
gen220 6y ago
Not intended as a rhetorical question, can you describe the dynamics of a long-term successful team where the PM had more business expertise than the engineer? I agree with the division of labor you describe, in principle, but I've never had the opportunity to observe it in practice. Maybe I've only worked at places that are not old + big enough yet. In the (relatively few!) teams I've known, the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up.
- theschwa 6y ago
  I work in an area like this. I'm in the automotive space where there's just a whole slew of industry knowledge to stay on top of; both business practices that change frequently as well as regulatory information. It's pretty rare to see engineers that know the industry as well as the PMs, so we focus heavily on having good communication and dedicating time to make sure features are well understood before any work starts. Our structure works well for us, but I can definitely see how it would be advantageous, where possible, to have engineers who knew more about the business.
- staysaasy 6y ago
  Hey good q. I work in enterprise SaaS and our team builds a fairly complex product. We have a range of technical and non-technical users within a given account, who use our product in different ways, and we have accounts that range in size from dozens to hundreds of thousands of employees with the differences in terms of usage patterns and needs that you'd expect. We also operate at high scale so our engineers need to know a lot about distributed systems and the integrations that our product has with other vendors/platforms/etc. We aren't unique in any of this from my experience. (sorry for being somewhat vague but I try to keep this account anonymous!) It's simply too much for our engineers to spend time deeply understanding every nuance of our business ("how should we make this product tradeoff between the needs of SMBs in Asia vs. the needs of our largest 10 customers across all countries? How will this then impact our pricing strategy?"). But PMs have more context here, because in exchange they don't (for example) know every nuance of how our data pipeline works. In terms of how we make it work, we 1. try really, really hard to align incentives between Eng/PM so that they win together, 2. make sure that teams work together closely and have time to bond, and 3. write things down in planning docs as much as possible, as that's one of the best ways to reduce conflict and also fully leverage non-overlapping expertise. "the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up." That's rough... those don't sound like good PMs to me fwiw. What I have seen are cases where very senior engineers have a better grasp of the overall product vision than some PMs, due to experience and tenure. But they usually don't have more expertise in all of the business questions simply due to relative lack of time spent in that domain. *** All of this isn't to say that engineers don't need to know about the business, or that it isn't a huge advantage if they do (it is). Just that there are so many hours in the day and eventually you've gotta get some division of labor.
rakamotog 6y ago
As a PM who works with multiple scrum teams / products - I agree with this and I understand where OP's message comes from as well. While I work with 4 teams, my involvement in each team is dependent upon the product mindedness of the team. I take care of internal/external enablement, customer documentation, bargaining design bandwidth exclusively for all the cases, for a couple of teams, I call team leads into more than half of my customer conversations, product strategy discussions. I believe the team collectively can decide the best work item for them 80% of times without my inputs. Only when org strategy or market reactions change, we reset. That being said, product mindedness is hard for engineering teams. 2 of the teams I work with, I am giving them inputs on every single feature they need to build. While I dislike doing this for every feature, its upto how the engineering leader envisions their team to function. For some, unless there are jira tickets, properly prioritized, with designs ready, they dont want to involve engineering teammates.

DamilolaA 6y ago

I agree but I don't think an individual can be 10/10 in both domains like you inferred. I think there will always be the need for a product person outside the engineers and developers.

staysaasy 6y ago
Maybe I wasn't clear, but I specifically do not think that getting people to be 10/10 in all domains should be the goal – I agree with you. This is why you need PMs IMO. Thanks for writing this post and generating this discussion.
- DamilolaA 6y ago
  Haha, I understand now. Thanks for reading.

deleted 6y ago

[deleted]

gen220 6y ago

Not intended as a rhetorical question, can you describe the dynamics of a long-term successful team where the PM had more business expertise than the engineer? I agree with the division of labor you describe, in principle, but I've never had the opportunity to observe it in practice. Maybe I've only worked at places that are not old + big enough yet. In the (relatively few!) teams I've known, the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up.

theschwa 6y ago
I work in an area like this. I'm in the automotive space where there's just a whole slew of industry knowledge to stay on top of; both business practices that change frequently as well as regulatory information. It's pretty rare to see engineers that know the industry as well as the PMs, so we focus heavily on having good communication and dedicating time to make sure features are well understood before any work starts. Our structure works well for us, but I can definitely see how it would be advantageous, where possible, to have engineers who knew more about the business.
staysaasy 6y ago
Hey good q. I work in enterprise SaaS and our team builds a fairly complex product. We have a range of technical and non-technical users within a given account, who use our product in different ways, and we have accounts that range in size from dozens to hundreds of thousands of employees with the differences in terms of usage patterns and needs that you'd expect. We also operate at high scale so our engineers need to know a lot about distributed systems and the integrations that our product has with other vendors/platforms/etc. We aren't unique in any of this from my experience. (sorry for being somewhat vague but I try to keep this account anonymous!) It's simply too much for our engineers to spend time deeply understanding every nuance of our business ("how should we make this product tradeoff between the needs of SMBs in Asia vs. the needs of our largest 10 customers across all countries? How will this then impact our pricing strategy?"). But PMs have more context here, because in exchange they don't (for example) know every nuance of how our data pipeline works. In terms of how we make it work, we 1. try really, really hard to align incentives between Eng/PM so that they win together, 2. make sure that teams work together closely and have time to bond, and 3. write things down in planning docs as much as possible, as that's one of the best ways to reduce conflict and also fully leverage non-overlapping expertise. "the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up." That's rough... those don't sound like good PMs to me fwiw. What I have seen are cases where very senior engineers have a better grasp of the overall product vision than some PMs, due to experience and tenure. But they usually don't have more expertise in all of the business questions simply due to relative lack of time spent in that domain. *** All of this isn't to say that engineers don't need to know about the business, or that it isn't a huge advantage if they do (it is). Just that there are so many hours in the day and eventually you've gotta get some division of labor.

rakamotog 6y ago

As a PM who works with multiple scrum teams / products - I agree with this and I understand where OP's message comes from as well. While I work with 4 teams, my involvement in each team is dependent upon the product mindedness of the team. I take care of internal/external enablement, customer documentation, bargaining design bandwidth exclusively for all the cases, for a couple of teams, I call team leads into more than half of my customer conversations, product strategy discussions. I believe the team collectively can decide the best work item for them 80% of times without my inputs. Only when org strategy or market reactions change, we reset. That being said, product mindedness is hard for engineering teams. 2 of the teams I work with, I am giving them inputs on every single feature they need to build. While I dislike doing this for every feature, its upto how the engineering leader envisions their team to function. For some, unless there are jira tickets, properly prioritized, with designs ready, they dont want to involve engineering teammates.