30 ms·

I’m not too fond of the “separate Product and Engineering organizations” model… The whole idea of having one branch of the org chart telling another what to do

I’m not too fond of the “separate Product and Engineering organizations” model… The whole idea of having one branch of the org chart telling another what to do is kind of flawed. I think it’s often better to divide up the product over many separate small teams, each with a product focused “mini CEO” and a tech focused “mini CTO”.

makestuff 4y ago
yeah i was at a startup that had SVP of product and SVP of engineering. For the entire year I was there 60% of the time was spent in meetings where they just blamed each other. Engineering would say product didn't tell us what to build so we just built what we thought they wanted and product would say they told engineering what to build but they did it incorrectly. The company I am at now has a leader who has product and engineering reporting to them for their charter basically following the mini-ceo/cto you described. It has its issues but works much better than the alternative.
- ipaddr 4y ago
  You needed a project manager SVP reporting to cio to make that work with a department for requirements
  - chrisabrams 4y ago
    Thank you for this it was much appreciated humor during my lunch break!
- zingar 4y ago
  The leader who has product and engineering reporting to them is a CTO. Someone who only does one of those things is not a CTO and shouldn’t have C-level decision making power.
P5fRxh5kUvp2th 4y ago
100% this, what ends up happening is product wedges themselves between business and technical so they wield the power due to having business' ear, and any attempt by technical to communicate directly with business is met with severe reactions. The thing to understand is that very likely your technical people are smarter than your product people. In addition, part of software development is being able to identify what needs to be solved. Any developer with a modicum of experience knows how to do this. Just as you have a technical leader on the team, you need a technical architect on the team. That person can interface with the business or the business analyst (or both) as needed. separate teams is a degenerate case for strong software development. I once literally had a business person ask "who should be involved in this conversation" and my response was "product and technical so we can advise". Product responded after me with "Product" and the lack of technical there was deafening. It becomes a power play, the theory of the different departments works out about as well as putting a racist and a black man in a room to collaborate on race relations.
- taude 4y ago
  theres a lot of orgs where product people will be onshore and the technies offshore, so the model and barrier kind of makes sense (for this operating model), and typically the Product people will be the more expensive/smarter/critical resource in this case.
  - kenhwang 4y ago
    In my personal experience, that model has rarely led to a good product, good technical implementation, or even good development velocity.
  - P5fRxh5kUvp2th 4y ago
    In this setup you need onshore to manage that offshore team or you're just asking for pain.
- rektomatic 4y ago
  >very likely your technical people are smarter than your product people I'm guessing you work in the technical side of things?
  - P5fRxh5kUvp2th 4y ago
    - ButterBiscuits 4y ago
      - P5fRxh5kUvp2th 4y ago
        ButterBiscuits 4y ago
hipppocamp 4y ago
> I think it’s often better to divide up the product over many separate small teams, each with a product focused “mini CEO” and a tech focused “mini CTO”. This only gets you so far. It tends to optimize for speed of teams but at the detriment of the overall product. Eventually you end up with splintering of ideas, terminology, duplicate functionality and features that almost work the same way. You see it across all big companies and products. AWS is a great example of the mess they've made between services and how they don't always play well together and you end up with teams actually competing as they assert that their product should own something that's others shouldn't. I wouldn't be surprised if Google is in the same mess (Drive is a fucking cluster of a mess and it's basically impossible to use for anything productivity related - and don't get me started on how Google Classroom works within that ecosystem that's a double yikes). Same goes for Atlassian. What's the saying? Don't ship your org chart?
- AndreasHae 4y ago
  Can you think of any FAANG scale orgs that haven’t run into having a fragmented product landscape? Maybe there’s just a hard limit of how much complexity one business unit can handle before it stops being able to scale up. With that in mind, decentralized teams with tight product+tech collaboration seem to be a successful model. Otherwise we would probably already have seen an example of a successful tech company with centralized product/tech departments.
  - Jare 4y ago
    The fragmentation issues doesn't need FAANG scale, and is already a possibility for any org that scales past 50 people or so. If a team has the potential to interfere with another, or the need to depend on another, you already have the primordial soup for conflict and widening cracks.
  - kcexn 4y ago
    Isn't Apple very successful with centralised product/tech departments?
    - 4y ago
deleted 4y ago
[deleted]
vsareto 4y ago
That's usually what happens: assigned product people to engineering teams who focus on what the engineering team works on, then they report one level higher. You shouldn't be seeing a new decision-making Product person every month or so - that's bad news bears. It gets to this state naturally if your product is fairly large and has loose/well-defined modules that are distinct from one-another.
spacemadness 4y ago
I’m dealing with this right now and it feels like we’re at constant war instead of collaborating.
bkuehl 4y ago
Our company did a restructuring a couple years ago where the web/user-facing part of the dev team was moved under the same branch with Product. At first I was skeptical, but it has worked out very well. Product Managers and the developers feel like they are on the same "team" working toward a better product. There's a lot more collaboration with PMs trying to get developer input/insight, etc. Things used to be a lot more siloed, and I think it really hurt innovation.
- drewbeck 4y ago
  This is a really intriguing approach! I can see why it works.
PragmaticPulp 4y ago
Fortunately, this article isn't either. The second half of the article is about breaking down that wall (From the article): > Eliminating the wall between Product and Engineering is essential to establishing high performing product teams. (Quoting parent post): > The whole idea of having one branch of the org chart telling another what to do is kind of flawed. Completely agree, and all of these approaches are destined to fail if it turns into different branches of the org chart fighting with each other. Most of my issues with separate product orgs have come from product executives who feel the product/engineering relationship needs to be more of a handoff or prescriptive relationship. It's not. > I think it’s often better to divide up the product over many separate small teams, each with a product focused “mini CEO” and a tech focused “mini CTO”. Whatever you do, don't call them "mini CEO" and "mini CTO". This generally implies that the CEO is at the top, which breaks the whole collaborative team idea that we're going for in the first place.
CSMastermind 4y ago
I disagree but the thing I'd disagree most about is calling your product managers a "mini CEO". That exact mistake as led to some of the worst product outcomes I've witnessed.
- wobbly_bush 4y ago
  Curious, what about that title caused bad outcomes?
  - CSMastermind 4y ago
    I think it sets the wrong expectations for those product managers but in terms of their duties and in terms of collaboration with their team members. I've seen product managers who thought they were _managers_ actually in charge of the people on the team and this led to frustration. OR they thought they were decisions makers who had some measure of authority instead of just another member of a team with a specific role. In general collaboration with And when I think about the product managers, I've worked with who described themselves as "mini-CEOs" they lacked basic product management skills. For example: focusing on the what over the why, being overly process driven, and lacking a cohesive vision for what the product will be long term. I can't tell you correlation-causation here. Whether the description of "mini-CEOs" attracts people who are bad at product management or whether telling someone their job is to be a "mini-CEO" causes them to behave poorly.
lifeisstillgood 4y ago
Yes. Take a rough guide to military planning and you see "strategy, Operations and Tactics" not "business vs tech". And the prevailing direction is towards "mission command" - where each level provides the resources down to the next but it's not "directing" as opposed to "hand off"
crazygringo 4y ago
What you're describing is how it's already usually done, from what I've seen. But the PM still reports to a director of product, and the TL still reports to director of engineering. And when the director of product and director of engineering have different visions and priorities and criteria for promoting, that's the problem described in the article. And you certainly can't have engineering report to product or vice-versa... I've seen both before and it's utter disaster.

makestuff 4y ago

yeah i was at a startup that had SVP of product and SVP of engineering. For the entire year I was there 60% of the time was spent in meetings where they just blamed each other. Engineering would say product didn't tell us what to build so we just built what we thought they wanted and product would say they told engineering what to build but they did it incorrectly. The company I am at now has a leader who has product and engineering reporting to them for their charter basically following the mini-ceo/cto you described. It has its issues but works much better than the alternative.

ipaddr 4y ago
You needed a project manager SVP reporting to cio to make that work with a department for requirements
- chrisabrams 4y ago
  Thank you for this it was much appreciated humor during my lunch break!
zingar 4y ago
The leader who has product and engineering reporting to them is a CTO. Someone who only does one of those things is not a CTO and shouldn’t have C-level decision making power.

P5fRxh5kUvp2th 4y ago

100% this, what ends up happening is product wedges themselves between business and technical so they wield the power due to having business' ear, and any attempt by technical to communicate directly with business is met with severe reactions. The thing to understand is that very likely your technical people are smarter than your product people. In addition, part of software development is being able to identify what needs to be solved. Any developer with a modicum of experience knows how to do this. Just as you have a technical leader on the team, you need a technical architect on the team. That person can interface with the business or the business analyst (or both) as needed. separate teams is a degenerate case for strong software development. I once literally had a business person ask "who should be involved in this conversation" and my response was "product and technical so we can advise". Product responded after me with "Product" and the lack of technical there was deafening. It becomes a power play, the theory of the different departments works out about as well as putting a racist and a black man in a room to collaborate on race relations.

taude 4y ago
theres a lot of orgs where product people will be onshore and the technies offshore, so the model and barrier kind of makes sense (for this operating model), and typically the Product people will be the more expensive/smarter/critical resource in this case.
- kenhwang 4y ago
  In my personal experience, that model has rarely led to a good product, good technical implementation, or even good development velocity.
- P5fRxh5kUvp2th 4y ago
  In this setup you need onshore to manage that offshore team or you're just asking for pain.
rektomatic 4y ago
>very likely your technical people are smarter than your product people I'm guessing you work in the technical side of things?
- P5fRxh5kUvp2th 4y ago
  - ButterBiscuits 4y ago
    - P5fRxh5kUvp2th 4y ago
      - ButterBiscuits 4y ago

hipppocamp 4y ago

> I think it’s often better to divide up the product over many separate small teams, each with a product focused “mini CEO” and a tech focused “mini CTO”. This only gets you so far. It tends to optimize for speed of teams but at the detriment of the overall product. Eventually you end up with splintering of ideas, terminology, duplicate functionality and features that almost work the same way. You see it across all big companies and products. AWS is a great example of the mess they've made between services and how they don't always play well together and you end up with teams actually competing as they assert that their product should own something that's others shouldn't. I wouldn't be surprised if Google is in the same mess (Drive is a fucking cluster of a mess and it's basically impossible to use for anything productivity related - and don't get me started on how Google Classroom works within that ecosystem that's a double yikes). Same goes for Atlassian. What's the saying? Don't ship your org chart?

AndreasHae 4y ago
Can you think of any FAANG scale orgs that haven’t run into having a fragmented product landscape? Maybe there’s just a hard limit of how much complexity one business unit can handle before it stops being able to scale up. With that in mind, decentralized teams with tight product+tech collaboration seem to be a successful model. Otherwise we would probably already have seen an example of a successful tech company with centralized product/tech departments.
- Jare 4y ago
  The fragmentation issues doesn't need FAANG scale, and is already a possibility for any org that scales past 50 people or so. If a team has the potential to interfere with another, or the need to depend on another, you already have the primordial soup for conflict and widening cracks.
- kcexn 4y ago
  Isn't Apple very successful with centralised product/tech departments?
  - 4y ago

deleted 4y ago

[deleted]

vsareto 4y ago

That's usually what happens: assigned product people to engineering teams who focus on what the engineering team works on, then they report one level higher. You shouldn't be seeing a new decision-making Product person every month or so - that's bad news bears. It gets to this state naturally if your product is fairly large and has loose/well-defined modules that are distinct from one-another.

spacemadness 4y ago

I’m dealing with this right now and it feels like we’re at constant war instead of collaborating.

bkuehl 4y ago

Our company did a restructuring a couple years ago where the web/user-facing part of the dev team was moved under the same branch with Product. At first I was skeptical, but it has worked out very well. Product Managers and the developers feel like they are on the same "team" working toward a better product. There's a lot more collaboration with PMs trying to get developer input/insight, etc. Things used to be a lot more siloed, and I think it really hurt innovation.

drewbeck 4y ago
This is a really intriguing approach! I can see why it works.

PragmaticPulp 4y ago

Fortunately, this article isn't either. The second half of the article is about breaking down that wall (From the article): > Eliminating the wall between Product and Engineering is essential to establishing high performing product teams. (Quoting parent post): > The whole idea of having one branch of the org chart telling another what to do is kind of flawed. Completely agree, and all of these approaches are destined to fail if it turns into different branches of the org chart fighting with each other. Most of my issues with separate product orgs have come from product executives who feel the product/engineering relationship needs to be more of a handoff or prescriptive relationship. It's not. > I think it’s often better to divide up the product over many separate small teams, each with a product focused “mini CEO” and a tech focused “mini CTO”. Whatever you do, don't call them "mini CEO" and "mini CTO". This generally implies that the CEO is at the top, which breaks the whole collaborative team idea that we're going for in the first place.

CSMastermind 4y ago

I disagree but the thing I'd disagree most about is calling your product managers a "mini CEO". That exact mistake as led to some of the worst product outcomes I've witnessed.

wobbly_bush 4y ago
Curious, what about that title caused bad outcomes?
- CSMastermind 4y ago
  I think it sets the wrong expectations for those product managers but in terms of their duties and in terms of collaboration with their team members. I've seen product managers who thought they were _managers_ actually in charge of the people on the team and this led to frustration. OR they thought they were decisions makers who had some measure of authority instead of just another member of a team with a specific role. In general collaboration with And when I think about the product managers, I've worked with who described themselves as "mini-CEOs" they lacked basic product management skills. For example: focusing on the what over the why, being overly process driven, and lacking a cohesive vision for what the product will be long term. I can't tell you correlation-causation here. Whether the description of "mini-CEOs" attracts people who are bad at product management or whether telling someone their job is to be a "mini-CEO" causes them to behave poorly.

lifeisstillgood 4y ago

Yes. Take a rough guide to military planning and you see "strategy, Operations and Tactics" not "business vs tech". And the prevailing direction is towards "mission command" - where each level provides the resources down to the next but it's not "directing" as opposed to "hand off"

crazygringo 4y ago

What you're describing is how it's already usually done, from what I've seen. But the PM still reports to a director of product, and the TL still reports to director of engineering. And when the director of product and director of engineering have different visions and priorities and criteria for promoting, that's the problem described in the article. And you certainly can't have engineering report to product or vice-versa... I've seen both before and it's utter disaster.