The hardest conversation I had in 2025 was firing a senior engineer I had hired

I hired Daniel in March. His interview was one of the best I had ever conducted. Sharp technical thinking. Excellent communication. Deep experience with distributed systems at a company much larger than ours. He passed every round with high confidence scores. The team was excited.

By June, I knew it was not working. By August, the team knew. By October, I made the call. Three months of coaching and two performance improvement plans later, Daniel was gone. It was the hardest conversation I had in 2025, and it was my fault in ways I did not fully understand until after.

Generate a realistic hiring editorial scene with pull request diff, handwritten notes, laptop on a desk, soft overhead lighting, 16:9, no staged interview smiles, no stock-photo office feel.

Most of the leadership posts in this phase are me compressing scar tissue into defaults. It also builds on what I learned earlier in “How I budget engineering time and why I give 20 percent to platform work non-negotiably.” I am less interested in performative management language now and more interested in the boring mechanisms that keep teams aligned when nobody is in a heroic mood.

Editorial supporting image for the section "What Went Wrong" in the article "The hardest conversation I had in 2025 was firing a senior engineer I had hired". Show conference-room table or desk with planning notes, incident timeline, dashboard printouts, half-drunk coffee, and a worn notebook for "The hardest conversation I had in 2025 was firing a senior engineer I had hired". Focus on one operational artifact that makes the post feel lived-in rather than conceptual. Color palette: slate, amber, off-white paper, low-contrast office shadows. Mood: measured, confident, strategic, scarred enough to sound calm while saying hard things. Composition: 16:9 landscape image, documentary/editorial feel, no text overlays, no stock-photo polish. Avoid: No staged handshake photos, no smiling meeting stock imagery, no motivational poster energy, no text overlays.

What Went Wrong

Daniel was a genuinely talented engineer. The problem was not his skill. The problem was the operating environment. At his previous company, a 2,000-person engineering organization, he had clear specifications, dedicated project managers, established processes, and a support structure that handled everything except the technical work.

At FinanceOps, a 12-person company with 5 engineers, none of that existed. Daniel needed to:

• Write his own specifications from conversations with stakeholders who were not engineers.
• Manage his own timeline with no project manager to buffer between business pressure and engineering reality.
• Make architectural decisions with incomplete information and no architect to validate them.
• Ship to production without a QA team, staging environment with realistic data, or a comprehensive test suite for every edge case.
• Context-switch between three workstreams in a single day because the team was too small for single-threaded work.

Daniel was not bad at these things. He was visibly uncomfortable with the ambiguity. He asked for specifications that did not exist. He waited for approvals that nobody was going to give. He wrote design documents for decisions that needed to be made in an afternoon. The pace of a startup requires a comfort with imperfection that his career had never demanded of him.

What I Should Have Caught in the Interview

Looking back, the interview process failed to test for the one thing that mattered most: ability to operate effectively with minimal structure.

• We tested technical skill. Daniel had it. Technical skill is necessary but not sufficient for a startup senior engineer.
• We tested communication. Daniel was articulate. But communication in a structured interview and communication in the chaos of a startup standup are different skills.
• We did not test autonomy under ambiguity. We should have given Daniel a vague problem statement and observed how he navigated the ambiguity. Not whether he got the right answer, but whether he was energized or paralyzed by the uncertainty.
• We did not test pace. The interview happened over a week. At a startup, the equivalent decisions happen in a day. Speed of context-switching, speed of decision-making, speed of adaptation. We never tested any of it.

The Performance Management Process

When I first noticed Daniel struggling, I made the classic mistake: I assumed it would get better with time. It did not. By the time I initiated formal performance management, three months of the team working around Daniel’s struggles had created resentment that was hard to undo.

The performance improvement plan was specific. Three measurable objectives over four weeks. Ship a feature end-to-end without a specification document being written for him. Make three architectural decisions independently and document the reasoning. Lead a production deployment including the on-call follow-up. These were not unreasonable expectations for a senior engineer. They were the minimum bar for operating at our scale.

Daniel completed one of the three objectives. The other two stalled in the same pattern: waiting for clarity that was not coming, writing proposals that needed to be decisions, and seeking consensus where ownership was the requirement.

The Conversation

The termination conversation lasted twenty minutes. I was honest about what had not worked and why. I was clear that the failure was mutual: our interview process had not tested for what mattered, and the role was not what his career had prepared him for. Daniel was gracious. He had seen it coming.

The team’s reaction was relief, not celebration. They had been carrying extra load for months. One engineer told me: “I wish you had done this two months ago.” She was right. I had waited too long because the conversation was hard and I kept hoping the next PIP cycle would be different.

What I Changed

• The interview process now includes an ambiguity exercise. Candidates get a deliberately vague problem and ninety minutes. We evaluate how they structure the ambiguity, not whether they solve the problem.
• Reference checks now specifically ask: “How did this person perform when processes were immature or absent?”
• I initiate performance conversations earlier. If I notice a pattern in the first month, I address it in the first month. Waiting is not compassion. It is avoidance.
• I stopped hiring for prior company prestige. A senior engineer from a large company is not a senior engineer at a startup. The skills overlap but do not match.

Create an editorial desk scene about engineering hiring judgment: scorecards, code review notes, subtle authority, 1:1, natural shadows, no HR stock-photo look.

By the time I wrote this, the lesson was bigger than the tool or incident. The job had become setting defaults a team could trust, then proving those defaults in systems like lifeos and bisen-apps. That is leadership work, not just technical taste.

Performance management is the most important and least taught leadership skill. Nobody teaches you how to fire someone you like and respect. You learn by doing it badly and then doing it better.

Daniel is now at a mid-stage company with 200 engineers. He is thriving. The environment matches his strengths. The failure was not in his ability. It was in the match between his operating style and our operating environment. My job is to get that match right, and I got it wrong.