If you want to build a decent team, you really have to relax your grip on the tech part.
You don't fix every problem yourself, but have someone who can fix it available. Otherwise, people don't grow, and you can't take a vacation. You totally need a general (middle / senior level) understanding of technology, but having a separate person with strong technical chops is key.
> In which company does this happen, I wonder!
As a staff engineer on a design system for a top 50 website, roughly half my job was detailing a tech roadmap and identifying what can break across the codebase, something you can do perfectly well on grass.
I even think this is sometimes in good faith, as in "this is some serious shot, better handle it myself to avoid failure".
My favorite pattern is what I call "code sheriff" lead, who does all code reviews himself to prevent bad code from reaching trunk. Then proceed to complain how you can't go on a vacation because all processes stop.
Good point on the control over your promotions, it's something I experienced when moving into an EM role. Banging my head until hitting an actual growth team.
I come from Russia, we're not exactly known for great people management, and I'd say management up to department head is expected to handle the tech part as well even in larger companies such as Yandex / VK. This fits your definition of normal companies perfectly.
Thanks for the feedback! I must say I've never worked in real big tech, and I've never worked with an IC beyond staff level. I'd imagine promotions to principal / fellow are quite rare as well? Besides, most "normal" companies don't have these grades, at all.
By transferable, I mean skills that are useful outside of our big tech bubble. You might not want to go out as money is very nice, but still good to know you can do something beside computer beep bop.
Not saying management is harder than engineering, at all. It's just another nice big area to learn something new.
Big companies tend to be quite prescriptive about role boundaries, so if you're an FE engineer, you can learn design and provide input as much as you want, but you won't likely get to design a new screen from scratch instead of your regular designer.
I mean, over the last few years as an IC I fiddled with CI setups and automated QA, wrote some CLI codegens, but after some time you really notice you start inventing problems to have some fun.
Well, it's well known that to become a team lead you must eat the previous team lead)
To be fair, some managers over-optimize to protect against people undermining them, not sharing knowledge and responsibility and even actively removing top performers with leadership ambitions
I haven't had any luck applying to leadership positions without prior experience. Your best bet is finding a fast-growing product: when the team triples, you'll need some new managers. I got to move around 2 months into my IC job, and now my team has grown to have another 3 leadership slots.
Note this is not a map of people or sub-teams, but of roles seen in a product team.
In an organization, you typically have several product teams, some infrastructure teams (like security or dev tooling) that don't directly ship to users, and a management structure of EMs and C-levels on top.
Because all valid JS code is also valid TS code (considering implicit any). Or, put another way, the set of all valid JS programs is a subset of all valid TS programs.
Almost every case where you use the value results in an error with unknown, but not with any:
let danger: any;
// These all compile:
danger(), 9 / danger, danger.access, danger.map(x => x \* 2)
let safe: unknown;
// These all explode in TS:
safe(), 9 / safe, safe.access, safe.map(x => x \* 2)