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

Only a subset of Google docs were ever shared like this. The lawyers never shared. The internal security people had private files. HR had its files. The people doing the financial reporting were/are bound by all manner of rules. Google's famed internal openness was only ever for a subset of docs meant for developers, not anything like a free/open data policy.


Yeah this article really seems to confuse the monorepo and files.

The monorepo was always accessible to all. First day on the job, you can literally see all the source code. Which is crazy cool. (With a few exceptions I'm sure, but not many.) I'm assuming that's not changing?

But any time someone creates a Google Doc it defaults to private. People will then share it with other editors and then their team as necessary.

It happens all the time that you follow a link to a deck to try to understand what a team is working on, and you get a "no permission" and have to e-mail them to explain why you want to see it... and you usually get permission within a few hours but sometimes you needed to look something up quick before a meeting and missed the chance.

Most of the time it's not out of any great secrecy, just that teams don't want other teams to misunderstand info out of context, like whether a team is actually pivoting or just exploring it or just brainstorming internally.


While monorepo is still a thing, they created a feature called “silos” to allow secret projects, to prevent fiascos like Dragonfly (censored search in China) and Maven (DOD drone image recognition) which both were discovered from monorepo.

Ironically, Allo cancelation was discovered by Allo team from a comment in a check in which was made by mistake days/weeks before the announcement.


The feature is actually called silos? I thought the hip thing to do was tear down all the silos in a company?


Other companies tries to be like Google, while Google tries to be like other companies.


During my time there, the internal Android repo required VP approval to access. Though I understand this was relaxed later.


Isn't that obvious? There are laws against having HR files available to anyone, and some fabled company culture doesn't get to override that.


Personnel files, yes, but one could definitely share hiring practice statements, salary schedules, rules for how requisitions are approved/allocated, how much freedom hiring manages have to negotiate salaries, etc. Whether that is a good idea is another question, but it could be done if the goal was as much openness as possible.


I've also heard (not a Googler myself), that parts of the code are private, like very specific parts of the search algorithm that are very critical IP. So while a vast majority of the code is readable by most, it's not some kind of completely transparent place.


Yes, this is true. It's usually code with sensitive IP in it, which is limited to the people working on it. The API around that code and the binaries that result from it are exposed to other teams, but not the original code.


From the article:

> Many large companies have policies restricting access to sensitive information to a “need-to-know” basis. But in some segments of Google’s workforce, the reaction to Walker’s argument was immediate and harsh. On an internal messaging forum, one employee described the data policy as “a total collapse of Google culture.” An engineering manager posted a lengthy attack on Walker’s note, which he called "arrogant and infantilizing." The need-to-know policy "denies us a form of trust and respect that is again an important part of the intrinsic motivation to work here,” the manager wrote.

I don’t work for Google, and this kind of entitlement mentality confuses me. I’d hate it if everyone had access to the stuff I was working on. That seems weird and kind of creepy. Without proper context lots of stuff could get misinterpreted (broadly speaking).


Misinterpreted in what way? What are you doing that you wouldn’t be comfortable sharing with other people in your own company?


Never mind misinterpreting docs then. There are documents that you wouldn't want read and properly interpreted by the wrong people at the wrong time.

For example, every year when it's time to allocate headcount resources, management has to make tough choices about which teams and projects should be expanded and which should be cut. This necessarily involves discussion about past performance and future expectations. Imagine seeing your team stack-ranked 3/4 of the way down some random prioritized list. You would be correct in interpreting that doc as meaning that management values your team in the bottom 1/4 of all teams in the org.

Without the context about expectations for funding, it might torpedo your psychological safety and ruin your Christmas. And then in January funding comes through for the whole organization (as management expected), and nothing ends up getting cut.

There are countless examples of how random docs can easily be taken out of context and cause angst and paranoia.


[flagged]


If you continue to post unsubstantive and/or flamebait comments, we are going to have to ban you again. Please re-read https://news.ycombinator.com/newsguidelines.html and fix this.




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

Search: