Comment by havermeyer | Hacker News Reader

Comment by havermeyer | Hacker News Reader

I saw a lot of this when I worked at Google, both with internal-facing products and external-facing ones (software, though, not hardware). Organization A would build their own query engine, for example, but then organization B would build their own competing one because A's solution didn't quite work in the ways that they wanted it to. The result, of course, was that now you have a proliferation of query engines, and if you're a neutral party, you just end up being confused about which to pick since they all have tradeoffs, and none of them have sufficient headcount to build out more complete functionality. In terms of external products, there's a long line of competing chat, video calling, payment, etc. solutions, most of which have been killed off by now.

My takeaway was that I wish leadership had thought more critically about how to invest resources across organizations to build fewer but more adaptable products, but I don't think the right incentives existed :/

I’ve never been more motivated to quit than when on the other side of this. The thing that already exists only seems from a distance like it does what I need. It makes different trade offs, it’s poor quality, the team that owns it is far away, and they “agree in principle” with all my proposed changes but “it’s a question of resources.” On smaller projects I have sucked it up, and wow. Something special about tying yourself up in knots to do work you’re ashamed of in the end.

On the bigger projects I’ve always managed to wriggle out, thank god. Usually by building something domain specific so as to avoid the appearance of direct competition. Language and branding are crucial here. If your design doc uses the words “rules engine” half the company perks up. Why aren’t you using ours? On the other hand “configuration” is totally fine.

Would a data driven approach help reduce the number of interpretations of what the problem being solved actually is?

HN downvoters are truly inscrutable. What could possibly trigger malcontent in that topical, targeted question I just asked??

I didn't downvote you, but I will offer, I read your GP several times and I still don't understand the question.

Well thank you for informing me of that.

I'm hopeful that if people were to look at the same data the teams would not have such vastly different ideas about what problem they are trying to solve. I presume that these organizations generate overlapping products because they don't communicate, but shared data is a kind of top-down communication which works even if the teams feel that they can not coordinate.

Generally the existing system is appropriate to the business context it was first built for. The problem is that the owning team would like to claim the “impact” of you reusing their solution in a new domain, while maintaining a “not my problem” disposition towards the unique constraints of your domain, and towards the daily ergonomics of your life in their codebase. What’s needed is a proper platform team that can serve both customers.

Honestly, your previous question looks like it was generated by a bot.

If a bot generated that I'd be screaming in the streets.

Seems like there's a pretty big difference between two groups duplicating the work of a handful of engineers, like in your query engine example, and billion dollar programs like in the article. My personal favorite example of the former were workflow systems; somewhere around 2009 Google had like 15 different ones. But obviously the reason was that nobody had foreseen such a need early enough, a lot groups ended up building their own solutions, and with so much fragmentation none of them could reach critical mass organically.

In terms of large scale and crippling internal competition, Nokia comes to mind with their utterly non-cooperating consumer vs. business mobile phone divisions back in the day.

It seems they have too many developers without better things to do ..

I don’t think it is so much that they don’t have better things to do as it is that their primary project is blocked by some distant tool not quite doing what they need and unwilling or unable to make it do what they need.

So the engineers roll their own. It works perfectly well for their narrow use case , but is also half-baked for the general case.

Then a year later some distant team sees that you half baked solution would work for them if it were generalized a bit, but you don’t have the time or resources to help this distant team. So yet another half baked solution appears.

IMO the alternative is not clearly better either. A certain amount of internal competition and diversity is healthy, but not too much nor too little. Putting “all your eggs in one basket” can also end in disaster, and the worst case is arguably worse.

Well, then there's Hangouts which already had all the necessary features and Google killed it anyway.

Which shows that Google is an internecine regressive management hierarchy like any other.

Reply on news.ycombinator.com