Every outside new manager would come in and in some form or another look down on this guy in some form due to his age and generally not doing "a lot" of tasks and new products.
It took the local VP to come down and regularly high five him after his product git rave reviews from customers (regularly) and make the point every time some manager didn't get it.
That guy's code, documentation, everything was rock solid, and the number of support cases for everything he did was so low that the dude was without a doubt the most productive person as far as income goes. You could sell the product that he worked on and just rake in money with almost no costs after that. Almost everything else had a lot of support costs and etc.
Meanwhile the guys who were doing all the new stuff, sucked at trying to juggle 12 things because it looked good on a resume.
Do your job well, it looks you are not doing very much, why are we paying you?
Everything is on fire, it looks you are not doing your job properly, why are we paying you?
I've worked with a few engineers over my career like the person you described and frankly they are worth their weight in gold, been able to bank on their output working reliably and consistently over time is hugely valuable, doubly so when what they do is the bedrock of many other things.
Of course the unhurried, thoughtful person looks like they are slacking and the hurried, frantically working person looks like they are a hard worker.
Fundamentally it's because impact is harder to measure than perception.
I once worked at a place where the development process for the Windows version of their product was GLACIAL because there was no way to run the CI scripts locally or even set up a dev environment that could build the product. People actually edited code in a text editor and then submitted it to github and waited an hour for the CI job to build a virtual Windows instance, run updates, install Visual Studio, Oracle, and all supporting software, run the compile and bail with a syntax error :((((((
So I made a Powershell script to install everything from scratch on a fresh Windows 10 or Windows Server system using Chocolatey. The script took about an hour to run, but once it was done you had a Windows box (or VM) that could build the project in 2 minutes at most, or just run the CI script directly before committing. Suddenly it didn't take weeks to fix bugs in the Windows client, and corrupted installs or DLL hell was one "wipe", "run script", "walk away while it churns for an hour" cycle to a perfect dev environment again.
I was fired 6 months later for "not stepping up enough".
Typically, higher leveled engineers have higher workforce multipliers —- their output is measured not only on their own work but how they move the whole team, division, company, or industry forward.
Now this isn’t the sys admins fault at all. The sys admin definitely helped here but the devs still have a broken workflow.
As a developer, you run the script once on your fresh Windows dev box, and then you can develop, run unit tests, or even run the CI script locally to have confidence that it will actually pass CI when you check your code in (and not overload the server with bad builds). In fact, I did all of my dev work in a VM because it's super easy to tear down and rebuild if I break the OS somehow or introduce an unexpected dependency ("it works on my machine" syndrome).
As an admin, you only have to include this one script onto a fresh Windows image, then run it and save the resulting VM image for the CI server to run (instead of installing everything on every run as part of the build script like they were doing).
The original issue was that everyone was using the CI server AS a dev environment because they couldn't get the project to build on a standalone box (it was tricky to set up, and undocumented, and the build scripts assumed a complicated CI environment). And management wasn't even raising a stink about this, despite the HUGE cost (in a large corporation I can understand this sort of thing falling through the cracks sometimes, but not in a small startup!). I'm actually not a sysadmin (I'm a developer), but I do hate inefficiencies like this enough to do something about it.
Absolutely. Another nontrivial variable is the tendency for managers/team leads to get the "credit" for successful work, even if they aren't trying to.
I've had managers before that did nothing but impede a high performing team. Luckily we delivered despite this. But it never failed, the manager would get accolades (often very public) for successfully releases, customer feedback, etc, and would end up promoted up. Meanwhile the team kept doing our thing, getting barely-matches-inflation annual increases and more and more micromanagement from the scrum diehards. Didn't take too long for the team to move on to better things. I have a dream of someday reuniting the super team for a sweet startup idea. Not likely to happen but I can dream :-)
More about this: https://news.ycombinator.com/item?id=25663767
> Everything is on fire, it looks you are not doing your job properly, why are we paying you?
Option 3: Everything is on fire, be really quick to respond to your manager and then poke and prod at things in production until it kinda works, repeat daily. This guys a hard worker! I'll have to keep him in mind for a promotion.
Installed update X to prevent risk Y
Wrote script to advance process Z on input A
Etc...
What did you do today?
What do you need help with?
What went well?
What was frustrating?
What should we change or fix?
When we get together to talk about their day or their week, these logs are extremely useful. Sometimes they generate tickets, sometimes book or course recommendations, people to talk to, sometimes just conversations.
I had a good mentor when I was doing sysadmin. Not quite as formal as this, but the conversations were similar.
I used to track my tasks in Jira with the thought that maybe my boss would look at it and see what I was doing. Of course he wasn't looking at it so I stopped doing it.
My log is mostly for me to provide a list of achievements to my boss whenever there's a review, or if I'm questioned about what I spend my time on.
If I sysadmin again, I am going to do that. "Why those trains ran on time."
It’s one of those things that would probably be naturally suited to voice-activated systems (“Hey Siri, today I updated system X to avoid Y, and I wrote a script to improve process Z on input A” - 5 seconds to say, log saved in the right place, keywords like “updated” and “system X” recognised and formalized into some record, etc), if only such systems actually worked on any word beyond the most trivial (good luck with context-less mentions of pythons, rubies, native-american tribes who somehow serve pages of webs, androids in phones, etc etc).
This isn't helped by the current trend of trying to hire mostly fullstack developers, also known as hiring one person to do the job of three people. It does almost nothing but incentivize packing resumes to hopefully make the cut and burn people out from switching modes.
People who specialize will be better at their specialization, but you will be good enough for majority of apps.
At the end of the day, some people like Javascrip and CSS. And "full stack" only means that they will work with those, SQL, and some backend language (that may be Javascript too). It doesn't imply anything on the workload, all it does imply is that the place is hiring a generalist instead of specialists.
The problem is pretty simple. Let's say you are cutting-edge in all the technologies that make you very adaptable at time T. You get hired. You decide a stack A/B/C/... for your next project. You get stuck in that project for ... let's say 3 years. (a reasonable time for a project to reach production and have a few real-life iterations). If you are not an assh... who leaves after 2 years (leaving the production/maintenance to others, i.e never having lived the "hell" of maintaining things for real), then you are 3 years-behind in all the technologies that are not in the A/B/C/... stack.
Now, at time T+3, you are ... the obsolete man [for TTZ fans only :)]
Very much the high performer type who SHOULD NOT 'progress' to management or supervisor or ... reviewer of any sort.
He was professional, but "prickly". I found the keys to get along with him but a lot of folks didn't have the patience.
Another story may be because he may not be promotable to such position because of mentioned "prickly" behavior, which may or may be not just engineering honesty and straightforward approach in contrast to bs(sugarcoating, ass kissing, exaggregating, sweeping dirt under carpet, etc) culture established in many companies.
Actually just writing code at Google is, from my experience, a small part of the job and not rewarded. The faster you get out of writing code and get into designing and delegating it, the better you're off. Sucks if you don't like it.
Coming up with a way to reward and improve nose to the grindstone technical contribution seems to me key to having an effective organization.
EDIT: also consider, doing management or team lead at a company like Google is so different from, say, a small company, that the trajectory may make no sense for somebody. Before I came to Google I felt myself on a career track that was team-lead/architect focused, mgmt interest, etc. Once I got there, that evaporated. I just couldn't imagine myself doing that kind of work in this large of a company.
That was one of the primary reasons I stayed a contractor most of my career.
Might be time for me to revisit that, this being the year when I really think I need to start something new. I have no idea how to make that switch though.
Are you contracting through your own business, or someone else's?
For me, getting into it was easy. I packed off a resume to several of the local contracting companies. They pass the resumes to the ultimate company, who will do an interview (usually very low stress because it's easy to get rid of you) and then the contracting company and the employer work out all the details. (It may have changed, but at the time of my last such deal about 2005, the contracting company absorbed about 15% of what the end company was paying for you.)
Do realize that you need to keep at least 6-9 months of your income in a readily accessible account (savings, money market, or (whoo, I'm old) CD). I never went for more than a week before I could another job, but I have known people who had more trouble.
I have since gone into federal government contracting, which is another whole bag of stinky fish heads.
Essentially since you are contracting, you are outside of the "bubble" where decisions regarding business get made. So while you may have important work on the project, you are not there when they are deciding on business aspects of it, you are usually not invited to any type of sales meetings or meetings with the clients. This is reserved for company people.
Another aspect you can do is that you can outright reject that type of work or slowly move away toward a client that is not requiring that type of work. When you are working in a company, you usually do not have power to do that. Your only option in a company is usually to quit and then hope next company doesn't pull you into that meatgrinder.
The down side is that you don't have any direct influence on those business decisions. (At one point, I wrote about three different login/single-sign-on clients for a web app infrastructure (including Kerberos/Active Directory) before they finally decided that SAML2 was politically/technically the right choice. Frustrating.) You do have indirect influence if you have a good relationship with your team lead, who will likely be a "real person", a real employee.
If you are thinking of contracting/consulting, I'd highly recommend joining a diversified team in the 10-100 range so you can do the parts of the work you love and rely on your team for the rest.
In my case, it was usually a contracting company with 10-100 contractors working for one or more client companies, but the contractor had 0 day-to-day influence on the work I did. (I did try to pick up my paycheck in person and chat with the office staff.)
Part of that is that the big companies typically hire suits to do management - which were basically the jocks in high school that always got the girl... that type - they run everything in the world now. Loud mouth tech bro asshole types.
Underdiscussed IMO. It's not a dichotomy.
Some sports, most coaches came from players, but the NFL notably does not.
I can't think of any sport where players are expected to become coaches.
In amateur sports it's common. E.g. in rowing, cycling, fencing, cross country skiing, etc., people are generally expected to coach at some point. Albeit usually while they're doing the sport, and not necessarily as their primary careers.
This does, however, not necessarily mean that everyone is a good coach, nor does it mean that everyone should stop practicing what they're doing and focus solely on coaching.
Not everyone wants that though.
I guess if there is an accounting analogy, it would be selecting one accountant to work closely with the government to ensure that the tax law is fully understood and to watch the other accountants to ensure that they are following that tax law, reducing the inefficiencies of all the accountants in a firm needing to spend their days acquiring a perfect understanding of the tax law and not spending their days doing the practical accounting work.
It’s an art and a science. So I much prefer the comparison with pro athletes who become coaches or actors who become directors.
It is not that all or most engineers would be good manager, but without that background you are guaranteed to not be good.
> And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation.
The key feedback/suggestions I see for my own performance review is to define my impact on both the monetary and cultural success of my org. Exactly the opposite of what you are saying.
> being asked to 'level up' and told that this is your mission can lead to an unpleasurable career
I don't see this happening either. I commonly hear others say the opposite and make it known they are no longer trying to level up and that they are happy where they are.
> technical team lead to management or architect
This does not jive at all with the various career ladders I see. There is no ceiling that requires me to move to management in my tech ladder.
> find that you don't enjoy the new responsibilities
To some extent, the promo process levels up employees already working at that n+1. Sure, some may not want to maintain that, but that is ultimately up to the individual.
Disclaimer: I work at Google, opinions are my own.
What you get out of that is people frantically chasing impact and visibility instead of focusing on the humdrum drudgery of keeping the lights on. The result is penny wise and pound foolish behavior that definitely does not correspond to the monetary or cultural success of the corporation. People who are good at gaming the system in this can create their "impact", collect the rewards, and make an internal transfer before the costs or superficiality of their "impact" catch up with them.
EDIT: I guess when I worked in ads, there were ad performance type metrics discussed to some degree. Not much though.
So I have to ask: do you or have you worked at a FAANG with these systems? I may be wrong but I suspect you haven't, particularly if you're equating them with more traditional hierarchies.
The whole point of a system like this (and I have direct experience at Google and Facebook) is so you can go pretty far as purely as an IC. You're not forced to become a manager.
So at Google for example, new hires start as a T3 (T4 for PhDs). There is an expectation for growth up to T5, meaning technically you are meant to progress over time. When I was there this wasn't strictly enforced (eg I knew people who had been T4 for 5+ years) but it may vary from PA to PA or manager to manager and it may well have become stricter.
IIRC the general guidance was 2-3 years T3 to T4 another 2-3 years for T4 to T5.
At that point you can sit at T5 forever if that's what you want to do. People's desire to get promoted leads them to becoming managers because it is demonstrably easier to promoted from M1 (T5 equivalent) to M2 as en EM than it is from T5 to T6 as an IC.
These higher levels are really an indication of your organizational and technical impact and for this you really have to influence others. This is not being a people manager however.
But the point is that there's no "up or out" (beyond T5) like you may find at IBM or KPMG.
Now there are definite issues with Google's approach here and that's really a whole other topic. I just don't think your observations here adequately describe the FAANG career paths (IMHO).
Yes, 9 years at Google. But yes, not experience beyond the L4/L5 tier.
It is true that the IBM type structure isn't the same, and yes, Google is fine with you staying around L5 forever (well, L4 now). But the matrix of things to get beyond L4 really is, in the grand scheme of things, about moving beyond development and into delegation, or at least ownership. It's not management, but it is about leadership/cross-team collaboration and "demonstrating impact" to others. So, like I said elsewhere, small-p political.
At least that's my experience from seeing the L4 to L5 transition. But it may also be a product of my smaller office, where the number of projects is smaller, team size is smaller, and larger technical contributions of impact are harder to find.
EDIT: Also I've seen a lot of change in the 9 years, in terms of how the organization as a whole behaves, and it is becoming more and more like a traditional BigCorp. I just checked percent/ and within engineering 86.43473% full-time employees are newer than me. And a lot more if you count non-engineering. It is a way larger company than I started in.
EDIT2: I should underline, that the perf/promo process obviously works for a large, perhaps the majority, number of people. But it doesn't for all. It requires adapting to an organizational model that not everybody accords with. And I think that's in the spirit of the original topic: organizational structures / procedures that become your career goals may not make you happy, so find a company whose process matches what you want to get out of life. Or try.
Facilitating meetings, reviewing documents, tracking schedules, reporting progress, convincing teams to prioritize the work, negotiating with those challenging the technical decisions, securing credit, deflecting blame, getting resources, etc. The model of an effective L6 or L7 IC is part secretary, part Frank Underwood.
You're right that you don't have to pursue L6/L7, but L5 is attainable in < 4 years. No 46 year old wants to be doing the same thing for the same pay as a 26 year old.
<foghorn-leghorn>I say, I say, I say boy, I resemble that remark</>
Why not? Being a T5 SWE at Google is (or at least it can be) pretty chill. It's a sweet spot for low stress and relatively high compensation. Why exactly do you need to "advance" your career, particularly if you don't want to be actually or effectively managing other people?
The alternative is the "up or out" approach that drives engineers in other industries into being (usually bad) managers.
It's not really that chill, and if you don't continue to do those things (lead or be exceptionally strong) that will show on your perf and therefore your compensation. Going from L4 to L5 means committing yourself to doing that on an ongoing basis. Remember at Google that "consistently meets expectations" is only a 2 out of 5 rating, just above "Needs improvement."
Coasting at L4 ("SWE III") could be fine. Large independent technical contributions, manage your own priorities, participate in design, etc. Solid individual contributor. Really equivalent to "senior developer" at most other jobs.
But now let's say you want to go transfer to a new project. The manager on the other team sees you've been at Google many years, but still at L4. Hm. Results may vary.
Not everyone makes a good team lead. Especially in a place like Google surrounded by PhDs and super achievers. But the expectation at Google up until very recently was basically that you should become that, or get out. Now in the last few years, it's been stated it's perfectly fine to plateau at L4. But I'm not convinced that that's the reality of the culture or expectations of managers.
It's just impossible for everyone in a company to be a team lead, so not everyone can become that to become an L5.
Which leaves the other option, to become an L5, which is to be an "exceptionally strong individual contributor" and being that "on an ongoing basis". Not everyone in a company can be an "exceptionally" strong person, otherwise it wouldn't be exceptional any longer.
You're saying the expectation was to either become L5 or get out. So now we have all these PhDs and super achievers working at Google, but only some of them can be exceptional vs. the others.
You were exceptional vs. regular people and made it to L5. Now comes in a super achieving PhD that's a tad better than you and now he's exceptional. You are no longer exceptional. You're just an average super achiever. So get the eff off Google's lawn. Stack ranking completed.
Unless you found one of those rare teams that stays together for the long haul, but the experience with such a special phenomenon should make it more than worth your while.
If L4s are not getting opportunity to lead, they are on a sinking ship anyway and the smart ones are LeetCoding.
(Obviously this all reflects the crazy economic moment of the last 10 years in Silicon Valley, but so does the level system you're critiquing).
Teams do not expand until infinity. In fact, it is often better for teams to not expand.
If you are expected to be leader after two years, because the teams are expanding regardless of whether more people are needed and because everyone else is fresh new, then there is issue with managemet
I don’t expect that to last forever, but it’s the context that this system is built for.
This makes me curious about what T1 and T2 would mean.
Tech companies don't pay particularly well for these things, but their benefits packages are very competitive.
Not that small companies can't be hell, too.
Another challenge with large firms is the overall lack of variance.
Robert Townsend had a comment that stuck with me, you don't get to be GM by behaving like GM. Which is beware of cargo culting successful organizations as they exist now. I'll also suggest don't cargo cult hyper funded startups if you aren't one either.
Disagree on personal experience with two of the FAANG Cos I have worked for. A person content in their position, performing/delivering as expected can (and many do) coast. There was little to no pressure from these firms to "move up or move out".
"When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path"
As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems. For one, organizational incompetence when people who were valuable contributors where they were are elevated up into roles where they no longer can apply those skills as effectively (i.e. technical team lead to management or architect) leaving a vacuum below. A form of the Peter Principle I guess, except the individual may have competence in their new role but not be happy, or make the team itself less successful.
And most importantly, as he touches on: being asked to 'level up' and told that this is your mission can lead to an unpleasurable career. Either when you do get that promo and then find that you don't enjoy the new responsibilities (but become trapped by the position / upgraded compensation etc.) or when you don't get the promo (or don't try) and find that your value in the eyes of yourself and others seems less.
And finally, I think this type of thing can really take hold in places with a highly academic background / focus / origin (like Google, etc.) as it mimics in many ways the grade / peer review achievement structure of academia. And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation.
Smaller companies looking to grow/formalize should exercise caution when looking at the rating/performance/promo process @ FAANGs / MS as a model for their own.
(I'm at 20-25ish years in the industry, but really feel junior in so many ways when I read the words of veterans like this.)