Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"Most organizations have shifted to organize their engineering teams by product"

We have done the same. The great thing about it is locating decision makers and customer insight close to developers. The bad thing is that what is perceived to be a "product" can be very different from the natural division of technical work to be done.

I sometimes joke that our Head of Product ended up involuntarily being our Chief Architect. The master plan of the tech has to be divided along these fault lines between Product A and Product B.

In Sales these may be sold as separate products. But the reality is that 80% of functio ality is shared between them, and these 80% do not get a good organization developed around it, since the A vs B split is at the core of the company chart.



Would it work to denote that 80 % as a separate product X that only has internal customers?

On the one hand, it's the obvious solution. On the other hand, that would move the developers of X further away from the customers of A and B.


Also the internal product is, in effect, a compulsory purchase by teams A and B, therein lacking the selection pressure that normally drives product development.

What other approaches to shared-something cross functional product teams are there?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: