I ignore the spotlight as a staff engineer

That's how it works for every organization. Not just corporate America. Want to play on the varsity baseball team? Better be popular with the coaches and other players. Otherwise you're on the bench keeping score. Want to go to Harvard grad school? Better be the right kind of popular. Want to be celebrated in machine learning? Better be popular by doing shallow work on lots of projects. The whole world is a scam, and the scammers always win.

This is one of the main reasons I'm trying to pivot away from a career inside a corporate environment. There is too much politics. I wish it was just do the work and go home, and get rewarded for the work that was completed, but instead there is a huge self-promotion (as in marketing) component. If that's what it takes I might as well do something that I own and control. If I'm going to need to worry about how to market my own work then I might as well try and at least not have a boss. I always thought the point of being an employee and having a limited paycheck meant that you don't worry about this things. That's the fair tradeoff.

So I'm not sure about this, particularly in the context of this article. I think it definitely applies to the splashy, Spotlight, one-off projects that will make a career with one shot. But a lot of careers aren't made that way, and this article is specifically talking about the ones that aren't.

I've found that trust is a currency in a corporate environment, possibly the most important one. And trust is built over time. If you work behind the scenes to ensure the success of a project but don't claim it, there's a decent chance somebody else will, and maybe it'll appear in their promo packet. But if you are in the vicinity of enough successful projects, over a long period of time, there's a good chance that leadership will notice that the common element is you. And in the process you'll built up a good reputation and network, so even if leadership gets replaced there are lots of other people that want to work with you. Promotions come slower at first, but they eventually catch up since you don't need to suffer the resets of failed projects and new roles.

It's pretty demoralizing to realize that appearances matter more than merit in careers/politics/dating/business/etc. The pragmatic approach is to not give up on merit but not neglect appearances either.

Still, the idealist in me hates this. It feels like quality should win out over advertising yet it rarely does in the grand scheme of things.

This hits close to home. I'm UK-based remote working for a US company, and I've seen this play out more times than I'd like. Led the architecture and design on products that went on to do $100m+, only for someone else to waltz in and take the credit once I'd moved on to the next thing. The annoying bit is that being good at your job often means you get dragged into the next hard problem before the last one's had its moment. Meanwhile, whoever happens to be standing there when the champagne corks pop gets all the credit. The paper trail advice is bang on. I'd just add - document decisions as you make them, not after the fact. Architecture decision records, design docs with your name on them, commit histories that tell the story. Handy when people's memories start getting conveniently fuzzy.

Personally, I don't care. Pay me and leave me the hell alone. We get 80 short years on this beautiful blue marble, if we're exceedingly lucky, and I refuse to spend one red second of that playing stupid games to excel in a sclerotic economic system that didn't even exist until very recently.

So I'm going to continue to try to grind it out as best as I can, while spending time on the things that actually matter: music, art, making delicious food for me and my friends, my hobbies, my family, my local community. Corporate America is bereft of joy and meaning anyway. Maybe it makes me some sort of sucker, but I don't care. I'd rather live.

I've always kind of expected it to work this way, with people being cutthroat and stealing credit for other people's work.

What I have seen in reality is a lot more nuanced. There are a lot of good ideas that will simply die if nobody pitches them the right way, i.e. if no one gets the rest of the team/org/company to understand and agree that it solves an important problem.

There are also very few novel ideas in a mature business or technology space. Every time I think I've come up with one, I search the internal company docs and often someone had mentioned the same thing 5 years ago in some long-forgotten design doc or something.

I've come to realize that the hard thing and the bottleneck for a good idea to have real impact is not the idea itself or the execution, it's pulling the right strings to make space for the idea and get it accepted. At a small scale, in your own team or ownership domain, this isn't necessary and you can just build things and let the results speak for themselves. But the amount of impact that thing has on the broader company will be limited if you don't pull the strings the right way.

Some people despise this idea and in that case, a big company is probably not the right place for you. But most of the cases I've seen of "brilliant engineers passed over for credit" were people not realizing and not doing this necessary part of the job. If someone else steps in and gets the idea more widely recognized after you had let it stall and moved onto the next thing, then 1. usually you do still some partial recognition for it so it's a win/win and 2. the other person is not really stealing credit, because if they had done nothing the idea would have just died and you wouldn't have gotten credit anyway.

this is the biggest benefit of 1:1's in my opinion.

Often, individuals can claim credit simply by being first and loudest. For example, and individual can highlight a problem area that someone is already working on in the team and loudly talk about the flaws in the current approach and how they will solve it. The individual need not actually solve the task if the first person finishes - but now the success is subconsciously attributed to the thought leadership/approach of the new individual.

Good managers/leadership teams have mechanisms to limit this type of strategy, but it requires them to talk to everyone on the team - listen for unsaid feedback and look at hard artifacts. Otherwise you quickly have a team of people who are great at nothing more than talking about problems and dreaming of solutions.

Working at FAANG kinda bypasses this once you reach the "rest & vest" phrase. It's like whatever I don't give a fuck. I've met tons of them. They don't care about credits because they've earned so much.

You don't have to self-promote aggressively, but you do have to advocate for your work

This has happened to me several times!

Hamming, in his book The Art of Doing Science and Engineering, also encourages this.

But the last edition was in 1994 and he was writing from the position of having worked at Bell Labs for most of his career. We don’t really have that these days.

It’s great if you can find a way to be a non-fungible developer. I think part of the strategy is taking the spotlight and managing perceptions of your work. You don’t get to choose what you work on most of the time but you can make sure that it’s visible and useful.

As the author suggests, and I think I aspire to myself, is building good tools and libraries that people appreciate and depend on.

I can think of a couple of times when I wasn’t the best at something, yet still got opportunities simply because someone well-established in that space liked me.

And I can think of the opposite too - situations where I was at a disadvantage because someone higher up just didn’t like me.

For me, it’s more or less balanced at a balance at this point of time. But most people around me, I don’t think they’ve been as lucky.

You can own the narrative while also not being in the spotlight.

At the end of the day, only a handful of stakeholders matter in any organization. So long as you can promote you and your team's initiatives to your manager, your skip manager, and a couple key members of Product, Sales, Customer Success, and Leadership - your place is secure.

In fact, in most cases I would say a mass spotlight is actually a net negative, because it only increases the risk that someone might view you as a potential competitor for either budget or responsibility.

So long as you remain aligned to the business's stated goals for the year and can communicate that to the relevant subsegment of stakeholders, a massive spotlight is unnecessary.

It shouldn’t be this way. Merit should be the metric. But it’s true. No matter how good or bad your numbers are, if Bob likes you, you’re good.

Keep polishing those soft skills and if you have a face only your mother would love, be a writer… but get your voice out there.

I've seen the same dynamics play out at mid-sized companies

I agree with the author in regards to it being different career paths, but I think your take is better and more nuanced. I've done both. I started my career being a spotlight engineer, quickly advancing the ranks and being sent on a educational path for leadership. I didn't like it though. Don't get me wrong. I basked in the glory for the first year, but then when it got to be just a regular day, I really started to miss solving what I see as interesting problems. Which is often working on stability and safety, building tools and infrastructure which makes it easier for other people to serve the business.

Maybe it's because I've done the spotlight thing, but I don't really care about praise from management anymore. In fact I suspect that most of my direct managers have never really known what I did, but since they've seen the impact for other people, it's not really been an issue in regards to my reviews or pay. I don't get a lot of credit and I don't get a lot of praise. I don't necessarily see someone who's build a great product with the tools I've made as stealing my credit either. That's sort of the point of what I do.

I completely agree with you that this is not just Big Tech, or Enterprise or even in organisations that are focused on Tech. I also agree that it's not about ignoring the business, you're still going to want to build things that are useful. You're still going to do change management from the ground up to make sure people know the tools are useful and how to use them. You're still going to network and be friendly with your co-workers.

What you can skip is a lot of the corporate politics and frankly most of the "financial" information. I don't even think the price is very high, you don't get the publicity, but it's not like spotlight engineers necessarily get better pay or better career paths unless they want to go into management.

I'm very well aware of the privilege afforded to me by my company and the time I'm working in. I tried to emphasize in the post several times that this is not a "universal guide to success" and that in other companies or teams, a different approach and strategy might be needed.

The whole reason I wrote this post at all was, with the success of Sean's work on HN recently, I felt people were leaning too far into the direction of "you need to constantly move around and go where the exec attention is". I just wanted to show that, from my singular experience, it is possible to carve out a different path in some positions while still being ambitious and "successful" (for some definition of success).

Did you read the full post? The author addressed these points at the end. They’re not naive.

The thing about your bigco, the OPs and the post he's talking about, is it's all so abstract from money.

You have two poles here.

1. The VC route, strikes gold, and never really needs to live with the reality of asking what an ROI is, it's all talk about spotlight, impact and value, without any articulation about cash money.

2. The MBA route where you effectively can't brush your teeth without a cost/benefit analysis that itself often cost multiple times your initiative, resulting in nothing getting done until you're in some tech debt armageddon.

The reality is if you're still making bank on the abstract without being able to articulate revenue or costs, you're probably still in the good times.

Deep work that's important but does not appear shiny carries an elevated risk of being completely messed up by someone.

"Oh this thing here looks steady and boring. This sure does not need a team of six."

Next thing you know, the thing falls apart, destabilizing everything that stood on it's stability.

Unfortunately, in this profession we are being lead by managers that do not longer have deep knowledge of how to build good software systems. They can't evaluate contributions in code, so they resort to evaluate participation, and popularity.

As an engineer you are left with a dilema. Either you focus on writing solid code and making your projects move forward or you focus on selling your self to the leadership class.

As long as quietly making stuff pays off, sure. If I get a bigger paycheck just from being known by the higher ups I'll go for the popularity contest. People work to feed themselves and their families after all and considering how unethical big tech is, I dont think anything u work on could do anything to better the world. So yeah, popularity contest and doing as little work as possible it is.

Couldn’t agree more (but frustratingly due to HN’ shitty mobile experience i downvoted this, sorry!)

In a past life i used to complain that people only praised my work after i fucked up and subsequently fixed it. I’d go month on month of great execution and all I’d hear would be complaints, but as soon as i “fixed” a major issue, i was a hero.

I’ve learn that setting appropriate incentives is the hardest part of building an effective organization.

That kind of bottom-up traction feels rare, but when it happens, it's incredibly energizing

> But he can only do so because he is a staff software engineer.

I don't agree with this at all. This is how I've worked for my entire time at Google, all the way from new grad L3 joining the company till today. Ignoring the spotlight does not mean "don't get attention from other people" but "don't chase the project execs are focusing on".

Whenever I've work on a project, I make a very active effort to make sure engineers are aware of it, especially if I think they would find it useful. But that's different than going to my execs and asking "what's the highest priority at the moment" and working on that.

There is another risk: you run for 2 years and prevent a major problem that would bite the company in year 3 or 4. However because the problem never happened nobody knows how much you saved everyone and so you don't replace all that capital you used up.

Every company I've worked for has regular meetings where they honor the people who stayed late to get the release out the door (I work in embedded systems where upgrades often mean flying someone with a USB stick to a remote location without cell service - thus bug free releases are important since upgrades are expensive). I can't help thinking every time that if the rewarded person had just done their job 6 months ago they wouldn't have had the bug in the first place.

> The risk comes from being wrong.

It's definitely a high risk high reward strategy but if you have the context from being the space for years and you've done your due diligence by speaking to your customers before you build things, you reduce the risk significantly.

Of course the risk can never be zero though and luck definitely played a role in past successes.

You are only left alone if your cathedrals generate enough value while being ignored. The post is about a tools team, so long as the tools work and nobody comes selling a "cheaper tool that solves everything" management doesn't care and you get to work. However if you tools start causing problems for the engineers who use them and the complain to management you are in trouble. If someone else comes along with a "cheaper tool that solves everything" you are in trouble (such tool may or may not be cheaper/better, the point is they can sell management on the idea they are - you didn't successfully defend yours)

Edit: there is one more danger: you do your job well and management thinks you do nothing and so gets rid of you (only to hire a new team in 3 months when everything collapses)

What do you mean? The quoted text is the exact strategy I always use.

I don't want or need to be told top down what to do, it's better to think for myself and propose that upward. Execs appreciate it because it makes their jobs easier; users get the features they actually want; I get to work on what I think is important.

What am I missing that makes this a bad strategy?

The same things that go wrong anyway?

Nothing, except maybe an asteroid hitting the building and wiping out the entire team?

Priorities only become priorities because people fought for them to become priorities.

You can fight that battle via significant self promotion, but you can also lobby for yourself by keeping in constant contact with a subset of stakeholders who actually matter (your manager, your skip manager, your PM, your PM's manager, and maybe 1-2 adjacent EMs).

And honestly, the latter is the norm and much easier as well simply because it ensures that other people are fighting your battle.

It's not that I want to avoid the career metagame (I would argue I haven't so far) but that the career metagame is different depending on your environment.

It’s a little snarky and cynical but I’ve found little use for product managers in infra and devx teams because they typically don’t have the technical background to have relevant product vision and anyone that can make L7+ as an engineer on this sort of team should be able to figure out what the product should be.

This is different in a product team because engineers aren’t the customers, although I’d still argue anyone senior in a product engineering team should still have at least some product sense.

> Would a PM be responsible for this sort of broader thinking in a more typical team?

Good PMs do exactly this in product teams yes. But unfortunately PMs are not immune to shifting priorities and moving around either, just like I describe for engineers. So it's very hard to make it work but the best PMs I know somehow manage anyway!

My goal with this post was not to claim this is a universal template to success for everyone but simply sharing an approach that worked for me.

I tried to point out several times that, yes there are places where a "move fast with leadership" approach works better. And yes this only works in the biggest companies capable of sustaining an infra team for a long period of time.

It’s not luck. To assume so, let alone say so, is uninformed and quite rude.

Getting into these roles requires a ton of hard work. Yes, it’s a grind.

If you feel it’s only achievable with luck, I suggest you’re selling yourself short.

There are staff level jobs like that in every company. However they are hard to get into. You have to prove yourself constantly and for long enough that the executives trust they can leave you alone and you will solve problems. You here means your team, as a staff engineer you likely have a lot of more junior engineers working under you.

My brother had an internship in a medium-sized company, and after 6 months, a new product (that he was hired for basically) and 3 new internal tools (including one for reading data trace, which, after reading this, is quite a propos), he was hired as a staff engineer.

I do not have his proactivity for sure, nor I have his ease with other people, but I managed to land my job in an infra/tool for network and security without much difficulties.

Firstly, thanks for the thoughtful comments across the post. Really happy you found it insightful!

> But it's best to build a strong portfolio of going fast (where needed), going slow (where high leverage), and if everyone agrees your "going slow" led to huge returns you get the best of all worlds.

I guess maybe I oversold this a little in the post but I definitely think that product orgs value speed more than infra orgs: there's often an mismatch when I speak to product engineers on how fast they expect us to build things for them vs how fast we can actually go while considering all our other customers and not breaking other usecases.

> my protip for prospective staff engineers is to _never_ say you only care about [speed, stability]

Fully agreed, both are important for engineers to have. As above, I think the relative composition of them varies though depending on the area (just pulling numbers from the top of my head, maybe it's 70/30 in favor of speed in product orgs, 30/70 in favor of stability in infra orgs).

> surely we can agree impressing customer stakeholders is even more important in (healthy) product orgs

You're absolutely right for what I say in the post; reflecting I think I maybe did not go into this topic in enough detail for the nuance it deserves (but the post already felt long enough!).

Let's split the discussion into 3 different areas (as IMO they each work slightly different): infra/devex, B2C and B2B.

* Infra/devex: as I say in the post, it's critical to impress your other team's managers as that's how you prove impact.

* B2C: your customers are consumers so it's all MAUs, revenue etc. There is no "customer stakeholder" who will give you direct feedback for your promo packet

* B2B: here's where it gets interesting. So if your management chain is directly able to talk to customers (and especially senior managers) to solicit feedback without middle layers (parter manager, account managers, PMs) then yes you're absolutely correct. But often this is not the case: the middle layers act as a filtering point so you get only a fuzzy sense of how stakeholders in the other company about a specific technical thing you worked on. So again it's sort of at the whim of how your manager feels the other company's managers feels.

The basic point I was trying to make is that if you're working on external facing product, from my understanding, even if you impress your external stakeholders, it's not like in your promo packet you can attribute concrete quotes to the customers. quotes like "we couldn't have done X in our company without the work of Y engineer in your org who worked on Z". Whereas this sort of quote is extremely common to see in infra promo packets.

Hope this made sense, I'm not sure I communicated this last point well!

So you suggest firing people based on their title alone? Sounds pretty damn stupid.

so what one should do after a certain age?