What Silicon Valley gets about engineers that traditional companies do not • Hacker News Board

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

#251

Post by koonsolo » Mon, Jan 11, 2021, 7:50 AM UTC

phendrenad2 wrote: post #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…

If your engineers are not involved on the business side, they basically have no clue about who the customer is, how the user use the software, what problems they bump into etc. In the bigger companies I worked, engineers never even seen a customer or user.

A vision needs to flow top-down, but if you want your engineers to make helpful suggestions, they need to be involved on the business and customer side from day 1.

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

#252

Post by KaiserPro » Mon, Jan 11, 2021, 8:00 AM UTC

throwawaybbqed wrote: post #59

KaiserPro wrote: post #54

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.

How it worked for us was as follows:

the business goals were translated into "epic" tickets, after that it was entirely up to the engineers.

An example of this would be something like:

We need an API that allows secure access to service x. It must have authentication, respond with an answer inside x milliseconds, It must work with a developer admin interface (see ticket z)

Ticket z would be assigned to the web team, and we would work closely on an interface between the API backend and the dev interface.

After that, my team would layout and make a high level design. We'd break that design down into individual "sub epics" and let each dev create and work on tickets as they see fit.

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

#253

Post by plutonorm » Mon, Jan 11, 2021, 8:00 AM UTC

gwbas1c wrote: post #125

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…

Yeah, but if you are like me someone who always wanted to get out of software completely, this would have been a god send. But over here in the UK I've never been at a company that has allowed me to even have a sniff of the business side. And I'm nearly 20 years into an IT career spanning 8 different companies.

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

#254

Post by boffinism » Mon, Jan 11, 2021, 8:03 AM UTC

achow wrote: 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…

Do you believe the product managers would have defined the spec both faster and equally correctly in all the details, if they'd done it in advance before getting the engineers involved? (My guess from experience of comparable situations would be no, but keen to hear alternative perspectives)

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

#255

Post by v8engine » Mon, Jan 11, 2021, 8:07 AM UTC

danielheath wrote: post #191

ShamelessC wrote: post #168

Earlier quoted context omitted.

That's interesting... I think. Could you give an example (as contrived as you wish) to illustrate this point?

Essentially, developers with substantial domain experience / familiarity with the problem space tend to do what they think is best, instead of following orders. Accepting the value of that behavior requires a great deal of personal and organizational maturity, especially when you want to try something out quickly and your developers refuse. Sample phrases include: "Why did the customer ask for that - it sounds like o…

>"Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses".

I don't get it. Can you explain?

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

#256

Post by physicsguy » Mon, Jan 11, 2021, 8:18 AM UTC

mark-r wrote: post #142

bigiain wrote: post #113

Earlier quoted context omitted.

Jira, for all it's warts, is a massively configurable piece of software that can be deployed/used in a hugely broad variety of ways. I once worked at a place where Jira was without doubt a positive force within the company. There was an Altassian-trained Jira specialist working there who collaborated setting up each Jira project, and provided ongoing advice/assistanece to users (both PMs and devs). This was in a comp…

Yes, Jira is very configurable. But whether you'll be allowed to configure it is an open question. I worked on a team that had a very finely tuned Jira workflow. Then one day we discovered that all our customizations had been eliminated. The company had decided that it wanted all configurations to be based on a company standard, and no deviations would be allowed. We weren't even warned ahead of time.

We can't even install plugins on ours!

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

#257

Post by hef19898 » Mon, Jan 11, 2021, 8:18 AM UTC

celim307 wrote: post #46

quicklime wrote: post #18

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…

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…

It's funny, how that would be one of the major differences between Amazon and other companies I worked for. Only for Supply Chain management and logistics.

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

#258

Post by loceng » Mon, Jan 11, 2021, 8:19 AM UTC

boffinism wrote: post #254

achow wrote: 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…

Do you believe the product managers would have defined the spec both faster and equally correctly in all the details, if they'd done it in advance before getting the engineers involved? (My guess from experience of comparable situations would be no, but keen to hear alternative perspectives)

That would depend on the experience and domain expertise of said project manager, no?

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

#259

Post by lordnacho » Mon, Jan 11, 2021, 8:21 AM UTC

cbozeman wrote: post #248

tehjoker wrote: post #194

Earlier quoted context omitted.

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.

So much this. I actually studied a joint course of Engineering and business, which was supposed to be two thirds of the Engineering course, two thirds of the business course. When you put it together the Engineering was still about two thirds of the total, with the business stuff mainly being simple things that took a long time to read. Everyone thought it was unsubstantiated just-so stories (Betamax, five forces, etc), but the point was to know the stories so you could communicate with business people.

If you look at things that are actually hard, nobody keeps you from getting the info. You're just not going to understand that graduate seminar in ergodic theory, though you're welcome to attend.

The reason they keep you from the info is of course you'll see the naked emperor.

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

#260

Post by bennyelv » Mon, Jan 11, 2021, 8:23 AM UTC

dependsontheq wrote: post #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…

I think funding and margins are the thing that are actually causal here: when you're swimming in funds, can afford to hire whoever you like to do whatever you like and you don't need to be turning a profit for at least 5 years, the organisation can be run very differently to one in which quarter to quarter cashflow really matters and there are margins to think about.

Funnily enough I work at a software company which is bootstrapped and where cashflow matters, I'd love to run things like a fully funded SV startup but I can't. We just can't afford it.