Taro Experts

Regardless of the subject in question, there's always someone selling some metaphorical shovel for some gold rush. But if we take a more high-level interpretation of the phrase, we can see it as: for every job, there's always someone selling tools to achieve that job. I think all parties involved have that understanding in some shape or form.

So the question they really have is likely moreso around if the quality of membership is greater than the yearly subscription cost. So the doubts that need to cleared up can be narrowed down to:

1. What value can Taro tangibly provide?
2. Is this value worth the $400/year?

For the first, it'd likely help the most if you provide your own experiences growing through Taro (a faster promo to SDEII might be a good artifact).

For the second, that's up to them to define their definition of value. But we can start this definition with a more standard financial sense: assuming Taro can get me promoted faster, is a faster promo worth $400/year? Given most software companies have pay increases each band for a couple thousand dollars, getting a promo + raise a cycle early can put that couple thousand in your pocket a bit earlier.

There’s a few things that you probably want in place first. • Scope that makes sense for a dedicated EM and Eng team (ideally scope has ballooned for an existing EM, so splitting is natural) • Strong trust from the EM or Senior EM you will report to, anyone you’d be asking (please ask, don’t force) to report directly to you, and any stakeholders (PMs, etc) who will depend on your team’s output. • Experience directing other engineer’s work as a project or team lead (ideally not writing code on the project), interacting across teams (with other TLs or EMs) to deliver something in partnership, and presenting results (ideally good and bad) to a director/VP (whatever your new skip level will be) • A willingness to let go of coding and design decisions, and to tell engineers very bad news (poor ratings, project cancelation, etc.)

From there, if you get as much of this in place as possible, start by taking on some of your manager’s responsibilities. Shadow them in some meetings, then go in their place. Write a strategy document for a program or long-term plan for your team. If you can, own a project from requirements to delivery without coding or designing. Your ownership means you are responsible, you are making sure plans are sane, you are making sure work is allocated properly, etc. You give stakeholders good and bad news as soon as you know it, you course correct a plan and adjust dates proactively, and present alternative approaches to get plans back to green.

After you have a good feel for what the job will be like, if you still want to do it, see if you can have a trial period without permanent commitment. For a quarter or half, act as if in all ways, with your manager only entering notes (after reviewing with you) and ratings as necessary. If you and your manager agree it’s working, then make it official.

It is not a one way door. You don’t have to stay EM forever. You can learn a lot of useful things and move back to a senior or staff engineering role. There will be some reasonable suspicion that you can still work as an IC, so keep skills up. You may like to do that anyway once it isn’t part of your job.

For context I moved from mid-level engineer (L5) at Amazon to baby manager (most line managers are L6), was promoted to L6 as manager, then moved to Meta, then Google, as Staff SWE.

This is an incredible question!

Today, you're making decisions in software design, tomorrow they will be about large system architectures, and some day perhaps business decisions. Not to mention the countless life decisions we need to make along the way.

Making decisions that are almost always 'right' is a key skill and it can play a big role in determining our life trajectory. It comes with experience, but you can fast track it by asking on forums like these.

On the tactical front, I'd identify the desired outcome and use that to reverse-engineer the properties of the desired system.

For example, for the database schema, write the down the queries you need to run and let that inform the schema.

For websocket libraries, identify your current and projected need for latency/throughput and devex to make a list of the properties the library must have. Then it becomes a matter of sifting through the docs to identify the right candidates quickly.

This approach will keep you from going down rabbit holes to identify the "best" candidates that might have features you don't care for.

The deeper answer is to have an easier relationship with "best." :)

By nature, all software requirements are not understood ahead of time. So, we will be wrong from time to time—and it's not a personal failure or lack of diligence. Researching too deeply comes with the additional cost of indecision and burnout, and yields diminishing returns with time spent.

Working backwards from the identified properties will enable you to balance "best" with "good enough" or "right for now" and make progress quickly while feeling reasonably confident about your choice.

Does this answer your questions?

I like Alex's idea of a "secret manager" and I did the same for a little bit in my current role.

If this is a large enough company, I would try and switch teams or quiet-quit (or actually quit) and look outward. From my observations in the question, it looks like a startup based in India.

Having bad leadership can take a significant mental toll. I would recommend use the resources available on Taro and look outward.

For side projects my goto is to ask friends (or people in Taro) what the status quo is and do that. Don't overthink it. Use perplexity to speed up research. Give it your details and ask it to make a suggestion.

I feel like frameworks follow the 90/10 rule. 90% of the features will be similar and only 10% differ. For side projects you'll almost certainly not hit these niche requirements

Also in terms of database, schemas are supposed to be evolving. Most libraries will have some migration handler to handle changing schemas so you should definitely not spend more than a few mins worrying about schemas.

In general most learning happens when you can no longer do what you did before because of a new constraint. When you naturally hit these constrains your learning 10x'es