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.
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.