What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not

I've worked at various tech companies: from "traditional" shops and consultancies, through an investment bank, to high-growth tech firms. I've also talked with software engineers working at startups, banking, automotive, big tech, and more "traditional" companies. This mix had a healthy sample of Silicon-Valley companies and ones headquartered outside this region.

I've noticed that Silicon Valley companies consistently "get" a few things that their traditional counterparts fail to either understand or implement in practice - especially in Europe. These are practices that result in faster innovation at a company-level, better professional growth for engineers, and just better "utilization", for the better word for it. In turn, Silicon Valley companies can (and do!) pay higher wages, and they get more value out of the same person.

In this article, I'll use the term "Silicon Valley-like company" to refer to modern companies who create high leverage with each software engineering hire, and who have traditionally been headquartered in Silicon Valley - though many newer ones no longer got started there. They are the kind of companies that are comparable in working output per engineer to the likes of Facebook or Google. They use similar methodologies and can often attract talent from other "Silicon Valley-like" companies.

Here are the key things these companies "get" better than many others.

1. Autonomy for software engineers

In "traditional" companies, developers get work items assigned to them - most often JIRA tickets. These tickets are vetted by the product - or project - manager, and they have most key details to do the work. And they're expected to do just that. There's little need for questions unless it's about clarifying a detail in the ticket.

Join a "SV-like" company, and you'll see little of this. There are projects, and there are program managers and engineering managers. But for the most part, engineers are expected (and encouraged!) to figure out the "how" of the work, including making larger decisions. In some places, each project would have an engineer leading it, who facilitates breaking up the work. At other places, engineering managers or senior engineers could do this work. Regardless of how it's done, all engineers are incentivized to look at the big picture, to unblock themselves, and to solve any problem they see.

Engineers taking initiative is something "SV-like" companies celebrate. It's common to see services and features built that engineers suggested or have teams spend dedicated time paying off tech debt that people on the team advocated for. And it is uncommon for managers to tell engineers what exactly to do, to break down their work into small chunks or to micromanage them. People self manage.

The expectation from developers at traditional companies is to complete assigned work. At SV-like companies, it's to solve problems that the business has. This is a huge difference. It impacts the day-to-day life of any engineer.

At traditional companies, the notion of devs do what they are told often ends up with a hierarchical setup. I've talked with people at a bank that had six levels of project management. Developers were at the bottom two. Decisions were allowed to be done from level three. Basically, those doing the work did not have a say - by design. Need I add that this bank was struggling with how their software department was (not) working?

A hierarchical view of the world. Some traditional companies still work like this.

Compare this with places where engineers are recognized to have the ability to solve problems on the ground better than anyone else. Leaders know that it's in the best interest of the business to share all relevant business context with them, and give space for execution.

Passing context down and giving autonomy to make decisions is how efficient organizations pull ahead.

2. Curious problem solvers, not mindless resources

Traditional companies tend to think of an engineer's time of 8 hours to spend on coding. Any time that is not in front of a computer, and doing coding, is often thought of as waste. And they justify this with the high cost. I've heard someone describe the reasoning like this:

Software engineers get paid more than many other functions. We need to utilize them accordingly. We can't have them run empty.

"SV-like" companies think of software engineers as the people best suited to solve the problems that the organization has. They hire not only for technical skills but communication and problem-solving ability. Their thinking is a bit more like this:

Software engineers are among the highest-paid people in our company. This is because they can bring some of the highest leverage through coding and problem solving. We want to expose them to the business, so while they are doing their "normal" work, they can also find more impactful opportunities for the business.

In practice, a motivated engineer easily makes multiple times the impact of a "factory worker" who is just told what to do. In the worst case, when the work spec is are clear and correct, both people have the same output. However, engineers who are encouraged to solve problems will often stop and think before picking up work, identifying opportunities for more impact. Here's a couple of conversations I've had at "SV-like" companies after asking an engineer if they can do X:

  • "I did a bit of digging, and though we could do X, if we can reduce the scope by this feature that won't make a difference for the business impact, we could ship this without any code changes, just changing a few config files."
  • "I am concerned if we could ship the project, and think we should put a pause on it. I checked what our competitors are doing, and one of them launched a similar feature, but reversed it, after they got investigated by the regulator. Have we checked with the legal team if we could ship this at all?"
  • "I looked at our backlog, and project Y is really similar. If we combined project X and project Y, we could ship two things, with very little overhead."
  • "We could either build this project on the legacy infrastructure now, but then we have migrate to the new infra that will be complete in a month. Can we delay the project by a month, until the new infra is ready, to avoid double work? If there's no strong business reason to launch in a month, I'd really suggest we do this"

In an environment that encourages problem solving and results over following directions, better decisions are made.

3. Internal data, code, and documentation transparency

Transparency is big at SV companies. Though there are exceptions - Apple or Palantir supposedly taking great care to give as little information to engineers as needed - I've observed most "SV-like" companies sharing as much as they can. They do this in a way that is in line with GDPR, PII, and other regulations that apply to them.

Employees - not just engineers - often have access to realtime business metrics, and data sources to write their own queries and create custom reports. At Skyscanner, we would get a daily summary email on the daily revenue breakdown, every day. At Uber, there would be a weekly growth newsletter with similar metrics, weekly.

As companies grow and as they go public, a consolidation of this information happens. Still, engineers still have access to business data for their organization that helps guide their decision making.
At traditional companies, much of this does not exist. Engineers get the spec, and the higher ups will know why something is decided - at least, that's the idea.

4. Exposure to the business and to business metrics

At SV companies, it's expected that each team member understands what part of the business their work impacts and how. The team goals are rarely just to ship a feature: it's to decrease customer churn by 2% by launching Feature1, or to increase revenue by a predicted $10M/year by shipping ProjectX.

SV engineers are encouraged to interact with the rest of the business and build relationships outside just fellow engineers. In practice, more senior engineers usually end up doing this: from having 1:1s with product managers to taking part in customer research sessions. But I've seen new joiner engineers work directly with business stakeholders without anyone blinking an eye.

In contrast, traditional companies often make it impossible for developers to interact with the rest of the business. This is not how it's presented, though. They'll say "we want to shield our engineers from distraction". But I've heard stories of an engineering manager wanting to invite team members to a product presentation, and the product manager shutting this idea down. "We need them to work, and we can't afford to be distracted." is a common excuse.

When an engineer at a traditional company builds relationships outside their team, they'll often get told they are "not focusing enough", "wasting time" or doing things that is "not their business". This kind of "unusual" activity would often be recorded as a negative in their performance review.

It sounds crazy to me that companies would take some of their best-positioned problem solvers, and force them into the "you just write code" box, but it's happening. And the same companies who try to measure engineering productivity with metrics related to lines of code or commits wonder why their engineers are not product-focused or product-aware.

5. Engineer-to-engineer comms over triangle-communication

When you're an engineer and have a question about how another team does something, you go about it differently at traditional, and at "SV-like" companies.

Traditional companies will encourage hierarchical communication. This is both to "shield" engineers, and also because managers in these places prefer to be information hubs, and not give up control over this part. Here's how a question or ask to another team would often go:

Communicating in a "traditional" / hierarchical organization

"SV-like" companies encourage engineer-to-engineer communication, cutting out middlemen. This is faster in all cases. And in cases where the engineer on the other team cannot help, this process can fall back to the "traditional" model of the manager helping out facilitating the discussion:

Communicating done (far more) efficiently

6. Investing in a less frustrating developer experience

Developing in 2020 can be frustrating. Not because of writing code - that's the easy part! - but the surrounding things. Setting up dependencies. Deploying to production or test environments. CI/CD. Monitoring and alerting. These are not that big of a deal while you're on a team of a few people. Still, they'll come up every now and then.

However, the developer experience becomes much more frustrating as the company grows. It starts with smaller things like the build time getting slower, dependencies adding up, or changes that need to be made across services. It continues with figuring out which team owns which service, small migrations blowing up by impacting many teams, all the way to redefining the architecture across all of engineering.

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

While it might sound counter-intuitive to hire software engineers who only focus on other software engineers working faster: at many places, it's not. It's a great return that helps these companies move faster, and developers stay happier.

(This also happens to be an area I'm quite interested in, and where I'm validating some startup ideas - if you have thoughts on this space, hit me up).

7. Higher leverage --> higher {autonomy, pay}

Any SV-like company who wants to compete in pay for engineers needs to create high leverage where the value brought in by these engineers exceed their salaries. This leverage can come both at scale, and at growing the business. Reducing time wasted on things like unnecessary comms, and tooling all add to this leverage. Giving enough autonomy for engineers to (over) contribute to the business is how you can keep this leverage high.

What much of Google, Facebook and other established companies are paying high salaries today, is the leverage of scale. An engineer at one of these companies often builds features used by many millions of customers. This kind of leverage and value-add pays for itself.

Higher autonomy --> higher leverage --> higher value created --> higher pay (all while the company still makes a profit)

What SV-like startups do is leverage software engineers in growing the business. This is how a software engineer at Fog Creek software implemented a million-dollar idea for ad classfields. It's how a few engineers and designers pushed ahead to build the Like button at Facebook. The business impact of this button is well in the billions: allowing Facebook to (re-) target ads, and "track" users outside of the Facebook site.

Had any of the people mentioned above worked at a "traditional" environment, their ideas would have stayed exactly that: ideas. "SV-like" startups incentivize engineers to come forward with business ideas, and implement them, while they are are at it. Everyone is better off for it: the people with the idea and the business.

Companies that leverage engineers well will have no trouble paying close to the top of the market, or above it. Basecamp is a good example of non-"Big tech" company that leverages engineers well, meaning they can also pay top of the SF market for base salary, globally, while staying profitable.

The biggest overall difference

There's a lot of aspects to differences in how different type of companies approach their relationship to engineers. The biggest one is this, though. "SV-like" companies think of engineers as value generators, and creative problem solvers. Traditional companies think of them as factory workers.

This divide in thinking is what leads to forward-thinking companies being able to both pay engineers better, while giving them more autonomy. A factory worker has a very well-defined added value, that you can plan for. A creative problem solver, on the other hand, can bring in 10x that value, when utilized properly. It makes sense to pay them more, give them more freedom, and as this is how you enable them to contribute more value business value.

Once you've worked in a SV-like environment, you also struggle to go back to the "traditional" workplace, where everyone has their well-defined role, and eyebrows are raised when you step out of it.

As a software engineer, pleasant places to work at is where you are a problem solver, not a factory worker. Which one are you today?

Gergely Orosz

A hands-on engineering manager, previously developing across the stack for a decade. Working at the intersection of Silicon Valley and Europe. Currently at Uber. Microsoft, Skype & JPMorgan alumni.

Amsterdam, Netherlands