During that time, the team around me dissolved due to severe attrition, leaving a skeleton crew of developers and I was the last remaining developer working on this specific project. During performance review time, I was told I wasn't performing at an adequate level because the number of code reviews I performed was very low. When I pointed out that I was the only person on my team, so no one came to me for code reviews their response was that I should have sought out code to review on my own.
I quit soon after.
If anyone reading is in a similar boat, asking for positive written feedback from the teams you work with and including that in your performance review is one way to get recognized for high impact low visibility work. It sucks that you have to go out of your way to gain recognition and it won’t always work but that can be how it is in large companies.
I really should turn that into a business now that I think about it.
I needed my bosses help getting my teams work prioritized on the global roadmap. He informed that our team just wasn't high priority enough this quarter. Then fast forward too performance review he said I didn't do enough to get work prioritized.
I quit 3 weeks later.
If you are doing amazing work that benefits hundreds, thousands or even millions of people, but nobody is paying attention, then it will be really hard to justify it.
Conversely, shallow stuff that might only benefit a few but gets tons of attention, is easy to justify and keep going.
Two engineers. Engineer A working on the new shiny prototype stuff that is riddled with bugs and errors and never goes to production but gets to demo it to the upper management.
Engineer B grinding away on the old "legacy"system fixing bugs adding some new small features generally keeping things going.
Who do you expect will be getting the bigger RSU package? Unfortunately it seems that often the key factor is indeed visibility.
For one thing, just the existence of titles like Staff Engineer seems to have exploded in the last 5 years or so, at least from my perspective. My first few jobs out of school, it seemed like the progression was Junior, quickly to just "Software Engineer", eventually to Senior, and then nowhere particular, maybe management. I guess everyone in the industry can't help but steal Google's structure so these new levels of Staff, Senior Staff, Principal seem to have grown in popularity, but I think it's a more recent idea than not. I'm glad that standardized IC tracks are growing but it's hardly a given and the first factor is that your company offers them in the first place.
Still, it's incredibly unstandardized. Having insight into both companies, I know a place like Twitter, Staff Engineer is handed out more lightly than a place like Google and can be more reflective of political prowess than engineering impact.
A dynamic I've seen over and over again is orgs expect more senior engineers to work on more senior stuff but inevitably there is a massive amount of work that's individually low impact but collectively high impact to be done. In a dream world you'd figure out ways to automate it but that's not always feasible. So often times there are political wars fought over access to high impact projects which are perceived as necessary for promotion, while core, critical work that's less sexy but critical to good product gets left undone. If you want to know why a lot of tech companies that pay engineers massive amounts can launch shiny new things with ease but struggle with the basics, look no further.
One of Google's approach to this problem is to create a massively complicated ladder system of engineers, where you have employees that would be labeled Software Engineers at any other company by nature of their job responsibilities, but at Google are called something else and are specifically boxed out of more desirable projects by nature of their non-SWE title. And of course the contractor vs full-time distinction exists as well.
Another dynamic that can happen is that you have huge engineering impact but your company's product strategy fails so its all for nought. You can impact your company's chance of success but ultimately a company works in a given industry on certain problems and if for whatever reason the company's big picture strategy fails then that has a high chance of undermining and overshadowing your individual impact.
Or you were born in the wrong country or run into major health issues that block access to high impact work.
Overall, I just find advice like "work on high impact stuff, don't snack" to be oversimplified to the point of pandering when, there's so many variables outside the scope of your control as to whether you'll even get access to the opportunity to do high impact work in the first place. And while, of course there's almost certainly a correlation between strong engineering IC career trajectory and skill, work ethic, and good career decisions, there's also undoubtedly a massive amount of all sorts of bias that make me skeptical of a cookbook on how to get there.
I think the origin of "Staff, Senior Staff, Principal" came from an attempt to create an IC track. You've been around a while, and you can execute stuff well on your own, where does your career go from there besides manager?
The fact that the assumption was manager is why we have a lot of these problems, tbh. I hate managers who hate managing but that's a separate discussion.
Also funnily enough I was just having a discussion how my company's career ladder explicitly says (in bold!) that promotion is not a reward. If it's not, what is it? What is the reward for hard work and growth, if it isn't that?
Ultimately what I see underlying this article and many like it is an assumption that, at least at an "enlightened" company, politics don't matter. If a company prioritizes low-impact high visibility, that's a stupid company... Yet I've never seen a company free of politics. There will never be a company where your personal assessment of impact of your work matters more than your boss's or their boss's.
We also can't pretend like the amount of work at any given level matches the number of engineers at that level (or who want to be at that level). It just never will. So there will be jockeying for position.
You shouldn't be playing politics all day (a trap I sometimes fall in) but you can't ignore it either. Politics often means justifying your work up the chain, being aware of priorities of those above you etc - it's not just kissing up. Ignore it at your peril.
Whenever I read an article like this I wonder if such a workplace exists, or does the author hope it exists and is writing for this ideal environment where tasks can be put into a 4-box of high/low impact/visibility. I realize the author somewhat addresses this with "Many companies conflate high-visibility and high-impact," but it feels more like the vast majority of companies where most people will work conflate the two.
As you said, the real world is a mess and a lot of people (me included) make the decision to optimize to what keeps them employed. This is especially true because (IME) at a lot of companies impact and visibility are things that can suddenly change. One day the task you're working on is going to save the world, and the next nobody cares anymore.
There are always more JIRA tickets to grind, but if that's all you do, no matter your throughput, it's hard to move up.
Non-technical managers can be great too, when they know their limitations and know the skills of their team. It is possible to have a good non-technical manager managing technical people.
If so, that's the first takeaway here: A non-technical manager is a red flag that should not be ignored.
Between those two: I'll take the non skilled every time.
That's why you need IC tracks with Principal and above engineers, so that the person that _knows_ stuff is in charge of technical decision and the manager can be in charge of people problems / communications / strategy / scheduling, none of which strong technical people are particularly known to be good at.
Think about this, what good does having a SVP of a big company be an engineer that hasn't coded a line of code in 20+ years? These people probably don't even remember what it means to be a programmer.
I would much rather have a manager that is good at being a manager and doesn't know anything about coding, rather than a mediocre manager that also knows coding but they are not in the loop and think they knows better than me.
Bad managers are the red flag - update your heuristic accordingly.
> It’s ok to spend some of your time on snacks to keep yourself motivated between bigger accomplishments, but you have to keep yourself honest about how much time you’re spending on high-impact work versus low-impact work. In senior roles, you’re more likely to self-determine your work and if you’re not deliberately tracking your work, it’s easy to catch yourself doing little to no high-impact work.
In my own personal experience, that boost of actually accomplishing something right now instead of slowly starting the process of impactfully pushing another rock up a hill is very tempting.
Does anyone have any experience or recommendations for effectively tracking your own work and putting yourself in the right headspace to tackle these more long lived impactful tasks? This mental game seems to me to be one of the huge factors that determine outcomes.
I tend to have some challenges with attention at the best of times. My interests tend to run hot and cold. I can make a huge impact and move a project significantly forward when I get into it and hyperfocus on it. But other times managing to focus my attention on a tasks that I know would be high impact is mental torture.
1. Do a start-of-week plan, and end-of-week review. Pick a few milestones that are achievable this week. Hold yourself accountable and check in with yourself to see if you completed them. If you didn't, review why not. Did you snack too much? Did you get pulled into lower-priority meetings? Did you work on some other urgent stuff that is actually OK to drop your tasks for? Keep any insights at the top of your "weekly plans" doc so you can remind yourself of them and try to avoid making the same errors repeatedly. Breaking your long-term goals into milestones also gives you some "snack-like" satisfaction before you get to the finish line and earn the big payoff.
2. Every day, pick a task that you're going to do "hell or high water". Try to get that done before you snack. Typically this is (a piece of) one of your weekly tasks. If your calendar is prone to getting filled up with meetings, block off some "maker time" on your calendar to get this task done. I find it helpful to preemptively schedule timeslots for my project work at the beginning of the week even when my calendar is likely to remain open; it keeps me honest.
3. Timebox your snacking. If you feel like you need a break from longer-range tasks, you want to get an energy boost, etc., set a timebox, say "1 hours refactoring these tests", and try to return to your hell-or-high-water task after that timebox. I find it easy to go down the rabbit hole when I start snacking, especially if I get deep into the flow state. Flow is good! But it can lead you astray from your longer-term goals if you're flowing on something that's not your #1 priority.
As for the mechanics of tracking your work, I have used a personal Trello, todo.txt doc, Roam, GDoc, pen & paper -- this is immensely personal but just having a single place where you can go back and remind yourself what you were supposed to be working on is really helpful.
The only time when tracking work has been really useful was when the Icelandic banks went bust during the crash of 2008. Having a log of work-done helped a little in trying to get paid after my client went down. But, in other cases, I’ve found that the result of the work is the log of work done.
I would add that always double check on regular basis that at least one of the things you are working on is a priority for your manager. Use your 1:1 meetings to confirm this and make sure you are aligned, and where you arent, that there is an over-riding company-acceptable reason. The bigger the company, the more this matters.
I find the Pomodoro timer technique (25-minute timeboxes) helpful maintaining short-term focus (and for breaking my focus, giving me a chance to review whether I am snacking or need to move to a different task for my next 25-minute timebox).
A web-based Pomodoro timer I keep in a pinned tab: https://tomato-timer.com/
During my PhD I would write down what specific task I was working on in a work journal every half hour or so and it would help me refine the specific problem/question I was working on. At the end of the day I would have made a steady progression through a relatively abstract problem which might not have been apparent at the beginning.
I take the same approach with working on the various projects now as a software engineer. I find the act of documenting my progress/thoughts as I go extremely calming. There’s a balance to be struck here - I only take this approach when developing something new and I have to record all the things which didn’t work.
The mental game is very important. Definitely hard to work on the things that actually matter - they are usually difficult, new, more intricate to setup, etc. What I've found to work is to "just start on it" - starting is the hardest part. Telling yourself you'll do 15 minutes of it or something, so you will actually start. Usually, when the 15 minutes are up, I won't be stopping. The inertia goes from "not going it" to "doing it" and it's hard to change ha
I usually procrastinate when it's not clear what exactly has to be done and how, and writing it down somewhere helps immensely.
By broad front, I mean that I'm inching a lot of things forward, instead of focusing all of my attention on a single breakthrough.
If my motivation is low, I'll do small things that will be helpful when my motivation returns. This includes planning, buying supplies, cleaning up the workspace (physical or digital) or implementing quality of life improvements. For example, I might not be ready to extract a bolt that broke in a motorcycle engine ([expletive]), but I can disassemble the engine, buy tools, or figure out how it's done.
Sometimes, this gets me right back into it. Sometimes it just makes it easier for another day. To keep with the analogy, I call it stabilizing the front.
If you do this, it's critical that you leave yourself an easy reintroduction to the project. This might be a 95% finished commit, or a really good readme. You shouldn't dread getting back into it because of the project's state.
I realized this was true for my personal projects this year, but never realized it's also exactly the same as work.
Yes, you shouldn't solely be a snacker, probably, but I think it's counterproductive to think of engineers as highly autonomous, robotic units that can view each task selection in total isolation. Previous, unrelated tasks can influence your ability to complete your current task. The weight of future tasks can pull you down.
> It’s ok to spend some of your time on snacks to keep yourself motivated between bigger accomplishments, but you have to keep yourself honest about how much time you’re spending on high-impact work versus low-impact work. In senior roles, you’re more likely to self-determine your work and if you’re not deliberately tracking your work, it’s easy to catch yourself doing little to no high-impact work.
People sit on their niche, defend it to the death and let it take up all their time. That's how it was in every big organisation I've seen. Understandably so, people didn't want to be seen as lazy or expendable, they wanted to defend their self-worth. That's how you get to Parkinson's law and the cult of busyness (and stress, lots of stress, even though there was no reason for it, it's just work, maybe explaining the increase in depression/burnout).
I'm constantly creating new open source projects with little functions that get lots of adoption. Just added some code to validate a SQLite schema in a Pythonic manner for example. Nothing groudbreaking, but makes it easier for the folks that need to do this in the future.
The Unix-philosophy is writing programs that do one thing well. Lots of little functions can be combined to build something great. Lots of "snacks" can be used to make a feast!
Regardless, “customers buy your product in a marketplace” absolutely does not indicate or have really any connection with “providing something that matters to someone.”
While it slows my career trajectory, I am now able to spend way way less time on work and way more time on other things. What the other things are.. time will tell.
It came out nicely. The work I did has become a worldwide standard.
Now that I'm out of that position, I have returned to doing what I want to do. There has been some "snacking," except it's really healthy snacks, because every project I do -even the experimental ones- is done in "ship mode."
Just one example was that they had this one template for Spring Boot projects that you weren't allowed to deviate from; in particular, you weren't allowed to fundamentally change the build process, which was one of the most insane things ever: it would pull in other scripts from other git repositories at build time, which in turn would transitively pull in other scripts etc., which just led to a build you didn't understand anymore and some settings were impossible to override. Also, you could only build the project with an internet connection and from within the office network... I'm sure whoever wrote that thought they were being really clever.
And what I have observed happens is that some people (higher ups) assume that this kind of administration is actually "management" or "leadership" and promote people, who themselves think that administration is leadership, etc.
The solution is probably to work somewhere else, but I think the root cause is the bundling of admin or coordination type work with seniority and leadership, where somehow it is assumed that because you're a better administrator that e.g. technical direction should also rest with you.
And I don't mind if a company recognises that administrative and organisational tasks are important; if you can really act as a multiplier by making other people more efficient, that is actually valuable. The problem is when you don't try to find out if these things really make people more efficient or are just petty ways for some people to build their little kingdoms.
I can't speak for every company, but generally for a senior promotion you just need to prove that you are a competent developer and can be trusted to deliver medium-sized projects (e.g., 3 developers for a quarter) from design to release without much or any oversight.
If you're not getting those opportunities, you need to talk to your manager about that.
Most of us won't build stuff that matters, and even for those who do, it probably won't matter matter enough to sacrifice your personal life.
You are not your job.
The preening and snacking advice was spot on.
However, the last paragraph was a bit jarring. You'll be judged by:
> your prestige, the prestige of the titles you’ve had and companies you’ve worked at, your backchannel reputation, and how you present in your interview process.
But only the third one (backchannel reputation) is affected by all the other advice. You can be a preener at Uber or Google and you'll probably have a better chance of being hired at a FANG than someone like me who has worked for smaller companies most of his career.
That said, my goal after two decades is to find a company where I'm happy rather than clawing after the most prestige, so perhaps I'm misreading what he's saying.
That said: names still help - if someone's on the fence then saying something like "they didn't do that great but based on their projects at Google I think they probably just had a bad day" isn't uncommon - but it's far from a requirement, which is a good thing.
What does get rewarded is your social network and your ability to present yourself in a pleasing manner. Even the concept of "career growth" seems like a relic from a bygone age, as if it were possible to measure a human's value to their company on some linear scale, when in fact the vast majority of "growth" along that scale simply results in a schedule packed with inane, endless meetings. Meetings in which social network and presentation come to dominate a structure that can be accurately described as a primitive pecking order. The value of expertise rapidly decays in rooms where no one actually does anything anymore.
The advice in this article seems to be that if you just keep your head down and focus on making these impacts, someone, someday is sure to notice. It might take 20 years of being a doormat for the politicians, but you'll have retained your dignity (just perhaps not your keen sense of irony). And on that fabled judgement day, when at last your patience and diligence are recognized by a panel of wizened software elders, you will have earned passage into programmer Valhalla (another dev job, almost certainly reporting to another politician).
My advice, would be to completely ignore all the performative speeches given by HR and others up in the hierarchy about values and goals and whatnot, because what tends to win the day in any group of humans larger than a handful hasn't changed in thousands of years: power. You either have it, or you must ultimately become a sycophant. Anyone outside that binary can be safely ignored, regardless of their impact, and plenty of companies do indeed blunder along on pure momentum, essentially forever, happy to ignore or absorb any accidental impacts originating from the fringes.
As the article itself states, few care about company-wide success, only about whether they will personally benefit in some manner. It's a boring, reductive game in the end, but the good news is that it's really no one's fault, this is just how humans operate. Rather than appealing to the better angels of our nature, as this article nobly attempts, I posit it is better to accept the situation for what it is and make your peace with being stuck at whatever position in the hierarchy you can stomach sleazing your way into. The author would rather have you be an idealist, forever searching for the right group of leaders that will value your principles and your hard work. Feels a bit like titling at windmills to me, and perhaps as though the author is fluffing up their portfolio of "leaderly things I have said" in preparation for their next presentation.
After reading this, I suppose I can say that I was considering asking for a snack, so I'm glad I chose to stick with the new feature. I just hope I actually pull it off.
From the site's front page:
> The transition into Staff Engineer, and its further evolutions like Principal Engineer, remains particularly challenging and undocumented. What are the skills you need to develop to reach Staff Engineer? What skills do you need to succeed after you've reached it? How do most folks reach this role? What can companies do to streamline the path to Staff Engineer? Will you enjoy being a Staff Engineer or toil for years for a role that doesn't suit you?
> The StaffEng project aims to collect the stories of folks who are operating in Staff, Principal or Distinguished Engineer roles.
The flipside of ghosts is 'This time will be different'. Eventually you get tired of watching the same avalanche play out in slow motion over and over again.
There's a lot of reasons people stay, and a lot of reasons people leave. I may argue for things I don't even care that much about, because I want or need the people who do care, and if they're hamstrung or quit, then I'll be in the same boat soon enough.
What some people call 'ghosts' are dots that they will never connect. I'm sure you know someone who complains about their 'bad luck' all the time, but many in your circle can list all the ways they're self-sabotaging. You've all but given up because the person won't take advice, maybe even avoiding you or certain topics because they don't want a lecture. But you're supposed to clean up their messes because that's what friends do.
Most of us are somewhere on that spectrum, and everyone you talk to has a different narrative about why someone bailed or why a plan failed.
Hate the company culture, not the player. If there is no accountability for incompetence or even malice, whose fault is that? The success of the company matters way less than the happiness of your immediate boss.
Be that as it may, this is more common than rare and these things influence how optics-focused mid-level leaders behave that report to those senior leaders. And most hands-on folk work under such mid-level leaders. Unless you are a star performer, it may not be easy to avoid this as opportunities are getting scarcer in these times for most folks.
Something tells me that this person is rather more idealistic than you would expect from someone branding themselves as a "staff engineer". People who have such an approach to leadership don't give two hoots about the opinion of their line-level subordinates or about the actual amount of value generated. The only thing that matters is the opinion of the person who will decide on their next promotion, either inside the company or somewhere else.
Sometimes doing impactful things can be very fulfilling but it generally means using some very boring and unpleasant technology (cough puppet cough)
I think most people just want to do something different than what they're currently doing every now and then.
80,000 hours is roughly how much we'll spend in our lives at work. If we focus that energy and attention well, we can accomplish a lot of good in the world.
See: Effective Altruism
Hamming knew how to make you think
Often new leaders are hired because they are unique specialists in a needed technology or new capability area.
I’ve worked in companies that had to hire billing experts, SOX compliance experts, machine learning experts, embedded systems experts, and so on - to lead fairly big initiatives and drastically restructure an engineering organization.
You can’t have it both ways. You can’t hire them to pursue a program in their specialization (what they are uniquely good at) but then also turn around and act suspicious that they are “snacking” or “preening” or deliberately seeking high visibility projects for credit.
On top of this, how juvenile do you have to be to think of your colleagues this way and generalize complex motivations and difficult prioritization into little cartoon phrases like snacking or preening. That speaks to a lot of negativity and arrogance on part of the author or anyone who would adopt these views.
Maybe that other team needs to solve a low effort, low reward task because last year they were forced to lay off a trusted teammate and everyone’s morale is terrible, and they need a quick win.
Maybe that project you arrogantly believe is all about “visibility” is actually required for some compliance reasons you aren’t aware of.
Stop wasting time with these judgments and perhaps take an attitude of trusting your colleagues and believing they are sincere, and especially trusting their judgment in their project areas of specialization.
