Live data from Hacker News

What Silicon Valley gets about engineers that traditional companies do not

blog.pragmaticengineer.com

241–250 of 339 posts

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

#241
post #210

Earlier quoted context omitted.

In my experience it is the opposite of that. Many ‘product’ groups exist because engineering teams kept complaining about meetings and just wanted to be told what the build. Collectively as a profession we have ceded away many of the things that made software development unique and powerful over the last 10 or so years.

This is true, but I've also seen "product leaders" in organizations not articulate a clear vision, requiring the engineering staff to do a Socratic-like process to pull tangible requirements out of said "product leader". It's a tedious process so I'm not surprised engineers throw their hands up and just have a PM do it. I do think SV puts more trust in their engineering teams to produce polished software, whereas oth…

Completely agree, same thing has led to massive growth of product mangers, product owners, and various other titles that do similar things.

The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.

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

#242
post #218
post #213

Earlier quoted context omitted.

Hmm, that is a weird conclusion to draw from the observations. The article and the conversation here suggests that the Silicon Valley model is a good way to give developers more leverage and also to get more out of them. That model is generally far from cooperatives and still has plenty of hierarchy. Getting 'organised' and into cooperatives might still work, I don't know? I'm just saying that the available evidence…

I would be interested if you have a few names of software cooperatives (still running or not). I don't think a company's purpose is necessary to eat the world but that's going into opinions so I will refrain.

This book had an interesting take on the subject: https://leanpub.com/developerhegemony

It asked why couldn't development firms be organized like how doctors or lawyers often organize themselves, as partnerships with the PMs, etc like nurses or paralegals.

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

#243

Earlier quoted context omitted.

I've been the client engineer before, trying to get through the opaque 'solution support' folks to the actual engineers of the product. No dice. We could never get the problem solved and we ended up ditching the product.

When I eventually got an NPS e-mail from them, I gave them a 1, and explained that I couldn't get through to actual engineers so we gave up, and then a solution engineer followed up and apologized and informed me that if there was anything they could do, to let them know. I never wanted to bang my head against the monitor harder than in that moment.

For anyone like me who had never seen the term "NPS e-mail", this seems to explain it pretty well:

https://www.questionpro.com/blog/nps-email/

(I don't know anything about this company and am not endorsing them, just noting it as a reference.)

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

#244

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…

Can you please describe how you had a Jira/ticket system that you felt gave you autonomy? Very curious how it could be implemented in a research setting.

I had a similar experience years ago. It was not Jira but bugzilla, but you can use it in the same way (I told you it was years ago ;)).

Any engineer could open any ticket for another engineer or team. You could also set the priority to how urgent it was. The receiving engineer could adjust the priority according to their own work of course.

Basically all work that you do was in the tracker. You could even add things for yourself, so you had a central place for your or anyones todo list.

Best work environment I ever worked as a software developer. There was never something blocking that some manager had to resolve, because you would just open a ticket an assign it to the person or team you think is relevant. All discussion was done in the ticket.

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

#245

I've worked at both SV and traditional companies, and I feel like this very closely matches my experience. One of the things I worry about is that even at companies that are doing "Agile transformations" and adopting methodologies like Scrum, in practice have "Product Owners" who are there to give instructions via Jira tickets. Other roles like "Business Analysts" are there to ensure that lowly developers never have…

I think it also depends a lot on the type of dev and if they want to take responsibility. I have experienced many devs that just didn’t care about the business and design side of things. “Leave me alone and go talk to the product owner”, was something I gotten quite often. But, to be fair I often also got “We want to be more involved in decision making”.

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

#246
This is a good article but there is a causality problem. I know a lot of pure software companies in the EU that work like that. If software is your core business, developers are in the loop at every decision, if your core business is building power plants...they are not. Now the Marc Andressen argument might be that software eats the world and everybody should run their business like this, and that might actually be true or not. Beside this product/core relationship problem, I see one other issue and that are margins, many SV companies are comparatively young and are in new markets with high margins (or ridiculously high funding) these high margins change their way of doing business.

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

#247
Having work at both styles of companies, in my opinion you really want a mix of both. Top-down decision-making is great! It allows your engineers to be engineers, cranking out good code and not "thinking up the stack" and worrying about the business logic. On the other hand, when engineers see a problem area, or see a feature that could be implemented in another way, you absolutely must stop everything and listen to them. This is a rare occurrence and they usually know what they're talking about.

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

#248

Earlier quoted context omitted.

We had a large disconnect between product and engineering. The directors solution was to have mandatory 8 hours of sprint ceremonies a week where we would review the definition of “bug” and “epic”, every week. We also were required to sit in on all team meetings regardless if it was your team. We had two full time scrum masters for a team of six engineers. I suggested instead engineers get looped earlier into the pro…

Business people love to think that their knowledge is somehow on a plane that others can't approach, but we see how many dumb decisions are made on a daily basis. The business would be comprehensible and steerable to everyone in the company, including the janitor, if education were institutionalized.

I have to admit, its pretty arrogant to think someone can make it through high-level physics, chemistry, mathematics, logic, etc., but can't figure out your business classes. Almost makes me laugh out loud.

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

#249

I once had a rather prestigious developer position in a Silicon Valley company. The "approachability" was a double edged sword. One problem I fought was that a lot of people expected handholding from me, or wanted me in their meeting to "feel important." There really is value to having your manager act as a gatekeeper. Another problem I had was that less ambitious people in other departments (support, qa,) would thro…

yes! I'm more junior than you are, but once I got a rep as a gung ho problem solver, I started getting approached by random sales associates asking me to implement features. I would usually do it out of love for the business, even if it meant I was staying up until 2am hacking shit together. But then I burned out. My quality of life improved significantly when I started being strict about people communicating with me only through my manager or product manager.

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

#250
post #94

Earlier quoted context omitted.

What you are looking for is RTE; Release Train Engineer

haha wow suppose I should have guessed there were already layers above and beyond the scrum master it's like the leaning tower of bullshit

Its turtles all the way up.
Post reply on HN