Read “Effective Java”, as mentioned. Ok, now do it again and write code samples or find ones in your code to fix to adhere. Alright, now codify the rules in your linter and make it part of the coding standard for your team (with whatever exceptions are a must). Read it again.

Read “Java Concurrency in Practice”. Explain to the most junior engineer you know why the idiomatic solution for double-checked locking works (with volatile, with local cached version, etc). Then explain that this is why you use memozing suppliers instead of hand-writing this. Write different concurrent code with native @synchronized critical
sections. Do it with methods instead of a brief section. Use ReentrantLocks instead. Now do it without locks using Atomics, Suppliers, etc. Ok, now with chained futures. Alright, do readers/writers. Ok, now modify criteria with deadline for readers to avoid starvation if many writers are queued.

Learn how to create type safe arrays of a type determines via reflection. Now never do that in production code.

Compile a class file. Use javap to disassemble the class file. Make changes, do it again, see what changes. Dex it for android, then use dexdump to evaluate the dexed version. Repeat all of these steps. Tell me why you can’t have more than 65536 methods in one dex file, and which instruction is the limiting factor.

Write a function in C. Have it add or multiply two numbers. Simple. Call it through JNI.

Read the source code for Java and Guava collections.

Oh, now that you’ve done all that: why do you care what’s under the hood? Are you needing to write your own JVM or a new GC, or needing to tune behaviors for a given workload? Do you just want to write idiomatic Java and know how to debug it? As mentioned above, this is X-Y. What do you want to achieve, and why do you think knowing java under the hood will help? 


Staff Eng @ Google, Ex-Meta SWE, Ex-Amazon SDM/SDE

Lee McKeeman

> Should I expect acknowledgment or appreciation from my manager for these extra efforts?

No. You are working more. They didn’t ask you to, and even if they did it was up to you. If you said you’re going to put in extra hours for a month to solve some huge problem and you do solve it, you will get credit for solving the problem, not the extra hours.

> Is it beneficial to communicate my extended hours to my manager…?

Probably no. I think you need to figure out if the team is all over-worked, or if everyone else is working sanely and you are not, and figure out why if the latter. Alex mentioned focus and efficiency. If your tasks are mis-scoped communicate that. You’re not getting a bonus for working extra hours.

> How do managers typically view overtime?

If you’re exempt, it’s not "overtime". But in terms of working many extra hours… I would prefer you didn’t. If you boost productivity in the short term, you’ll set incorrect expectations on what you and your team can deliver, and you’ll get stuck in a cycle. Your work quality will decline, your productivity will drop, and your team will be even more overextended. Work at a sustainable pace, and set expectations accordingly. If your workload can’t be done sustainably, that needs fixing. Again, if it’s just you maybe you need new approaches. If it’s your whole team you need your manager to know and fix it.

The technical leadership track is not about becoming more technically proficient in some stack, or knowing 3 more patterns, or nuances of your favorite languages compiler. Designing something important, and being able to manage dependencies, other engineers (and make their work better because you’re there) contributions, launch with clear metrics, and maintenance without a huge human cost matter much more than you, individually, designing extremely complex systems.

I will note that collaborative editors seem scary, and there are weird edges for sure… but most documents are written by one person. When there are multiple editors it is a few to a few dozen. I honestly don’t know what 500 people actively editing one document looks like, but that’s rarely v1. Ten in-flight edit operations with sane resolution mechanics is probably enough to get started. The scale for docs is a lot more about breadth (billions of documents) than concurrent editing of a single document. One of these is much, much harder than the other. And once you solve one for a smaller number of in-flight operations, scaling that may not be as crazy. Note I don’t work on docs, but imagine dispatching the 200 in-flight edits to different hosts in bundles based on nearness in the edit point, then recombining the results after these are all resolved, push that state back to clients, etc. I’m sure this isn’t how it’s done, but you don’t have to know either. You need to have common sense design skills for the domain you’re working in.

You listed 3 things you’re doing:
Org-spanning projects
Org-spanning impact (through projects or other behavior?)
Multiple mentees

Ok. That sounds like seniorish behavior. Are you scaling mentorship so that other senior or mid level engineers are learning from you how to effectively mentor, and setting up a cross-team matching program to get more people mentored and mentoring? You need to scale yourself. 3-4 mentees is a lot, but priming 3 new mentors every 6 months, then moving on to teaching the original batch to teach others in a year or so means multiplicative impact. What you do by your own hand isn’t enough, you need to multiply impact through systems, programs, and elevating others to do what you can do.

With org-wide projects… that’s cool. Did you design it from the bottom-up? How much responsibility did you have for delivery, how many engineers’ efforts were you directing during implementation, how many course corrections did you make to stay on track, how many stakeholders did you keep informed on a push basis, etc? The project matters, but your behavior matters more. How a junior, mid-level, senior, staff(+) handle similar work is different. Considerations are not the same. How it never has to be done again, or made less painful happens at higher levels.

Years of experience is a poor metric, but some companies will gate on this if there’s no clear guidelines and more senior people to assess candidates for promotion. Have you asked for differences between you current behaviors and what a promotable candidate would look like? Have you asked where your manager thinks you are, and how far you have to go?

I will note 5 years is… a good start. I know folk have grown to staff quickly. These wunderkinds are not the standard. I worked in smaller companies for almost ten years, then worked another 8 or 9 years in FAANG before getting to Staff. While YOE is not a good proxy, I think you should be realistic about your progress. What opportunities are being gated by this promotion? What will be different if you get there in 1 year versus 3 years?

Your friend/manager sharing performance comments about other engineers is totally out of line. It’s already dicey that you had a personal relationship, they interviewed you, and they are your direct manager. I can imagine the senior most engineer/lead being given some direction on who needs help, etc., but just tossing out “yes, S1 is underperforming” is really problematic.

M+S1, Y+S2 :: M+S2, Y+S1 :: M+Y, S1+S2. These are the possible permutations, that’s it. 3. The manager not trusting you, so not giving you a meaty project seems unlikely. They aren’t giving S1, who they have determined to be an underperformer, an important project. 1/3 of the time, you’ll be with S1, the rest you’ll be with others and likely get better work. Have you told your manager you think you were given the less interesting project and want to stretch on more ambitious projects?

S2 has the red flag of saying “You look like you can’t code”. That’s super problematic. I would recommend checking in with them to make sure you’re progressing in their opinion, and actively seek constructive feedback. If they are demeaning, that has to be addressed. If this was a jerk thing and they move past it, it’s not good but survivable.

I don’t intend to criticize, but if you’re referring to folk in a non-gendered way, just use they or their name/“label” (Senior 1) if “they” would be ambiguous. S1 got one “his”. Generally I appreciate degendering, but I can’t “skip” the paired pronouns and it’s a speed bump.

Focus on your manager’s feedback and direction. There’s nothing you can do about your manager’s feeling about S1. If S2 is a jerk again, it’s worth mentioning to your manager. Focus on what you can control, which is the work you do.

This is not a make-or-break conversation. You don’t need to impress them, be a person. Ideally you sow seeds of an ongoing relationship. Even if it’s not formal mentorship, being able to ping them with quick questions, whatever… that’s real value.

The “easy” things to ask would be things like “What do you wish you knew when you first started here?” and “Who do I need to know to be effective?” and “What is the worst code we have, and how can I learn it?”. But really… you don’t know enough yet to ask any really probing questions. Most important is “Can we meet again in 6 weeks when I’m terribly confused?”.

If your EM cannot give this person critical feedback on this negative pattern of behavior, they need to escalate. This is not acceptable.

You COULD ask the E6 where in the issues delegated to you that you can find the required information, as it feels as if you should be able to find this yourself based on their response to questions. If there is none, you can then ask “is there another method you’d like me to use for knowledge transfer on tasks? Right now I feel that I’m bothering you when I ask in X or Y forum, and I’d like to smooth this out”. Something like that. But I feel like this person has… something else going on. I think they have technical depth that their level requires, but does not have the soft skills required. They need support in developing this. Your skip or a more senior IC in the org may be able to help, but this person needs to accept they need the help. Feedback from a high enough level may get them there, but it may not.

You can also leverage your EM and ask them to triage these issues coming from the E6, with a standard format that includes the details that tend to be missing. If the E6 won’t follow the process, then it has to get escalated.

It is my opinion that someone at this level helping a more junior employee through a sensitive HR situation is sort of part of the job. Yes, it was nice they did this for you, who is in another org, but their impact should be very broad.

This feels more like you should write and send a hand-written note thanking them personally. From there, sharing with their manager or HR in their space seems too convoluted. At most you could say “I had a very difficult and sensitive situation I cannot discuss explicitly, and person X went above and beyond to aid me in navigating this. Without help on this matter &lt;fill in, would you not work there?&gt;.” That seems to cover like… a great thing was done, but it cannot be discussed.

It sounds very, very difficult and am sorry you and your team are in that situation. The old team didn’t hold up because what is being asked is impossible. Step one is to protect the team’s ability to function long term, and that means working reasonable shifts and resting. If this means, for a short while, you have one person from each discipline on-call so they can be putting out fires, and others are resting, then there’s “recovery days” following on-call, do it.

Automate, and simplify the hell out of things. Do things run out or disk space? If more disks can be thrown at it, so that. If not, rotate anything that uses space off aggressively and automatically, and have alarms that escalate as the disk gets lower and lower. Have fix-it scripts to aid in cleanup if a human has to do it, but make that the exception. If the systems you support are unstable over time, look into rotating servers out of the active pool and restarting services however often it takes until you can figure out what is leaking memory, file handles, or whatever else causes time-impacted instability.

Ideally I’d try to have 3 designated work types:

- On-call
- Automation/operational tools
- Core systems stability

It may not mean that every week people swap, but you need to guard people’s time to be able to focus on fixing the sources of the fires, not just putting them out.

On-call should be generating hash marks every time a particular issue occurs so you can have that guide prioritization of tools to automate or simplify repair, and fix root causes.

You should invest in growing your ability to handle greater complexity and more ambiguity. You should invest in growing soft skills, decomposing work streams, mentorship, and other soft skills.

In 5 years whatever tech you invest in will have changed dramatically. How you manage complexity, ambiguity and interpersonal communication won’t.

1. If it’s 5 per week, I feel like you can answer. “I’m not in the market right now, but good luck on your search!” Is easy. If you want to be specific “I’m not interested in consulting roles right now, but I appreciate the consideration!”. That’s 30 seconds. If you do 5 at the end of the week, that’s 2.5 minutes. Recruiters are valuable connections to have.
2. Where you’ve worked may affect recruiters, but once you get an interview (via a recruiter connection because you don’t burn bridges), as long as you’ve done complex work, and have the right skills, the interviewers or selection committee won’t care about this Tier stuff.

If there are two people that can do this work, you and an E6, and the work that needs to be done is “lower level”… it has to be done. You can try to decompose it so you can both knock it out in a week or two, you can have a “get it done” rotation by project or month or something… but the bottom line is they have seniority. You should be shadowing them on the work they are doing, contributing where you can, etc. but sort of have to accept they are better suited to take on that work now. There’s times that simply require delivery, and times you can stretch and grow. With two iOS engineers, though, unless y’all move to a shared code setup that allows other devs to contribute, you cross train, etc there probably isn’t ever going to be a time you’re not building workaday features.

It sounds like hiring an E3 or E4 isn’t an option, not sure about cross training, but basically this isn’t a team to grow on with the current composition. Maybe you can build something that allows no-code/low code feature addition to accelerate that stuff, but that seems lofty.

Your manager should be handling this. If there’s a normal on-boarding that’s companywide before you join your team, maybe they are waiting for that. Ask them! Your manager is the entry point for all of this stuff.

In terms of what YOU do, write up your intro. What do you want to share about yourself? Any specific tech things you care a lot about? What made you want to join PayPal? What about this team? Any hobbies you’d want to share? I go for humor but that’s not strictly necessary.

Beyond that, you should definitely be in rooms and meeting invites soon, but if it distracts you from onboarding it’s fine to wait until your “team join” date.

beyond that part of your onboarding to the team should be to meet everyone 1:1. I just do it for face time, getting some notifications and expertise out of folks, etc.

Just saw this. If you’re still struggling maybe you can get a corvid for a study buddy: <https://www.beautyofplanet.com/scientists-find-crows-are-capable-of-recursion-a-cognitive-ability-thought-to-be-unique-to-humans-and-other-primates/>

I worked at Amazon as an L5 engineer, then L5 software development manager, then promoted to L6 software development manager. As such, I only worked in a mid-level engineer role there. What is going to impair my ability to answer exactly as you want to is I didn’t really do what my role entailed? I was glue, and sometimes that was coding, but a lot was being a de facto TPM, solving one big thing that impacted a lot of teams, and other weird things.

I will tell you what I saw as more common for the role. At first in video the L5 SDEs were the senior people, even if it’s a mid-level role. There was one L6 that was drifting away, and 3-4 L5s, with… I dunno, 20-25 L4 engineers we supported. That ratio meant a lot more support via code review, design review, triaging issues, validating test strategy with QA, arguing with counterparts on the devices side about requirements, and so on. I would expect a TPM or senior engineer to do a lot of those things.

In my second org, things were a little more normal. L5s were the coding workhorses. They did design some subsystems, led projects with a couple of other engineers on them, did some cross-team work, but still had to do a lot of the coding. The L4s were slower, needed more handholding, and so on, though many grew very quickly. I don’t recall a hard breakdown, but would say that meetings were 8-10% of their time, reviewing code 10-15%, reviewing designs 3-5%, planning 10%, designing 1-3%, oncall/operational support 10%, other weird overhead 5-10%, then coding in what’s leftover (37-53%). As they grew toward senior, the coding shifted down, mentorship, reviewing, ombudsperson work with other teams would go up.

Maybe this helps?

First: I’m sorry you’re being treated this way, it’s really outrageous. Consider carefully what you’d like to happen now. If the manager stopped and apologized, would that be enough to reestablish trust, or is it permanently damaged by their behavior to date? If trust cannot be repaired, you cannot work for this person going forward. If you’re wanting to take action to protect others that’s admirable, but you need to take care of your own mental health first.

So now action steps. Document these things, with quotes or very near quotes/paraphrasing. Having a paper trail no matter what happens next is critical. Check in with people that have witnessed this that you trust will keep the conversation private. Do they see what you see? Have they experienced something similar? You are impacted by this behavior, but others being able to back you up goes a long way if you formally complain. Have someone else you trust see the paper trail as you’re building it so, if things come to a head, it can be shown that you did not make all of this up on the spot.

If you cannot find a new team, or some freeze or whatever keeps that from happening, looking outside is a good idea. Just do that anyway, so you have options.

In terms of layoffs, your manager having a chip on their shoulder isn’t great, but raising a red flag and then being retaliated against for it would likely be a much more serious issue than the behaviors themselves. This is a main reason you keep your file with someone copied on it with clear dates, etc.

Beyond that I’m not super sure what to tell you. Having 1:1 shadowed secretly or whatever to have this witnessed is unlikely to happen, you recording without permission is a bad idea and maybe illegal, etc.

So the short version is “get out”, the long version is document and cover your ass as thoroughly as possible.

I don’t know the very best resources for this, but would mostly say that having an ideal problem is often the best way to start proving this out to yourself.

You mentioned a lot of use cases, so probably picking one of those would help. I frankly fall back to recursion last when an iterative solution, often with a queue, cannot be used. Recursion has the messy issue of (in most languages without proper tail recursion and things) burning stack space, and when operating at scale that often isn’t workable. Trampolining is a technique that is rarely employed (in my experience), so stack exhaustion is a big risk.

Anyway! Let’s say you’re doing a binary tree exploration. You are passed a node that’s the root of the tree. Your exploration will either go right or left. Once you’ve picked which one, you are going to begin a search on the right or left node. This is the same work you did on the root node. The same method can be used. So now you do a search starting with left, then pick which of its children to explore and call the method with the appropriate one, and so on.

The “normal” setup for recursive functions is to have one or more base cases (null node, node with no children, node that matches search criteria) which do NOT call the method again, instead returning a terminal value and one or more recursive cases that DO call the method again with different parameters, often returning its result.

Things can get tricky when you need to construct a result based on the full recursive path, if you need to create a set of results (ie multiple matches), and plenty of other situations without a single return value determined in the base case at the deepest level of recursion. I would say that is “next step” once you gave the basics down.

You generally DO NOT want to store any external state. Your state is the current status of the stack, or possibly (like a visited set to break cycles) some state passed through as a parameter through the call chain.

I would start with something like a Binary Tree Map, where keys are the sort criteria of the map, and each node contains a value. Your node has a left node, right node, key field, and value field. The method you build is “getValueForKey” and accepts a base node and a key. It returns the value in the node with the given key, or null/empty/throw if there is no node with a matching key. Write the base cases first:

- Null node input, return null
- Null key, return null
- Key matches node key, return node value

Then the recursive case:

- Call the method itself again, returning its result, and passing the right or left node and the same key

Once you’ve built this you can write additional methods like an insert of a key/value, that returns the old value if it’s being replaced or null if it’s a new key. You can write a remove that unlinks a node (but is a little trickier, because if you’re removing a node in the middle of the tree you have to merge its children. The easiest is take the right node, then descend the right side of the left node until you get to the bottom and place the old right node there. This definitely unbalances).

Eventually you’re going to be able to enumerate base cases and recursive cases when considering these problems. Sometimes you’ll need to have an entry point method, then a recursive helper because you need to have helper parameters like the visited set that you shouldn’t require a caller to provide.

This is rambly. You’ll probably get a clearer answer asking ChatGPT.

This is tricky territory. Someone is going to feel excluded. You say senior engineers, but if a L62 is leading a team, do they get to come or not?

From there, direction can be challenging. Is this social? Is it scrum of scrums to share what major progress is being made and any overall blockers to see if anyone can help? Is it to talk about cross org initiatives and how to coordinate (separate from kick offs and XFN meetings)? Is it to drive things like engineering productivity, engineer satisfaction surveys, cross-org hack days? Maybe process things like mentor matching across teams or full-org design reviews or senior-eng casual coffee chats?

If you actually feel like one or many of these things would be useful and truly the engineers at L63+ are the right folk to drive this (versus TPMs, involving eng managers, etc), then maybe this is a good plan. Ideally, though, anything you discuss and decide should be actionable by members of this group, otherwise it is just an exclusive club that generates work for other people and that feels bad.

I think discussing challenges that may be hard to talk about with managers in the room (prioritization issues, difficulty with randomization, etc) could be helpful.

From there, like anything that is expensive (this meeting is expensive once, very expensive if reoccurring more than 2x per year), you should drive consensus that it is valuable to the org and to the individual attendees with a doc. Write up goals and non-goals, what would be addressed in a one-off, or that needs to be addressed on a reoccurring basis (but i would honestly defer the decision to have it repeat), why this forum would be the best way to address those things, what some alternatives are if this isn’t adopted, etc. Have one or two peers review first, refine from their feedback, and if they buy-in ask the group to review it with a one week or so lead time. If they buy in (like any doc), then proceed with scheduling a single occurrence. Have a clear agenda, drive clear action items, and afterwards you can write up a postmortem and get input with a survey (maybe two questions, did it have value, would reoccurring instances have value) and decide how to proceed.

This could be revelatory and very impactful for the org. It could also be a huge waste of time. Try to work out if there is at least strong potential for the prior before you prove the latter.

Rahul already hit on most of the high points I’d suggest myself. One thing I’d state slightly differently, which is: If you take on the “personal projects” or “initiatives” and devote X% of your time (whatever you and your manager decide) and shrink enough glue work to do that, what gets dropped and who is going to pick up that slack?

Ideally you’re working your way out of a job in as many ways as possible. Don’t do anything for an extended period of time that no one else can do, be partnering and passing things over. Run one book club, then pass MCing/organizing to someone more junior for whom this team impact actually moves the needle. Run a knowledge transfer then have it recorded and good documentation, and let someone else take on being the point of contact for this. Whatever you are good at that others aren’t, it is your job to teach and transfer.

From there, recognize that you are growing and evolving, and as Rahul recommended, make sure that growth is in a direction you actually like. You shouldn’t be coding more, but coding critical things very efficiently. You shouldn’t be designing all of your teams modules, you should have best practices and a review process that puts guardrails on everyone else doing that. Eventually you should be working to spread this to other orgs if it’s effective, or find how to adapt your process into a common framework. It’s a scaling game now, and you don’t scale by coding 10x as much.

You said you shared a file with your accomplishments, so I thought this sort of… covered what your boss could share with others to try to “sell” this. The email seemed like a sort of… documentation thing. If the file is a punch list and you think narrative form would be more convincing you could definitely write that up.

Is it important to you that you do not improve managing up and working well with others? Has every one of these interactions been flawless so it is impossible that this is legitimate feedback? Do you have a lot of reliable witnesses to all of them that have confirmed this to you?

It is unfortunate that a concrete example wasn’t provided. Regardless, it is still a gift to have this feedback because this seems like a clear blind spot you have. Others are observing a soft spot, letting you know, and you aren’t wanting to hear it. Do you believe this is being done dishonestly as a personal attack or to sabotage you?

Late feedback is better than no feedback. Even if there were other opportunities maybe recent events and corroborating details from others made this bubble to the top in terms of priority addressing it.

Would you have preferred not to be told? are you wanting advice to help “change” your manager’s perception of this in you without changing your behavior?

The general answer is to ask if they block this critical work, or if they are nice-to-have and can be tackled separately in a dedicated CR instead of adding complexity to what you’re already doing since they are out-of-scope. Rarely does someone want to be on the hook for blocking something for superfluous reasons and have their name attached, so they will back off. You should create a ticket or ask them to in order to track the follow-up, but you don’t have to own it and they can help prioritize it if it’s really important.

In terms of saying “some other team owns this library” I think it’s fine for you to open an issue against that team, link their comments, and CC the commenter. This shouldn’t take long, and doesn’t mean you own it. Pointing them to the actual person requesting helps, since it is really their ask.

Leading by example is a good policy but I wouldn’t try to get out of things by showing that the requestor isn’t following the rules they espouse. This can only cause trouble. What you can do is ask if this should be a part of the team’s coding standards, and create an issue and put it into meeting notes for a team meeting to discuss if that is a standard you want to establish. If so, then this person is then more beholden to the standard. If not, you shouldn’t be required to be the only one doing more than required.

Can you address your ideas to one or both of these engineers separately and garner support before bringing it up in a meeting with both of them where they may be vying for… I don’t know what, attention, respect, power? You attempting to be a third voice and get your ideas heard and accepted in an already contentious environment doesn’t seem like a recipe for success.

if your boss specifically wants you interceding in the conflicts between these E6s, I don’t think your boss is doing the right thing. They should be figuring out mitigations on their own. You can always note in the meeting that you are thinking through an alternative idea and will send it out after when you’ve fleshed it out. That way you can show initiative and that you’re working through things in the meeting without the discussion happening in real time with this jockeying between leads.

It feels a little silly to me, but I’ve never been great at these sorts of things. My biggest “raises” have been getting top of band new stock grants, dramatic stock growth, and changing companies. I guess early in my career I had large raises by percent, but I was making very little to start with.

Maybe this “write a letter” thing is effective and I’m just out of the loop, but I am not sure the goal. Like you get the rationale back in writing? Or… they… can’t deny you asked them?

Are you delivering 20% more value than you were when you got your last raise (not like this really determines anything, just don’t know what is driving this ask for you)? How big of a raise was it?

What is true is that you are very unlikely to get this raise even if you send the request as a singing telegram or written on a delightful red velvet cake. If you’re paid below market, getting a market offer and either taking it or leveraging it is probably the quickest way to increase your comp. Even trying to get a counter seems less likely at a company where your tech skills and what they cost are a liability not an asset when they look at the books.

Someone is expending their energy, and taking a risk of negative pushback and hurt feelings, to provide you with information that will allow you to get better, with no benefit to them.

Not telling you is very easy. The easiest thing in the world. There is no (or very little) risk in keeping quiet. Giving someone critical feedback takes courage, preparation, and finesse.

When you are getting the feedback, it is not the time to respond. You can yell, cry, swear, whatever later. In the moment you can ask some clarifying questions like “what specific situation did this come up?”, or “Do you have any ideas of how I could have done that differently?”. Otherwise, so not be trying to synthesize or process the data in the moment. You need to be a passive observer. Take the notes and really process and make a plan later. Nothing you say in response (except “Thank you”) isn’t really going to be helpful for anyone.

it is also fair to seek a second opinion, as you may exhibit some behavior in certain situations, which changes how you approach it. 

Amazon Engineering ICs:

- L4 - College hire, or little experience, responsible for self with help. Code, start to work on small features, design very small subsystems
- L5 - Workhorse, huge in terms of scope. Starts at self-sufficiency and some team impact, grows to system ownership and design, team leadership, cross team impact.
- L6 - Senior SDE, leads one or multiple teams. Owns large pieces of infrastructure, designs new large systems. Impacts an org between 25-50 engineers at the high end.
- L7 - Principal. Rare. Councils directors and VPs on tech, owns multiple large systems driving a business unit, impacts 50-100+ engineers.
- L8 - senior principal. Launches huge systems no one else has before, impacts large lines of business, 100s of engineers. Defines tech direction for large parts of the company
- L10 (9 doesn’t exist) - VP, distinguished engineer. Industry leaders, long term company vision. James Gosling was hired into this level, as an example.
- L11 - SVP, first promotion to this level was recent, James Hamilton. Advises Jassy, etc.

Managers:

- L5 - Rare, transitional. Manages a small team, limited scope and short term vision
- L6 - general line manager, manages 2 pizza team. Rarely manages managers. Medium to large scope, longer term vision
- L7 - Senior SDM. Org leader, manages managers and senior ICs, large scope, org vision.
- L8 - Director, large org, sometimes large engineering org, or running a business across disciplines (GM)
- L10 - VP, strictly engineering isn’t as common anymore, but would be a medium-large business unit’s whole engineering org. AWS’ CTO Werner Vogels is at this level.
- L11 - SVP, not sure if anyone that only owns engineering has this job. Seems like “no” if Vogels isn’t there.

I don’t have the energy to write up Google or Meta. They have more levels of engineers, slightly more granular but not really. L3 is smaller, than the levels sort of “bridge” Amazon’s. L5 is senior, L6 staff, L7 senior staff, L8 principal, L9 distinguished, L10 fellow at Google. Meta is pretty similar but are weird about leveling, seems to top out at 9, say senior at 5 but it’s murky. Management I don’t have extensive knowledge of, but Meta it’s pretty similar to Amazon at L6/M1, M2 senior, D1 director, D2 senior director, then there’s… 2 levels of VP. Google is similar. L7 senior, 8 director, 9 senior director, 10 VP, 11 SVP.

This being your new manager complicates it a little, but not much. People get sick, have parental or other leave, go on vacation and so on. Managers leave a team or company and their reports roll up a level until they are backfilled. It’s pretty normal, in my view, but understand it may be unusual for you.

You won’t be able to establish immediate rapport with your new manager, but you CAN still be checking in with them.

Create a document that is shared with your director and your manager. Write up what you are working on, their priorities, and any questions or concerns you have. During 1:1s with your director outline the conversation there, with any action items for any of the 3 of you, and tag them with @ to ensure they know and are notified, and can find it quickly later. Ask your manager to follow up on items they are tagged in, and ask if they need additional call outs in email or chat when they have new questions to answer or action items assigned.

If your director gives you any new tasks or reprioritizes your work, make sure to clearly call this out, and tag your manager with INFO so they know it isn’t an action or question for them, but just keeping them explicitly informed if your work changes. If you want, you can keep a separate work log shared with both parties to share daily or biweekly notes of what tasks you’re working on and progress you’re making.

You may want to (if you don’t now) have the team keep notes during standups, and they can be shared with your manager. You could volunteer (or see if you want to rotate through the team) to summarize these notes each week to give a snapshot.

Beyond that it seems weird your manager won’t stay up a little later to connect with you during your morning at least once or twice, and strange you aren’t entertaining doing the same to connect during their working hours. At least just once or twice to chat.

The habits you establish can still be useful after your manager returns. You’ll still have 1:1s with your director at some cadence, and you and your manager can keep better track of shared tasks and things.

“I’d love to help, but can presently only allocate time during my office hours to consult and can’t accept new projects without them being prioritized through the intake process here (link), and having one of my current priorities superseded. Any additional out-of-band work threatens my current deliverables and I am not able to delay these without explicit approval”.

If it’s really higher priority than your current work they can prioritize it through a normal process. If it’s not, you shouldn’t be doing it. Helping people do things the right way is still helping them. Randomizing your own work to serve every random request isn’t responsible.

If your team handles high priority requests during on-call, you can also refer them to on-call with the caveat that production issues will be given preference, or let them know when your next on-call shift is, but this is giving them too much power IMO and any high-pri things that on-call would handle should still follow ingestion and prioritization process. Sideband work sources are a bad time for everyone.

This isn’t completely clear. You said you’re working on a project with a sister team already. Aren’t you already working across teams?

Why not start with your manager, even if they don’t run the project itself? They may not be able to allocate the specific work, but could determine if this is how they want to allocate your time and communicate with the right people.

Are you going to strip all years of employment, duration of employment, etc?

I get it, age discrimination is real, but people are going to work out your old if you’ve been working professionally for more than 5-10 years.

I think it’s irrelevant, I’d tell people to take it off resumes, but… hm… if people want to know they’ll work it out.

I don’t follow how the math is working. To have 12 hour follow the Sun shifts, you need two people on call. To have two week shifts with 12-24 weeks off, you’d need between 14 and 26 people evenly divided on opposite sides of the earth. I don’t know how 4 people (do you mean adding 4 to an already large rotation) gets anywhere close to this.

Staff SWE at Google, ex-Meta, ex-Amazon

I like this idea in theory, but it may not work in this case in practice based on where your team is located.

US + South America: UTC-8 through UTC-3, so 6 timezones.

Then there are “a few QA engineers” in India, UTC+5.5.

To follow the Sun in terms of not being woken up at night, but more commonly to only be on-call during working hours, you need much broader distribution of personnel or people with wildly different sleep schedules.

Just to demonstrate:

We don’t want anyone on-call before 8a and past 8p local time. I think 3 8 hour shifts is actually correct, but I’m being the most generous. If pacific time starts at 8a, this is noon UTC, which we’ll use to measure our coverage. If eastern Brazilians then work until 8p local, this is 23:00 UTC. We have covered 11 out of 24 hours. If India picked up at 23:00 UTC, that’s 4:30a local time. Even if we said their shift was 4:30a-4:30p local time, we’d still have a coverage gap for an hour, and we’ve made the “few” engineers in India cover really sad on-call hours every day, while the shifts of those in the americas, because presumably there are many more people, are far less frequent. Yes, you can start west coast at 7a and have full coverage, etc. but again… your distribution doesn’t work. Pacific, GMT, China are spaced 8 hours apart, so if your team was evenly spread to those three places this would be much more tenable.

maybe slim down goals and see?

For writing code, which is most of your job now, 10wpm or something is likely fine.

For writing long documents touch typing is marginally more important, but I still think that at levels much slower than where you are the typing itself isn’t the limiting factor.

Even for text chat, if speed is an issue probably switch to audio or video. Quick questions are fine but long conversations that would demand fast back and forth it’s likely a bad medium.

What was Stephen Hawking’s typing speed? Bill Gates’? Linus Torvalds’? Grace Hopper’s? Ada Lovelace’? Bill Joy’s? Does anyone know or care? Some of them may be at 100wpm, some 1wpm and it’s irrelevant to impact. Don’t learn to type faster until you’ve proven it’s clearing a bottleneck more severe than any other knowledge you could acquire.

No one is unimpeachable in all areas. Even amazing people could have greater impact or better balance priorities. What may be true is you aren’t exposed to all of these things or may not know how to identify them. That isn’t an insult, that’s a realistic assessment.

Is on-call a non-issue? Even joining it when you’re new?

Do engineers feel empowered to push back on unreasonable goals?

Does the team feel like the right balance is being made between paying down debt and new work? (Even if the right balance is there, the manager isn’t communicating well if the team disagrees)

Your experience is a really great onboarding, but there’s like 100 other dimensions and concerns, from cross team collaboration to planning to fighting for headcount (or not to lose it), and so on. Again, don’t expect you’d be exposed to all of it, but there may be a few things that are suboptimal you have seen even if they don’t seem egregious.

If there is no negative, the critical feedback can focus on how they can spread their impact if they truly are the Kwisatz Haderach. Does your team have an amazing planning system that others don’t use? Why aren’t they selling it?

You won’t get any negative blowback if you give no negative feedback, but it’s harder to include glowing feedback when there was no critical feedback to balance it. I’ve had to exclude positive feedback because no critical feedback was given.

I would further add that you should have workstreams broken out, then detail estimates with level of confidence for each. If there is a workstream with significant risk or uncertainty, don’t give dates after an initial milestone or design spike, or give them 0% certainty, and specifically layout that this is the riskiest part of the project, and most likely to require more time. Breaking this down much more into smaller milestones that have decreasing certainty as they get further into the future can make it easier to catch if it’s slipping early and try to intervene.

Why are you working on this project? Did your previous project get canceled? Did you “finish” something (does that happen?)?

It feels odd, for sure. Are you the seniormost engineer on the project? Have you had a frank conversation with your own leadership and the product owners and their leadership about your feelings? Why do they believe so strongly in this that it is funded?

From there, how do you hedge if this isn’t successful or a good market fit? Can a small-scale market test be conducted with a fake or prototype to see if people actually want it? Is there UX research to back up the need?

If you are willing to “bet your badge” against it, and you can’t make the arguments to convince others to abandon this project, you need to leave. You may be right, but if a decision is made and you will not commit to it, your presence is poison. I’m not saying you’re in the wrong but it is sounding like nothing can be done to convince you this is a good way to spend time.

The last thing I will bring up is how much tech debt could you possibly insinuate into the scope of this project (we must break this dependency to support this feature, we need a more extensible plugin system, we have to make this event-based instead of blocking) such that even if the feature fails, you’re leaving the code in an unquestionably better condition than when you started, which is still a win? It may not be possible with aggressive timelines, but it is another hedge to make lemonade.

I can’t answer this fully, only say I couldn’t fit at Meta after a long tenure at Amazon and left after a year.

Boomerang to Amazon with new comp bands will likely get you $500s which I imagine would be commiserate with Meta now. Finding a team where you’re excited there could change your outlook, and you having tenure and promotion there may take some “prove it” pressure off. L5 is debated as terminal, but L6 is unquestionably terminal. You don’t need to stress to get to principal. Your pay may dip into the 400s (or high 300s? I don’t know bands exactly) after initial grant if you’re not getting high ratings, but if you’re OK with that it is likely fine.

Getting feedback from seniors doesn’t seem the same as your project being led by them. They will be overseeing everything, even if it’s led by an E4.

Get a mentor outside of the team. I would say a tenured E4, or newish E5. Tenured E5s might be able to focus some time for you, but they should be getting tenured E4s to E5. Ask if one of the E5s on your team can be a sounding board or ramp up buddy or whatever, that casts it differently than mentorship. Say you will rely on the project lead, but also want a focused outside perspective.

Getting these different sources of feedback will be helpful, versus relying on a single project lead to be your only source (who may also have a skewed opinion because they are so deep in the same project).

I want to note that 30% senior, 50% mid, 20% entry level is a fairly senior leaning team. Your classification of “only” 30% seniors seems a bit skewed. Many teams are lucky to have one or two seniors.

You want concrete progress. It may be better to state a goal in terms of testing, I.e. automate testing for all issues discovered during Q4 rollout attempt, do small population testing to identify new issues, and have full deployment plan established targeting end of Q2’23.

saying you’ll be x% rolled out isn’t something you can take solid actions to achieve. You don’t know what issues you’ll uncover, if you have to roll back, etc. See if shadow testing (like doing the work of the feature on a segregated fleet, in a hidden place, whatever) can help you gain confidence without user impact. Also work to set acceptable regression values and time frames to address them. If 0 regression is acceptable you will find yourselves correcting or optimizing things far outside of scope to compensate and it will snowball.

How well you perform at your current level is (or should be) tangential to your readiness for promotion. The “obvious” case is someone overperforming at current level tasks, while also performing on-level at next-level tasks. That’s not the only formula, though.

Getting promoted requires doing two jobs anywhere that promotions are trailing (promoted once you’re doing the new job). Being excellent at your old job and good at your new job is hard. Sometimes you have to be good at your old job (solid delivery, but not changing lives) to have the time and energy to be good at your new job (doing things that aren’t measured or required in your current job).

That’s a bit of a tangent, but if your manager has said to get promoted you need a high rating I would be puzzled.

Anyway! Most people get promoted then leave a team once it’s locked. It feels “safer”. The problem I see is a team that is unable to provide the scope needed for everyone to move up, so waiting around may actually delay promotion for some members. I would strive to understand what the gaps are between your current body of work and the next level. Is your manager supporting the promo and do you have work that fills the gaps in the immediate future?

You should have any next level work you’ve done clearly documented and supported by managers and next level peers. That should be portable. The question is just the gaps, and if it’s faster to fill them on your current team, or if you could move, ramp up, and fill them elsewhere.

This shouldn’t be mysterious. You and your manager should know the gaps and strategy to fill them, half they intend to promote you (or you apply? I can’t remember how Meta does it), and so on. If none of this is clear, you are not on track to promotion. When you talk to new potential managers you should be laying out gaps to promo and getting their opinion on your ability to fill them and possible timelines.

If your current team has the work and your manager supports your promotion, sticking around will likely be quicker. If not, leaving might be better. If there’s outside factors like you hate your team, manager, work, etc then leave and don’t worry about promo impact.

A lot of companies expire email and chat after some amount of time. Many do not expire calendar events, even from the distant past. A calendar invite with yourself can serve as a makeshift notepad.

Anyway… if you want people-focus, more than project focus, if you can export your calendar and get it into a text format, you may be able to do a frequency map of folks you’ve met with. You might filter your immediate team and just name them directly.

Once you have that, you can either make a list, or do something like a word cloud emphasizing those you’ve worked with most (or met with at least).

Beyond that, people love stories. If you take 5 (or 10 or whatever) people with different types of relationships (team mate, mentor, mentee, partner team member), you can write up as briefly as possible your best memory of working with them.

From there, if it’s authentic, you can note in passing (“While I’ve worked on amazing efforts like X and Y, what matters most…”) projects, but assert that the people you have worked with, taught, learned from, etc. are what have meant the most to you over the last 5 years, and those memories will stay with you even if every work item you ever completed is deprecated and gone, etc.

I like to sprinkle humor in to really line them up for a gut punch of emotion like that at the end. Gets their guard down.

I can’t believe people know the names of these things, I just can’t memorize that.

[Here](https://www.linkedin.com/feed/update/urn:li:activity:7004456645527298048?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7004456645527298048%2C7004477765949292544%29) I discussed this *today* in a LinkedIn comment, and someone else shared the name of this pattern. Regardless of me thinking this is a good approach, I don’t know if you’re “there”, in terms of being ready to start pulling the system apart.

I would start with documentation. Both vertical, and horizontal. By vertical I mean for key functions (and eventually all functions) document how a call propagates through the system. What methods are called, what they do, etc. for horizontal, after a few vertical steps, see if you can start classifying things into layers like storage access, business logic, transforms, UI generation, etc. It may be too messy and smeared around, but at least give it a shot.

Start small, and try to make changes to how something displays. Add a small feature that makes a write to a new field/table/whatever in storage. Be documenting everything. For these exemplar changes, link your document to the change lists. If there’s a small team, divide and conquer these tasks and knowledge share and document the whole way.

Once you understand the system really well, it may be worth identifying the hardest to understand or most error prone area and start figuring out how to isolate it. Does it do too much? Can you carve off an individual responsibility and just move the code, don’t rewrite it. If you can isolate it gradually, it may become easier to understand and fix.

Once you’ve decomposed the worst part, it will likely be easier to organize the less messy parts as well.

Wherever you can, once you understand what something does, add tests. The more you can test individual pieces the greater confidence you can eventually have replacing them. Do not replace anything without thorough testing, and having a plan to revert/redirect traffic.

Why you want to rewrite it needs to be clear, though. The act of reimplementing is expensive, and can carry a lot of risk. Good tests help, but don’t ameliorate the risk. When you finish, in the best case, you have something that works the same. It is a significant investment, which can only pay off if a lot of people save a lot of time extending it in the future. The more granular you make your changes, the easier it is to replace things while continuing to use the system and add features to it. You will not get dedicated time to do the rewrite, you will need to keep adding customer value in the meantime.

Have a list of the work, and track it. Be able to know how close done is. When new feature code is added try not to implement in the existing outdated code, try to make a shunt into that code that calls out to something new. Try not to dig the hole any deeper.

Regarding format, that may be more company-specific but if I were reading it, I’d want it laid out in:
Section header, Monolith Deprecation
Summary paragraph detailing the big picture
Numbered list of each contribution, API issue corrected, each time-saving action. Each of these will have problem/action/impact for that one thing.
Closing summary of the overall result/sum of impact.

This may not be best, but I would prefer context and be able to see detail as well as big picture impact for this project.

What would have happened if you didn’t exist? You weren’t there at all. The team needed a loaner because they lacked capacity. If you didn’t bail them out, what would the impact be to the timeline of the migration, or if they prioritized it over other work, realistically how many engineers for how long would be pulled from other tasks? What would happen to the things that were deprioritized?

yes, this will be speculation and estimates, but the numbers likely exist because the team said “we can start work on extractions in Q2 2023” and someone said “what if we loaned you an engineer and they only needed support” and they agreed.

If you only did what was committed, and didn’t take on the rework of the API, how would it have impacted the migration? Could you have done the extractions but it would have taken longer, performed worse, generated tech debt? How much would that have cost to fix?

The deadline slipping doesn’t sound like it was because you made poor decisions. Your input still led to shipping, and I imagine without you the slip would be worse. Quantify it. Ideally quantify how you impacted the remote team’s design and vetting process, too, since a substandard API was delivered.

It’s hard to know what your product or products are from this, and if it’s one product per client, so it is “theirs” and you are doing custom development, or if you have a couple of products and clients set the roadmap on new features.

Regardless, know this isn’t unique. Many companies with direct customer input to roadmap or prioritization run into this. It gets more difficult when a few customers are responsible for significant chunks of revenue. The less diverse revenue sources, the less control the company has over its own destiny.

So are you just doomed and you should give up and be blown by the wind every time a user changes their mind? Eh, probably not, but it isn’t a dev-only fix. There are a lot of forms of discipline that can help, but if your account managers/sales support folk/executive team aren’t on board and willing to push back, have requirement freezes, have a minimum time between last change and development start, and so on then what dev does may not matter too much.

One possible system is to grant individual customers with a certain number of work units per quarter or half or whatever. Whenever you start doing any kind of work, it counts against their credit even if they back out or change their mind, and how they use their work units is committed by half, etc. Ideally there is still some number of weeks/months between their commit to the work and when you start work so you’re not starting on things they aren’t really committed to. Again, lynchpin is this being committed and enforced.

It may be the case that the sales engineers or technical account reps or product managers or business analysts or whomever gathers requirements and finalized them on your side is really bad at their job, too. If they aren’t asking the right questions, presenting options to narrow possibilities, and getting sign-off from an executive on the client’s side, then clients shifting their asks isn’t really their fault. They may not have expertise to do this themselves.

Some possible things you might do from the dev side that could be more “self-determined” is to be more deliberate about the ordering of implementation, doing some things “just in time” instead of significant pre-planning, making late-binding decisions as late as possible, and moving more functionality to a rules engine or other dynamic system that is flexible and easier to modify than core code. If you are told that the slate of incoming features requires new document storage, two new event types, and a new interface to an external system. All of the proposed features have user-facing UI components, and a few have new admin options. There are tough calls to make, often a new interface to an outside system may take months. It could be that you say you cannot commit to the user-facing work until the quarter or half after that is completed, and it may take 1-2 quarters to onboard. Some of the other things, like event types, may be trivial to add so you can wait until the last minute to start adding these in parallel with the associated UI work. New document storage may be expensive to add, but you may choose to create the data access layer that uses a memory-only mock of the storage first, and only when you have had unchanged requirements for a quarter or something so you actually add the new storage and swap a real implementation in the access layer while in parallel the code that uses the new storage can be written against the already-in-place data access layer.

All of this is, of course, hypothetical. In terms of managing team morale, be sure that any good designs or implementations are celebrated and recognized, and are considered for perf and promo. Something shipping when that often gets derailed by clients should not be the only work that “counts”. When there is a change, allow engineers to continue to work to a reasonable stopping point, commit the work, have it disabled, and move on. If it is revisited later, great. If it is abandoned it can be removed when that is high confidence.

This isn’t easy, a lot is out of your control, so taking baby steps and minimizing the impact is probably best.

You need to own the mistake you made. You caused a delay on a project. A week isn’t a lot, but you chose to do this on your own without prioritization direction or informing stakeholders.

Your work time is not your own, and you misallocated it. You ran into friction for this “side project”, and didn’t decide to bail out or defer the side project, you kept going. You will need to determine what work is high value and explain and champion that work, then do it. You going rogue even if you think it’s for an important project isn’t showing good judgement.

You working on a project that your manager didn’t vet as promo worthy, and then delaying a project that was a priority for your team, is a data point that you’re not behaving as an SDE-III. You need to move past this with humility, not defend it.

You should say something like “I’m sorry, I made a serious mid judgement that negatively impacted the team. I was overzealous and really wanted to work on project XFNA. I mistakenly thought I could ramp up and contribute without impact to Project B, which I was committed to. I was wrong, and even when I realized it would take more work than I thought, kept pursuing it without consulting you, our team, or our stakeholders. I do think project XFNA has great potential for impact, but I was irresponsible prioritizing that over committed work, and will not do that again. I will make sure we catch up and hit future milestones on Project B, and after that would like to discuss if I can contribute some time to Project XFNA, or find something else with cross-team impact, to expand my scope”. You should apologize to the rest of your team and take responsibility publicly, too.

If this team doesn’t have scope to get you to SDE-III and you can’t scalably and responsibly create that scope, you need to find a new team.

Do you have subtasks or acceptance criteria you are working through? Do you have a way to measure progress more than “done/not done”?

I’m not going to preach TDD or anything, but an example would be that you wrote your 8 tests to cover the acceptance criteria, and you have done the work to get 3 of them passing and are working on the logic for two more today.

again, that doesn’t have to be the metric, but decomposing into measurable chunks is important.

Systematize. Make a checklist, or a template, or have a form that enforces certain things. Leaving it to people remembering or best intentions is planning for it to fail.

if you can automate creation of an artifact, do that. If not, automate the check that it’s included. If you need to always have a sign-off from a buddy beforehand that will double check, do that, but ideally a system makes that unnecessary.

it depends. Is it for comprehension or for critique?

if it’s for comprehension, i tend to work vertically. What makes field X display on screen, or sets a given field in an API request. Then work backwards to the source. I find that getting a broad understanding of a given subsystem is less helpful than seeing how the layers fit together at first.

For reviews it’s honestly a lot more “code smell”. I’d there something odd about the shape of code? Something that seems totally against idiom or standards? I do look at context, but normally during the grokking process for an “interesting” bit.

If you’re struggling with idea to code in time limit, including taking short (10-15s) breaks to say what you’ll do first, or note you’ll return to clean something up, ask if you should write out all preconditions checks, etc… I feel like getting much more familiar/comfortable with the language you work in, algorithm implementation, and so on. Also, take shortcuts. Say methodX does X, and say if there’s time you’ll come back to it. If it’s obvious but tedious that should be fine.

I am saying this because the typing part should be the least intensive. Talking it out, taking direction or getting input on what should be prioritized, etc is more relevant than the code you write. Quiet time will possibly have interviewer tune out, or be inclined to ask their own questions, interrupting at an inopportune time. If you take your own breaks to talk, you stay in control of the timing.

I’m not saying I never said I was inclined to hire someone that coded quietly, but the code is the least interesting part, and just table stakes. How you reason, how fast you can pivot, showing you think through options thoroughly, etc is so much more important, and raw code doesn’t tell that story.

You can make great strides toward Sr SDE in this situation, but you have to actually own the solutions to these problems. I don’t want to be too direct, but things like “we never have time” sounds like resignation, not a challenge to be overcome.

Stop having on-call handle low-pri tickets. They take pages. That’s enough. If it’s low priority, it should be treated as such and can be triaged into an appropriate future period of work.

Get watir rules (thinks that is what it’s called) for triaging incoming tickets before they even get to you, avoiding many and having greater clarity when they do arrive.

Automate common bug type resolution. Identify the top 1-2 root causes of bugs every quarter and fix them, or at least dedicate time to moving that direction. Allocate time. You don’t have time to do new work if you’re not keeping your system and team healthy.

Being a workhorse for dependent teams is rough. You need ingestion processes, self-service feature request process, allocate a certain amount of time per quarter or half to these projects, and do ranking WITH all the stakeholders in the room. If you can’t sort it out, then it needs to be escalated. You can’t manufacture more time, it is limited, and you’re taking on more than the team can do.

This team is in bad shape. Take it to a team in good shape with qualitative survey results from engineers that show improvement, and quantitative measures of incoming tickets, SLA, on-time feature delivery (because you maintain focus) and so on. That is promotable.

you’re going to have to do most of this to get there anyway. Other teams may not be as bad off, so you may have to find the opportunities yourself. They are plainly visible on this team.

Always have a note taker. When you need to redirect, say: This is critical and beyond this meeting’s scope. We’ll take a note and schedule time to finish. The next item on the agenda is a date for a date on project X milestone 1, Anna is the lead on that but am interested in hearing if there are any considerations that require research that might impact our ability to give a date by Friday.

Basically: this has value, but we must cover our agenda.

If you NEED Freeform team brainstorming, maybe schedule that, but probably get loose topics in a shared doc first to at least jump start. Do this rarely/as-needed, NOT reoccurring every week.

I think that the “ask well-informed questions” is noble, but has limits.

Instead of asking a bunch of small questions with no context or understanding, I would ask for resources to use to learn from scratch. Just what they’d use if they had to learn it again. This shows interest, but is clear that you can’t even ask smart questions because you are starting from zero.

Do you have responsibility for this person (lead, mentor, onboarding buddy) or only interest? This is important because how much you need to be involved depends a lot on this.

Regardless, you need to understand how they feel. Don’t come in guns blazing telling them how they need to improve. Come in gently, ready to have a vulnerable conversation in a safe space. Get a self-assessment from them first. How are you feeling about progress so far? Are there any areas you need more support in? See what they think. If they don’t think they are doing poorly, you asserting it as a “3rd party peer” is inappropriate and could be a set back. It might cause more resistance, incite fear, etc.

If they know they’re behind, you can again look at what could better support them. They aren’t beholden to you to share if there are extenuating circumstances impacting this. I opened up to my team at Meta that I’d botched my meds and fallen into deep depression that affected my performance, but I don’t expect most people to be comfortable doing that. How it got to this point has some relevance, but what’s next is more important.

If they share concrete support they need, there’s a chance you can’t provide it yourself. This is another place where what your relationship is matters. If you’re only an interested peer, and they need more clearly scoped work, you may not be able to do anything. If they tell you, open up, are clear, but then you’re unable to help this is rough.

I think, and I don’t know the circumstances, that you should be volunteering as a resource more than trying to bottom out all of the issues. Telling your manager that you really want to help support person X finish ramp up may be a way to do this without further complications.

I know this is sort of meandering because it’s hard to cover all bases since I don’t know the details. I’ve been the concerned peer and the responsible individual. I’ve been the person flailing/failing. This is delicate and I’d just caution you setting a tone or making commitments to this person that isn’t your place.

Having team influence is part of being mid-to-senior level. You-scope is entry-level scope.

I am a little confused at the phrasing here, though. You’re asking how to talk about it, but I’m not sure if you are actually doing it. If you don’t know how to enunciate impact, that’s a general growth area and should be something your manager or mentor is able to aid with directly. If you are coaching through effective code reviews, and have taken some common feedback and socialized it as code guidelines for the team, new lint rules, or whatever… then you are having team impact. To enunciate that you need to show that there were X reviews in a given period with Y problem, and now it never happens.

If you’re not having team impact that’s a different problem than not knowing how to talk about it. You should assess what you are good at, and be spreading that to the team through process and training. You should be assessing what you and the team could be better at and getting the help from others to fill those not just for you but for the team. You are close to the problems the team has, you should be starting to assess what those are, and either ideating solutions or seeking them from others if you can’t figure them out. I wouldn’t put it explicitly on you to be prioritizing these, getting them scoped, getting them on a roadmap, getting resources, and so on… that’s a little more senior-scope, but you should be starting down this path and getting senior or manager aid to get the rest done.

I think taking this initiative is appropriate, but I’d definitely make some tweaks. I am coming off a “failure to launch” experience at Meta where I tried what you’re suggesting and it could have gone better.

First, ask your manager or skip (and get them on a mail thread or a chat room or whatever so you are all on the same page) what timeline they expect you to be contributing, and what. If no one knows, this isn’t great, but certainly proceed with making your own plan and having it ratified by this group.

The other bit I’d be careful with is waiting 3 months. Even if your manager is busy, I really hope they can check in with you, even if it’s asynchronously, once every 2-4 weeks. You can go WAY astray in 3 months. You’re going to want to course correct.

If your plan has dates attached, and none of them are slipping at all, I guess maybe longer time periods, but it still makes me nervous. Again, my reason is I made this kind of plan, worked on it for six weeks, then my manager gave me a different, wholly dissimilar plan and said I was really behind on it after about six weeks. I may be conservative for this reason.

In that doc, I would organize it around whatever the principal tenets or role guide pillars are. If it’s like people, technical excellence, teamwork, and community building, set up how you will build up each. For people, have 1:1s with the engineers you’re responsible for and see where you can help them develop. For technical excellence, how you’ll learn the code your team owns, and the systems it interacts with, and identify 2-4 areas of improvement to prioritize over the next few halves. For teamwork, identify the processes your team is using that need people siloed or causes conflict and gather ideas to fix them. For community see if remote folk are always considered, what social activities are happening, how people socialize their work, and so on. These are obviously made up, but I think aligning to a scope that is right for you based on the role, and to guiding principles will show dedication to the company’s values.

As for pointers:
0xc48ad17b
0xdeadbeef
0xcafeeat5
0xa7edca7d

Edit: There were no responses when I started this =) enjoy going through three long replies.

What do you think will happen if you try something before you’re absolutely ready? Submit a code review with imperfect testing and be asked to correct it?

I am not a psychologist, but one may be able to help. It could be the case that there is anxiety about being seen as vulnerable, or showing flaws. It may not be safe for some reason, and as such you’d rather “fail” doing “all the right things” than take risks and be judged for your authentic self.

It may help to enunciate to a manager you want to try to stretch outside of your comfort zone, but want a net. Can you try to push on a non-critical, but greatly impactful project if delivered? Can you timebox a prototype to see if there’s promise, and if not this is useful data to have collected and you won’t be penalized? Something like that, taking measured risks, may be easier.

Reserve 10-20% of the team’s capacity for this and PM doesn’t choose which tasks that uses, engineering does. If that doesn’t work and it is hostile and not collaborative, there are back doors like inflating estimates and sneaking the tech debt pay down in, or tying certain features to certain improvements because they are “tipping point” things that will take a bad module and make it totally insane without a refactor.

If there is an organizational resistance to investment in code health, it can be hard to prove the value. If you can demonstrate degrading velocity, maybe it will help. If you can show bug counts climbing, maybe it will help. This really does require a lot of sales, framing, and digging deep to find supporting data.

Do you want to manage out poor performers? Tell people they didn’t get promoted? Tell your team a project they really believe in is canceled? Tell stakeholders an important feature isn’t landing?

The good parts exist too, of course. Promoting someone, celebrating a successful release and such, but my experience was that difficult things happened with higher frequency (but lower magnitude).

Why do you want to manage? Do you love writing documents, reporting/defending status in meetings, and want to step back from code and design? What type of leading do you want to do as a people manager that you can’t do as a more senior IC?

Would you have strong support and an ability to switch back if it doesn’t work out? Can you take on more management responsibilities without official title change to see if you like it? Can you talk in depth with existing managers about what they love and hate about their job?

What is considered new grad or entry level across the industry is bizarre. If the responsibility level and compensation matches your desired role, I don’t see any reason not to do it. I know that some places cap this at 1 year from graduation, or 1 year of professional experience or whatever, but not all do.

Not all experience is equal, either. The growth I had in the 8 years I was at Amazon was significantly different than the growth I had the prior 8 years I had worked in industry.

I don’t think there should be shame or guilt associated with taking a recent graduate role unless you’ve been promoted to intermediate roles elsewhere and it’s actually a step back in terms of responsibility, but I guess I feel like that’s more on the hiring company to decide than for you to say “no, I won’t do it”.

Basically: if I were you and I could get into a target company at an entry level doing the work I’m interested in, i would jump at it. Maybe you’ll be able to get promoted to an intermediate role faster because you know more about delivering software professionally than others hired into this role.

I can’t tell if this is about a single instance you intend to run, and have had experiences like this in the past, or if this is a reoccurring meeting with a similar group of people. Why it matters is because meeting hygiene like this is a habit not just an action you take one time. If you have a similar group, this is a habit you can build together, and gradually refine it over time so that it works for the group. If this is a one off it is going to take a lot of preplanning and structure.

I am going to challenge some of the presuppositions next. Everyone doesn’t need to speak. Not everyone wants to speak. Everyone needs an opportunity, but forcing people to speak is not inclusive and will push some people out of attending in the future, and it will be at significant cost. Them being there, listening, and chiming in if it’s critical or giving feedback offline is really important. If they are intermittently non-verbal, have social anxiety, require time to process and synthesize verbally presented information, whatever… give them that space and choice without taking their seat.

With that out of the way, have as many alternative means of engagement as possible. Let people physically in the meeting room add things or ask questions using a chat function of your meeting software. Let them use a facilitator as a mouth piece, sending the message privately to be read aloud. Give very clear indications of how follow ups should be sent so the whole group gets them and they are incorporated into the notes and action items (you have someone dedicated to taking notes and recording action items, right?).

So then when you DO need to cut someone off, how do you do that graciously? It helps if you establish norms in advance rather than having to do this ad hoc. Again, if this is an established team it is a lot easier to norm globally than just in a single meeting. Regardless, if it’s clear that when you need to move on, any person can say Radish and the note taker will note that person X was discussing topic Y, and left off with point Z, it will be clear that this is a “to be continued” rather than “shut up”, and the person can finish their thought offline in the agreed upon forum. If someone will not respect norms, escalating to less polite means can be necessary. You can be firm and not rude, though. 
“We gave a signal to move on, and gave some time to wrap up, but now we absolutely move on. I look forward to reading the rest of the details on this in the follow up”
“I’m sorry, I have to take the floor right now or we will have to break now and reschedule to get through the agenda”
“I’m afraid we’ve tried a number of means to move on. Respectfully, I am taking the floor back immediately and we are moving on”

If there is a single person that is causing this problem (I am sometimes this problem person), addressing it with them offline, and gathering their feedback in advance can help. Give them the document or agenda a day before, let them share all their thoughts, and add it to the document or preread or whatever. Protect the time. Meetings are extremely expensive and have goals and artifacts that must be generated.

Some people have auditory processing or attention issues where they actually can’t hear you when they are speaking, or process it, or break. Having alternative inputs like a red light, a gentle tap (if they’ve agreed, again, norms help), a hand wave, a gavel rap… whatever, it may be the case that you need to have these modalities ready.

If you don’t have an agenda you’ve already lost, so always start there. Honoring that is norm #2 after “be respectful to others, we are a team”.

That got away from me a little. I’m probably going to edit it down for LinkedIn since I spent a lot of time on it. [Here's the post.](https://lnkd.in/g7j-44_p)

Good luck, happy meeting-facilitation!

I would take a slightly different tact. What gives you energy in your work? What do you love most?

Get great at that. Ideally it’s something not everyone is great at, but regardless don’t get great at something you hate because it’s what you’ll be asked to do constantly. Let the passion guide this. You have strengths for sure, but you are new. Being great is the result of practice, with some natural proclivity maybe giving it a boost.

Also, ask your peers? Maybe you don’t know that you’re good at explaining complex topics. Maybe it’s identifying root causes of ongoing problems. Perhaps you ask thoughtful questions. You could be the most patient with new joiners or non-technical people and build bridges. Ask, and if you like the things that come back, refine and accentuate those.

Ask. I feel like I’ve started a lot of answers this way, but we here cannot know if you are before above, below, or at the expectations your manager and team have.

Ask your manager what your growth areas are, and if they are far below expectations, or at expectations but would make you really stand out. Ask what you are best at, and if you can leverage it differently to help your team.

Ask the same to senior engineers on the team.

It seems like you’re probably doing well, but expect to be where people with a lot more experience are. Be the best you, not better than people that had a huge head start on you.

When it comes to improving and working toward your first promotion, I am sure there are a ton of more detailed posts here for that. That is growth to the next level though, not to overcome performance problems, which I don’t think is where you are.

Ask them what their preferred engagement style is and do that. Otherwise you are not bothering them, you are doing your job, learning.

If they want to meet daily and pair with you on whatever you need, great. Email a digest of issues 3x per day and they’ll respond within Z minutes, otherwise DM? Neato. Post to the team chat with no one tagged, and if no response in X minutes, self-reply tagging your mentor, in Y more minutes tagging everyone? Sweet. Direct DM immediately and round robin team if mentor doesn’t respond? Perfect. If they say to contact them a particular way, you do, and they are bothered? That’s on them. If you don’t respect their preferences and walk to their desk (especially if it’s at their house) and nag them for 40 minutes without asking if it’s a good time in a non-disruptive medium first? That’s a bad time, and you should address it with them and your manager.

Be working on asking progressively better questions. I will edit this once I find the “hand holding” question, where Alex and I also addressed what good questions look like. It won’t be all at once, you won’t be a pro, but take a few weeks of bad questions and then really start timeboxed attempts at finding your own answers.

Remember that everyone has been in your place. Your job right now is to learn, your peers on the team’s job is to teach/help. You won’t be praised for taking much longer but not “bothering” anyone.

[Link to Handholding thread](https://link.jointaro.com/V8CySKVRZ8k1hBxd7)

I think the advice to avoid pigeonholing isn’t bad, there is good intent, but I think what isn’t included is what that would mean. To me this means you can no longer work in another area. I really don’t see that as a risk. To me the choices are broad diversification, narrow diversification, specialization, or very deep specialization. I think that digging into ML, as long as you’re still coding, working on training infrastructure and so on, is narrow diversification or specialization depending on exactly what you’re working on. 

If you decided to go way down a hole on one specific image recognition algorithm, and that was your life for 2-3 years, you may poke your head up and not be as ready to take on general system design problems or coding services. You could resharpen them, but they wouldn’t just be at “production quality”.

The broad generalization would be more like… “full stack”, where you’re jumping from storage concerns to front end to model training to internal tools and really never getting deep on anything but having a lot of broad working knowledge. I think for some startups or startup-like teams this flexibility can be helpful, but I think not having a specific area of strength (but you probably already do at a senior level) can also be a detriment when it comes to moving to a new team or company. 

What do you do?
A little of this, a little of that
Ok, but what big project did you land?
None, I just filled the gaps all over the place!

Sometimes this is really valued, but enunciating why you’re great and that you COULD land something big is harder to show.

So… if you like ML, try it. You won’t totally lose your other skills if you keep an eye on trends and don’t completely rathole on one specific technology.

Good luck!

Ask. Ask your mentor, or another member of the boot camp team. If they don’t know, ask who to ask next. Escalate through your mentor’s mentor and so on. Ask the bootcamp program manager if you need to.

I had a really hard time with team match. I was told that 4-6 months can start to raise eyebrows. During a hiring freeze it might be even longer. Know what the expectation is, this isn’t just a “you” problem.

In terms of what to do, find teams to do “free labor” for that you’d like to work for, but be sure that if they don’t accept you it isn’t niche tech. If you want to work on Hack, work in Hack. If mobile, work on mobile. Learn GraphQL, learn about mercurial. Use the tools. Be ready when teams open up hiring. The freeze is unlikely to last forever. If it does, they MIGHT layoff people not allocated to teams but this seems VERY unlikely. If you don’t want to wait around with no permanent team, you could shop other companies but there ARE slowdowns, so that could take a while too.

Good luck! Don’t worry alone, ask!

Alex gave a thorough answer, but I’ll give my interpretation:
You ask better questions, and you understand the answers.

Handholding is when you ask a not very good question, have to be led to the correct question to be asking through a lot of follow-ups, then are given an answer but you don’t understand it, so have to be shown in great detail. Even then, you can’t synthesize how to use this to get further unblocked.

Once you’re past handholding, you ask better questions, and when you get an answer you can apply it yourself and get unblocked. It is easy to help you, because your question has all of the context, and when an answer is given that can be the end of the interaction.

This extends to things like tasks assigned to you. Do you figure out 90% of it yourself, then ask a lead or PM to clarify the last 10% that’s actually ambiguous? Great. If you figure out 10% and ask a lot of questions that would easily be answered reading the PRD, or you’re asking the wrong people, that’s bad.

This is generally used as one of the distinguishing factors between SDE-I and II. Are you generally independent? Can you answer basic questions from others accurately? Do you deliver things self-sufficiently?

Another way to think about it is how much you “give” versus how much you “take”. It doesn’t mean SDE-Is don’t deliver value, but almost all interactions with others are getting help, and needing others to give to them. I think there’s a tipping point where your questions start elucidating things for others, you’re helping as much as needing help, and so on.

I have a bad taste in my mouth due to a particularly bad experience at Meta, but will try to put that aside.

Meta seems obsessed with metrics and experiments, but it feels a little disingenuous. You will set up your experiment, set guardrails, put the flag in your code (but did you expose it right? Not everyone does), then get nonsense results. You’ll change the universe and rerun it. It is possible that you repeat this multiple times, and the data doesn’t prove our your hypothesis. There’s a lot of stress, and time spent iterating, on getting the numbers to show the impact, or prove no impact, or whatever. It is my opinion that at times the results were invalid and nearly random, but once there was a result that looked good, that one was considered good. It felt a little cover your ass.

Access to Mark is pretty unprecedented. I think he’s gone off the deep end, but regardless getting on a Live every few weeks and taking questions from employees is… interesting.

I know some people love and swear by the level opacity @alex included. It does change culture. It really broke my brain and me trying to understand it only made things worse. I think I felt… deflated. I finally had a fancy, senior role and wasn’t supposed to tell anybody. More so it is super hard to deliver career advice without level information. I can assert it’s different, better or worse is an exercise for the reader.

There’s a lot of other things, but like… the Workplace stuff is… not used anywhere else I’ve worked, and the rubric to decide when to use WorkChat or whatever, Workplace posts, email… I never got it right. Use chat unless it’s a senior executive then email, but no one checks email.

Anyway… those are some I know, but I was full remote and not deeply steeped in a lot of culture.

The number you influence matters, direct leadership on a project less so. Having 20 engineers on a project team is maybe too many anyway.

Your behaviors should be having cross-team impact. 20-30 engineers (this is rough) should be better because of what you do. Certainly the 4-5 you are leading on a project should be MUCH better because they should be learning to do things like you, and there’s a lot of direct interaction, but your outside-of-project work should impact many more.

There could be project crossover if you can rework a library or tool to support this project but it’s also used by many others. It could be that you need to just do other things.

If you’re not wanting TLM or M1, just be clear on that, and be sure you’re doing what is needed on the people axis for E6. It’s only a problem if your manager or other E6+ engineers tell you it is, but I doubt the size of a project team is a primary blocker.

* Note: I have not promoted to E6 at Meta, this is general advice.

What is the E6 doing that you are not, and what would they be willing to give up to get you E6 data?

Have you talked to them about promotion, and where they think the gaps are? Your manager?

You’re speaking very generally. You’re looking for “scope”, but there’s a dozen things you could be missing.

There is an eternal hunt for the “E5” or “E6” golden project that will check all the boxes. And there’s one per every 20 people at the lower level, so it doesn’t fall into everyone’s lap. You need to construct the scope from what is there. 

Are there processes across this large project that need honing? If a TPM is owning them but they are ineffective can you champion and make it happen on the engineering side? Is there a cross-cutting concern like business and operational metrics, security, privacy, launch plan, experimentation model, or anything else that will span all of the E5 pods that you can own and deliver on? Is there a part of the work you’re doing that would be generally useful outside of your team, and you could design that modularly then socialize it? What mentorship, training, knowledge sharing, book clubs, and other org-wide initiatives exist, and can you revitalize one or create another that adds value?

Do you give your director feedback on what you’d like to have prioritized to improve your systems? Do you know what they value most and you ensure it has appropriate focus?

Do things that everyone is impacted by and no one else is doing. Rework your on-call to be more sane. Do a run book refresh program and assign out sections to make sure everything is accurate. Own driving a needed feature with internal tools teams, and see if you can build it yourself. See if there’s a common paper cut that you can catch with Lint rules and write them.

Shipping E5 scope well, as you seem to realize, does not get you to E6. You need to do both jobs for a while, so keep delivering on this subsystem and making the engineers you’re guiding better at every step, but be taking on additional work that is highly visible, impactful, and doesn’t have a clear solution.

And ask. Ask your manager if something you want to do is E6 scope. Don’t pour your heart into something and find that it doesn’t move the needle.

Good luck, god speed.

* Note: I never promoted anyone to E6 at Meta, this is more general advice, but is also why I said to double check with your manager.

There are no guarantees. If your manager is going to put you in the Needs Support bucket artificially to fire you based on new edicts, this trip is unlikely to be the make or break.

If you are going to keep working, attend meetings when possible, etc. and your performance really won’t change, I am not sure what the problem would be unless the witch hunt is already on. If the witch hunt is on, you being more visible for one month doesn’t seem likely to save you if you received the mark.

Performance eval is for a year. This is one month. I can’t say there won’t be recency bias going into PSC, but it *should* not. But the company *should not* be needing to cull 12-15% of people by moving the goal posts in the 11th (ok, 10th) hour, either and here we are.

Weigh the four scenarios:

• You go, your rating is fine. No regrets, no worries.

• You go, you get NS. You blame the trip and regret it, but you don’t actually know if that’s involved at all and did have the experience, family time, whatever.

• You don’t go, your rating is fine. You regret not going and wonder if you still would have been OK if you had.

• You don’t go, you get NS. Now you really regret not going because it didn’t matter that you stayed.

Based on the possibilities, I personally would go. I will admit a bias against Meta, especially now, but if having a life costs you your job, I don’t know if it’s a job you want. What do you cut out next year?

This us not an ideal setup, but there are worse (like being the first engineer on a team and being junior). There will be time for 1:1s, but there may not be as much “sit at your desk” (whether in office or not) time with the existing engineers. 

If I were the lead eng or SDM on this team, this is what I’d do. Assuming 2 existing members are SDE-II, 2 are SDE-I, and you’re adding 5 people:
Pod into groupings of:
1 existing SDE-II
1 existing SDE-I
2-3 new hires (3 to the most senior I/II pairing)

There may be more complexity in terms of the new hires being mostly SDE-II and only one existing member is. If that was the case I’d pod the 3 SDE-Is with 1-2 new hires each, and have the existing SDE-II doing active checkins with each pod as well as 1:1 with every new hire. Weekly if possible, 2x/3 weeks if not.

Calendar everything. No one should be left hanging for a long period of time. Each pod should be meeting as a group and talking through what everyone is doing in detail. New members should come to the standup or scrum if it exists and give their brief status but the pod leads should never be shocked at their blockers and already be working to fix them.

The manager should keep a weekly 1:1 with all new members as well. It should be separate from the SDE-II(s), and focus a little more on problems that aren’t getting resolved as quickly in the pod, and giving the Leadership Principle talks (I would say follow up, actually, they should do a session with the whole cohort going over them in detail, maybe two sessions), HR stuff (explaining pay, stocks, process), giving the new hires names outside the team to meet based on likely project assignment, etc. This is more strategic, while the engineers should be more tactical with helping you get your environment setup, first commit done, a guided tour through the code, an illustrated tour through service ownership and architecture, etc.

From there, I’d setup an onboarding oncall rotation, and have the new folk all on there. I’d start week one so in 3-4 months everyone will have had 2-3 rotations on it and be ready to start taking regular shifts with backup.

Have slack rooms with:
Whole team (already existing)
Whole team minus manager (already existing)
Just new hire cohort
Each pod

And of course be talking 1:1 with everyone on slack as needed.

If you are remote, VC as much as possible. Not just at scheduled meetings, like have a standing open chime that can be joined by any or everyone if needed if a conversation on slack takes more than 5 minutes or so. Talking is faster, VC will build rapport faster.

Try to do coffee chats with 2-3 new hires and your skip and director. Small forum makes it easier to ask questions but is more efficient with their time.

Each new hire should own a wiki page or onboarding document or some artifact of the team’s (or create them if there are none) and make it such that the next hire has a much easier time. Every question and its answer, every quirk or change to a documented process, all of it.

Have social time with the other new hires, and the whole team. Ask an off topic question in the team room daily and round robin the asker. Play games, or just chat.

Good luck. Again, suboptimal but I believe this setup can be made to work and get everyone up to speed effectively with enough disciplines

There’s way too much to unpack here, but a lot of it isn’t necessary.

Do you have any indication your performance is poor? The next cycle covers all of this year. You had half the year on another team. How did you perform there? If you just joined the company, you should get clear guidance on how long ramp up should be expected. I would say you should be operating at L4 now, but just now. As such, working on a design document seems at or above level to me, but I didn’t have a ton of time to acclimate at Meta, and the scope of the design may be small.

But talk to your manager! Do you have expectations written down and agreed to? Have you asked what rating you are tending toward based on performance to date, and what would help get you to the next level up or drop you to the next level down? They are a big part of managing your performance and a rating should not be a surprise.

I’m not going to talk about handling PIP because it’s just not on the table at this point. Get more data and work on avoiding that if it’s even a risk (doubt it is). If you need to shift priorities, do it. You still have a whole quarter!

How much you can do yourself may be limited, but have some thoughts.

Get a buddy assigned from the owning team, and clear everything with them in advance. If they want a more senior engineer on your side reviewing BEFORE you reach out to their POC, fine, do that. There should never be a surprised CR dropped in their lap. They should know about the design, the phases, the timing, how invasive the code is, etc. Once you have a buddy, it will be much easier to iterate and land your change.

However, embedded in your question is an assertion that often you have to do this. Why?! If there are not clear boundaries, ownership, plug-in models, async notifications to trigger cross-service behaviors, and other mechanisms to avoid this, there should be. At most you should be adding a socket that is pushing a message out, or pulling a call in. If there are concerns that this is too slow, this probably means that you’re adding something to the critical path and not asynchronously. This should be the vast minority of the time, and even then, the invasive part of the code should be calling to a module your team owns, with strict timing thresholds to avoid performance regressions. If you have conditional statements in the other team’s code, stop and find a different solution. Especially if this is happening all the time, decoupling is going to make everyone’s life much better.

The other advice is more for leadership. You are not being a good steward for your team if you are sending them on away missions all the time. You should be getting your work on the other team’s roadmap in time, or funding headcount for them to give you N weeks per quarter to do this work, or horse trading to take on work they need, or factor old debt your team introduced out, or whatever so THEY do the work in their code base if that’s truly where it belongs. If your team is taking on some more mundane tasks for them to free up their on-call to do your work, do that. Whatever keeps you from having to mess with their code, do it.

The biggest problem with you changing their code is on-going support. Are you getting paged when your code breaks their service? Or there’s a suspicion thereof? Will you support it for a month after you ship it then hand it off to them? It yields poor ownership and decreases their understanding of their own service.

Are you wanting to build the relationship gradually so you have the trust and rapport such that you’re getting these details organically, or are you fine doing that over time but you want actionable feedback *right now*?

The long game of building trust will be maintaining confidence when trusted with information, keeping your word, being transparent yourself, and seeking stretch goals. You don’t have to always achieve stretch goals, but seeing self-initiation is helpful.

If it’s “cut to the chase” feedback:
“I prefer a very direct communication style, I struggle to read between the lines. Even if you think some feedback is too forward or rude, I really do prefer to hear it unfiltered and make a plan to improve”

“I am in a growth phase, and can’t grow without clear feedback. Can you give me one thing I am not doing or could do better to focus on between now and one next meeting?”

“We have talked generally about my work, and I am interested in very pointed feedback to improve. If you don’t have detailed feedback, could you ask person X and Y who I have worked with directly. If they are comfortable they can tell me directly, otherwise please synthesize it and deliver it yourself.”

You need to be clear with your needs. If their boundaries are “I don’t give feedback outside of formal reviews” they are a bad manager, but I doubt that’s the case. They are getting their bearings still, but if you are very direct with your needs hopefully they can hear it.

Alex already described Active Listening in his post, which is a very important skill to develop. Being able to succinctly restate key points helps your note taking, and allows these summarizations to occur that sort of “check point” what is being presented.

Beyond that, though, everyone will benefit from a “blotter” that goes out after a meeting, and using that as a jumping off point for further offline discussion. Some people cannot synthesize information, reflect on it, and have good feedback in a time-constrained situation. Everyone should have a voice, not just those that speak quickly in the meeting itself.

Assign a note taker who is not the presenter in every meeting, and have those notes sent to the team after, even if everyone wasn’t able to attend. Then you have an “in” to provide your thoughts in response there, and have a record of it.

Diversity makes us better, but that means having flexible channels for this kind of feedback. If the introverted people, or those that require longer reflection to give insightful feedback, or those with social anxiety are all dismissed because they can’t give a response in one’s of minutes in a meeting, that is a loss. Level the playing field, and it will yield benefits beyond your own ability to contribute.

Time is a secondary factor compared to gap analysis and plans to fill them. Your plan may have hard time blocks (to launch a thing and maintain it, show success may take a few halves), but saying “I want to be promoted in 2 years” will still just come back to your gaps and seeing how to fill them in 2 years.

With the help of a manager (doesn’t have to be yours) or an engineer that has provided feedback on a successful IC5 promo, go through the guidelines for that level, and give examples of what you’ve done that meets them. If you have none, that goes right onto the gap list. If you have weak examples, it can go into a “needs improvement” gap section. Then start ideating. Is it people things? OK, do you need to mentor someone? Do you need to shepherd a promotion from L3 -> L4? Maybe it’s project ambiguity… get involved in your team’s planning and identify what projects are poorly defined and work with your manager to take ownership of those things. Once you have a plan, maybe missing a couple of pieces, work with your manager to see if they agree on the action items filling the gaps, and ask for support in filling them. If you haven’t found ideas to fill all the gaps, be looking and asking others.

Note checking all the boxes won’t mean you get promoted, but if you don’t you almost assuredly won’t.

People is not just hiring and onboarding. You are 1-2 levels above a lot of people on your team and adjacent teams. You have the ability to mentor, do knowledge sharing sessions, setting up book clubs, show and tells, aiding with promotion preparation, etc. New hires or potential hires are not the only people who can benefit from your involvement.

Also, it seems like asking your manager would be really helpful. List the things you love doing (individual mentorship, building better processes, etc) and see what the team needs most.

Change the mode of thinking about this. You are a peer, even if less experienced. You are providing the gift of a critique, not criticism. Criticism is telling someone what they did wrong, critique is providing analysis and potentially suggesting changes.

You should practice disagreeing and critiquing clearly and respectfully. If you do this, you’re not being a source of problems but a resource.

Some examples:
It appears that a design has completely disregarded the ability for a subsystem to scale. There is no cache in front of it, it has a hard limit based on its own dependencies that also won’t scale to meet this projects demands. Some choices:
Bad, criticism: This design will not work and is insufficient because subsystem Y cannot handle this traffic and you are not mitigating this. The system will fail under load.

Good, asking questions, but not being completely confident/direct:
I am not sure, but I understand that subsystem Y has some hard scaling limitations. Did I miss where this was handled? Is there something else that will mitigate that? Do I misunderstand the limitation?

Better, questions with clarity:
I think that most of this design is sound, but I do have questions about subsystem Y’s ability to scale under the load we will be introducing. Have the owners of that subsystem solved their scaling issue? If not, do you have a plan for that or is it still under consideration?

You can contribute right now. If you ask questions that don’t apply you’ll learn. If they do apply you’ll help. Either way, this is a win.

Similarly in code reviews, you can note that you are struggling to understand something and potentially give a needed perspective. If everyone has been boiling gradually, they are all used to it. You have the ability to call out the problems they overlook, and ask about how/when it will be fixed.

Capture the data, slice it by daily, monthly, and annually, and put it in your review. If you can, get real or approximate data on total, lifetime impact of these issues.

It was worth it, but that doesn’t mean you’ll be recognized for it. You are a better engineer and leader for having done it. Present it to your team or write a blog post or socialize however you need to. Show your techniques, and see if you can come up with static analysis rules to prevent it in the future, or at least raise awareness to try to catch in CR (but I mean… that’s relying on intentions).

If people don’t care about user experience, that’s a whole separate problem. I would try to drive this to be a key performance indicator, put it on a dashboard, and harp on it. It is eroding trust and user affinity for your product, even without user complaints.

Hopefully solving problems is its own reward for you, but I do understand concrete recognition would be nice. You may need to balance this kind of thing with more concrete business deliverables, but try to leverage on-call shifts or some fixed % of time for this.

I wouldn’t get too discouraged. This attitude and example will serve you in interviews and future work.

I want to write real replies here that are bespoke to the asker, AND I have written on a lot of topics on LinkedIn already. I don’t want to drag people away from Taro, nor copy-paste, so I will answer briefly but then link relevant things at the end.

Briefly: No. There is no reason to do this unless you really want a career change to a different role.

Not at all briefly: This isn’t a promotion from SDE, or the next step. Being an SDM is a much different job, even from a team lead role. Your love for planning projects or developing people is not sufficient. The amount of managing up and out is tremendous.

You may learn a few things being a manager that will make you a better IC if you come back. You can learn them other ways.

If you want to explore, do take some of your manager’s responsibilities outside of direct team management. Write some of their docs, go to some meetings to represent your team. See if you love those aspects.

Don’t do this without tremendous support. If who you will be reporting to isn’t L7 or long-tenured L6 that has MANAGED MANAGERS BEFORE, they will have a hard time teaching you as you ramp up. This is not something to do without a net.

[There and Back Again - My journey from IC engineer to SDM and back](https://lnkd.in/e-sNQmMA)

Qualities for an Engineering Manager, in 2 parts

- Part 1: <https://lnkd.in/gupBfs8j>
- Part 2: <https://lnkd.in/gnkwuAf3>

There are professional and interpersonal sides to this. Making adult friends is difficult, and there are sometimes added challenges (I have social stuff stemming from Autism), but making a work friend isn’t that much different than in your personal life. Are you interested in their work? Can you ask intelligent questions about it to show enthusiasm? Can you find some small way to help? Having *casual* 1:1s to catch up and “have coffee” may feel like a waste of time to some people, so definitely ask before scheduling that, but others find it a relief to take a step away from regular responsibilities.

From there, being visibly effective and caring as a leader is very useful in making allies that can be friends. Are you building bridges instead of walls? Do you take responsibility and provide solutions? If people know that coming to you leads to solutions, they are going to do it. If they are coming to you, it builds trust and respect. From that position it’s a lot easier to build a deeper relationship.

Are you unhappy with your comp now? If so, why? Are peers on your team with similar impact paid more? Are new hires getting larger offers (they always will)? Are outside companies paying more?

It’s OK to mention you are interested in expanding your impact, and for your compensation to match the impact you’re having now, but it probably won’t move the needle that much. Controlling the inputs (your impact, over delivery against role and level guidelines) has a real impact on the comp output. Your manager now doesn’t really. High ratings and promotion can be impacted by some politicking, but those are what get you paid, not talking now.

Outside offers can have an impact but it’s a weird game to play that I don’t love.

Do you code every day? Are you able to fluently code in your language or choice? If so, grinding leetcode likely isn’t where you need to focus. Do a few of these, and make sure you cover some major DSA categories. Work on speed a little, mostly just write scenarios out (loop types, graph traversal, cycle checking, etc) and be sure you can frame the approach in low ones of minutes so you can focus on the real work.

From there, START with a mock interview right now, before you tell them your timeframe. Know what you need to prepare, otherwise you’re just blindly throwing out a time more based on fear of underprep or of them pulling the plug without any objective plan with a timeline.

Do not overprep. Do not psych yourself out. Being ready is one thing, but trying to “crack it” with study and not having the skills is not a recipe for success even if you do get an offer.

After your mock interview, get detailed notes, choose a shortish turnaround, and do it again with someone else, or see if they can ask different questions.

Read a few tech blog entries or white papers addressing some of the company’s problems (or similar companies) to have an understanding of the current state of the art.

Write down the impacts of any significant work you’ve done so you have it handy for the interview. Have more examples than you expect to need.

Don’t endlessly ask for extensions. Get six weeks or whatever you decide now, and stick to it. If you are sick or have an emergency fine, but dragging it it will hurt your confidence.

Is your manager asking you to work this much, or do you feel pressure and are self-initiating that?

Be super aware you will end up going slower and producing with lower quality when you are working more than 8 (honestly more than 7ish) hours per day, and 36ish hours per week. I know we “have to” work 40 hours, but need to be honest that a lot of that is not really working.

From there, do you have supports other than your manager, like more senior members of the team?

What is the ramp up plan? Like is there documented stages? A timeline? You’re being told you aren’t ramping up “fast enough”, but what is fast enough and how far behind are you? Do you have a bug or project work that actually has an external deadline? I would argue that is not an effective way to ramp someone up.

From there do you have a mentor outside of your team that can give perspective without bias regarding your manager, and tell you if they believe you are behind? Do you have access to your manager’s manager to ask their opinion of your progress?

From there, the shift is going to be in behavior, perspective, and attitude, not how much time you put in. Ask your manager for regular checkins and hard goals. If you can’t meet them, ask why and get perspective from others on the team.

You were hired for a reason. You aren’t bad at this, but you need time. You may actually  be ramping slower than you “should”, and you need outside perspective on why that is. Maybe you need to just blast through a bug or two with no understanding to just show progress, maybe you need to pair program for a few days to get comfortable, maybe you’re using your tools inefficiently. You need to root cause before you can fix it. Again, no amount of time doing the wrong thing will fix it.

Good luck, god speed!