<story><title>FAANG promo committees are killing Kubernetes: A Short Thread</title><url>https://twitter.com/kantrn/status/1511791378497384454</url></story><parent_chain><item><author>paxys</author><text>While it is still a stretch, the title should be &amp;quot;Google&amp;#x27;s promo committee is killing Kubernetes&amp;quot;, since no other FAANG-equivalent is using or contributing to Kubernetes in a meaningful way.&lt;p&gt;The core point:&lt;p&gt;&amp;gt; It&amp;#x27;s too indirect, fixing a bug in kube-apiserver might retain a GCP customer or avoid a costly Apple services outage, but can you put a dollar value on that? How much is CI stability worth? Or community happiness?&lt;p&gt;While correct, the same is true for &lt;i&gt;most&lt;/i&gt; projects at these companies. Very little work that a single engineer does can be assigned a provable revenue number. How does someone working on an internal build tool get promoted? Or a new training model? A large-scale refactor of a legacy codebase? (All of these are examples of very senior promos at my own FAANG company).&lt;p&gt;Kubernetes is no different. An engineer has to show how the work they did first and foremost aligns with their team&amp;#x27;s goals. If it doesn&amp;#x27;t, then well they shouldn&amp;#x27;t have been working on it in the first place. While working on open-source projects might be tolerated, even on company time, it makes sense that it won&amp;#x27;t put you on a path to promotion unless there is direct benefit to the company from it.</text></item></parent_chain><comment><author>saagarjha</author><text>&amp;gt; While it is still a stretch, the title should be &amp;quot;Google&amp;#x27;s promo committee is killing Kubernetes&amp;quot;, since no other FAANG-equivalent is using or contributing to Kubernetes in a meaningful way.&lt;p&gt;Apple puts Kubernetes on &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;opensource.apple.com&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;opensource.apple.com&lt;/a&gt; as a project they &amp;quot;lead and contribute to&amp;quot;…&lt;p&gt;&amp;gt; Very little work that a single engineer does can be assigned a provable revenue number. How does someone working on an internal build tool get promoted?&lt;p&gt;While I generally agree, I&amp;#x27;ve made changes in our internal build tools that I can easily put a number on, although it&amp;#x27;s not a revenue number. Make build process 10s faster, 1000 engineers run this 10x a day, you&amp;#x27;re saving more than an engineer day per day of time. That&amp;#x27;s a definite impact right there, assuming your management is on board with accepting it :)</text></comment>
<story><title>FAANG promo committees are killing Kubernetes: A Short Thread</title><url>https://twitter.com/kantrn/status/1511791378497384454</url></story><parent_chain><item><author>paxys</author><text>While it is still a stretch, the title should be &amp;quot;Google&amp;#x27;s promo committee is killing Kubernetes&amp;quot;, since no other FAANG-equivalent is using or contributing to Kubernetes in a meaningful way.&lt;p&gt;The core point:&lt;p&gt;&amp;gt; It&amp;#x27;s too indirect, fixing a bug in kube-apiserver might retain a GCP customer or avoid a costly Apple services outage, but can you put a dollar value on that? How much is CI stability worth? Or community happiness?&lt;p&gt;While correct, the same is true for &lt;i&gt;most&lt;/i&gt; projects at these companies. Very little work that a single engineer does can be assigned a provable revenue number. How does someone working on an internal build tool get promoted? Or a new training model? A large-scale refactor of a legacy codebase? (All of these are examples of very senior promos at my own FAANG company).&lt;p&gt;Kubernetes is no different. An engineer has to show how the work they did first and foremost aligns with their team&amp;#x27;s goals. If it doesn&amp;#x27;t, then well they shouldn&amp;#x27;t have been working on it in the first place. While working on open-source projects might be tolerated, even on company time, it makes sense that it won&amp;#x27;t put you on a path to promotion unless there is direct benefit to the company from it.</text></item></parent_chain><comment><author>coredog64</author><text>Here it’s focused on k8s, but it’s not out of line if we generically apply it to AMZN.  How many services look cool, have a great re:Invent kick-off, and then go KTLO a year later?  I’m going to lay that at the feet of the AMZN promo process, which prioritizes creating something new over real and needed maintenance.&lt;p&gt;I’m going to further reduce this to lazy management.  It’s easier to point to splashy announcements to show impact than it is to put in the work and help your direct reports quantity unglamorous maintenance work.</text></comment>