TL;DR

You must treat chronic underperformance by a senior individual contributor as a business risk requiring immediate documentation, not a coaching opportunity to be nurtured indefinitely. The market does not reward your patience; it penalizes your inability to make hard personnel decisions within the first 90 days of identifying the gap. Your legacy as a manager is defined by the team you build, not the loyalty you show to someone who refuses to adapt to your startup's velocity.

Who This Is For

This analysis targets first-time engineering or product managers at Series A to Series B startups who inherited a senior engineer hired during the seed stage. You are likely managing a team of six to ten people while reporting directly to a CTO who is too busy with fundraising to manage personnel conflicts. Your current compensation package sits between $145,000 and $175,000 base salary with 0.15% to 0.4% equity, and you are losing sleep over a specific report who dominates architectural discussions but ships less code than your mid-level hires. You feel paralyzed because this person holds institutional knowledge about the legacy codebase, yet their output has dropped 40% over the last two quarters. You need a framework to resolve this without burning down the engineering culture or getting fired for inability to execute.

Why does a senior IC stop performing after joining a high-growth startup?

The decline in performance is rarely a skills gap; it is almost always a misalignment between the individual's desire for stability and the startup's requirement for chaotic iteration. In a Q3 leadership debrief at a late-stage unicorn, I watched a hiring manager defend a principal engineer who had missed three critical launch dates by claiming the engineer was "perfecting the architecture." The reality was that the engineer had optimized their career for deep, uninterrupted work blocks that no longer existed in a company pivoting every six weeks. The first counter-intuitive truth is that seniority often breeds fragility in early-stage environments, not resilience. These individuals were hired for their ability to build scalable systems, but as the startup shifts from building infrastructure to shipping features, their definition of quality becomes a bottleneck.

Consider the case of a staff engineer I evaluated who refused to use the new CI/CD pipeline because he deemed it "unstable," forcing the rest of the team to manually deploy hotfixes. This was not a technical judgment; it was a resistance to losing control. When you inherit a senior IC who was a founding member or an early hire, they often view the codebase as their personal fiefdom. Their performance drops because the metrics of success have changed from "system elegance" to "time to market," and they refuse to update their internal scorecard. The problem isn't their coding ability; it is their refusal to accept that the company has outgrown the phase where their specific type of perfectionism adds value.

You must recognize that high compensation acts as a golden handcuffs scenario that exacerbates the issue. A senior IC earning $210,000 in total compensation at a Series B company has little financial incentive to take the risks required to ship quickly. They have optimized for job security and technical purity, while your startup needs velocity and adaptability. In a specific incident involving a fintech startup, a senior backend engineer spent three weeks refactoring a payment module that was already functioning, delaying a regulatory compliance deadline. When confronted, he argued technical debt, but the subtext was a fear of obsolescence if the stack moved too fast. Your judgment call here is to realize that their underperformance is a rational response to their incentives, not an accidental slip-up.

How do I document underperformance without creating a legal liability for my startup?

Documentation must focus exclusively on business impact and missed deliverables, stripping away all subjective adjectives regarding attitude or culture fit. Legal liability arises when managers rely on vague notions of "not being a team player" rather than concrete instances where work was not completed to the defined standard. The second counter-intuitive truth is that being too nice in your written feedback creates the legal risk, not being direct. In a termination review I sat in on, the company lost a potential wrongful termination claim because the manager's Slack messages praised the employee's "deep thinking" while the formal review cited "lack of output." This contradiction gave the employee's lawyer the ammunition to argue the firing was pretextual.

Your documentation protocol must begin immediately, not after you have decided to fire the person. Start a dedicated log where you record specific dates, expected outcomes, and actual results. For example, instead of writing "John is slow," write "On October 14, John committed to delivering the API gateway integration by October 20; the feature was not merged until October 28, delaying the mobile team's sprint by five days." This level of granularity removes emotion and leaves no room for interpretation. You are building a timeline of facts that demonstrates a pattern of failure to meet agreed-upon business objectives. If you do not have a written record of the expectation and the missed deadline, you do not have a performance case; you have a personality conflict.

Avoid the trap of documenting "potential" or "future possibilities." Many first-time managers write reviews saying, "John could be a great leader if he communicated better." This is a trap. It suggests the problem is solvable with time, which undermines your argument that the performance is unacceptable. Instead, frame every entry around the cost to the business. "The delay in the API gateway forced us to delay the beta launch, resulting in a loss of potential user feedback data for two weeks." This connects the individual's action directly to company revenue or strategic goals. In the Silicon Valley legal landscape, courts and arbitrators look for a clear line between business necessity and managerial whim. Your documentation must draw that line with a sharpie, not a pencil.

Furthermore, ensure that every piece of feedback given verbally is followed up with an email summary within 24 hours. The script is simple: "Thanks for the chat today. To recap, we agreed that the priority is to ship the login flow by Friday, and any architecture discussions will happen post-launch. Please confirm if this matches your understanding." This creates a paper trail of agreement. If they ignore the email or argue with the summary, you have documented insubordination or misalignment, which are separate but compounding performance issues. Do not rely on memory. Do not rely on the employee's word. In a high-stakes termination involving a $220,000 earner, the difference between a clean separation and a six-month legal battle is often a single email chain confirming expectations.

What specific steps should I take to put a senior IC on a Performance Improvement Plan?

A Performance Improvement Plan (PIP) for a senior individual contributor must be structured as a 30-day sprint with binary pass/fail criteria, not a six-month journey of self-discovery. The third counter-intuitive truth is that a PIP is not a tool for improvement; it is a tool for managed exit and legal protection. Most first-time managers make the mistake of designing a PIP that looks like a coaching plan, filled with vague goals like "improve communication" or "mentor juniors." This is fatal. A senior IC can argue endlessly about whether they improved communication. They cannot argue about whether they shipped a specific ticket by a specific date.

Design the PIP with three to four specific, measurable deliverables that are undeniably within the scope of their role and achievable within the timeframe. For a senior backend engineer, a valid goal is "Complete the migration of the user service to the new database schema with zero downtime by Day 21." An invalid goal is "Demonstrate better ownership of the migration process." Notice the difference? One is a fact; the other is an opinion. If they fail to migrate the database, they fail the PIP. There is no debate. You must also include a clause that states any new critical bugs introduced during this period will result in immediate failure. This prevents them from rushing work to meet the deadline while destroying quality.

Before presenting the PIP, align with your HR business partner and your manager on the "off-ramp." You need to know exactly what happens if they pass (rare) and what happens if they fail (likely). In a recent debrief at a cloud infrastructure company, a manager presented a PIP without pre-aligning on the severance package. When the employee failed the PIP, the company had to negotiate a settlement of four months' salary plus continued equity vesting because they hadn't prepared the exit terms. Your preparation must include the separation agreement draft before you ever walk into the room. The conversation should be cold and clinical: "Here are the gaps. Here is the plan to address them over the next 30 days. If these specific outcomes are not met, your employment will end."

During the weekly check-ins, do not offer encouragement or soften the blow. Your role is to observe and record. If they ask for help, provide resources, but do not do the work for them. A common failure mode is the manager stepping in to save the project when the senior IC stalls. If you save them, you invalidate the PIP. Let them miss the deadline. Let them struggle. The data point you need is their inability to execute without your intervention. If they require your constant hand-holding to meet the goals of a senior role, they are not performing at a senior level. Document every instance where you had to intervene. This evidence is crucial for the final decision.

When is the right time to terminate a high-salary senior engineer who holds institutional knowledge?

The right time to terminate is the moment you realize that their institutional knowledge is being used as leverage to avoid accountability rather than to accelerate the team. Holding the company hostage with "only I understand this code" is not a retention strategy; it is a fireable offense in a mature organization. The fourth counter-intuitive truth is that keeping an underperforming senior IC actually destroys institutional knowledge faster than firing them, because they stop documenting and start gatekeeping to protect their status. In a Series C startup I advised, we kept a founding engineer for eight months past his prime because of fear about the legacy billing system. In those eight months, he documented nothing, and when he finally left, we spent $150,000 in contractor fees to reverse-engineer his logic.

You must calculate the "bus factor" cost versus the "toxicity" cost. If one person holds the keys to the kingdom and is underperforming, your immediate priority is to extract that knowledge, not to fix the person. Initiate a "knowledge transfer sprint" immediately upon deciding to move toward termination. Assign a mid-level engineer to pair with the senior IC specifically to document the critical paths. Frame this as a promotion opportunity for the mid-level engineer and a mentoring goal for the senior. If the senior IC refuses to cooperate or sabotages the transfer, you have your final piece of evidence for cause termination. Do not wait for the perfect moment; the perfect moment passed three months ago.

Timing also matters regarding equity vesting cliffs. While you should never keep someone solely because of equity math, be aware that terminating someone right before a 4-year cliff or a liquidity event can trigger significant morale issues and potential litigation if not handled with extreme precision. However, do not let this paralyze you. It is better to pay out a portion of accelerated vesting in a separation agreement than to carry a dead weight for another year. In a negotiation I witnessed, a company offered a departing senior IC two months of accelerated vesting in exchange for a full release of claims and a two-week knowledge transfer period. The employee took the deal, the team got the documentation, and the culture improved within a month.

Trust your gut on the cultural rot. If other high performers are starting to question why the underperformer is still there, you have already lost them. High performers hate inequity more than they hate hard work. When they see a senior IC collecting a $200,000+ salary while shipping half the volume of a junior, they assume leadership is incompetent or cowardly. This erosion of trust is harder to repair than the loss of code knowledge. Make the cut, pay for the transition, and rebuild the system with people who want to be there. The market is full of talented seniors who will respect your standards; do not let one bad actor convince you otherwise.

Preparation Checklist

  • Draft a chronological log of missed deadlines and specific business impacts dated within the last 60 days.
  • Prepare a 30-day PIP document with binary, measurable deliverables that require no subjective interpretation.
  • Align with HR and legal on the separation agreement terms, including severance multipliers and equity acceleration, before the first meeting.
  • Identify a mid-level engineer to shadow the senior IC for immediate knowledge extraction and documentation.
  • Work through a structured management framework for difficult conversations (the PM Interview Playbook covers handling high-stakes personnel conflicts with real debrief examples from FAANG leadership).
  • Script the opening statement for the PIP meeting to ensure it is direct, factual, and devoid of emotional padding.
  • Schedule weekly 30-minute check-ins strictly for status updates, ensuring a witness or HR representative is present or copied on summaries.

Mistakes to Avoid

BAD: Treating the PIP as a genuine coaching opportunity where you hope the employee will turn things around with enough support.

GOOD: Treating the PIP as a formal legal process designed to validate a termination decision if specific, pre-defined metrics are not met.

Why: Hope is not a strategy. If you are not willing to fire them on Day 31, you should not start the PIP on Day 1.

BAD: Using vague language like "needs to step up" or "show more leadership" in written documentation.

GOOD: Using quantitative language like "failed to merge PR #402 by the agreed date of Nov 12" or "missed three standups without notice."

Why: Ambiguity allows the employee to argue interpretation; facts close the loop.

BAD: Allowing the senior IC to continue owning critical path items without a shadow during the PIP period.

GOOD: Immediately assigning a secondary owner to all critical tasks to mitigate risk and facilitate knowledge transfer.

Why: Betting your product launch on an underperformer is negligence, not loyalty.

FAQ

Can I fire a senior IC immediately without a PIP if they are underperforming?

In most US at-will employment states, yes, you can terminate immediately without a PIP if you have documented prior warnings and clear evidence of performance failure. However, skipping a PIP increases legal risk and removes the chance for a clean, agreed-upon exit. A PIP provides the procedural fairness that protects the company from wrongful termination claims, especially for high-salary employees who can afford litigation. Only skip the PIP if the behavior involves harassment, theft, or gross misconduct.

How much severance should I offer a senior engineer we are letting go?

Standard severance for a senior individual contributor in Silicon Valley ranges from two to four months of base salary, often contingent on signing a release of claims. For employees with over four years of tenure, offering an additional month per year of service is common practice to ensure a smooth transition. Equity acceleration is negotiable; offering 50% to 100% of the next year's vesting can secure a faster knowledge transfer and a non-disparagement agreement. Do not be stingy; the cost of severance is lower than the cost of a lawsuit or team morale collapse.

What if the senior IC claims age discrimination when I put them on a PIP?

If your documentation focuses strictly on recent, specific instances of missed deliverables and business impact, age discrimination claims will not hold water. Ensure your PIP goals are identical to what you would set for a 25-year-old in the same role. Avoid any comments about them being "out of touch" or "slow to adapt." Stick to the data: dates, tickets, and outcomes. If you have a pattern of documenting performance issues consistently across all ages on your team, the claim lacks merit. Consult legal counsel immediately if they raise this flag.

The 0→1 PM Interview Playbook (2026 Edition) — view on Amazon →