What Silicon Valley gets about engineers that traditional companies do not

Teams have very limited scope in exchange for enormous autonomy. “Inmates run the asylum” as my former manager put it.

It’s not so cut and dried as that, now is it. The pressure from the expectation and need to bring leveraged value can be detrimental. sometimes, and highly dependent on the person, this is life destroying. factory work is fine for most people, i believe. even engineers.

What the article compares: SVC-like vs traditional can be more accurately described as non-software employment versus software employment. It isn't that silicon valley has some magical solution that nobody else has, but instead is incentivized to leverage expectations common to all other industries. Again, this is impossible to see if your experience is limited to writing/managing software, but is clear as day otherwise.

The key reason why this is different for other industries is that the expectations are higher for employees where the investment per employee is higher. This is even true of lower paid and lower educated professions like truck driver or construction equipment operator compared to software engineer. In all other industries there exists some form of licensing or certification followed by some form of formal training such as a broker/agent relationship and then there is continuing education or periodic re-certification. These processes exist because of regulation. They take time and money away from the profession, which is an investment into each employee. With that level of expense more is expected in return by the employer.

The software profession has none of that. There is no investment in a software employee aside from keeping them happy enough to retain them. As a result its hard to think anything more of them than as a tool, like a janitor. This where you get the churn the article accurately describes as death by JIRA. SVC-like companies invest more in employees with higher salaries and thus expect more in return, which is not entirely the same as a formal professional process, but is a step in solving for this gap.

As for plain as day examples look at the common expectations for engineers at engineering firms, lawyers at law firms, and even truck drivers and police officers. There are all kinds of administrative and documentation expectations that are impossible to find in most software developers. Comparatively most software developers at the traditional companies seem largely illiterate. As an example most of these guys are scared to death of writing original software without a billion packages from NPM or Maven and are almost utterly incapable of writing formal documentation.

1. Most tickets are opened by engineers themselves, and don't contain detailed specifications, but just notes to provide context.

2. The purpose of the ticket is to provide something to link to, and a place to put information as it emerges. So commits and PRs usually link to a ticket, as do engineering and product management planning documents, reports etc. Some tickets are terse and quickly closed, others could develop a long history, with status changes, links to other tickets and documents, ownership by different engineers over time etc.

3. We organize development into sprints, but a Scrum master would be disgusted by our process. Sprints are just short-terms planning horizons; we ship as soon as the code is ready and close tickets when the code is in production. The purpose of a sprint is to batch up all the low-level planning and prioritization so most of the time we're focused on execution.

4. High-level planning is all in GDocs, spreadsheets and Photoshop/Figma. Product management doesn't create tickets unless they are reporting a bug, and even that was pretty rare. Engineering management gets a lot of information about what's going on by observing Jira; this reduces the need for meetings to communicate status. (Doesn't eliminate meetings, of course, but it does seem to make them more interesting.)

Basically, it boils down to, you have to keep status somewhere, and Jira does that pretty well.