Startups sometimes have founders or early employees who are staff (or higher) engineers.
Sometimes this goes terribly: the staff engineer is used to working in a giant bureaucracy, so instead of writing code they organize a long series of meetings to produce a UML diagram or something, and the company fails.
Sometimes this goes amazingly: the staff engineer can fix bugs 10x faster than the competitors’ junior engineers while simultaneously having the soft skills to talk to customers, interview users, etc.
If you are in the former category, EA organizations mostly don’t need you. If you are in the latter category though, EA organizations desperately need you, for the same reasons startups want to hire you, even though you also have skills that we won’t be able to use.
If someone is considering applying to CEA I’m happy to talk with them about whether it would be a good fit for both sides, including which of their skills would be useful, which new ones they would have to learn, and how they would feel about that. Some people really like being able to meet a promising EA at a party, hear about one of their issues, rapidly bang out a PR to fix it, and then immediately see that EA become more impactful (and know that without them—it wouldn’t happen). But other people really like the “make a UML diagram” style of work, and don’t enjoy working here. It’s hard for me to guess or to give a generic answer that will fit everyone.
It seems like you are bucketing senior eng skills into bureaucracy or… agility? ability to work quickly and responsively? That is missing most of what makes staff engineers staff engineers. Start-ups want engineers who are overpowered for the immediate problem because they anticipate scaling, and decisions made now will affect their ability to do that later. EA is growing but AFAIK not at nearly the speed it would take to make use of those skills: you’re more likely to end up with something terribly overbuilt for the purpose.
From what you describe, I think you’d be much better off looking for a kick-ass mid-level PM with a coding background who wants to get back into engineering. They’d be giving up much less (both in terms of money, painstakingly acquired skills they enjoy using, and future option value), and are more likely to have the skills you actually want.
> Start-ups want engineers who are overpowered for the immediate problem because they anticipate scaling, and decisions made now will affect their ability to do that later.
I’m sure this is true of some startups, but was not true of mine, nor the ones I was thinking of what I wrote that.
Senior engineers are like… Really good engineers? Not sure how to describe it in a non-tautological way. I somewhat regularly see a senior engineer solve in an afternoon a problem which a junior engineer has struggled with for weeks.
Being able to move that quickly is extremely valuable for startups.
(I agree that many staff engineers are not “really good engineers” in the way I am describing, and are therefore probably not of interest to many EA organizations.)
Startups sometimes have founders or early employees who are staff (or higher) engineers.
Sometimes this goes terribly: the staff engineer is used to working in a giant bureaucracy, so instead of writing code they organize a long series of meetings to produce a UML diagram or something, and the company fails.
Sometimes this goes amazingly: the staff engineer can fix bugs 10x faster than the competitors’ junior engineers while simultaneously having the soft skills to talk to customers, interview users, etc.
If you are in the former category, EA organizations mostly don’t need you. If you are in the latter category though, EA organizations desperately need you, for the same reasons startups want to hire you, even though you also have skills that we won’t be able to use.
If someone is considering applying to CEA I’m happy to talk with them about whether it would be a good fit for both sides, including which of their skills would be useful, which new ones they would have to learn, and how they would feel about that. Some people really like being able to meet a promising EA at a party, hear about one of their issues, rapidly bang out a PR to fix it, and then immediately see that EA become more impactful (and know that without them—it wouldn’t happen). But other people really like the “make a UML diagram” style of work, and don’t enjoy working here. It’s hard for me to guess or to give a generic answer that will fit everyone.
It seems like you are bucketing senior eng skills into bureaucracy or… agility? ability to work quickly and responsively? That is missing most of what makes staff engineers staff engineers. Start-ups want engineers who are overpowered for the immediate problem because they anticipate scaling, and decisions made now will affect their ability to do that later. EA is growing but AFAIK not at nearly the speed it would take to make use of those skills: you’re more likely to end up with something terribly overbuilt for the purpose.
From what you describe, I think you’d be much better off looking for a kick-ass mid-level PM with a coding background who wants to get back into engineering. They’d be giving up much less (both in terms of money, painstakingly acquired skills they enjoy using, and future option value), and are more likely to have the skills you actually want.
> Start-ups want engineers who are overpowered for the immediate problem because they anticipate scaling, and decisions made now will affect their ability to do that later.
I’m sure this is true of some startups, but was not true of mine, nor the ones I was thinking of what I wrote that.
Senior engineers are like… Really good engineers? Not sure how to describe it in a non-tautological way. I somewhat regularly see a senior engineer solve in an afternoon a problem which a junior engineer has struggled with for weeks.
Being able to move that quickly is extremely valuable for startups.
(I agree that many staff engineers are not “really good engineers” in the way I am describing, and are therefore probably not of interest to many EA organizations.)