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

91–100 of 339 posts

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

#91

Post by jtdev »

tester756 wrote: post #84
lxe wrote: post #79

Software engineers can't always be the best or effective at solving problems that require specialized non-software engineering knowledge. In an SV-style company that develops a SaaS product, engineers can make all sorts of decisions, since they are solving a problem they are intimately familiar with. What about other industries that require specialized knowledge or regulatory bureaucracy, like finances or healthcare?

this, I work with mid-size ERPs that deal with some law, some tax, invoices and all this shit that ERPs deal with and I wouldnt trust myself to commit any "business logic" decision in that environment there's so much stuff happening

In such an environment engineers should be working closely with these subject matter experts... you don’t just put fear in the engineering culture and throw layers of bureaucracy at the engineers.

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

#92

Post by emerongi »

p_l wrote: post #66
chris11 wrote: post #63

Earlier quoted context omitted.

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?

I think that's the joke.

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

#93

Post by jedberg »

bigiain wrote: post #90
jedberg wrote: post #76

Earlier quoted context omitted.

A company that makes cast iron skillets can still have software as a core part of their business. Logistics, monitoring the manufacturing process, forecasting demand. All of these things can be software that is core to business. Or even more important, having a useful website for selling their products.

Sure, but Le Creuset will never describe themselves as "a software business"... (And if they did, I'd immediately be looking for a different cookware supplier.)

Ah yeah I don't think asking if they are a "software business" is actually a good question.

But I'd still be wary of working for them if their software engineers were in IT.

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

#94

Post by courtf »

lakala6790 wrote: post #78
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.

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

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

#95

Post by BigJono »

lxe wrote: post #79

Software engineers can't always be the best or effective at solving problems that require specialized non-software engineering knowledge. In an SV-style company that develops a SaaS product, engineers can make all sorts of decisions, since they are solving a problem they are intimately familiar with. What about other industries that require specialized knowledge or regulatory bureaucracy, like finances or healthcare?

You just have other technical roles to handle those areas that are treated the same as the software engineers. Or "technical" roles in the case of bureaucracy (once it gets complicated enough to need entire people to manage it).

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

#96

Post by bigiain »

jtdev wrote: post #86
abalashov wrote: post #58

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…

Those companies will die...

I don't think so. At least not all of them.

Agile is not always the right approach. For highly regulated or safety critical industries, it's quite likely to be the wrong approach.

(On the other hand, Waterfall for B2C mobile apps or casual games is also almost always the wrong approach too...)

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

#97

Post by abalashov »

jtdev wrote: post #86
abalashov wrote: post #58

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…

Those companies will die...

It's probably easy to believe that if you're developing a SaaS app on the Pacific Coast, but in actually-existing reality -- no, they won't.

Their business processes and products are often sclerotic, and so are vulnerable to disruption by smaller, more nimble startups. That's the central premise of virtually all B2B software from the Valley. But they certainly aren't going to die.

In fact, large companies and enormous capital are required to take things from a "disruptive innovation" to a household name, to say nothing of providing an exit for SV startups. So, they're a vital part of the biosphere and they're not going anywhere.

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

#98

Post by Roboprog »

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?

God-Emperor of Scrum. The code must flow.

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

#99

Post by chris11 »

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…

> The article uses JIRA is a touchstone that seems to equate to no autonomy.

Technically I don't think JIRA by itself means no autonomy, it's just how it's used. But JIRA can expose a ton of metrics to upper management. And I think that management influencing how JIRA is used probably indicates lower autonomy.

For instance, story points and velocity being tracked by management might be problematic. Is the team tracking everything with story points? Otherwise certain types of work could be hidden, and slow down velocity. Is management using those metrics for team or individual performance reviews?

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

#100

Post by chris11 »

emerongi wrote: post #92
p_l wrote: post #66

Earlier quoted context omitted.

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

I think that's the joke.

It would be like scrum of scrums in LeSS or PIs in SAFe. But instead of focusing on what work would be done, it would focus on how it would be done, and what changes scrum masters would make.
Post reply on HN