Brain Food
  • Brain Food
  • pages
    • Brain Food
    • docs
      • Developer Resources
      • book-notes
        • Eloquent Javascript - Marijn Haverbeke
        • Range - David Epstein
      • computer-science
        • The Impostor's Handbook - Rob Conery
      • javascript
        • Node JS
        • You Don't Know JS Yet (2nd Edition ) - Kyle Simpson
        • react
          • React Server Components
      • reading
        • 10 Thoughts From 100 Books
      • self-development
        • Personal OKRs - 2021 (July)
      • software-development
        • Advice to Myself When Starting as a Software Developer - Gergely Orosz
        • on-software-development
        • What Silicon Valley "Gets" About Software Engineers - Gergely Orosz
      • typescript
        • TypeScript Fundamentals
      • web
        • Performance Optimization
Powered by GitBook
On this page
  • 1. Autonomy for software engineers
  • 2. Curious problem solvers, not mindless resources
  • 3. Internal data, code, and documentation transparency
  • 4. Exposure to the business and to business metrics
  • 5. Engineer-to-engineer comms
  • 6. Investing in a less frustrating developer experience
  • 7. Higher leverage --> higher autonomy and pay
  • Summary

Was this helpful?

  1. pages
  2. docs
  3. software-development

What Silicon Valley "Gets" About Software Engineers - Gergely Orosz

Previouson-software-developmentNexttypescript

Last updated 2 years ago

Was this helpful?

1. Autonomy for software engineers

The expectation at traditional companies is to complete assigned work. At SV-like companies, it's to solve problems that the business has.

It's important to give developers the freedom to make important decisions that could positively benefit the business.

2. Curious problem solvers, not mindless resources

In practice, a motivated engineer easily makes multiple times the impact of a "factory worker" who is just told what tod o.

Engineers who are encouraged to solve problems will reflect on the tasks assigned to them. They will take the time to think about the business impact of the task. How does it align with the business goals? Can we avoid coding that feature at all? Can we ship multiple tasks at once?

3. Internal data, code, and documentation transparency

Employees - not just engineers - often have access to realtime business metrics.

Developers with access to business data can make better decisions. They will be better informed of the "why".

4. Exposure to the business and to business metrics

Engineers should be encouraged to intereact with the reset of the business. Facilitate communication between developers, designers, and product leaders. Let developers become product-focused.

5. Engineer-to-engineer comms

Encourage communication betwen developers from different teams. It's easier to solve problems as such.

6. Investing in a less frustrating developer experience

Companies that care about engineers focusing on solving problems quickly set up various infra, platform and SRE teams, who reduce the developer experience churn.

7. Higher leverage --> higher autonomy and pay

Summary

"SV-like" companies think of engineers as value generators, and problem solvers. Traditional companies think of them as factory workers.

Creative problem solvers can bring in more value when used properly. You also provide engineers a sense of purpose when you give them more freedom to make decisions. This is how you enable them to contribute more business value.

Engineer leverage
Source