opmelogy

> The goal is not "make all communication public". The goal is to get the job done.

Just adding that "get the job done" shouldn't be confused with personal productivity. Many younger/inexperienced devs that are highly motivated go through a phase (some get stuck here) that optimizes their personal productivity above the team's productivity. You end up with pockets of people that share knowledge (or hoard knowledge) with others left behind. You also end up with different subsets of people making different decisions, younger devs clinging to each other for feedback/guidance (yikes), and way more thrash that needed.

Ah gotcha. In this case it's not actually that you are hiding away and doing all your work via DM. You're just using it for smaller discussions and then circle back with the larger team to share info. That totally makes sense.

I was thinking that the OP for this comment thread was claiming that there are situations where public comments/knowledge sharing isn't needed for teams, which makes no sense to me.

FYI: I think you responding to the wrong parent comment. :)

FYI: all of these are off the mark, some more than others. Here's some more info to help flesh it out (which is lacking too because there is so much nuance to this stuff).

> 1. Amazon's internal beurocracy enables good teams to be very good, and bad teams to be very bad

These get sniffed out eventually. It's usually a cluster of teams and it comes down to a specific leader creating a toxic environment. Some are very good at managing up and hiding the problems. But that only lasts so long (although sometimes years).

> 2. However, there is significant internal mobility, so you can move if you get stuck on a bad team

Not true.

If you are SDE I (entry level) moving teams is incredibly hard. All of the job posting are for SDE II (except for rare circumstances) and above so you can't apply for other teams. Usually the only way to switch teams is if you know someone there and they can help you out.

If you are not in an engineering role, switching teams is even harder. The business side tends to be more political and also have more candidates for positions.

> 3. WFH policy is effectively left up to each individual team, so that is something to probe about during the interview

Not true.

If your skip-level or even higher says no remote then there will be no remote. While some groups may leave it to each "individual team" it can always be overruled.

> 4. Everybody at Amazon is in the on-call rotation, but on-call load varies significantly by team (I know someone working on an internal tool that has literally never gotten paged)

Not true.

There are teams that don't have on-call rotations. Groups that are building software that hasn't launched yet are likely not carrying a pager. Higher level managers and engineers (Principals) are likely not on a paper rotation. And a bunch of business teams don't have on-call rotations.

> 5. Churn is roughly 6%, as that is what the infamous URA target is set to;

Oversimplified.

That 6% changes every year. I've seen it much lower in some years. It all depends on what's going on in the company. That 6% is just a number they want forced out. It doesn't include people leaving on their own terms that the company would love to have back, so churn is higher.

> however, you'd be surprised how many incompetent people make it past even FAANG interviews, so I wouldn't particularly worry if you're good at your job and your boss isn't an asshole

That's a dangerous assumption to make. It's not as simple as if your boss isn't an asshole. A big factor is if your boss knows how to set you up for success and if you know the rules of how things work there.

During review time, groups that are run well will have each team bring a list of their lowest performers to discuss. They vet how well these employees are functioning against the expectations for their level. If things naturally fall into the right ratio of people that need to be slotted below the bar, then they are done. But if there are not enough people they start digging more into where people land in relation to each other. If your boss hasn't set you up with work that allows you to demonstrate your real abilities then you are likely in trouble. It's not that your boss is an asshole, but that they are inept and screwing things up.

How'd you come about this understanding? Very little of what you wrote here reflects my experience there.

I'm curious what sorts of groups/contexts working together wouldn't benefit from this. I'm having a hard time coming up with examples. If we're assuming that group activity means people that are all working on the same product, I can't see an argument for DM's and private conversations.

Sometimes putting blockers in front of people is absolutely what's needed. It's a common tactic for compliance and security - both of which can completely tank your company if not handled correctly. I suspect it's especially true if there are people with the skills to build who claim they are the only ones that are "actually trying to build things." Likely they don't have the right level of understanding of what needs to be built.

All great points. And it's becoming clear that we are using different tactics to reach the same ends. I've laid out how it's useful for me, you've laid out a another approach. Circles back to my original point - my experience has been different from what the author says and we just add in that you go about things a different way too. Looks like there's more than one way to achieve things which isn't terribly surprising.

Absolutely agree on the empathetic listening. But there are definitely times when devs come to be and no amount of empathetic listening is going to get to the room of the problem. Like when things are moving slower, why dates are being missed etc. And no amount of empathetic listening is going to be enough data to go to leadership to argue why things are off, why we need to delay things (and delay other teams), and build any sort of trust that you can reasonable manage the work for the team. But this may be limited to working at a FAANG company where projects span 100's of developers and any shift needs to be backed up with a lot of data about what's going on.

I've had the exact opposite experience. Velocity has helped my teams multiple times. It gives a sense of how much productivity drops when we add new members and if we don't recover within an expected time then we know something is up. It's also used as a rough early indicator that projects are running late and that there's no way we can hit expected time lines. Teams escalate and get alignment across the larger org on how to handle it (move dates, get additional help, etc.).

> Velocity metrics are as loathsome as the horoscope because neither provides any insight on why something went wrong or how to fix it.

This is such a weird statement to me. Of course it doesn't tell you why, it's just data. It's up to anyone that works with data to figure out what's going on.

> Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design.

This approach probably works out because you have senior engineers laying out a lot of the core structure and architecture for how things built. There's a tendency for newer people to tacitly adopt patterns that already exist and replicate.

However, this approach can be really problematic when you have a team that's primarily newer engineers. I've seen it multiple times and it's always the same result - productivity almost grinds to a halt over time because there are so many problems in the code base. The worst example I saw was switching teams and seeing the team velocity. We measured all the work in story points and used the exact same task as a baseline story point. The previous team with mostly senior engineers, a point took .5 days. With the new team that was started by all fresh grad engineers, a story point took a minimum of 3 days and usually bumped up to 4 days. This velocity lasted multiple years, even when the team had a much more balanced spread of senior, mid-level, and fresh grad engineers.

"This is Mark Zuckerberg either lying or not knowing anything about current issues on Facebook."

This sums up my general reaction that has been built up over time with how things have been handled. I'm sure that Zuckerberg is playing the PR route sometimes, but more often than not, my suspicion is that it's more about incompetence and cringe-worthy cluelessness than anything else.

The Facebook offices I've seen are filled with posters and messages that are more inclusive and respectful across different cultures and minorities. While there, it felt like I was looking at my own Facebook news feed. But compare that with other family member's feeds and their world is vastly different. Filled with fear about minorities, making false claims about history, countries, events, and medicine, and blatant lies that are obviously aimed at aggregating power to a select few. When the idea of fake news and Russian interference surfaced, the general reaction from Zuckerberg came across "lol - wat? That's not even a thing." There's been enough data points since then that shows his incompetence, be it deliberately lying or being completely clueless. For me, I've hit a point where trust is broken. Not just with leadership, but with the platform in general.

“The vast majority of what is required here are things that we’ve already had for years across the world for everyone.”

My understanding is that GDPR would require a deep delete of user data from Facebook's systems. Anyone have info on how that would work with shadow profiles that Facebook creates on your behalf and without your consent? Seems like this would fall under the domain of GDPR. (Which also makes me think of just how misleading that quote is from Zuckerberg)

Agreed on both counts. Although your second point just seems to feed into the idea of not just rolling in "journalists" into the ignore category, but news outlets if they are actively involved in this BS.

For the actual quote, it comes from here: http://www.foxnews.com/opinion/2018/03/28/liz-peek-census-20...

"Liberals are outraged over the Trump administration’s decision to include a citizenship question on the 2020 census."

That's the first line from the article, which clearly pits liberals as being the problem here while implying that conservatives automatically disagree (or in this case, "you are on the right side if you agree with me."). It's basic manipulation. People that behave this way are not worth the energy. They just get in the way most of the time.

"Liz Peek: Census 2020 – Liberals, get over it, we must ask about citizenship!"

This is enough to ignore the author and bury the article. Anyone that uses the term "liberal" or "conservative" as a way to drive a wedge between Americans in order to offend, distract, and "win" are not worth the time.