I've been asking this question about Java myself too so thanks for the question and the answers so far!

Instead of answering this for Java specifically, I want to take a step back and share the different levels of depth that a SWE can harness to solve different types of problems. Perhaps it'll help you clarify what level of depth you want to get to.

- **Basic.** SWEs with a basic level of understanding can write working code because they know the core language fundamentals. This would include syntax, data types, control structures (branching, functions, classes, etc), simple input/output, and etc. One can get surprisingly far with this amount of understanding.
- **Intermediate.** Engineers at the intermediate level know how to effectively utilize standard libraries, frameworks, and idiomatic language/design patterns in order architect complex systems. This might involve knowing a subset of inner workings for libraries, frameworks, and the language itself. Graduating from this level to the next requires some combination of reading, writing and re-writing production code. This is the level of expertise I'd hire SWEs at if I want to get something done.
- **Advanced.** Advanced users of languages know most of the internal workings for the language and frameworks they commonly leverage. This allows them to make choices that impact the performance of the system they are building and/or optimizing. It's usually at this stage that engineers develop an opinion for whether a language or framework fits a system's requirements. They can also dive deep to micro-manage memory, manage multi-threaded processes, and make direct contributions to frameworks and libraries. At this level, an engineer has a precise definition of the boundaries of their knowledge, and can very quickly pick up things they don't know. This is the level of expertise I want engineering leaders to have.
- **Mastery.** These are the engineers that have formed strong enough opinions about different types of languages that they themselves created a language to make their own tradeoffs as opposed to being confined to the languages that currently exist. Mastery is reserved for a small subset of engineers that are language authors and major contributors. There's a theoretical and philosophical element to this that requires a lot of thought and usually comes from a unique passion or new type of system need.

Resources wise, I do think you're right that the ratio of content for deeper levels of expertise is low when compared to more basic levels, but if you look closely on SWE forums and follow strong developers on social media, you'll find repeated references to what I would call *classic* materials. The most "classic" materials are the documentation for the original language or framework itself. I actually think these resources are almost always underrated since everyone prefers to read the latest and greatest. If you pivot from quick and snappy internet content to studying the classics and exercise learned concepts through writing and re-writing real code, you'll be able to achieve any level of proficiency you want.

Ex-Google SWE • FE/Mobile -> BE/Distributed/AI

Kevin Wu

Alex's suggestions would be what I would do as well. If you can garner their respect and trust from a technical perspective, they'll be open to your suggestions and ideas. I'd discover what kind of credibility influences them too (e.g. monetary impact, personal relationship, data, credentials, etc.) and go from there. Although the extent of influence you need will also depend on what kind of company management is trying to build and the extent to which they are open to changing that.

There are [different types of leadership](https://hbr.org/2024/04/6-common-leadership-styles-and-how-to-decide-which-to-use-when), and they each have their pros and cons. Different seasons in a company call for different types, and different people with different levels of skill work well under different styles.

It sounds like you're in an autocratic one. It's one thing for management to be intentionally this way. It's another to be accidental about it. The leadership seems to be unaware that they are lowering either you and/or your team's morale, which doesn't seem great. Separately, it also sounds like either you don't work well under this type of leadership or management doesn't have enough of your trust to do it this way.

It's worth pointing out the autocratic style is not all bad. It allows the team to move fast and can be more efficient - it's really great for moments of crisis or when the leader has proved themselves and the team deeply trusts the leader. The negatives of this leadership style is what you are experiencing.

I'm assuming you've been asked to step up to lead a small team. Let me know if this is not the case and I'll reframe my answer! I do think some of these thoughts also apply to tech leadership in general.

The overwhelming feeling you feel means that you're in a great spot for growth. Just make sure that overwhelming feeling doesn't actually overwhelm you. Keep your basics in check (sleep, eating, exercise) and learn to prioritize the big problems first (I would limit them to three) and leave the small problems for later. Some thoughts on how you can really take advantage of this opportunity:

- **Find a mentor and, if you can, a sponsor**. You'll need someone that's done this before on your side when you need the support, ideally someone that also has an existing network in your realm that they can help you tap into. Reach out to someone in your org that you respect. Make sure to also have someone that is outside of your org's walls so you can get third party support that is unbiased by your org's specific goals. If you can't find someone internally, I would suggest paying for it. It can be expensive, but I personally consider this type of investment worthwhile. Having mentors and sponsors makes a big difference when it comes to growth.
- **Take complete ownership and develop your own opinion.** Treat this like your problem and think about how you want to shape the entire project. Talk to peers and leadership to get a feel for what is important to them but also form a personal opinion on the matter.
- **Delegate tasks so you can dive deep technically.** If you don't have your technical ducks in a row, the team your leading will suffer so this is one of the more important things you can do. It is actually totally okay if you need to spin this up now - good leaders are able to tackle new spaces without prior knowledge but can spin up on topics quickly. It sounds like this might be your first time doing this but if you invest consistently in this, you'd be surprised at how fast you can come up to speed.
- **It's okay to say "I don't know".** But always follow up soon after with a newly formed understanding of the problem and some opinions.
- **Find the key players for each part of the system own.** Big problems rely on a collaborative group of individuals. Identifying these key people for yours will be important, whether it be for their knowledge, execution, leadership, or support.
- **Understand your team better by understanding their motivations.** My answer [here](https://www.jointaro.com/question/NIvlXBZZJgzmoSUyMtbj/looking-for-resources-on-increasing-your-teams-peers-productivity/) talks about how this is important since it'll help you make the most of your team.

To wrap it up, one person I've enjoyed learning about the topic of leadership and management is [Shreyas Doshi](https://linktr.ee/shreyasdoshi). He's an experienced product manager, but he talks a lot about leadership and I've gleaned quite a few practical things from his content. Here's [a video about delegation](https://www.youtube.com/watch?v=y4b6m5nzTh0) that I felt clarified for me how to delegate effectively.

In my experience, having a specific space or product in mind will help direct focus when it comes to depth.

The goal is to have enough technical tools in your belt to build in a specific space with both grace and speed. That requires a balance of system knowledge, language familiarity, how to implement certain algorithms and data structures in said languages, how to automate parts of your development flow, and the most useful libraries that exist within the ecosystem you're focused on. Debugging is a great callout too - anything to save you time while still maintaining good quality because in the end, that's what is valued by newly spun up product teams that launch truly great and innovative things.

From the topics you mentioned, certain aspects of depth matter, like how Kafka works under the hood, general latency numbers, how to be fault tolerant, load handling, and etc. These are important because they ultimately contribute to how well a good product will work. Good teams will evaluate you on these topics. If not, they'll at least evaluate how good you are at picking up the necessary amount of depth required to build something good.

I consider framework or language developments like news - I'll hear about the most important stuff if it is meaningful enough. I would only focus more on them if I were in language or framework development myself or if I have taken a personal interest.

It's awesome to see this kind of initiative from a team member!

The existing answers are tactical and great for general time management. Here are some points that come from the perspective of the bigger picture:

- **What are the motivations of your individual team members and leader?** A teammate's motivation is the source of their productivity, and understanding them can help you help them find their role and responsibility on the team. People are motivated and feel rewarded by different things (e.g. money, achievement, team camaraderie and support, etc.). The core problem of building a great team (or improving the team quality) is how to align the incentives so that the team is driven both individually and collaboratively to achieve a certain outcome.
- **What are the pain points of the DX (developer experience)?** Identifying and ranking these will help you figure out what the important problems to fix are. There are an array of things that could be improved here. Some examples:
  - The team spends a lot of time fixing critical bugs.
  - Build times are slow
  - There exists repeated manual operation.
  - Test coverage is low.
- **What are missing gaps in technical knowledge?** Each teammate's skill lies somewhere on a spectrum and some people care to grow it while others don't. As a teammate, identify and filling gaps through knowledge sharing can make a surprisingly big difference to team velocity.

You want to look for the following:

- **Growth.** If a team, org, or company is growing, there are more things to do than there are people to do them, which means the problem is not whether people are replaceable but rather whether there is enough talent to execute the vision of the organization. This is the difference between a zero sum environment and a positive sum environment. A team that is just beginning to discover the value they are bringing to users or customers will fall in this bucket.
- **Collaborative.** Generally growth means collaborative environment, but that's not always the case, so look for teams that understand the value of helping each other. Envy is a common emotion, but people that are collaborative usually convert it to motivation for their own growth. They're able to celebrate other people's success.
- **Metrics driven.** Metrics driven organizations are striving to avoid bias which means if you deliver impact, that is what is rewarded. Metrics are not necessarily just the metrics a team is responsible for, but what they mean in the context of serving the user, client, or customer.

It's not easy to identify and find environments like this though. As a junior or mid-level, I think outputting lots of high quality code and holding a mental model of both the system you're working on and its business impact is going to be what gives you opportunities to join organizations that possess these traits. I would also learn to exemplify these qualities yourself despite not being surrounded by them.

I have some general thoughts on the "social hierarchy" you're calling out.

> There is project specific information, in absence of really god wikis you have to rely on the peers in the team to provide you such information

I don't think most people are worried about being replaced. I like to think people are willing to help as long as the ask is clear. A question like "Hey, could you give me a high level overview of how this system works?", especially coming from a place of curiosity or desire to move the team forward, should be welcome. Relying on other teammates to succeed is normal. This applies at all levels of employment. Actually, the higher you go, the more important it is.

> Envy might appear between other senior folks if you progress quicker than them and might start to backstab you

If you're helping them as much as they are helping you (or perhaps you are helping them more) and you're helping the team accomplish large tasks and delivering impact where there is complexity and ambiguity, I think envy would likely be replaced with praise.

> Manager might not want to give you extra money and compensate at your true value.

It is within a company's incentives to hire you at the lowest rate to get the highest returns just like one would try to get the best deal for something they're buying. At the same time, a company should get what they pay for so if you're worth more than you think they are compensating you, and the market is saying so, then it could be time to leave. Good companies like to pay top of band so they are able to build a great team. There's a balance though - top of band pay without accountability can also lead to employee entitlement.

It's worth pointing out that knowing how much your worth requires checking with the market's assessment of you. It otherwise can be a self-biased assessment which can lead to unfounded grumbling.

> If you work too much, or too hard there's going to be problems withe the peers, because you increase the bar and kind of force them to work harder too.

This is more of a cultural fit issue. Different teams view work life balance differently. Some teams have delivered the crux of the impact they can, and are in maintenance mode, so working hard can be viewed as unnecessary. Other teams are in growth mode and there's a lot of work to do, so even though some people aren't working that hard, it's completely okay for others to work harder than they are. If your team is not working as hard as you'd like and peers are grumbling about how much work you're doing, it might be time to check out a different opportunity. There will definitely be companies that want your level of commitment.

Ex-Google Senior SWE • FE/Mobile -> BE/Distributed/AI

Jonathan gave a great answer. Here are some tactical tips that are related and might be helpful too.

> Every morning, I face the question - "which one do I focus today?

One way to solve this is plan the day before. I like planning my day before since when I wake up, I want to dedicate the best of mind to the hardest parts of my work instead of prioritizing and planning. It usually takes about 30 minutes to schedule out the day ahead.

> I try to give estimates by assuming my time would be equally divided among the 3, but its almost always unequally divided, meaning some product manager is let down almost always.

Estimation is a skill because we naturally tend to estimate as if everything goes well. I always add a 50% gap to my initial estimate and communicate a number closer to that since scope and dependencies can always come up and gives me a bit more room to work with.

It's natural to distribute focus across multiple projects unequally. There's always going to be some sort of priority ranking otherwise focus wouldn't be called focus. It's rare that all projects are equally important, so I'd prioritize according to the project's impact. If they are somehow equally important, my strategy would be to cycle through weeks of focus for one particular project at a time. Say week 1, Project A gets most of my focus, then B, then C, and week 2, Project B gets most of my focus, then C, then A, and so on.

If your PMs are being let down, I'd make a point to realign their expectations and communicate what changed compared to the initial expectations that were set up.

> A lot of times, if I am focusing on project A for the day, if I get pings about project B a lot, then my focus keeps going towards project B, and I can't make progress on both project A and project B

If a ping is taking more than 2 minutes of my time to respond or is not urgent, I tend to avoid responding altogether and batch responses for those into a 30 minute chunk of time that I call "Comms" and respond to them all at once. I've never had anyone be frustrated with this. If somebody were though, I'd explain to them that my focus time is precious and that I'm happy to collaborate, but set up a meeting so you can have my full attention. Please treat my attention as a precious resource to use sparingly.

A caveat to start: I have a general strategy in mind for the next company I join but do not have real experience to back it up (yet).

The answers to these questions will likely be found by tapping into the network of people you work with and the network of people that your work already impacts. This means reaching out to them, [leading with kindness,](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/) and learning about the following, likely over time:

- What are they focused on and why
- The value they are creating
- The challenges they are facing
- The things they might need from you to succeed
- The culture they are trying to uphold and things they wish could change

In addition to the immediate team, here are two other groups of people I'd also want to talk to:

- Customers
- Leaders of organizations delivering adjacent goals indirectly related to your team

I'd make a point to ask people I meet to introduce me to three other people/teams they think I should connect with so I can get a feel for who is known for a certain thing.

The skills that'll be required here are active listening, observing others actions over time, and prioritizing high impact win/win investments with fellow doers.

Here are some related discussions and Taro resources that might be helpful:

- [For a Staff engineer at a Big Tech company, what should their first 3-6 months look like?](https://www.jointaro.com/question/X8QYtxzD7SXdzMfcnBiX/for-a-staff-engineer-at-a-big-tech-company-what-should-their-first-3-6-months-look-like/)
- [How do I sell the vision behind a large, org-level project?](https://www.jointaro.com/question/vzivGNDnuwCctD3oeamP/how-do-i-sell-the-vision-behind-a-large-org-level-project/)
- [\[Masterclass\] How to Build Deep Relationships Quickly in Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

Sorry to hear that you're going through this - I know many people going through similar things.

When tough times come, I like to first check in on my basics. Am I sleeping well, eating well, and staying active? If not, I take a step back and re-focus myself on those things. I've learned that they deserve my highest priority regardless of what is happening around me.

If this is an ongoing thing, I also recommend therapy like Ryan mentioned. I recently read the [Happiness Hypothesis ](https://www.amazon.com/Happiness-Hypothesis-Finding-Modern-Ancient/dp/0465028020)by [Jonathan Haidt](https://jonathanhaidt.com/) and it mentions a specific type of therapy called CBT as one of three things that can really help boost overall happiness. The other two things Haidt mentions is meditation and medicine. Might be worth considering.

Other things like disconnecting by taking PTO, leaning on friends and family, and disconnecting from social media will help a ton.

After you have the above, here's some thoughts on how I'd approach defusing the specific topics you shared in order of priority:

- **Productivity**. I'd focus on personal productivity - do things that are investing in yourself and make that the first priority every day. That'll help you get out of job situations when you need to. For your work, I'd work out a sustainable pace for contribution to your company that you think is fair to keep the option to stay at your company as long as you need to.
- **Relationship with manager.** Being a manager has to be a difficult job, otherwise there would be more great managers. It's really unfortunate that a bad manager's choices and character deeply influences their reports. Regardless, learning to manage up helps you be flexible in many different types of management scenarios. Managing up just means figuring the point of exchange that is the best compromise for both sides to get what they want. However, when it's clear that there is a misalignment, it's time to leave. Investing in yourself will help here.
- **Company culture.** Sorry the culture sucks. Voicing feedback is one way to help although that doesn't mean things change. It does help you clarify what you care about when it comes to company culture. Perhaps it'll help others voice their thoughts too. I like to do my best to shape the culture around me to be better if I don't have control of the company's larger culture. Sometimes I learn that the culture I try to bring doesn't actually make others happy either. It helps me get feedback on what I think makes sense.
- **General economic instability**. I didn't know there were economic cycles until recently, and I've since learned that it is prudent to be always ready for them. It sucks particularly for those that don't have the financial support they need during this time and for those that are just starting their careers. Out of this group of people, those that win are those that can stay persistent in the face of rejection after rejection. People like that treat failure and rejection as part of the winning process.
- **AI dominion**. New tech just means a re-calibration and a re-development of a new strategy. Tech companies always scramble to figure out their strategy when new things show up. My personal opinion is that tech professionals should also do this on a personal level. For an entry-level person, I'd zone in on how AI can help me get better at my current job so I can start building high-leverage skills as opposed to using it to do my work for me. I like Andrej Karpathy's [tweet](https://twitter.com/karpathy/status/1767598414945292695) comparing automated software engineering to self-driving. I'd try to get to the level of expertise where I can provide oversight to AI.

I've experienced this too. I think many engineers end up here because they are facing some wall with regard to their growth. Sometimes just learning by doing is not enough since the work available to you doesn't have the scope for the type of learning that actually fosters growth.

My general advice is to pick the classic books in a space of interest and read them. For backend distributed systems, that would be Designing Data-Intensive Applications (DDIA). There's an ongoing book club where we review a chapter at a time together. Sounds like a perfect fit for the time you have and what I can gather about your interests.

The classics in a space or industry are important to read because they are generally timeless pillars, meaning everything new stems from it, even though it may have been published 10, 20, or even 100s of years ago. They'll connect you to the roots of what exists today and help you to understand a lot of the lingo. For example, DDIA gives you the foundation to understand white papers and research papers about distributed systems.

Classics also opens eyes to the gaps in knowledge one might have in other related aspects of the industry. Going through the book myself I picked up that I wanted to dive deeper into languages, security, and concurrent programming.

With the new knowledge, we do still need to bring it back to looking for opportunities to really retain it (see Taro's response to [How to Avoid Going Down the Rabbit Hole](https://www.jointaro.com/question/4XLModnvZVwgQYbZEbDD/how-to-avoid-going-down-the-rabbit-holes-when-learning-new-things/)). Sometimes this might mean taking a pay cut in the short term to optimize the development of a high leverage skill. In the long term, this type of focus usually pays off. It may also mean side projects or open source contribution.

Agreed that as an L4, clear defined scope is a better choice to prove your value to the company first unless your confident you can lead well in ambiguity. I'm assuming option 2 wouldn't take more than three quarters to ship.

Some of the strengths of the platform/infra option sounds great for L5 or even L6 scope. Since you're interested in the tech, I'd keep an eye on how that team grows and reach out to connect with the engineers that do end up working there. I'd also learn the tech on the side. Assuming option 2 won't take long, by the time you finish option 2, you'd have gained trust, gained some confidence, and will have a better feel for whether option 1 is good investment or not.

Didn't consider this option but it's a good one! Assuming there is enough value to raise prices, customer loyalty is something worth thinking about too. You can provide this by raising prices for new customers but not necessarily old ones to keep providing fair value to those that took an early risk on your product.

This sounds like a really exciting opportunity! Low user churn? Your team is onto something good. Definitely get more marketing and sales help since it's time for that.

Quick caveat: I haven't done this myself but I was actively learning about some of this as I was building my own company this past year.

I'd learn a bit more about *growth engineering* and *growth hacking*. Here's a great intro written by Jeff Chang who was a technical leader for growth at Pinterest: [Intro to Growth Engineering - Learn How to Prioritize the Right Projects](https://www.growthengblog.com/blog/2018/4/10/scaling-new-growth-opportunities-series-intro).

Generally, at this stage in the product, the engineering efforts that are high leverage are:

1. Investment in the new user's journey to experiencing the magical moment of your product. This is a shorter term investment.
2. Finding a new user pain in an adjacent domain and building prototypes for it with some percentage of your time. This would be a longer term investment and would require knowing your users well.

> 1. As an engineer, how can I break this “revenue” goal down to help figure out the team’s strategy and what we should be building?

Revenue should be convertible to number of users, and from there, you should be able to infer from other adjacent sources of traffic (e.g. web searches, email marketing, neighboring related features, etc.) how you can fill them and what you can do before solely relying on marketing and sales.

> 1. Are there sub metrics I should be setting sub goals for?
> 2. How do I estimate how much ARR a feature will get us? (Or is that just a waste of time because they’re just educated guesses?)

Generally, I like measuring retention using cohorts to see how we're doing on a periodic basis, say monthly. Feature sets change over time, and it's good to understand how retention is changing as new features are launched.

Sub metrics wise, I think the road to the moment of magic will be worth measuring. How many new users are dropping off before they hit the magic? Where at?

> 1. How do I know if features on our user feedback boards will help get us new customers (and therefore more ARR) vs just making existing customers happier? Our churn has been very low so as nice as it’d be to just build what our existing users want, I want to prioritize new customers to avoid the project being shut down prematurely.

If I could, I'd go talk to them. Ask them to *prioritize* their problems in the problem space your product is solving. If you can't do this, I'd at least get a feel through a survey. Here's a classic video by Eric Migicovsky (Founder of Pebble) on [How to Talk to Users](https://www.youtube.com/watch?v=MT4Ig2uqjTc&ab_channel=YCombinator). This might be done through a product manager or marketing lead.

It sounds like you're in disagreement with your manager, which is a good thing! It comes with having diversity. The part that is less than ideal is how it might be affecting your capacity at work, and perhaps even the velocity of your team/organization.

I want to say that pushback in the form of collected disagreement is actually really good even though your supervisor is technically not your peer. It's the type of communication that helps you and your supervisor build a quality relationship despite your differences.

I like Charlie's suggestion - setting up expectations and defining a mutual contract, especially with other teammates involved, will be valuable.

As part of that, I think being able to express the following in a conversation between you and your supervisor will also help:

1. Express how and why nits matter to your supervisor. In order to communicate this, you have to understand where your supervisor is coming from. Expressing this will help your supervisor see that you understand their motivations for nits exactly which shows empathy.
2. Express the tradeoffs that their view contributes to the overall team/organization.
3. Suggest your opinion, perhaps backed with credible articles that you've found.

It may also be worth checking in to see how other teammates feel about this as well. To do this well, approach it as a third party viewing the overall productivity of the team as opposed to a first party that is frustrated with your work environment.

Nice job clearing those interviews! Happy to help with a mock coding interview if you're interested.

good job sending it out there. gotta love the iterative process!

I've been thinking about this myself lately, but more so from the perspective of what I admire about strong SWEs. In addition to the very important skills the answers so far have already provided, here are some more technical pieces that I think strong SWEs often demonstrate.

- **A strong knowledge of the fundamentals of computer science.** Strong SWEs seem to be able to quickly pick up on the inner workings of the abstractions they are using when they need to. Often times, this requires some level of computer science understanding. They know, at the foundational level, how computers work, how languages work, some general frameworks and patterns, and how the internet works. This should most certainly include data structures and algorithms because computers are built completely off of these concepts. I suppose this might be why DSA is the interview standard, although it is true that the majority of work SWEs do on a daily basis don't require it. This type of knowledge is what allows a SWE to reason from first principles.
- **A working knowledge of the full software lifecycle.** Being able to quickly bring what a SWE is expected to bring at each point in the software lifecycle. For example, during ideation phase, this means being able to bring technical solutions and constraints to the table, including tradeoffs for different paths, and *communicating* it well. For another example, at the test stage, being able to draft up a test plan that will ensure consistent results even after the current release.
- **They write forward and backwards compatible software.** When strong SWEs release something into production, they're confident they're not breaking the existing experience, and they know they'll be able to continue building on top of the software they just shipped. A part of this is related to good habits surrounding flagging new features and bug fixes.
- **They know how their software is doing.** At any point in time, a strong SWE would be able to quickly figure out how their software is doing in the real world. This means that they've strategically placed logs in their software and have a place to monitor them. They are also monitoring the health of the resources that are running to serve them. For devices, this means things like battery usage and device thermals. For servers, this means similar things like CPU and memory usage.
- **They have a classical understanding of privacy and security.** Violating privacy is one of the sins of our generation in software. Knowing how to ethically manage the end user's data and know at what points of a system security may be a concern is a skill any SWE should have. A strong SWE understands the classic strategies to protect the user's privacy and security and know when they need to ask for more specialized help.
- **Automation** and **abstraction.** The "lazier" a SWE is, the better they seem to be, mostly because they quickly recognize when something can be automated or abstracted. Then they appropriately invest in the ones that'll give them high returns.

Some of these skills I'm actually missing myself even to this day, and I plan to dive into them over the next couple of years.

In terms of how to pick these skills up, most of these should come with the job and being promoted from entry-level to senior as long as your company has good SWE practices. The two that are a little harder to get just from getting to senior alone are "Automation" and the "Fundamentals of Computer Science". Automation comes with your own observations of things that are repetitive and can increase the velocity of you or your teams output. Learning computer science requires school or the combination of self-study and side projects that help you gain those concepts.

It sounds like you're doing a lot of good things the short two months into your new role. What is the standard you're measuring yourself to that makes you feel you need to boost your productivity? That'll help me answer your question better.

From what I can deduce, your question has various facets to it. Let me answer a couple of them.

> I feel like I don't have time to plan meetings when I clearly lack expertise in our current tech stack

I'll comment on the lack of expertise on the current tech stack here. It takes some time to ramp up to a new tech stack. A wholistic understanding usually involves some combination of studying and building. I'd allocate some time every day to study and ramp yourself up on different parts of the stack to understand the origin of the tech, the "standard libraries" equivalent of the tech, and study its strengths and weaknesses. It's also worth talking to your team about their experiences with it and understand how the choice was made to begin with. Pick up some extra bugs and try to fix them. As you do that and make progress on your project, your knowledge will also grow. This should get you up to speed in no time.

> I recognize I need to boost my productivity

Productivity is combined of three things:

1. **Being smart.** My comment above should partially address this through gaining knowledge. Some other aspects to this are being resourceful and being open to failure with execution. An example of this for a mid-level might be sharing a design before it's perfect in your eyes to see what people think versus what you think since your own bar may be unnecessarily high. The Pareto (20/80) rule is especially helpful here.
2. **Time spent** and 3. **Consistency.** This is about how much time you can put in to work and how long you can do it for. Someone that can sustainably execute 6 hours a day, but do it 5 days a week consistently for 2 months (240 hours total) will do better than someone that executes 8 hours a day 7 days a week but can only do it for 1 month and then need another month to recover (224 hours total). Ideally you can increase both, but everyone has their limits, so find yours. Good habits go a long way.

Piping in here because I've shared a similar dilemma when it comes to networking. I'm now in the part of my career where networking is becoming valuable. I am starting now, but in hindsight, I wish I spent at least a little bit of time developing it.

How is networking valuable from my perspective at an event like Taro's?

1. **You don't know what you don't know.** Talking to others can help surface things and ideas that are happening you either don't have the capacity to pay attention to or haven't experienced yourself yet. You get an inside scoop on those things as opposed to doing the research yourself. It's one form of scaling yourself if you will.
2. **Connecting over shared experiences.** The types of people that show up at an event like Taro's will have faced similar challenges with their career. It's a good place to connect with others over them, either by helping or getting help, or like the first point above mentions, learning about challenges that might exist you haven't yet encountered.
3. **Finding opportunities to help others.** As a builder, I think it's often interesting to hear about the pain and challenges others are experiencing because it'll help shape the ideas I have for side projects or opportunities to build something that can really help them.

> Can you expand on how to go past the mere exchange of information

I like to think of networking conversations kind of like casting a wide net to see what lands first before developing the topic deeper. There are a few types of connections one can make with someone else at a networking event. I'll list them out with specific questions that might be worth asking.

- **Skills.** What exactly do you do at work? What tech stack are you using? Tell me more about why you decided to use &lt;technology&gt; in this scenario? How did you go about choosing to specialize in &lt;technology&gt;? What do you like or dislike about &lt;technology&gt;? Who are you customers and what value do you bring to them?
- **Personal**. What kinds of challenges are you facing at work? What are some of your proudest accomplishments so far? Have you faced &lt;a challenge I'm facing&gt; before and how did you resolve it? What interesting things are you working on in your free time? 
- **Trends and current events**. What do you think about &lt;this trend&gt;? Do you know anyone that would be a good person to talk to more about &lt;this trend&gt;? &lt;Tech event&gt; is happening soon, have you attended it before?
- **Contextual**. How did you find out about &lt;this networking event&gt;? What motivated you to come to &lt;this event&gt;?

To wrap this up, one more tip: Tit-for-tat is the best game, but if others aren't playing it, you can always lead it. What I mean is you should always be aiming to share conversation time 50/50 as much as you can, and help lead others if they aren't asking questions in return by answering your own questions and covering a breadth of topics that might help you connect with the other individual further.

It'll be hard to do this well at first, so just keep trying and iterating. You'll find that the connections you make now might not benefit immediately, but provide a ground for opportunity down the road.

Wins:

- Feeling the most confident I've felt in awhile in technical phone screens
- Signing up for Taro, meeting other Taro members at the Bay Area Meetup, and helping fellow Tarodactyls out on the forum 🍠

Fails:

- Getting rejected from an initial phone interview even though the interview went well
- No responses from cold applications - I'm looking for referrals to Netflix and other companies if your company is hiring backend engineers.
- Failing a mock system design interview - I'm looking for help here as well.

Like you said, since you just made a transition, you might not directly ask for a promotion since you're still proving yourself, but it is never too early to voice your desire for promotion in the context of your desire for growth since that generally benefits the team and business. Voicing this desire earlier will help you get an idea of how your manager approaches the promotions of their reports and how the promotion process works at your company. It'll also help you identify things you didn't know the company's promotion process cares about.

There's this saying "the squeaky cog gets the great". Voicing your goal to grow and get promoted in combination with the great work you do will help your manager think about you when there are new projects down the pipeline.

I've personally found a lot of [great content on Taro about promotions](https://www.jointaro.com/search/?q=promotion)! Definitely dive into it. Here are some helpful ones that I think you might find helpful:

- [Asking For A Promotion The Wrong Way vs Right Way](https://www.jointaro.com/lesson/GvT4NBqaBULFlizarSCf/asking-for-a-promotion-the-wrong-way-vs-the-right-way/)
- [Promotion Is Underrated And The True Foundation Of Your Pay And Your Career](https://www.jointaro.com/lesson/0GGXmkPHbmB7LtWv8HXJ/promotion-is-underrated-and-the-true-foundation-of-your-pay-and-career/)
- [How do I pitch for a promotion?](https://www.jointaro.com/question/F4fF71CYSd72E5X02sEI/how-do-i-pitch-for-a-promotion/)

Ryan's answer is great - understanding what the question is trying to get at, highlighting them in your response, and connecting them with real experiences will go a long way.

I want to provide a couple examples of good answers given a situation like yours. To set the context, here's a little more about what "Tell me about a time you built a cross-functional feature that influenced other teams" might be trying to get at if I were asking this as a hiring manager:

- Does the candidate have an understanding of their relationship as a SWE with surrounding roles (can include Product Management, UX, QA, Marketing, Customer Support, Design) and how communication plays an important role?
- How much of the software lifecycle does the candidate have a grasp on?
- How much of the technical details were they involved in and are they able to communicate them well?
- Do they understand their feature and the impact it had on other teams?

Here are two examples of quality responses from a new grad hire that I think highlights their potential for a cross-functional opportunity even though they themselves might not have had the experience:

- "I haven't yet had the opportunity to work fully cross-functionally myself, but I did write a major part of a feature my manager owned that did. I joined the project when it was in the implementation phase, and I had to ramp up quickly to understand the design, the user requirements, and the technical stack in order to help with the effort. I attended weekly cross-functional meetings where I shared status updates and resolved issues about the design that I identified while working on the feature. I also had to create a test plan for my portion of the feature for the QA team that they were able to successfully execute tests with. This work didn't impact another team directly, but it did result in 100 users using the new feature."
- "My internship experiences so far haven't required cross-functional collaboration because my projects were experimental engineering features. However, if I were to work with a cross-functional team, I would make an active effort to make sure that the technical aspects of the feature we were building were able to support the product and design goals, and if not, I would reach out to communicate my concerns and provide possible alternatives. Though my manager was not technically a cross-functional partner, the experimental engineering feature I worked on required me to work with them to figure out how our technical stack could support the user requirements that they gave me. The experiment ended up not being worthwhile to be released by my team, but if it was a worthwhile investment because if it did succeed, it would've impacted my team in X way."

Both of these answers demonstrate communicative initiative, an understanding of the software development lifecycle, and a contextual understanding of who the stakeholders for their work are.

Learning

Networking

To Read

Content associated specifically with mobile

Mobile

Questions that are good to ask when joining a team.

Team Questions

Assessing Companies

Mentorship

Software engineering work is rarely smooth and well-defined: There will always be crazy surprises. If you're in any sort of engineering leadership role (tech lead or engineering manager), you will need to become great at project management.

[Taro Top 10] Project Management

As a software engineer, you are going to work across many, many different teams and companies across your career. This means that it's vital for you to get good at onboarding, so you can hit the ground running at any new job.

[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer

We're in the middle of the "Content Renaissance" when it comes to engineering content. More and more engineers are building large audiences across platforms like YouTube, LinkedIn, Substack, and more. Learn how you can build your own voice online and how it helps your career.

[Taro Top 10] Building An Engineering Brand And Content Creation

If I told you that you can make $10,000+ just sending a couple emails, would you do it? Definitely yes right? This is why you should always negotiate your offers. Use this collection to learn how you can navigate these awkward, high-intensity conversations to get the pay you deserve.

[Taro Top 10] Pay Negotiation

A lot of software engineers get obsessed with learning new technologies, constantly distracted by shiny object syndrome. What the rockstar engineers realize is that learning how to learn is much higher leverage.