Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Silicon Valley gets about engineers that traditional companies do not

blog.pragmaticengineer.com

Post reply on HN
Print view View original

61–70 of 339 posts

Re: What Silicon Valley gets about engineers that traditional companies do not

#61

Post by ju-st »

lukashrb wrote: post #41

Are there any German companies that work like this?

I'm working in a kind of internal startup of a big German company and we operate "SV-like" as described in the article. My job title is Software Developer but most of the time I'm convincing other developer teams to share code to speed up development, inventing simple solutions to complicated sounding wishes of product management, helping project management to prioritize low effort features and trying to find out what the customers really need.

The only problem is that there is no leverage or scale because the software is coupled to physical goods, which means no big profits to pay above average salary and no career progression.

And that is the point where I don't agree with the article. I don't see the correlation between salary and autonomy.

Re: What Silicon Valley gets about engineers that traditional companies do not

#62

Post by flibble »

mettamage wrote: post #52

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.

Flipdish (HQ in Ireland with a distributed tech team) is one.

Full disclosure - I’m the technical co-founder.

Re: What Silicon Valley gets about engineers that traditional companies do not

#63

Post by chris11 »

courtf wrote: post #24
opportune wrote: post #21

Earlier quoted context omitted.

Yes! The proliferation and role of "business people" in traditional companies is IMO their defining characteristic. It shows how much or how little a business trusts engineers (and also engineer's "status" within the company, e.g. are they respected and valued or treated as a disposable resource) to run the business as general problem solvers. The ironic thing about Agile is that it has a cottage industry of "scrum c…

I've long imagined a position just above the scrum masters: the scrum lord. I see this position as a critical component of any agile strategy that seeks to maximize scrum master productivity, while still allowing scrum masters all the autonomy they need for their day-to-day duties.

I definitely agree with you, but I don't think that's sufficient. I think at larger companies it would be helpful to spend a day or two every quarter having a scrum increment meeting. The SI would let scrum lords and scrum masters plan what experiments would occur during the next quarter.

Re: What Silicon Valley gets about engineers that traditional companies do not

#64

Post by optimiz3 »

klipt wrote: post #36
courtf wrote: post #24

Earlier quoted context omitted.

I've long imagined a position just above the scrum masters: the scrum lord. I see this position as a critical component of any agile strategy that seeks to maximize scrum master productivity, while still allowing scrum masters all the autonomy they need for their day-to-day duties.

Why settle for scrum lord when you could be scrum king? Scrum emperor? One day even scrum Pope?

Pope Scrootus the 1st

Re: What Silicon Valley gets about engineers that traditional companies do not

#65

Post by jgeada »

closeparen wrote: post #56
opportune wrote: post #16

I have noticed that as SV companies get larger they tend to adopt the more "old school" approach. Not that it's a binary - it's a spectrum, and depending on management chain/how an org runs, people can have different experiences. I think it's caused by 1. When you have very deep management chains you start to have lots of people with opinions on what you should do, how you should do it, who you should do it with. Eve…

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").

That is a brilliant take on middle management!

Re: What Silicon Valley gets about engineers that traditional companies do not

#66

Post by p_l »

chris11 wrote: post #63
courtf wrote: post #24

Earlier quoted context omitted.

I've long imagined a position just above the scrum masters: the scrum lord. I see this position as a critical component of any agile strategy that seeks to maximize scrum master productivity, while still allowing scrum masters all the autonomy they need for their day-to-day duties.

I definitely agree with you, but I don't think that's sufficient. I think at larger companies it would be helpful to spend a day or two every quarter having a scrum increment meeting. The SI would let scrum lords and scrum masters plan what experiments would occur during the next quarter.

Isn't that just the Scrum of Scrums meeting, only at higher level perhaps?

Re: What Silicon Valley gets about engineers that traditional companies do not

#67

Post by PascLeRasc »

jedberg wrote: post #33

The best way to tell if a company values engineers is to ask which cost center they are in. Is it IT? Then they will treat you like a cog and consider you just a cost to the company. Is it Product? Then they will consider you valuable and critical to the company's success.

Has anyone made the switch between these two types of companies? I’m 2 years into my career but I’m one of those cog engineers working in IT and it’s really draining my soul. I don’t know how to talk about my job in interviews without giving off red flags.

Re: What Silicon Valley gets about engineers that traditional companies do not

#68

Post by p_l »

consp wrote: post #51
tolbish wrote: post #31

Earlier quoted context omitted.

That would give developers too much power and make them non replaceable/interchangeable.

They already aren't replaceable in that sense. It it impossible to open a can of developers and hope to get results straight away or hope nothing gets lost if someone leaves.

If you drop your expectations low enough, then yes, it's possible. It involves a steady churn state and the idea that "it's just how it is".

Re: What Silicon Valley gets about engineers that traditional companies do not

#69

Post by ng12 »

Interestingly enough most of this applies to one of the SF tech darlings I worked for when it was growing between 200-1,000 people. Every day I'd get either a pile of Jira tickets or a PDF full of mocks to build. Several projects I worked on were canned at the last minute by the "product" clique.

I don't think it's about SV companies against traditional companies, but more about companies that intrinsically value technology versus those that do not.

Re: What Silicon Valley gets about engineers that traditional companies do not

#70

Post by azemetre »

PascLeRasc wrote: post #67
jedberg wrote: post #33

The best way to tell if a company values engineers is to ask which cost center they are in. Is it IT? Then they will treat you like a cog and consider you just a cost to the company. Is it Product? Then they will consider you valuable and critical to the company's success.

Has anyone made the switch between these two types of companies? I’m 2 years into my career but I’m one of those cog engineers working in IT and it’s really draining my soul. I don’t know how to talk about my job in interviews without giving off red flags.

I guess the question to ask is, what do you talk about? When I talk about working in those types of companies I mention that I like to work in cross functional teams, interact with product and design, being part of the ideation process, wanting to understand the business and deliver value quicker.

What types of things do you say and why do you feel they may be red flags?

Post reply on HN