Live data from Hacker News

What Silicon Valley gets about engineers that traditional companies do not

blog.pragmaticengineer.com

221–230 of 339 posts

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

#221

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…

In many companies, the 'product' department exists to protect the owners from the leverage developers would have if they had access to the business context.

My past work is Very much this.

Edit: details. Our devops allies itself with management and kept “business secrets” from developers. It was abbhorant to witness. I eventually introduced functionality into the devops tools and openned it to developers and got bullied (2nd edit: by my own team and management, i was soft bullied: silence treatments, secret meetings without me, lies, etc. i was junior. My own confession: i did the work without discussing it with the team after being told “fuck the devs” by a senior.) to quit.

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

#222
post #53
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.

A question I like for non-tech businesses is: "do you see this as a software business or transitioning to become one?" Because these days every business has to be investing into software products, and the ones that don't recognize that the software is key to all their products are the ones that are dead folks walking. They're also great targets for SaaS consultant vultures.

This can be carried too far. Every business now has a director or consultant whose job is to chart the company's progress towards becoming a software business. This can have any number of effects:

1. It's not a slam dunk that software development is an asset to a business. Entire books have been written on how to keep software projects from eating your business alive. Many software businesses fail.

2. The hardware people notice that they're being treated as second class citizens, and wander away. Remember, the best leave first, including the people who fully understand how your product works.

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

#223

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…

In many companies, the 'product' department exists to protect the owners from the leverage developers would have if they had access to the business context.

Thats an interesting take. But wouldn't product end up having the same leverage? Or is the goal to divide product and engineering work so that no one person has the complete view of the business?

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

#224
post #171

it's funny, as the faang interview process, as i know it, does not select for the hybrid dev/product skillset the OP describes. in fact, it shies away from it about as far as you can get, instead focusing on beloved algorithmic problem solving, which i guess is a good fit for standardized testing and leveling, but will tell you nothing about broad skills in both software development and product design/management as d…

algorithmic problem solving is very close to IOI/ACM ICPC type problems, which test on combination of knowledge of data structures+algorithms and creative ability to combine both to create own algorithms while being under interview anxiety+time limti stress. Quite essential in everything internet-scale and filters top percentile candidates pretty well. THis process is not required for your average company where IT is…

yeah, yeah. programming contest problems make better programmers, sure. OP is arguing that developers should be more involved in product design though. although in a large enough shop that will likely cap out with a single service...

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

#225

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…

This post just made me miss coding so much. I spend basically all my time these days understanding the business. Sometimes I just want to blindly code: create an algorithm to calculate x, make a screen to display y. But those roles don't pay.

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

#226

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…

> Silicon Valley engineering practices can look very non-Agile to a lot people from traditional companies that are doing Agile.

This is of course because the thing that traditional companies call "Agile" is really just the same business-as-usual top-down manager-controlled garbage software process they've always used but with the cool-sounding name "Agile" slapped on it.

Whereas what SV companies do is much closer to what Agile is really about, regardless of what they call it.

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

#227
post #210

Earlier quoted context omitted.

In many companies, the 'product' department exists to protect the owners from the leverage developers would have if they had access to the business context.

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 other companies will burn through tons of dev resources over nit-picking or implementing speculative edge-cases.

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

#228

Earlier quoted context omitted.

How about “people over process”? Yet we are slaves to Agile Scrum process and procedure. Double talk.

The reasons behind the creation of Scrum and the reasons behind the adoption of Scrum are different. Plus, most implementations of Scrum are bullshit. Scrum does not recognize the role of a "project manager". There's the product owner, the scrum master and the development team. That's all. The scrum master only exists to guarantee the process is followed. The scrum master is just a scrum evangelist, not a real leader…

And product owner and scrum master need to be highly skilled people with a lot of responsibility instead of whoever has nothing better to do at the moment as is so often the case.

I still can’t figure out how line managers and architects fit into a well run scrum environment. Seems they would be losing a lot of power.

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

#229
post #187

No focus on a structured product definition and leaving it to engineers to 'figure it out' does not bode well for the end user or business itself. This is a real experience in a FAANG company - we were developing a new product in enterprise space targeted to small enterprise IT admins who may not be highly trained or experienced. One of tiny feature was the ability to download and self manage security certificates (u…

I think there is certainly a middle ground between "engineers do all the decision making" and "engineers do none of the decision making." I'm not sure the author was advocating the former. Rather, I think the author was saying that the possibility to influence the decision making at a fundamental level is what makes the SV-like companies great.

This follows my experience. Even at a FAANG, product managers aren't going to get every detail and edge cases are going to pop-up, so requirements are going to come from a back-and-forth between product and eng throughout the process. That back-and-forth is the key, not expecting engineers to figure out all the requirements, nor from product managers either.

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

#230

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…

As a person who was there for the early days of Agile, I just want to say it's sad that's what Agile has become. You're right, of course. But that's not what was meant. Somehow "Individual and interactions over processes and tools" became "individuals, please stop interacting and conform to these processes and tools".
Post reply on HN