Not necessarily the same individual, but the same team. If a particular product needs an API and a distributed system and a mobile client app and a website, it should be the responsibility of a group of people that has that skillset between them who sit together, have daily standups together, and all of that. I would expect the distributed systems specialist to be willing and able to add a line to the website or vice versa; different team members have different specialities but everyone owns the product and anyone picking up a feature takes responsibility for delivery of that feature. If a feature requires two people's skillsets they can pair on it and collaborate directly; if it requires more than that, find a way to break it down into smaller features that can be implemented individually but will still constitute customer-facing product features. (This is something people often assume will be impossible, but it almost always turns out to be easy once you try, IME).
If there's a function that's sufficiently universal and valuable that you want to share it (e.g. server administration), you have to stop doing deep integration across that feature boundary and pare it down to a more product-like interface (e.g. your server administrators offer a way for your application deployment to specify which libraries it depends on, rather than managing directly which libraries are installed on which server) where a product-like roadmap is sufficient. If there's a one-off feature that requires deep integration with another team, that feature should be done by a pair with one individual from each team, who can coordinate directly with each other.
> I'm saying: we need to do better. It's important to do better. And it's worth noting that the really amazing companies we see out there that do huge, good work? Netflix, Google, Mozilla, even Amazon (who I don't think very highly of) etc? They don't do that holocracy thing or that flat organizational structure. Heck, they've even gone so far is to separate site reliability from product engineering entirely. And most folks who I respect as engineer say this separation is the right call.
I don't see the giants as the ones doing the amazing work - their big innovations happened when they were smaller - and within the class of giants I would loosely guess that the more effective ones follow a lower-management, more-segregated-teams style. (FWIW I think Facebook - conspicuously absent from your list - have been more effective among the giants, both in terms of making a better product and in terms of producing high-quality technical libraries). But we're getting beyond the level where I can really have an informed opinion; I haven't worked for enough large companies to have a statistically valid sample, and while in the absence of proper studies I'm inclined to trust to my own experience, I could've just been lucky at the less-heavily managed ones and unlucky at the more-heavily managed ones.
> I think you have a curiously warped view of architecture. That it spans quarters or even months into the future. It doesn't. Often times, it's as much about auditing the existing babel of engineer rodeo projects to find out what's closest to meeting the requirements and helping those engineers sketch out how to take it the remaining agonizing 20%.
My view is based on what I've seen people in "architect" positions do; I'd certainly say there's a lot of variation in what it means between different companies, but it's always been some form of making technical decisions earlier than during coding (even if just at the start of the week after scoping out a particular feature) and as such I've always found it counterproductive.
Pair-programming with a developer on the same team who knows the codebase well can be extremely positive if that's what you meant, and I suppose you could consider that person an "architect". But I find it's vital that that person not be any kind of formal manager: the easiest way for it to go wrong is when the junior partner gets intimidated and stops contributing.
