At my previous company, I worked on high impact, very low visibility work. I was working directly with operations teams around the world in order to enable features that needed to be tweaked globally. It was vital for teams in their specific geography to work properly, but no one beyond those teams and my direct manager understood what I was doing. I enjoyed it because it was literally enabling functionality across countries around the world which was great for our customers and our company.
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.
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.
This is good advice, I'll add one more thing: make sure your manager values what you are doing. If they do not then you are headed for trouble regardless. In fact, I'd go so far as to say that your manager relationship is probably the single most important factor to optimize for in any job. If you don't have mutual trust and respect it will lead to distortions, and in the worst cases can create long-term psychological corruption leaving one cynical and unable to trust their own better instincts.
Often times the ratings, bonus and "calibration" is done at a senior manager / director level. So if you have no visibility in those circles, you'll not fare well. Often times, your direct manager won't have any say in this matter and the top bosses will need to take decisions based on politics and retention and other considerations. Another thing to keep in mind is that your manager might not want you to move around and giving you average ratings will help.
I'm onto my third big project and each of them shipped with my solo effort (but on the backend). It's wildly successfully and impacted 10s of millions of people but the ratings always make it seem that what I thought was exceptional contributions were "expected"! Thankfully the bonus/money is decent.
Hahaha, of course, if I really knew the answer to that, I'm sure I'd be doing much better than I am. :D
But I've sometimes had success with the following:
- get attached to high-visibility problems or initiatives, which admittedly also have higher risk in making you look bad
- write up really good reports/proposals on what you're doing and why it's important; good writeups sometimes get passed around and shown as example to the rest of the company; really good writing skills are underappreciated by many technical people
- do presentations about your work, knock it out of the park when someone important is in the room
These opportunities are like waves for surfers. Surfers spend a lot of time just waiting for the right wave, but when the wave finally comes, the surfer better be ready. It's like the stories of Apple employees being ready with a summary if Steve Jobs bumped into them in the elevator and asked them what they're working on. Gotta be ready.
What if a company set aside a day each month and told everyone to do this -- maybe could give insight into what everyone does, ppl learn from each other, and invisible work gets noticed?
> write ... reports ... on what you're doing and why it's important
Almost like content marketing for a startup, but instead for oneself inside a company
I think the biggest thing honestly is just having a good manager. If you don't have a good manager, and they don't support making you visible, it's quite the fight to become visible.
I see this attitude too often among technical people. They think that having a good relationship with someone means sucking up and losing one's integrity, when in fact, it just means having a good relationship. Having a good relationship with my wife doesn't mean I'm sucking up to my wife. We love and respect each other because we value each other. I don't love my manager, and my people don't love me, but we better respect each other and know how to have good relationships with each other. Technical people who have difficulty having good relationships with others in the workplace need to understand that they can be difficult people to work with, and that they often create drama due to their misconceptions about what relationships are.
People who have good relationship skills can also tell the difference between having a good relationship with mutual respect, as opposed to actually sucking up to some narcissist. All technical people need to be able to have that level of relationship wisdom, the ability to see the difference. Sadly, and this is the most unfortunate part, people who are bad at it often think that they're good at it, and so they don't understand why they're being attacked when they're not actually being attacked; then they get angry and disgruntled, creating what was a preventable situation.
No one said anything about "sucking up" to your manager at all. In fact, my interpretation of the parent was more akin to making sure that you can have open, two-way communication with your manager, so that they understand the importance of the work you are doing. A bad manager (or one that simply doesn't see eye-to-eye with you) can ruin an otherwise fulfilling job, no matter what you do.
You wholly misunderstood me. I can see you like the blunt approach so let me be clear: if your manager does not value what you are doing then quit your job.
What's the rationale?
"If your manager does not value what you are doing then quit your manager" would make more sense, but of course would be of little practical value.
For the record, you are not employed by nor for your manager. Have a look at your employment contract, it is probably not written that your job is to please or help promote your manager. Usually, your job is to perform some kind of action directed towards the outside of the company (like shipping software to customers).
That's really my issue with big companies: by the sheer effect of inflated volume, one gets surrounded more and more by coworkers, internal projects, etc, and come to forget that the purpose of it all is to act on the outside world not within the corporation itself.
That's at least how I understood the parent's "think only about doing your job" and I agree wholeheartedly.
I go maybe a step further: I send out project-specific surveys that have things like impact metrics (How significant has the impact of Project X been, in terms of dollars, hours of effort, or deals won), classic NPS type questions (If a similar situation arose in the future, how likely would you be to reach out to me/my team for help?), and questions that dive into how the project went, how it was organized, and more.
I really should turn that into a business now that I think about it.
I worked in a company where we had this kind of surveys, but there was a catch; every feedback that was not excellent, was considered bad performance. So yeah, not so great place.
That's why there should not be a hard metric set by people who don't even know how to code. Performance review should be conducted by people who have a direct understanding of what is being done, and if that's impossible, at least people with a capacity to understand what is being done.
The other side of the argument is often how do you keep things objective and consistent across the company, especially when it’s a large company. How do you make sure a “senior engineer” on one team is reviewed on the same criteria as someone on a completely different team.
That's not much of an argument when the supposedly "objective" measurements aren't measuring what's truly important anyway. I think the best you can do is probably to moderate the managers assessment with "360" feedback from everyone an emplotee works with, and similar feedback on the manager themselves.
Why should a senior engineer on one team be reviewed along the same criteria as a senior engineer on another team? Do you judge a kernel developer the same way you'd judge a Javascript expert? Fundamentally, it comes down to whether the person is helping their team accomplish its goals. And the best way to do that is to ask the team, rather than try to cast about for some kind of nonexistent "objective" value metric that allows you to rank every single developer in your organization.
Where I work we have very broad criteria that applies to almost everyone in the same occupation. Those are not negotiable but measurable - when we apply only tiny bits of subjective understanding
this hits home. I worked on a team that wasn't high priority. I had issues getting our teams features prioritized cause every team had about 6-8 dependent teams in order to ship something and when I had these discussions to get our work on other teams backlog's, I was told they didn't have the bandwidth to do work for low priority teams.
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.
It's through cases like this that you realize that what actually matters to the world is whatever gets the most attention.
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.
If your compensation is based on visibility, then communicating the importance of your work is as important as doing it. If your company will pay you more if you spend less time working and more time communicating about your work, then you should make that adjustment.
If you don't advocate for the work you do, or yourself, you're making it harder for EVERYONE.
Humbleness is fine, but laboring in the shadows on critical stuff makes it harder to allocate resources to where they are best directed (like you and the work you do!).
One of the priceless conclusions I've reached during my career is that software engineering is not only about developing software, but also about self-marketing the importance of it
One of the reasons I find your story relevant is that advice-pieces like the OP kind of assume a ton of factors are in place that are actually often largely out of your control. It kind of paints this clear career trajectory path for engineers when I think the real world is infinitely more chaotic and random.
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.
I worked at a big telco (BT) and they had a super flat structure and a yearly/18 month promotion round that might have 20-25 slots for MPG1 to MPG2 in a division of 40-50k.
MPG1 and MPG2 where the IC grades after that that it was management grades.
You normally had around 18-100 pass the paper shift who then got a board interview.
I played the game and passed the paper shift several times but in the end left the company.
There are also pratical concerns. If you have a family, sticking to high-impact work will have high impact on the time you can devote to your family commitments (unless you are some sort of genius who solves everything before/within deadline). In that case you actually might desire a bunch of "snacking" with just a few high-impact thrown in.
>It kind of paints this clear career trajectory path for engineers when I think the real world is infinitely more chaotic and random.
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.
Probably because the organization doesn't have a great technical culture. It is a red flag, but understanding that it's not an easy problem to solve is helpful. It's not easy to find great technical managers, especially in non-technical organizations. Look at how many non-technical organizations around the world spend millions of dollars on software projects that eventually get written off as failures. It's appalling, especially given that we definitely have the knowledge on how to make good software already. Skills in managing technical initiatives and teams are sorely underappreciated, even by many technical people who actually do the work.
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.
Whatever happens - it happens by design. Your work wasn't quite as important as you believed it to be. Managers have a very good feeling on where to invest and where to divest their personal energy. Either your area or the whole company wasn't set up for success, so they divested while you hung on to a lost cause. It's not your fault but that doesn't matter because you took the blame. Better pay more attention to what's going on around you next time and don't expect your boss to do the important job for you.
I have had non technical managers that delegated and trusted their team, and I have had "technical" managers that hadn't learned new skills since the 90s.
Between those two: I'll take the non skilled every time.
As long as the manager is not the one making technical decision, then there's nothing wrong with a non-technical manager.
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.
It really depends on the organization. I've been in places where the job of the manager really is to just "manage": make sure everyone has a desk and a computer and takes their vacation sometimes but not too much and so forth. Performance was based on peer review, work was planned from the bottom up. Obviously a non-technical manager is fine in this role and a technical person would be wasted.
Yeah, no. I have run tech teams as a non technical lead. It just forced me to trust my team, listen to them and fight for them. Meanwhile the technical leads lacked the people skills to display empathy, provide feedback in a way that was respectful, and many other shortcomings that hurt productivity and morale.
Bad managers are the red flag - update your heuristic accordingly.
Not all coders are good coders. If your manager was the opposite of what you strive to be, your work probably won't make a good impression in their eyes.
I don't think I agree with the "Stop Snacking" advice. We all go through times where we need a boost to our sense of accomplishment, it can put the wind in our sails to address bigger problems. Sometimes snarfing up a bunch of snack tasks can make all the difference in the world.
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.
I think the author specifically addresses your point:
> 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.
Does anybody else think work in bigger companies is just snacking and only snacking? With the faint hope that all 20.000 employees' snacking somehow is more then the sum of all parts and assembles to a high impact 10 story Powerranger/Gundam?
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).
This section presupposes that you inevitably run out of tasks that are high-impact and easy, which hasn't been what I've observed. There are tons of little code functions that can be tested, released via open source / internal libraries and add lots of value.
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!
I save my snackers for the end of the day when my brain is shot during time that wouldn’t be useful for my bigger tasks. I see the author’s point though and broadly agree.
This seems like great advice, and it resonates with me. I've seen people make a big impact by following this path.
> 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.
A couple strategies that I've employed, that have helped me:
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.
This is great advice. I do something similar and it’s been working. The only thing I dont fully agree with is the tracking of work. I’ve found that tracking work has very little value to me, so I just don’t spend time on it.
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 didn't use to track my work and I noticed that at yearly review time it's been pretty difficult to remind what I actually did for last year. I'd go through merged PRs in the main projects, but it's only a tip of the iceberg.
Some time ago we moved daily standup to Slack, and since then I have a pretty good history of what I did each day. I created a wiki page where every 1-3 months I try to summarize all the stuff I did in the quarter (code shipped, dashboards created, docs written & non code work done, like helping X ship Y -- with screenshots, links etc.) and then it gives me a bit of confidence boost during the perf review time.
Cannot upvote this enough. These are excellent ideas for managing work, constantly making forwards progress, and showing to yourself, and the world, that you are having an impact.
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).
Checklists are useful for breaking a task down and providing incremental steps to progress through.
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.
Definitely agree on snacking being very seductive - it makes you feel useful and doing stuff, but when you zoom out, it's usually very inconsequential
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
Trick that often works for me: create a ticket in JIRA, explain well what has to be done, how, document gotchas etc.; assign to yourself; if it's a code ticket, create a local branch with ticket number.
I usually procrastinate when it's not clear what exactly has to be done and how, and writing it down somewhere helps immensely.
In my personal life, I adopted a "broad front" approach to long term projects.
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've found focusing on the hardest problems first when enthusiasm is high nets the best results as the difficulty over time of remaining tasks coincides with waning enthusiasm and fatigue. Focusing on small tasks first and delaying large problems has the opposite effect - unless there's not enough context to complete the larger tasks without completing smaller parts first.
I was effectively forced to accept a new job due to not being able to pay my rent after COVID. This role is entirely snacking and preening, so it is mildly fulfilling because I get to close ~7 jiras every day. But, I haven’t learned much and am never challenged.
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.
I sometimes wonder whether I would enjoy having a job like that, rather than one that takes all my mental and creativity energy, even if it means less pay and prestige. I could stop working at all hours and potentially do creative endeavors like write a book.
I had a job like that for a long time (I was a manager). Since I didn't have a "shower clause" in my employment contract, I was free to do a lot of open-source work.
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."
That’s the clause that says your employer owns every idea that you come up with in the shower. These often go way beyond the “anything done with company equipment or on company time” thing, which is actually already handled by standard employment law.
A sufficient amount of lobbying and precedent from underfunded defendants will make a lot of things legal (in the US).
In some states like CA, shower clauses are void except for a few explicit carveouts (the ones you might expect -- do personal projects on your own time and dime, and don't directly compete with your employer), but in, e.g., a lot of east coast states shower clauses are stronger and more commonly enforced.
Even when unenforceable though, you still have the threat of a court case; your employer can attempt to argue that your personal project falls into one of the exceptions that would grant them ownership of your IP, and a court case is sufficiently painful that it's a bit of a punishment in its own right even if you would win.
Also as a practical matter, some companies have shower clauses that additionally stipulate the company can allow you to retain IP on your personal projects if you ask permission. That could be abused, but for large enough companies that touch enough industries that can work out in your favor because a loose interpretation of the law would actually grant them ownership of your IP anyway, but if they have a policy of generally allowing side hustles then the fact that they've explicitly signed over any ownership claims to you will give you a strong leg up (and peace of mind) in any potential court cases -- potentially allowing them to be thrown out before they start.
All your intellectual output (include during the shower) belongs to the company by default and you have to ask for permission for the company to sign away it.
Ah, the last company I worked for had a lot of people optimising for low-impact-high-visibility work... in fact, it was probably often negative-impact. A lot of people who were just trying to protect their turf, try to establish insane and counterproductive "standards" for all teams, constantly reinvent the wheels instead of trying to look for mature, off-the-shelf solutions (I'm not against rolling your own where necessary, but you can really overdo it), etc.
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.
It's interesting, I think I would broadly characterize a lot of the preening work as administrative type tasks, like writing down a process for something as you say, or making a style guide, or a maintaining a table of something, etc.
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.
It was definitely a problem deep within the company culture and due to the failure of management to really understand and recognise engineering talent. Visibility and impact being different things is a problem everywhere, but most other companies I worked for did a better job at least trying to distinguish between the two.
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.
The conflation of administration and leadership is a really good way to put it. I’m frequently amazed that people who seem to be doing the work of a secretary are actually highly-paid “managers”.
This was a great post. I think it is tilted more toward engineers in larger orgs, where there are many teams, but I still appreciated all of it.
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.
I believe part of the magic of the FANG process is that it actually doesn't matter where you come from for likelihood of hire. It probably matters because they can level set but for hiring you have to knock out the interviews, which are the same whether you've worked at Google or Billabong Valley Software.
Yeah, the focus on the specific interview in the moment has both upsides and downsides. It can be frustrating and arbitrary but it also avoids some traditional in-group shenanigans and unfairness that is common in a lot of places. "I have to study all this crap even though I've done X, Y, and Z already" on one hand; "I can study independently and prepare for this interview even though I don't currently work at Google" on the other.
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.
I guess it depends if you believe psychological manipulation or deliberately facilitating addiction count as thievery.
Regardless, “customers buy your product in a marketplace” absolutely does not indicate or have really any connection with “providing something that matters to someone.”
Yes and yes. Saying otherwise would be like the foolish attitude “advertising doesn’t work on me.”
Everyone in developed nations buys tons of shit they don’t want, like or need, from sheer ad manipulation and repetition.
Tobacco companies literally employed chemistry PhDs to discover how to add ammonia to make uptake of nicotine more rapid, to literally physically addict you to their product.
Companies spend capital T Trillions a year on corporate research in branding, impulse packaging, habit formation, etc. etc.
In one, some subset of humans are just mindless automatons who are helplessly subject to manipulation. They only buy things they have been tricked into thinking they want. They have no personal agency. In this world, how do you ethically conduct any business? Is it even possible for you to do anything? How do you know you're not one of the mindless automatons who's just being manipulated into doing something against their interest? What choices can you even make?
In another view, humans can be lied to and manipulated to some extent, but ultimately have agency and can make choices for themselves. I've been a smoker. I can tell you from experience that smokers want, need, and like to smoke cigarettes. They are not stupid. They are not unaware of the risks. Many eventually decide, yes, they decide using their own brains and free will to stop smoking. I know it happens because I did.
If you decide there's no such thing as personal agency, I suggest carefully following the consequences of that logic and seeing where it leads you.
> Companies spend capital T Trillions a year on corporate research in branding, impulse packaging, habit formation, etc. etc.
How do you know they weren't just manipulated into spending that money on advertising services they don't want need or like, since that's apparently a possible thing to do? Why would anyone bother building a product at all if you could just use advertising to manipulate people into giving you money for something that is of no value at all to them?
I’m sorry but this is just rhetorical nonsense. Manipulation can exist and be a primal cause of someone’s actions even if generally personal agency exists. It’s not some philosophical epiphany to try to mix up some grandiose concern of determinism vs free will vs basic social manipulation.
I’d flip it around and say _you_ need to think about the consequences of your viewpoint. Social manipulation is just a basic phenomenon. It happens. If you’re espousing some philosophical perspective that doesn’t comport with just basic 101 human behavior, your philosophy is wrong, no matter how principled.
> Regardless, “customers buy your product in a marketplace” absolutely does not indicate or have really any connection with “providing something that matters to someone.”
Your basic contention is that nobody ever buys any product because it's something they want need or like. Indeed you're saying that a product mattering to someone has no connection whatsoever to them buying it.
There's a difference between "social manipulation exists", which I never disputed and "social manipulation, and social manipulation alone is the only reason anyone has ever purchased anything", which is the natural consequence of the contention that a product mattering to someone is wholly independent of them purchasing it.
I think the misunderstanding comes from you saying "A does not imply B" and the other poster misunderstanding that as "A implies not B". This is a rather common mistake in arguments I find ):
The comment went beyond saying A does not imply B to say that A is completely unrelated to B, even outside of degenerate scenarios such as addiction. Claiming that purchases are completely uncorrelated with receiving value from something is a much stronger and obviously false claim to anyone who thinks about it for more than a minute.
Given the downvotes on imgabe’s comments, it seems that understanding is sufficiently uncommon / extreme and easily corrected by rereading, so as to render this additional data point too much of an outlier to factor it into any conclusions.
Nobody disputes it’s possible to have the same understanding, it’s just not reasonable, and not realistic to claim it as a function of the way the point was initially written.
> Your basic contention is that nobody ever buys any product because it's something they want need or like.
No this is the question you asked which they answered affirmatively:
> Do you believe people routinely buy things that don't matter to them? Do you buy things that don't matter to you?
Routinely != Exclusively
EDIT: I can see how the "does not have any connection with" could sound like that, but as someone says below their argument is just "Buy does not imply need/like"
The guidance staffeng.com provides is very useful, but is there something similar for one level below? I am nearly a senior engineer by title at my company (one level below it) - where can I look for guidance on getting to senior?
Generally getting to senior is much more straightforward than moving past that. In a Google-style system, senior is the terminal level, which everyone is expected to reach. So there should be clear guidelines and a lot of examples of others who have been promoted there.
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.
That seems to be mostly it, though I've found there's a little bit more to it. Namely, not presenting your raw unfiltered thoughts and opinions as much but presenting them through more of a "party line" filter.
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.
I had a recent discussion with someone who argued that new senior leaders deliberately push for major changes even though they suspect the efforts will fail. Such changes make the organization increasingly dependent on the new leader, and also ensures anything that does go well gets attributed to the new leader directly rather than their team. If this is your approach to leadership, please know that you’re awful and take the time to work on yourself until the well-being and success of an entire company matters to you more than being perceived as essential.
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.
I tried to do this sort of thing for many years, with mixed results. One constant is that no matter the outcome of my efforts, whether something I built made the company money or was a waste, there was seldom any kind of conclusion or major takeaway. Making an impact has rarely helped me, not with promotions or prestige or even with getting a raise. Impact has been disconnected from any sort of return almost everywhere I have worked.
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.
The article is aimed at people who have made the life choice of less personal time vs more work/pay. Presumably these people have thought about things and consciously made that decision. There is no reason to tell them they have made the wrong choice.
“More money” is a very narrow view. Companies care about all sorts of things. Money, power, prestige (some open source projects, publicity). But yeah in general if you’re working for someone it doesn’t hurt to make sure your work matters to them, no?
> I had a recent discussion with someone who argued that new senior leaders deliberately push for major changes even though they suspect the efforts will fail. Such changes make the organization increasingly dependent on the new leader, and also ensures anything that does go well gets attributed to the new leader directly rather than their team. If this is your approach to leadership, please know that you’re awful and take the time to work on yourself until the well-being and success of an entire company matters to you more than being perceived as essential.
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.
> Such changes make the organization increasingly dependent on the new leader, and also ensures anything that does go well gets attributed to the new leader directly rather than their team. If this is your approach to leadership, please know that you’re awful and take the time to work on yourself until the well-being and success of an entire company matters to you more than being perceived as essential.
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.
Recently I was hired for a new job and my very first task was a considerably big undertaking for an entirely new feature of the application. I felt a bit overwhelmed, and was considering asking for something simpler like bug fixes so I could get familiar with the code first, but ultimately decided that I could make a better impression and a bigger impact with this project.
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.
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.
This whole site is dedicated to articles on how to reach the Staff Engineer level (i.e. on the IC track, above Senior Engineer).
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.
This article puts up some pretense but it’s all over the place and very inconsistent. Overall it’s a pretty bad article and pretty heavy on arrogance.
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.
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.