What Silicon Valley gets about engineers that traditional companies do not

What European companies are like this? I've been trying to apply for ages at US companies, for the reasons such as this. Reading HN for 6 years and being US-centered in general (thanks to tech) made me want to work like this. I've noticed that at European organizations people indeed try to pin me in a box, and then I can't thrive when I'm working there.

The article uses JIRA is a touchstone that seems to equate to no autonomy. I think this is wrong.

I have worked at a good number of places, including a FAAMG.

The freedom that was given to me directly correlates to company size & seniority.

When I was younger, I didn't get much autonomy, why? because I was a naive arrogant prick. I would dream up solutions to problems that didn't exist. I would make existing problems worse by trying out new things.

When a company gets larger, it will bump into problems, missed features, deadlines or massive bugs. New procedures will get be implemented to make sure that those don't happen again. Ticketing is a good thing, so long as its developer lead. It allows delegation of tasks, and simple tracking of state. Its an artform that should be taught.

I was at a start up for two years that was bought out by a FAAMG. We were working on cutting edge computer vision research. We had a tight process, tracked with ticketing. We had complete autonomy.

We were chucked into SV "culture" only to find that is somehow managed to make cutting edge research both more chaotic and boring. Ironically I have much less freedom than I did when I worked at a large financial newspaper.

4. Middle managers are going to do something with their days. Once the growth frenzy stops and they're longer occupied by procuring and filling headcount, they go the next thing they know, implementing systems of surveillance ("accountability") and control ("alignment").

It all depends on who you're hiring and what you're building. Definitely applicable to startups and innovators coming up from the bottom.

But, there are absolutely companies maintaining low-growth Clunky Java Accounting Application for Insurance Companies #574 for whom this approach is contraindicated. Those companies can hire relatively entry-level, average graduates, at commensurate salaries, and assign them highly structured JIRA tickets.

Would they get better talent if their fronds tended more toward the SV model of compensation and autonomy described in the article? Absolutely. But in terms of marginal productivity or ROI, it's far from clear that it makes much of a difference to the financial performance of Cluky Java Accounting Application for Insurance Companies #574. That means massively overpaying for skills, or skill levels, that aren't really needed, or aren't needed enough to matter.

No, it's not the kind of software development any of us want to do, and I think the audience for this post are for the most part in no danger of having to. But I think it's important to be honest about the fact that this sort of dimly-lit, cubicle-dwelling sweatshop software work _is_ a high percentage of software development occurring on the planet. For that type of company, following the "SV" philosophy would arguably constitute a dereliction of fiduciary duty.

My view may be somewhat coloured by my exposure to medium to enterprise-sized companies in the telecom world, where a lot of the work is tedious, unimaginative and formulaic, using unexciting but established technology stacks, and so forth. But it still needs to be done, and there are companies who darken the skies with people to do it.

Lastly, I incorporate by reference everything that has been said elsewhere in this thread about the nature of large organisations and the poor scalability of engineering-led company process. Most software work, by volume, doesn't consist of skunkworks innovation or the development of something new. Most software work is incremental, in many cases strictly maintenance mode, and caters to many stakeholders. Large organisations and big capital serve an entirely different purpose that is realised at points further along the technology and product lifecycle. In this comment, I merely chose to focus on (1) the problems of empowering "average" talent this way and (2) the poor prospectus for doing so.

I dearly hope my cast iron skillet will never require a firmware upgrade.