Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Seniority Roller Coaster and Down-Leveling in Tech

blog.pragmaticengineer.com

Post reply on HN
Print view View original

121–130 of 202 posts

Re: The Seniority Roller Coaster and Down-Leveling in Tech

#121

Post by lostcolony »

allturtles wrote: post #115
lostcolony wrote: post #67

Earlier quoted context omitted.

Designing != documenting design. To get promoted in FAANG (and many large tech companies), yes, you need to document it. Interestingly, whether it works or not is completely unrelated to whether it's documented or not. In fact, the types of useful documentation (descriptions of how decisions were reached, known tradeoffs, API contracts, etc) often are completely different than the types of documentation management as…

> Interestingly, whether it works or not is completely unrelated to whether it's documented or not. I disagree. Writing up your design gives others the opportunity to provide feedback and improve the design (and possibly catch major flaws) before you build it. If you never write up your design there's a higher chance that you have built something that doesn't correctly fulfill the product requirements / won't scale /…

I think you're assuming that documentation is the only way to collaborate. I'm a big fan of talking to people. The outcome of that talking may turn into documentation, but, per my post, it tends to turn into -useful- documentation if it does, which is very different than the company mandated types of documentation, at least in my experience.

A software specific formulation of Goodhart's Law applies here; if documentation is the metric, the organization will prioritize documentation, regardless of its effect on delivery. If working code is the metric, documentation may still happen if it helps to deliver working code.

There have been zero times that mandated documentation felt helpful to me, and was able to be used without massive modification after the fact by anyone else (I remember one project that had their architectural design document v1...and v2. v1 was the mandated "before you build", and v2 was the "we've now built something that works and it is so different that it's easier to start anew than modify v1"); there have been uncountable times that I have chosen to document something that seemed important to share or persist to inform later decisions.

Re: The Seniority Roller Coaster and Down-Leveling in Tech

#122

Post by MattGaiser »

ryandrake wrote: post #117
MattGaiser wrote: post #104

Earlier quoted context omitted.

I could do all this regularly or send out resumes/answer recruiters every year or two? No wonder tenure is so low.

Everywhere I've worked, it's an order of magnitude easier to get a L+1 job at another company than it is to get promoted to L+1. Until and unless that's fixed, expect tenure to remain low. The fact that no company fixes this tells me this is employers' desired end state.

Yep. Even with the Great Resignation in full swing, companies don't seem to care about the losses other than whining about it.

As far as they are concerned, we are replaceable commodity cogs. So we should act like commodity sellers.

Re: The Seniority Roller Coaster and Down-Leveling in Tech

#123

Post by mistrial9 »

spoonjim wrote: post #60
azdle wrote: post #21

Earlier quoted context omitted.

Are you me? I spent the last 3 years completely redeveloping the foundation of our platform which will save the company millions of dollars a year. I didn't do it alone or anything. But I started the project, was the only one to work on it full time throughout the whole project, defined the underlying architecture, and implemented most of the lowest layers. I poured all my energy into the project. We launched beginni…

Avoid all work besides that which is likely to get your boss’ boss promoted.

when big tech company A was preparing for being sold, they brought in "my boss' boss" .. a woman new to the company. She promptly refused to meet with any rank and file engineer, at all, despite an arms long list of them wanting to meet. Secondly, she stopped showing up to her assigned office on the same floor as the engineers, where her predecessor had a glass-wall office overlooking the same working area.. Later, we found out that she was in fact inviting herself to any and all meetings she could get into, regarding the coming sale of the company.. it was a strategic move on her part to absolutely distance herself in every way from those doing work, and meet and become important to, officers in the company who will be part of the company sale.

source: late 90s bay area california

Re: The Seniority Roller Coaster and Down-Leveling in Tech

#124

Post by endtime »

lostcolony wrote: post #67
endtime wrote: post #41

Earlier quoted context omitted.

> I turned our product from a total waste about to be cancelled into a promising tech with some momentum, but I spent all my time coding instead of writing about coding, and I likely won’t get promoted again this cycle. As a FAANG SWE, what I am reading is "I spent two years cranking out code without doing any design work. My manager and TL never suggested I write a design doc, or didn't give me opportunities to do s…

Designing != documenting design. To get promoted in FAANG (and many large tech companies), yes, you need to document it. Interestingly, whether it works or not is completely unrelated to whether it's documented or not. In fact, the types of useful documentation (descriptions of how decisions were reached, known tradeoffs, API contracts, etc) often are completely different than the types of documentation management as…

> Designing != documenting design.

At least at Google (where I work), a "design doc" is an iterative and interactive design proposal, including alternatives considered and rationale for design choices made, not (just) documentation of what the design is.

"Documentation" of the sort you describe is an almost entirely unrelated thing, again just speaking of Google.

Re: The Seniority Roller Coaster and Down-Leveling in Tech

#125

Post by allturtles »

lostcolony wrote: post #121
allturtles wrote: post #115

Earlier quoted context omitted.

> Interestingly, whether it works or not is completely unrelated to whether it's documented or not. I disagree. Writing up your design gives others the opportunity to provide feedback and improve the design (and possibly catch major flaws) before you build it. If you never write up your design there's a higher chance that you have built something that doesn't correctly fulfill the product requirements / won't scale /…

I think you're assuming that documentation is the only way to collaborate. I'm a big fan of talking to people. The outcome of that talking may turn into documentation, but, per my post, it tends to turn into -useful- documentation if it does, which is very different than the company mandated types of documentation, at least in my experience. A software specific formulation of Goodhart's Law applies here; if documenta…

> if documentation is the metric, the organization will prioritize documentation, regardless of its effect on delivery. If working code is the metric, documentation may still happen if it helps to deliver working code.

IMO, good organizations should have both metrics. You should document your intent, and then you should be able to show that it worked out after the fact. "Working code" is a lagging metric with many dimensions (functional, secure, performant, etc.). If your only reason to believe you will get to working code on all those dimensions on a 6 month+ project is that the person who is building it thinks it's right, that's a big risk.

It seems like you're describing a particular kind of dysfunctional org where there's top-down mandates for forms of documentation that aren't valuable for sharing plans or informing later decisions. That hasn't been my experience of how design is done where I've worked, where writing designs is a collaborative process that starts with your team.

Re: The Seniority Roller Coaster and Down-Leveling in Tech

#126

Post by morei »

aix1 wrote: post #111
nostrademons wrote: post #80

Earlier quoted context omitted.

Note that at Big Tech companies, almost all code is written by L3/L4 (the untitled "Software Engineers") and the few L5s ("Senior") that enjoy coding. L6-L8 ("Staff" through "Principal") are the political levels, where EQ is more important than IQ, your job is as much wrangling/convincing/selling/negotiating with other people as writing code. Most L6-L8 engineers are managers, but even those who are ICs spend the maj…

There do exist those rare creatures who manage to get promoted to, and beyond, L6 as ICs. I've been trying figure out how they do it, but can't say I've been making much progress. (I'm Staff myself, but would not have got here without management responsibilities.)

It's rare, but possible.

Known of v high level example that is just incredibly disciplined about how they spend their time (e.g. "I did this, but was slowed significantly by poor code over that. Estimate about 30% time loss. I'm going to spend N weeks more in this area, so it's worth me spending 3.5 days fixing that code, but no more. I think I can fix it in about 2 days, so I will fix it. If I can't see the end of the fix by the time I'm 4 hours in, then I'm probably wrong about the expected time, so will abandon the fix").

The result is ridiculous productivity. They don't work long hours (strictly 9-5), but just very, very focused on making certain that there will be meaningful results from those hours.

So they exist, but absolutely it's not going to be common!

Re: The Seniority Roller Coaster and Down-Leveling in Tech

#127

Post by KaiserPro »

I think this applies mostly to "top tier tech"

In the UK, I have only been "down levelled" once, and that was when my company got bought out by a FAANG. I went from head of infra(with a growing team), to almost a ticket monkey, but not quite. Apparently I'm bottom rung senior, but given that I'm not managing people, infra or projects, its really not.

This is of course natural, as FAANGs are stuffed with over achievers and people willing to sacrifice _everything_ for for fake company points. I am happy enough collecting my kings ransom for handling 1/20th of the responsibility I had in the previous company.

I am lucky that when I have been looking for a new job I haven't had pressure to take anything that was on hand. This meant that I could avoid the bullshit jobs and push for something I wanted to do. At each stage I've had more responsibility, or more control over my area.

Re: The Seniority Roller Coaster and Down-Leveling in Tech

#128

Post by 908B64B197 »

pcmoney wrote: post #16

“For example, a senior title at Big Tech typically expects more from an engineer than a small developer agency, a non-tech-first company, or a recently founded start-up does” This is simply not true. Seniors at FAANG type companies simply dont do that much. Typically have a narrow specialty and a good grasp on how it fits into the larger Org’s strategy etc. Senior engineers at a small shop do EVERYTHING. Front end, b…

> Seniors at FAANG type companies simply dont do that much

I could see why some at smaller companies would believe that, or rather prefer to believe that.

Re: The Seniority Roller Coaster and Down-Leveling in Tech

#129

Post by joshuamorton »

lostcolony wrote: post #121
allturtles wrote: post #115

Earlier quoted context omitted.

> Interestingly, whether it works or not is completely unrelated to whether it's documented or not. I disagree. Writing up your design gives others the opportunity to provide feedback and improve the design (and possibly catch major flaws) before you build it. If you never write up your design there's a higher chance that you have built something that doesn't correctly fulfill the product requirements / won't scale /…

I think you're assuming that documentation is the only way to collaborate. I'm a big fan of talking to people. The outcome of that talking may turn into documentation, but, per my post, it tends to turn into -useful- documentation if it does, which is very different than the company mandated types of documentation, at least in my experience. A software specific formulation of Goodhart's Law applies here; if documenta…

> I'm a big fan of talking to people. The outcome of that talking may turn into documentation,

For any nontrivial design, it must. I expect that many people in this thread are coming from the Google (or Amazon?) perspective where a "design doc" is a formalization of a collaborative conversation. For small designs, it may be just a mild reformation of a set of meeting notes (you should take notes when you talk to people!). For larger projects, there's an iterative process where you start with a proposal that may be that, and get it reviewed and ensure you cover all the aspects that it will impact.

I've been on both he giving and receiving end of the "oh hey you may need to rethink this due to XYZ" at what was assumed to be late in the design process. THat's annoying, but much less annoying than spending 2 weeks or 2 months building a thing only to have to throw that effort away.

Re: The Seniority Roller Coaster and Down-Leveling in Tech

#130

Post by madrox »

I intentionally took a down-level, going from director of a 40+ team to an 8 person team. It was an opportunity to work on a product that I was excited about, and I didn't believe my ego was wrapped up in team size. It seemed like less responsibility for more money was a great deal.

I still maintain that's true. However, in hindsight what I learned was that no matter the org, it's frustrating as a manager to not have the level of influence you're accustomed to...especially when you see organizational problems. I had more experience than my boss did in their role, and they were drowning. I realized within two weeks that I had made a mistake and could only watch. Six months later that entire org got dissolved and reorganized. That leader was laid off.

The only way I'd recommend a down-level to anyone is if you really believe you can accept people operating above your level being bad at their roles.

Post reply on HN