It sounds like the same thing that Steve Yegge placed in his rant in 2011 [1] where teams should collaborate via interfaces.

[1] - https://gist.github.com/chitchcock/1281611

> I observed an example of this at New Relic:

So, sample size == 1. :-D

This is a sensible idea.

It really just boils down to the K.I.S.S. Principle (Keep It Simple, Stupid).

Remove as many branches and variables as possible. Increase focus.

In complex situation you can often deal with parts of a problem to the detriment of the whole. There should be some expression "its the whole, stupid", because we all tend to do this.

Long ago I worked at a significant corporation. We won't name names. They decide to completely rewrite their software because the original architecture was limiting. A good decision. So for one YEAR different groups went off - in silos - and worked on their area of the project. On the day, of the release they put all the pieces together only to find that NONE OF THE PIECES fit. The company was doomed.

We talk about intellectual terms - like Agile, like Silos, like whatever. None of that matters. It is intellectual. Only one thing matters. Functionality. If you get better results from thinking in silos, then that is the best. If you get best results from 'agile' then great.

But to a large extend arguing agile vs silos vs some other thing is just an indication you are not paying attention to the real thing.

One strategy for all of this is just "hello world". Want to build a new, shiny software thingy? On day one, get it to say "hello world". Then every day forever after make sure it can say "hello world" AND can show some new feature. Like every day demo what it can do.

That's it. If you can do that in a silo, great. If you can do that in agile, or waterfall, or whatever that is great. As long as you can *show* that the product can do more today than yesterday.

"Decrease collaboration". Sigh.

I'd be extremely interested if someone has managed to do this with platform-wide product features. For example, take all login procedures across Microsoft products. In my experience, this is super difficult to pull off.

Individual teams don't know enough to make the right decisions, as login, recovery etc is really complex under the hood, so you need a central team handling that (even and especially the UI - you may want to have a login button appear in the same place regardless of which product you use).

Having a platform-wide team controlling (part of) the OKRs of a large number of other teams does not work great, because to those teams, enforcing company wide mandates feels like a priority inversion, and is often countered with passive-aggressive behavior.

I'm not too familiar with Apple product internals, but the apple ecosystem feels overall coherent. Maybe they managed?

This series has come up a few times, and as someone who's worked mostly on inherently cross-functional teams (support, docs, QA) it exemplifies the most dysfunctional places that I've worked at, because it presumes that the people gating connections between silos exist, are competent at it, are incentivized toward both openness and transparency, and are held accountable if they fail.

Which, in practice, never all fucking happens at once.

If your job is to both facilitate and limit unnecessary communication between teams, and you systematically build your org around centralized communications chokepoints to protect R&D from product/marketing/support, you need to field and triage all of the requests made to developers for everyone else to effectively do their own jobs.

As the post notes:

> You want local groups to be able to act independently and have what they need to be successful. You want centralized functions to set high level objectives and coordinate where necessary to produce the right outcomes.

But nobody hires for this. C-suite sure as fuck doesn't want to do it. Their direct reports treat anything that _limits_ the visibility of their accomplishments like poison. So it ends up on the next level of project/product managers, or tech leads at orgs philosophically opposed to the concept of a PM; either way, that person already has too much work to do reporting to (or shielding the devs from) upper management.

I've worked in exactly one place where the company siloed with a someone who was designated as responsible for the silo and also wasn't overloaded with tasks that compromised their ability to do that.

So one of a few things happen:

- The people supporting customers can't get the information they need, so they do a bad job. The company defends the PMs and devs, the customers blame the people in support for incompetence, the support teams get flushed, and nothing changes for anyone. The silo has done its job; the customer is unhappy, support is ineffective, docs are written blind, the PM and devs get pulled into customer escalations between increasingly rare moments of focus.

- The support teams ignore all directives from upper management, dodge the PMs, and establish direct relationships with engineers. The silo has failed; the customer is supported better, but the devs are miserable from constant moments of small distractions, and product progress slows to a grind.

- The company recognizes that the Platonic model of siloing described in OP doesn't work in an org led by glory hounds (so, all tech companies) with more stakeholders outside of R&D than in it (so, most B2B and especially B2C tech companies). It then restructures teams such that _some_ of the devs are outside of the silo to deal exclusively with those requests, which works only if you have enough unicorn devs who are both good at their job, social, can independently manage unrelated projects, and consistently document their own processes.

The second post in the series suggests Amazon's single-threaded ownership for inherently cross-functional teams, which is where I gave up trying to give this the benefit of the doubt. Consolidating on a single point of failure as it recommends, instead of a fourth leg on the three-legged stool focused on cross-functional tasks and org awareness, will delight a team's engineers at the disproportional expense of every other person who's forced to deal with that owner.