Hacker Newsnew | past | comments | ask | show | jobs | submit | hubertdinsk's commentslogin

Why not both?

Where I work, there have been a lot of pushback where that BS doesn't make a lick of sense (the crown jewel of BS request atm: "let's put AI in the bootloader").

Good governance "should" also mean that those kinds of pushback are encouraged.


I imagine it went like this:

CEO: Put AI everywhere/

Engineering Staff: There's a lot of places where it doesn't make sense to do this.

CEO: Do it or find somewhere else to work.

The problem of pushback at the lower levels is that it is completely ineffective when the top levels are set on something.


As a point of data for your statement, Jassy has repeatedly said that teams that have higher AI adoption are safe from layoffs. Use AI or lose your job is the blunt message

What a wild business metric. Apparently not measuring productivity, profit, or even vague "impact." Just "AI adoption." Imagine your boss said that your job was safe if you switched over to using Python instead of whatever language you're currently developing in.

For sure, my org adopted KPIs for 95% AI usage measured weekly, and it was reviewed. Not 95% rolling weekly average, 95% each and every single week. I personally witness managers being called out why their team of 8 one week suddenly had only 7 people using AI that week. Take a vacation and your manager had to answer for it. Use an AI tool that they couldn't track, well, your manager had to answer for that too and probably had to harass you to use a measurable tool.

It was complete nonsense. Wound up leaving, partly over it. Nobody wanted to hear the emporor had no clothes and it made more sense to get out before that made my a layoff or URA target.


Something I've noticed is that companies don't really promote intelligent people up the chain of command. Socialism failed because it was a less effective economic system than capitalism, and lots of its issues are neatly replicated within capitalist companies:

- having friends is more important than making output, which means that people above certain level just play politics instead of actually managing the company

- managers who miss targets get more people assigned which makes them climb the hierarchy, which means all levels below top level have the incentive to be inefficient

- saying "no" to the ruling party, no matter how stupid the idea is, is the second-easiest way to get replaced. The easiest is to offend the wrong person

- planning periods misaligned with the economic reality

An intelligent person will either be optimized out of the system, or will learn how to game it to their own advantage.


See recent discussion on why senior devs left projects crash.

It is easier to let it all crash and burn, and try to leave with less scars as possible than try to fight the system.

You get to lose more for the visibility to fight back than letting it go down in flames.


It could have been both for sure. I'm just going off the public info here though and it doesn't seem like the employees failed to do what they were told to do.

In a company as large as MS, I'd never really expect a culture of encouraging pushback from below. They'd just never get anything done and the team culture and morale would likely end up in the tank.


No no I agree with you.

It's just that I don't vibe with the sentiment that company culture are a one-way street from management.

Anyway I do see that after a while the people who would have said no would all be gone. So maybe this is not the start of the decline but actually closer to the end of Microslop.


I'd say it's also to stop people from doing dumb things (i.e. proactive defense).

Say, if the org runs Postgres in-house, there's a mighty chance that an intern somewhere might decide to ...test things out in a creative way.

Perhaps the idea of outsourcing that to Oracle is that Oracle has the processes/controls to rein in such interns. As opposed to e.g. a hospital having to create such processes/controls.

(Oracle is still a bad idea IMHO, just slightly less so comparatively)


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

Search: