That most engineers use the same IDE at Google allows the company to collect a huge amount of telemetry about what features they are using, how often, and how much. Quite similar to the entire codebase being in a single repo, it allows a certain visibility into what is happening that just isn't possible other places.
When Google wanted engineers to use AI features, it turned them on in Cider-V by default. And if you turned them off, later updates would turn them back on. This is very good for your adoption metrics, but might not tell you exactly what you want to know about engineer happiness.
Such a dominant IDE also allows management to ignore the long-tail of users who aren't using it.
> When Google wanted engineers to use AI features, it turned them on in Cider-V by default. And if you turned them off, later updates would turn them back on.
How is that good? That would be the first thing that would force me to use IDE that is not controller by 1984 entities.
Visibility doesn't always get you value though. See the many companies that unify their ticketing to something like Jira, and end up running reports on in. The actual accuracy of the aggregates is rarely great, and instead leads to people doing "jira optimization" to make reports look good.
I once worked at a place where VPs were looking at sprint burndown charts, and asked what happened if the line didn't look a lot like the line expected by JIRA. The telemetry is therefore often a curse, as any metric becomes a target. How many companies today have KPIs about having automated code reviews, which are then ignored by the devs, because said reviews are just wrong on almost everything?
The learnings of Seeing Like A State don't apply just to governments.
You have to be very careful in management to not create perverse incentives. I like to use change control processes as an example. In theory, a super strict change process for every single change is great, because it'll ensure everything gets reviewed thoroughly. In practice, that leads to people flouting the change process as much as they think they can possibly get away with, because it becomes a serious impediment to getting work done. A more moderate change process would have higher compliance, and actually lead to more oversight, than a super strict one.