Are promo committees killing open-source contributions from Big Tech?

Kubernetes is struggling to hold onto core contributors working at Big Tech. Is this a systemic issue or an isolated one?

👋 Hi, this is Gergely with a bonus free issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at big tech and high-growth startups through the lens of engineering managers and senior engineers.

📢 Join The Pragmatic Engineer Talent Directory 📢

Are you hiring senior engineers or engineering leaders? On Tuesday, 28th June, I’m opening up access to The Pragmatic Engineer Talent director and releasing the first drop of candidates.

You’ll have access to candidates vetted by me. In this first drop you will be able to connect with 80+ world-class software engineers, engineering managers and engineering leaders, many of whom worked at top companies - both Big Tech, high-growth startups and scaleups.

You’ll get twice-a-month drops of hand-curated world-class software engineers and engineering managers open to new opportunities and can also post a job advert to The Pragmatic Engineer Job Board.

My goal is to make this directory the best place for world-class tech companies to find standout engineers and engineering managers - and the other way around.

If you’re looking for new opportunities - and are a software engineer or engineering manager with 5+ years of experience - you can also apply, joining publicly or anonymously.

On to today’s issue:

Early in April, a Twitter thread went viral on how Big Tech promo committees are “killing” Kubernetes and open-source contributions, generally:

Noah Kantrowitz @kantrn

FAANG promo committees are killing Kubernetes: A Short Thread 🧵

 As a summary:

Noah Kantrowitz @kantrn

tl;dr big tech promotion incentives are pushing people away from multi-vendor-project open source contribution as a full time job, so work is slowing down and I don't know how to fix it.

And some more details, quoting from this thread by Noah Kantrowitz:

“The promo process isn't exactly the same everywhere, but most of the FAANG-o-sphere has settled on a similar pattern of:

1. write up a document that says why you should get promoted, your "promo packet"

2. get your manager to submit that to the committee

3. wait

4. maybe profit

Packets have become huge manifestos at this point. You need to describe why your work is important, how you've made money for the company, how you've been a leader, internal letters of recommendation from high-ranking peers, and for top titles often external recommendations too. (...)

Going L6->7 at Google is worth ~200k/year, 7->8 is ~400. Similar patterns at other places. This isn't just about a title, ridiculous amounts of money are on the line. (...)

Promo committees have, for years now, been consistently undervaluing the work of full-time Kubernetes contributors. Or really of open source work more broadly.

Attributable revenue has been taking over as one of the most important factors at most companies. And Kubernetes has very little of that. It's happened gradually, and I don't think this was ever an intended outcome but it's a thing and we have to live with it. (...)

So people move on, sometimes to other teams at the same FAANG that work on more prestigious (read: more billable revenue) projects, sometimes to small startups to try and monetize their niche expertise, many just burn out from the stress of it all. (...)

So here we are, a rapidly shrinking pool of maintainers mostly working on really esoteric features because someone worked out how to connect them to revenue numbers. This is not a sustainable situation.”

My view is what’s described in this thread is all too typical within any major company, not just Big Tech. As a company grows, the organization wants to make sure it allocates its resources – read: its most experienced software engineers – on the initiatives that matter most for the business. They’ll start to reward – read: promote and give high bonuses to – people who work on projects with demonstrable business impact; read: it’s all about making money.

Projects that are ongoing, interesting or important, but have no easy pathway to monetization might still get funding, but Staff-and-above engineers will find it increasingly hard to get promoted, or to see their contributions reflected in their pay packets. This is because while they may put in lots of effort, those exertions aren’t tied to revenue.

So, it’s ironic that Big Tech incentives are what created tools like Kubernetes, React and other industry-wide solutions. These same incentives that today make it less feasible for tenured, experienced engineers to be ambitious and keep working on Kubernetes, are what allowed Google to invest in a project like Kubernetes, or Facebook to invest in React. As I write in Preparing for Promotions:

“How can you impact a large group of engineers, and drive a major business outcome? An obvious answer is to solve an engineering problem the organization has. However, to get promoted, the “what” (impact) is not enough. You need to perform at the next level of the “how” (competencies) as well. In practice, this means building something non-trivial that involves coordination of large groups, and is a difficult engineering challenge.

“This is exactly why, instead of using an existing third-party framework for an organization-wide issue, engineers working towards Staff promotions will write their own, in-house solution. As justification, they will find edge cases where existing solutions do not work well enough, and they’ll go ahead and execute this complex, impactful – and promotion-worthy – project. 

“Though at times building custom tooling is justified by unique needs, there is little to no incentive for any engineer to go with an off-the-shelf vendor solution that solves the problem. This approach would be labelled as trivial and would not meet the complexity expectations the software engineering and architecture/design competencies demand at senior and-above levels. 

“Promotion Driven Development is one of the reasons why all of Big Tech has built custom solutions for everything, from developer tools, through observability tools, to rebuilding products that did not take off. I’m not exaggerating: Google built 20 different chat products over 16 years, often in parallel. It is certain that each of these chat projects got dozens of engineers and managers promoted to the next level, before another group made the case to start a complex project from scratch with an even larger impact, instead of fixing up the existing one.”

The reality is in Big Tech, it’s challenging to keep someone on one project for a long time. At most companies, internal mobility is encouraged and made easy. When people move to a new team, the ones building greenfield solutions are the places engineers join, who want to get that next promotion. Keeping the lights on for a non-cash-cow product has never been – and likely never will be – rewarded as much as building something new or bringing in lots more revenue.

From my point of view, I’m happy to see Big Tech has launched much of their tooling in public, providing a viable alternative to grassroots’ movements – such as Linux – and commercial vendors. While it would be ideal for the rest of the industry if they could keep investing in these offerings indefinitely, there are dynamics at play we need to acknowledge. Perhaps these same dynamics are an opening for other, for-profit startups to step up and plug the gaps showing in the current ecosystem?

This was a section from this yesterday’s The Scoop article - a column where I cover patterns and trends I observe and hear about within Big Tech and at high-growth startups.