AStellersSeaCow

Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor.

It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.

I chuckled at the implication that BAH's work has any value to begin with.

Came here to post about LCM too, amazing place.

Sadly "in stasis" is pretty generous. I know several people who were in that win of the Allen org and they've all said that Jody Allen viewed it as a waste of time and money and was delighted at the opportunity to close it and never reopen courtesy of the pandemic.

I worked in a part of Amazon that had a lot of ability to help detect and flag this sort of fraud. I had to fight hard to get even a proof of concept project greenlit.

There was exteme organizational disinterest - partly for a bad but predictable reason (we made a lot of money off these fraudsters) and partly for a reason so bad it still makes me cringe (money recovered from identified fraudsters went into the balance sheet of a different SVP's org, so our org viewed it as a waste of time).

I made the case that the longer we let the problem fester, the less people would trust Amazon to buy anything. Leadership didn't really care but got sick of me constantly making noise about this and eventually signed off. That said, at my project's peak I had four engineers and one data scientist. Compare to consumer fraud and vendor fraud, both of which negatively impact Amazon directly, which were fought by entire VP-level orgs of hundreds of people.

In the end we put together a system that detected blatant fraud easily and in worrying volume, but as soon as I left - which meant there wasn't anyone in leadership sponsoring it - it was quietly mothballed.

Maria Bamford is excited.

But not too excited.

My answer is yes to all of the questions.

People making $250k on average getting laid off is admittedly less of a tragedy than people making $75k on average getting laid off. The former would have more opportunity to save and potentially less impact on their lifestyle and financial stability.

But the laid off workers have a lot more in common and a much closer standard of living with each other than with the billionaires whose wealth their layoffs are serving to marginally increase.

Yeah, I hate the way they were conducted but can't think of a better way that wouldn't open the company up to a lot of risk.

I'm not convinced that announcing them in advance is actually better anyways. We have partner teams in Europe who get to spend a month or more after the announcement worrying about whether or not they still have a job. Morale on the teams in the US took a noticeable hit, but the teams in EU have seemed utterly miserable for the last week.

Consider this: you have a high-performer and a low-performer. You have a mandate to reduce your team size by 1. Who do you choose?

This isn't how layoffs work. They don't to go each manager and tell them to reduce their team by X - that does happen, but it happens by way of managing people out for performance reasons, and it's not called layoffs. It's firing/unregretted attrition.

What happened here (at least at Google and Amazon) is that a relative handful of upper management worked with a relative handful of people in HR to use some formula to identify thousands of people to lay off. They definitely targeted some projects more than others, and entire projects/orgs/divisions were scrapped as part of it.

... if they don't do that, they're at a competitive disadvantage.

There's general agreement within Google that this absolutely puts us at a competitive disadvantage. Googlers in good standing and with years of knowledge about our business and systems were let go. When (if?) the economy recovers, we'll hire new people to do the same job, but worse.

It isn't being driven by competitive factors, it's being driven by a combination of profit-seeking and workforce-cowing.

You are not privy to either the list of employees who were let go or their historical performance reviews

I know this local to my org. I can say first-hand that most low performers from the current and prior cycles were not impacted by the layoffs, while people who were high performers in the current and/or prior cycles were impacted by the layoffs. The experiences of other people managers within the company (and at Amazon and Microsoft) agree with this.

I don't want to get too into Kremlinology, because I don't have enough data to say for sure how people in my org were selected beyond "performance wasn't a major consideration". But there is definite high-level tilt towards cutting people from certain areas in the company (parts of maps and devices were hit hard, most of cloud was barely impacted).

I'll temper my general "layoffs must be done without regard to performance" into a more specific "in this case, layoffs were done with at most marginal regard to performance".

Google and other big tech companies who participated in this round of layoffs explicitly ignored the most recent performance signal. They may have used older signal, but it clearly wasn't a significant driving factor. At most it may have been a tiebreaker if all else was equal. As noted in that link, seniority, redundancy, skills, and placement within the business were communicated to be the overwhelming factors.

Don't have access to that BI link, but it'd be pretty dunderheaded if MS did use layoffs for low performer housecleaning. Every time you let someone go because of low performance, you have a very non-negligible chance of that person suing you for how you conducted the termination. In the event of someone being _fired_ for low performance, their manager should have a clear paper trail documenting the low performance and the lack of improvement that led to their firing. That paper trail won't exist in the case of surprise layoffs. Doing that en masse would be opening yourself up to a hell of a class action suit.

It's also possible that people are saying layoffs not meaning the technical term, but to mean "fired a bunch of people in a small timespan". That was the Amazon business-as-usual approach, but it was called "unregretted attrition" rather than (correctly) firing or (incorrectly) layoffs.

https://www.investopedia.com/terms/l/layoff.asp

First sentence: "A layoff is the temporary or permanent termination of employment by an employer for reasons unrelated to the employee's performance."

Current Googler, I have no insider info at all, found out about this the same Friday morning as everyone else. Everything expressed here is speculation based on my own observations and conversations with HR leaders at Google and other companies involved in this round of industry layoffs.

It's unfortunately not surprising that some current and rising stars in the open source world were impacted by this. There's an important factor in layoffs that is poorly understood and almost never underlined in reporting: layoffs _must_ be done without regard to performance, because otherwise they aren't layoffs, they are mass firings.

Layoffs have important legal and personal implications. They need to be applied broadly, either across the entire company or across divisions within the company that are unsustainable. They can't consider performance as a primary factor, since doing so both necessitates a lot more paper trail and makes unemployment insurance much more complicated. They can't be contested by individuals, since they don't count as termination in the legal sense.

On the plus side, because they are not tied to performance it gives impacted employees an honest, blameless justification for why their role ended. The fact that there's public outcry about high performers being impacted provides air cover for everyone else.

All that said, I agree with the posters who have called this out as being a fuck-you, know-your-place gesture from the wealth class to the professional class.

Not so sure. I was in a research lab at a similar school a couple decades ago. There were two staff lab assistants (not sure they'd be considered administrators by any stretch), and the PI shared an executive assistant with three other PIs. That's not a ton of local overhead.

At the department level, there were of course deans, provosts, counselors, admissions people, etc etc etc, but even that departmental overhead wasn't more than maybe a 1:8 ratio compared to the number of grad students.

I'm sure there was similar or even greater proportional administrative staff once you got to the university level, but even if you include every single employee in big departments like Research and Graduate Admissions, it wasn't anywhere close to even half the number of students. I know this because the entirety of the administration fit into a few old buildings in half the campus, while the rest of the buildings on that half and all of the buildings in the newer part of campus were filled with labs and classrooms.

So in the ensuing twenty years, administrators have either gotten massively worse at their jobs and required far more of them to accomplish the same things (running directly counter to the general trends in worker productivity in that time), or they've created an immense amount of new make-work for themselves and their colleagues. Articles like this point pretty strongly at the latter explanation.

Counterpoint: you don't have enough good metrics.

That said, serious competition would also be good for Google. The maps org is still huge but a lot of what they are doing is tiny iterative improvements these days, not enough swinging for the fences to really add new and exciting products/APIs. If nothing else comes of this, hopefully it spooks some Geo org planners into thinking bigger.

And yet, here you are.

Managers are heavily expected to keep growing their team(s). A manager whose team is flat in terms of size and scope year over year is going to be viewed as underperforming, even if they dramatically improved what they do own (in most of the company, at least).

This means a lot of managers hire for the sake of hiring, and create projects to facilitate that hiring rather than because the projects add any real value. They'll work with their PMs to invent some numbers to sell the project to leadership, but at the end of the day a lot of what goes on there is makework, solving problems that don't exist or re-solving solved problems without improving the solution significantly.

That said, since there's so much cutthroat resource contention, plenty of extremely important/valuable projects are chronically understaffed. I'm sure there's meaningful work for most to all of the engineers currently working at Amazon, but a pretty significant chunk of them are absolutely not doing anything meaningful today.

Part of the issue is they can't/won't compete on comp or benefits with other big tech companies, but still have high-ish standards on hiring, relative to the industry as a whole.

That means they need a huge candidate pool, since most won't make it through interviews, and most of those who do won't accept their offer since they can get better offers from other companies.

My perspective after five years in tech management:

Effective managers from a pure tech background tend to have happy, functional teams that get things done well and add a lot of long term value to the company. They focus on "managing down", ie making sure their reports are happy and that they are building/doing the right things.

Effective managers with MBAs tend to have miserable teams that get things done fast and add a lot of perceived short term value to the company, at the cost of lots of long term value loss. They tend to focus on "managing up", ie making sure their bosses are happy and that they are personally looking good even if they are running things full speed off a cliff.

The former managers grow careers, build systems that don't need to be replaced every two years, and are remembered positively by their peers and reports. Of course, the latter managers get promoted much more readily and inflict that style of thinking on ever-widening orgs.

The most depressing part is that the latter style of manager -sometimes slowly, sometimes quickly - inevitably take over orgs and companies. Major stockholders/board members are too focused on the short term, and managers like that focus on short term value (or the perception thereof) at any cost.

I think he's cherry piketting data.

So to some degree that's preaching to the choir around here; I still use emacs extensively and adore it, but I'd also never wish it upon anyone who doesn't value work efficiency over low cognitive load and nice aesthetics. In my experience, at least, that's most people.

In light of that, I think it's less that we've "lost" keyboard-driven efficiency as much as knowingly sacrificed it in favor of spending UI/UX dev time on more generally desired/useful features. The nice thing about being the type of power user who wants more keyboard functionality is that you can often code/macro it yourself.

To call this rose-tinted glasses when considering how things worked in 1983 is a massive understatement.

A counterexample: in 1983, enter two search terms, one of them slightly misspelled or misremembered, hit f3: "no results", spend 10 minutes trying to find the needle in the haystack, give up and physically search for the thing yourself.

Enter two search terms slightly incorrectly now: no of the time it will know exactly what you want, may even autocorrect a typo locally, get your accurate search results in a second.

When things were faster 30+ years ago (and they absolutely were NOT the vast majority of the time, this example cherry picked one of the few instances that they were), it was because the use case was hyperspecific, hyperlocalized to a platform, and the fussy and often counterintuitive interfaces served as guard rails.

The article has absolutely valid points on ways UIs have been tuned in odd ways (often to make them usable, albeit suboptimally, for the very different inputs of touch and mouse), but the obsession about speed being worse now borders on quixotic. Software back then was, at absolute best, akin to a drag racer - if all you want to do it move 200 meters in one predetermined direction then sometimes is was fine. Want to go 300 meters, or go in a slightly different direction, or don't know how to drive a drag racer? Sorry, need to find a different car/course/detailed instruction manual.

I'm at Amazon now, my team is fairly shitty - let's say in the bottom third of engineering teams anyone at the company would want to work for - and the average tenure of people on the team is close to 5 years.

It's hard to get fired as a college hire. It happens, but only if you're pretty lazy or a fuckup or a mis-hire to begin with. I've seen vanishingly few cases where someone was managed out at a time that it denied them stock vests, and only once that it was even mentioned (then by an exceptionally petty manager).

To be perfectly clear: working at Amazon sucks for plenty of reasons, some of them covered in this thread. Compensation is not commensurate with the quality of engineer you have to be to work there, the company is disgustingly cheap in general, many teams are drowning in tech debt (the original post's cheerleading aside, half my org is still suffering from the slapdash way the Oracle migration was sped through to meet arbitrary internal deadlines), and the fraction of managers interested in building petty fiefdoms rather than interesting or good tech is increasing at an alarming rate. But anyone who thinks it's a huddled mass of sobbing husks with PTSD is overstating it.

I don't doubt that the findings are the case, I've experienced it myself and seen it in plenty others. What I would've liked to see in the paper, though, is more proof of the cause-and-effect relationship's weight here: do people who naturally stay up late get worse grades, or do people who get worse grades end up with worse sleep habits?

I'd guess there's some degree of both, but without the study being more longitudinal (eg, tracking the same population across their entire time in college to see how their grades and sleep habits relate) it's hard to say. Purely anecdotally, I've seen people who start struggling (for reasons that have nothing to do with sleep) drift into a depressive/withdrawn existence that includes insomnia and sleeping late.

I'd been looking for other uses for my angle grinder, and this is way better than the other ideas I had.

When this news first came out, I tried practically all the alternatives. My personal experiences:

Wadded up aluminum foil: really does not work well. It gets loose grime off, but anything at all burnt on will take very vigorous scrubbing and possibly result in shredded foil everywhere. Also feels like a huge waste of foil.

Wooden scraper: works ok, since it's not flexible doesn't get between the slats well, need to put a lot of elbow grease in to get stuck-on stuff, and if you leave it outside in my high humidity region - even under a cover - it will get disgusting fast

Abrasive pads/steel wool - work surprisingly well, but need to be replaced constantly and it's fairly disgusting work (you will feel like you need a shower afterwards) because you are basically in the grill

Nylon brush - did literally nothing.

The solution I'm currently on is a wire brush that is continuous spirals of wire rather than bristles. Available from your preferred online merchant, etc. Does not work nearly as well as a traditional wire brush: have to use quite a bit more force, and very awkward to maneuver it between the slats. That said, it gets the job done very well and it's durable.

I know a guy who worked for that company. Sounds like they had no goal beyond refactoring their ActionScript as better ActionScript as recently as a couple years ago, denying the ample writing on the wall that this was a fool's errand. I assume they pivoted and turned that into a stepping-stone for their Haxe port when it finally sunk in that Flash was getting euthanized. So they might be monkeying with the timeline and cause-and-effect in the article, but the end state is ultimately what matters.

Yep, I did software development in academia for a biochem lab and they paid less than 1/3 what I make in industry. Not only that: I was lower on the totem pole than a first semester PhD student, there was zero potential for career growth of any sort (the prof I worked for laughed out loud when I asked about it), and my job security was entirely governed by the grant approval/extension whims of the NSF and NIH.

Foreknowledge of all that wasn't enough to keep me from working at the job for a while. It was a super interesting experience, and I learned an enormous amount about biochem, comp bio, synthetic bio, and several other fascinating subjects.

What eventually caused me to leave was the continuous, losing battle for sane software development practices. It wasn't just that lab: everyone I encountered in the techy side of bio - save for the oddball comp bio or synth bio prof/student with a CS background that included industry experience - was completely adverse to treating their software as anything other than a means to an end. In the year and a half I lasted before taking a job in industry, that one lab easily wasted hundreds of work hours navigating easily preventable tech debt, writing the exact same code for the Nth time, fixing the same deployment or revision control mistakes for the Nth time, etc, while any attempt on my part to put in standards and practices to alleviate any of it was dismissed out of hand as a waste of time.

In short, I agree that there's a shortage of software engineering knowledge and skills in the field, but beyond the obvious financial, organizational, and career development hurdles keeping talent away, there's a major attitude adjustment required by the researchers themselves.

FTA: "Fortunately, American roadways are safer than ever, with highway fatalities at historic lows. Roads can be dangerous, but the perception of roads getting increasingly dangerous is a false one." ... "Published Jul 23, 2014"

And then: https://www.nhtsa.gov/press-releases/traffic-fatalities-shar...