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.

You needed a project manager SVP reporting to cio to make that work with a department for requirements

Thank you for this it was much appreciated humor during my lunch break!

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.

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.

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.

In my personal experience, that model has rarely led to a good product, good technical implementation, or even good development velocity.

In this setup you need onshore to manage that offshore team or you're just asking for pain.

>very likely your technical people are smarter than your product people

I'm guessing you work in the technical side of things?

should I guess you're not and that your sole reason for responding is defensiveness in wanting to believe you're smarter than software developers?

Or maybe we can try again?

> should I guess you're not and that your sole reason for responding is defensiveness in wanting to believe you're smarter than software developers?

You can guess that, and honestly it's not even a terrible guess. But it makes you a hypocrite. If you're offended by someone making this kind of assumption about you, reciprocating it isn't going to bring down barriers to communication.

> Or maybe we can try again?

You deflected entirely from the comment, which is fine. But then why reply at all? It sounds like you just want to be defensive.

Why would I seriously engage someone who starts off with such accusations?

The answer is I wouldn't, and I didn't. Oh snap, am I a hypocrite for not engaging you the way you wanted to be engaged?

Oh well.

I’ve had luck hiring people with “dev bootcamp” level experience who didn’t excel as an engineer post-bootcamp, but know enough technical jargon to communicate, collaborate, and understand engineers.

Often these are people who became bored with day to day coding having more interest in the business side of the company

People with relevant industry experience, even if non-technical, are also good candidates for product roles.

>very likely your technical people are smarter than your product people

Intelligence is multifaceted. That business listens to product and not to engineers could be seen as a type of social intelligence of which engineers are notoriously unskilled.

Regardless, framing any portion of your organization as "smarter than" (implicitly "better than") isn't going to help in terms of fostering collaboration.

Also a lot of PMs are former engineers. One could argue a person capable of doing both at a high level is "smarter" than a person who cannot. Certainly they would have a unique perspective compared to people who have only been on one side or the other.

But like you said, intelligence is multifaceted, and comparing people's intelligence is pointless and divisive.

PM is not product, when they get separated from technical in companies, they're literally product, as a team.

But more importantly, most of the time what happens is these people have 2, maybe 3 years of experience. They've done enough to be able to roughly understand technology, and that experience helps them communicate with the technical side, but in no way shape or form does that mean they would come anywhere close to that 20 year old vet on the development team.

But the flip side isn't true. In companies without that strong delineation between them, it's the 20 year old vet who would be doing what product is doing.

Companies who do this are too compartmentalized and they become extremely slow as a result. It's all in an effort to keep technical from having an outsized influence.

I have never understood why companies consistently hire people right out of college (often with random degrees unrelated to anything relevant) to tell a team of engineers with 10-20 years of experience what (and often how) to build.

Back when I was new, engineers worked directly with subject matter experts and the occasional business analyst. Now we’ve mostly replaced SMEs with product, and I don’t think it’s working out.

> Back when I was new, engineers worked directly with subject matter experts and the occasional business analyst. Now we’ve mostly replaced SMEs with product, and I don’t think it’s working out.

Exactly this.

Not only that, but when it works the way you're describing, it's often a 2-way conversation. The developer strives to understand the goals, then starts making suggestions to determine if the business is ok with shortcomings that would make it a lot cheaper and faster, but would fulfill those goals. They'll also dig into what the business wants in the future so when the implementation starts they can take that into account.

Instead we get product who wants to own all of that and then throw things up into a jira ticket and have it magically be great. There's no value add there.

Yes it is multi faceted. But in this industry one of those facets is worth more.

I am an engineer by trade, but I would argue product is more important than engineering. WHAT you work on is ultimately more important than HOW it is achieved from my experience. Yes, bad engineering will ruin a product, but it is all moot if you are not working on the right thing. So many companies I have worked with are working on the wrong thing. Another way to put it is, a company with a great product that has bad engineering will outperform a company that has great engineering but a bad product. Product/market fit rules all. Once I understood this I was able to work with the product team better.

^ and this attitude is _exactly_ why so many companies can't get anything done and why I explicitly pointed out that software developers tend to be smarter than your product people.

So lets be very clear on what I was saying.

SOFTWARE DEVELOPERS CAN DO THE JOB OF PRODUCT, PRODUCT CANNOT DO THE JOB OF SOFTWARE DEVELOPERS.

It kills me how many people seem to think the doers are the least important part of it. Gamedev gets this right with the insistence that the idea guy is worthless.

I work as a software architect and I see this all the time.

There are several things you might not see. Anyone who has done both jobs will tell you this.

It's not a job, it's a role, one that senior developers take on all the time.

It gets turned into a job and the result is business people constantly bitching about why everything is slow and what DOES get done is never what they wanted.

The phone game is real.

It's a job of many roles and it's a crazy difficult job to do well at. I'd never do it again. Engineering feels like a cake walk in comparison.

The reason you found it so hard is because you weren't doing the implementation, which is why software developers should be taking on that role.

At that point you're a glorified translator hoping that both sides are understanding each other perfectly. And what's worse is they both speak English!

Translating between who? I don't think we share the same experiences with companies, roles etc, so we might be talking past each other.

I'm talking about the product role at silicon valley tech companies like google etc and working on enterprise products where it took a lot to understand the customers, workflows, industries etc. From your comment above maybe you think translating between eng and "business"? At the companies I'm talking about, product is "business". I'm speculating, but you might have experienced the agile heavy places with a product owner or something, planning sprints or something? That's not what I'm talking about here.

between business needs and how it gets implemented.

Companies that do this took 3 roles and smashed them into 1.

- marketing fit - business analyst (aka domain experts) - technical implementation

The reason you see people talking about how hard it is for product is because product gets to interface with the business and has an understanding of the problems and the proposed solutions. They try to tell technical to implement with no real understanding of both, due the reality of the phone game it's never implemented as they want, and they get frustrated.

The solution is to stop trying to make technical the tech equivalent of ditch diggers.

Yes, if you want a ditch dug it's relatively easy to communicate that to someone. Software aint ditches.

So while product couldn't begin to start implementing themselves, technical can absolutely be having those conversations with business.

I can see what you are saying if one is the environment you describe.

I've never worked somewhere where eng was treated like ditch diggers. But I've also never worked anywhere where this "business analyst" actually existed. If you build products for many customers there is no such person, because different customers need slightly different things and you have to pick a position v competitors.

Maybe try changing environments? Not everywhere works as you describe.

Then youve never done any real engineering lol. People who say this were often paper pushers anywhere

Most people who have done real engineering and real product jobs will tell you PM is a harder job to do well.

There is more pressure, less control, more uncertainty, more people to keep happy, more ambiguity. And the number of context switches is intolerably high for many (including me).

It is a lot easier to be a bad PM than an engineer, I'll grant you that. And most PMs aren't great.

What you mean is it's extremely difficult not to produce shit software with a setup like this, even though paradoxically the theory is that this should produce higher quality software.

The reason for this is something called tacit knowledge. The only way for a developer to be successful is if they have the same level of understanding that product does. Since they don't, product needs to be the one implementing. Since neither happens, you get shit software.

The solution is either product starts implementing or software developers stop being treated as line workers.

product used to be three roles that worked together. software dev, business analyst, and marketing. And depending on the size of the company, business analyst and marketing often means working directly with business because that's who collaborates between those two.

There is no value-add in product, the theory has proven out to be untrue.

Give it another 10-20 years and we'll be reading articles about how the "smart" companies are doing away with product and giving it back to the other roles and asking them to do something crazy like talk to each other.

"working with business" suggests we must be talking about different situations.

I'm talking about a company building software products they sell, eg an enterprise software product like salesforce, google cloud, aws, splunk etc. Not internal software or software built for a specific client.

It's all the same, someone has a need and you give them a solution.

That need is either driven by business wanting to improve the software or by technical wanting to improve the software. product doesn't belong in there.

product will never identify that a technical change will enable new things, for example. The ones who can do that aren't allowed in the conversation.

We aren't talking about the same environment.

Trying to simultaneously satisfy many customers in a market where there are multiple options, different ways to slice and dice the customer segments, different dimensions on which to optimize a product, different ways to reach customers, different systems to integrate with, it's just a whole different ballgame to building a specific solution for a specific customer.

And at somewhere like google for example, most of the PMs are former engineers and can see technical changes enabling new things. On top of that, at somewhere like Google engineers do meet with customers, frequently. There isn't some dividing line like you describe because all the business units are run by PMs or engineers. They are "business" in your terms.

It is what it is. Your observations and suggestions may well be true and sensible in the environment you are operating in.

You keep saying PM.

Yes. At most silicon valley tech companies PM = Product Manager.

Different environments.

You can have a PM without a product team, they are not the same thing.

Yep, you can structure the roles however you like. I'd guess every plausible combination has been tried.

In my world engineers are first class citizens who have real input to the product decisions and meet customers, the PMs are usually technically capable, the PM job is too big to be done part time and hence isn't. It is what it is, and doesn't seem to be close to how things work in your world. But in my world, the product job is more complex than "someone has a need and you give them a solution". For internal development or consulting, that's probably right.

Yeah product managers have a very high opinion of themselves lol. While a handful might be really valuable most are worse than worthless

Yeah I mean I work at a place that thankfully has no "product" team. That was a valuable thing at a certain place but it's been replicated needlessly and most product managers are glorified project managers with no power or responsibility

Does your company sell software products/services? Or you are building internal software/consulting?

> Intelligence is multifaceted. That business listens to product and not to engineers could be seen as a type of social intelligence of which engineers are notoriously unskilled.

To some extent that's true. I'm sure that product folks tend to have higher verbal intelligence (on average). But all forms of intelligence are highly correlated with each other, and engineers are likely higher overall. Many (though not all) of the engineers I know are quite articulate, even when English isn't their first language.

Much of the difference in "social intelligence" might just come down to being more outgoing and assertive, rather than an actual difference in ability.

> Regardless, framing any portion of your organization as "smarter than" (implicitly "better than") isn't going to help in terms of fostering collaboration.

I agree that the other poster's framing was hostile, but I am sympathetic to their frustration. I think it is helpful to remind product and business leaders that your engineers can be great allies in solving hard business problems.

It's not hostile, just a simple statement of fact.

These product teams aren't interested in collaboration, that's part of the point. A strong software developer can do products job better than they themselves can do it, but they get treated like code monkeys.

> putting a racist and a black man in a room

Suggestion: Avoid prickly metaphors. Especially ones that imply reader is situated in a particular country?

Reason: Everyone can be racist. In a place with only black men, is nobody a racist?

Disclaimer: White guy on an Island. Sorry for off-topic content, I try not to make it a habit. I am generally against PC bullshit.

Did you understand the point?

Then communication happened, and oddly enough, communicating succinctly was more important than listing out all possible combinations in an effort for perfection.

Your tone comes across to me as “snarky” https://news.ycombinator.com/newsguidelines.html

Your comment completely ignores my point! My point is that I want conversations on this site to be worthwhile, and divisive thinking tends to destroy that. Your example “black man” is unnecessary and creates a divisive context. I think you make the same category of error in your implied definitions of “engineer” and “intelligence”. If you might spend some time to read through the comment tree below your GP comment, and try and understand why various people are reacting, I think that would help you and the HN community. Aside: Yes, I did understand “the point” which was written about in the article. Disclaimer: I have no HN superpowers.

Edit: What outcome do you want for yourself by commenting here? For me, I want to read insightful comments, and I want to practice my thinking by challenging myself to think about topics that others know more about.

your post was unnecessary, delete it and move on.

> The thing to understand is that very likely your technical people are smarter than your product people.

Weird. I was an engineer for about 13 years, and I was good at it by the accounts of others. I’ve now been a PM for 6 years and most of the engineers I looked up to along the way have either become PMs, EMs, or Architects. All of us are well above average IQ. We didn’t lose any IQ points by changing job roles.

I would suggest that if the basis of your world view is that other people are less intelligent than you due to their job role that you may wish to rethink it. You are placing way too much emphasis on the wrong thing and prejudging your (current and future) work colleagues based on an inaccurate stereotype.

And I would suggest that the wording of "very likely" implies statistics.

The people that need to understand this are the product people, not the developers, who are the ones treated as if they cannot understand.

> 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?

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.

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.

Isn't Apple very successful with centralised product/tech departments?

I was wondering the same thing. I suspect that Apple has a strong top-down culture that's been set by Steve Jobs, so you likely have a "single-threaded owner" model, regardless of how the org chart really looks. Companies that rely on more distributed models where you have peers that have final say over their product decisions end up with splintering and features that don't align well.

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.

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

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.

This is a really intriguing approach! I can see why it works.

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.

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.

Curious, what about that title caused bad outcomes?

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.

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"

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.