Feedback that I'm underperforming for my level. Is this PIP? What now?

Update for anyone interested. With Alex's guidance from the comments, I worked to turn the pre-PIP around.

The highlights:

• I immediately started candid conversations with my manager on expectations and what gaps I was missing. I spent my 1:1 meetings with him driving this myself. Inspired by this 1-1s are meant to be awkward video.
• I analyzed my last few diffs and created a doc of my diff shortcomings. Briefly presented it to my manager and it made a good impression. It was also a great exercise for myself in reflecting on my code quality.
• I dropped responsibilities that weren't in my manager's expectations and blocked huge chunks of focus time on my calendar.
• Followed advice in How To Write Better Code Faster As A Software Engineer and Level Up Your Code Quality as a Software Engineer Taro course.
• I went around asking my teammates for feedback (having awkward 1:1s again) and improved on it.

I landed in the Meet Most Expectations bucket during my performance review. They usually put engineers with this rating on PIP, but my manager noticed my improvement and did not. I was very lucky to have a manager and teammates who acknowledged my work, provided candid feedback, and believed I could turn things around. Fast forward to now and I'm consistently at Meeting Expectations now. I am doing relatively much better on the team and couldn't have done it without Taro!

I wanted to give kudos to Alex for his fast response to my question and guidance. I never would have been able to iterate on the critical feedback as well without it. Also want to shout-out Rahul for making the Ultimate Performance Improvement Plan guide. Though I was ultimately not put on PIP, the guide clarified the process for me and assuaged many of my fears.

Sorry to hear - Things are definitely bad, and I'm pretty sure you're at risk of a PIP. 😢 That being said, let's figure this out together. I think this is salvageable, especially since you were hired at L4. If this was L5 or L6, it would be far trickier.

I have a lot to say here, so I'll outline a step-by-step process across multiple comments:

Clean Up Your Mental State

• Software is a brutal field where a burnt out engineer working 80-work weeks can easily only be productive as an engineer with a clear mind working 30-hour weeks (yep, not even 40). I'm 99% sure you are somewhere in this camp.
• At the bare minimum, spend a weekend pretending that this isn't happening. During those 2 days, do something fun and live your life, preferably with friends and family.
• If you have some PTO stored up, try to take 1 week off (9 days if you have a weekend on each side of it). Tell your manager that you understand the feedback (and appreciate it), so you need this time to come back refreshed to earn your spot on the team.
• Come back from whatever break you take recharged, so you can actually follow through on my next steps.

Create A Doc Of Your Diff Shortcomings

• Someone repeatedly getting 5+ comments on their diffs is definitely a red flag, especially at L4.
• The good news is that these comments will rarely contain completely unique types of feedback after 3+ months.
• I have reviewed literally thousands of diffs from L3/L4/L5 engineers, and 90% of my comments are coming from ~50 patterns. Assuming 5 comments/diff, you should exhaust this in 15-30 diffs or 1-2 months at most companies.
• Go through your past 25 diffs at least, look at the comments, and extract those patterns into a checklist you run through pre-commit.
• You can dig deeper into this topic here: "How to ensure mistakes do not repeat?"

Level Up Your Technical Planning

• A big piece of the L3 -> L4 jump is a clear evolution with proactive thinking around code (i.e. how to write it well).
• This is reflected in the scope taken on. With an L3, I expect them to take on tasks that are 1 month or less in time-scale. With an L4, I expect them to own meaningful slices of entire projects that are 1-3 months in time-scale (sometimes an L4 can even own the entire project if the scale is local enough).
• With this increased time-scale, it is extremely foolish to tackle your work without a thorough plan. So how does this manifest? Like in my prior comment, as a technical document.
• For anything >1 week, I recommend using whatever task-level object you have (Jira ticket, Asana task) to put down details (project context, code structure strategy, edge cases, rollout plan).
• For anything >1 month, I recommend making a full-on product spec/system-design doc. It's like the task-level one but in far more detail.
• After you have created these artifacts, socialize it among the team to get feedback. If the project is big enough, book a meeting. Treat all the feedback as a gift and address it ASAP.
• For a great resource to model off of alongside a more thorough breakdown of steps, check this out: System Design Masterclass: Taro Playlists

Answering Your Questions

Is this a sign to leave my team or company? And the profession? Despite my best efforts, I'm disappointing my team and it's taking a toll.

No and no. People get over-leveled all the time. It happens. Doing the time math, you were hired in mid-2022 when the market was at peak and layoffs weren't really a thing yet. That was also a time before RTO, and remote work is devastating for earlier-in-career engineers like yourself. This isn't your fault.

I haven't been served a PIP yet, but is this a sign that it's coming?

I think this is likely "pre-PIP", and whether it comes will depend mostly on the next 2 months (the remainder of Q1). However, I strongly believe that you can produce clear, positive, and impressive behavior change within 2 months. 2 months is a long time.

Naive take, but is it a bad idea/even possible to ask for a downlevel? The reasoning was that I'd rather keep my job than lose it.

I wouldn't throw in the towel yet, and the policy here will depend on company. Meta was pretty much 100% against it (there were very, very, very few exceptions). If the PIP does come, then you can try this as a last resort, but I wouldn't dwell on this right now.

Any advice?

I know that this is easier said than done, but believe in yourself. The only true limitations a software engineer has are how fast they can type and speak words to people. At the end of the day, we all have the same 24 hours, including your high-performer teammates. The difference between a L6 and an L4 or a high-performer vs. a low-performer is that the high-performing seniors are making better decisions across the hundreds of micro and macro decisions they get presented throughout each day.

Relentlessly Sharpen Your Productivity

• Go as scorched earth as possible on your calendar as you can. Delete any meetings where you don't have a >20% chance of speaking within them. Identity meeting series where you're just sitting through them and kill those.
• For your remaining meetings, group them up on certain days as much as possible to create focus days where you can do deep work.
• Have Slack/Teams closed throughout the day. Only open it 3 times a day to batch responding to messages (beginning, middle, and end of day).
• Ignore tasks that aren't part of your core roadmap work. Learn to say "No". Follow the advice here: "How to figure out what the most important projects are?"
• If you have 80 minutes, go through this: [Masterclass] How To Write Better Code Faster As A Software Engineer

Thanks Alex. I had a follow-up with my manager recently. I presented a doc on my growth gaps based on his prior feedback and the role guidelines and analysis on my most recent code commits to discuss the code metrics we focused on. But my manager said it was less about the number of comments and the small issues we pointed out in the code and more about reducing the amount of back-and-forth and building trust among my teammates. He said he would mainly rely on peer feedback as a sign of improvement. But there was some mention of metrics like the number of diffs compared to the rest of the team and less-back-and-forth sounds like fewer revisions. I asked him for specific examples for improvement and he told me it was in everything I worked on. So these points felt pretty demoralizing. I'm not sure how supportive my manager is. He's been pretty hands-off so far.

He also asked me to set some milestones for my current project for this quarter and he'll evaluate whether I'm meeting those deadlines and matching the standards for code quality. I'm supposed to get my formal performance review in the coming weeks, so am feeling antsy.

What your manager says makes sense: The subjective feedback from peers is the most important angle at the end of the day. Engineering metrics are just really tricky to talk about, which is why managers will almost always give a "politically correct" answer when they're brought up (i.e. "There's more to it than just numbers"). But at the end of the day, numbers do matter:

• If an engineer always gets 10 comments per diff and takes ~5 revisions to land each commit - There are very few engineers who can do this and still be meeting expectations.
• If an engineer only gets 0-1 comments per diff and lands their commits on the first try 95% of the time - In 99% of cases (assuming the team is giving thorough code review), this means that the engineer has stellar code quality and is likely a high performer, especially as an L3 or L4.

In terms of your manager's level of support, it feels at least neutral to me. Your manager isn't reviewing your diffs (a good EM shouldn't be), so they need to get this signal from your teammates.

Make it your goal to dazzle your code reviewing colleagues with immaculate quality. If you want an in-depth example, check out this GitHub PR: https://github.com/Gear61/tcg-android-archive-and-feedback/pull/19