Before You Fire a Technical Employee, Diagnose the System

A senior data engineer misses a delivery date. The visible fact is simple. The cause may not be.

Perhaps the engineer cannot do the work at the required level. Perhaps the project depends on a source system that changes without notice. Perhaps nobody decided who owns data quality. Perhaps an AI coding assistant helped the team produce more code while review, testing, and architecture fell behind. Or perhaps the manager has quietly changed the definition of success three times.

All of those situations can look like underperformance on a status report. They demand different responses.

Employee termination is a legal and human process, and the rules vary by jurisdiction, contract, policy, union agreement, and individual circumstances. Managers should involve qualified HR and legal professionals rather than treating an article as legal advice. But before a formal process begins, a technical leader still has an important management responsibility: diagnose what is actually failing.

This note offers a decision record for that diagnosis. It is not designed to make dismissal easier. It is designed to make managerial reasoning clearer, earlier, and fairer—while there is still time to improve the work, change the role, or correct the system.

Start with four competing explanations

When a person is struggling, managers often form a story too quickly: careless, slow, resistant, not senior enough, or “not a fit.” Those labels compress a complicated situation into a judgment about character. They also make it difficult to see evidence that points elsewhere.

Use four hypotheses instead:

These explanations can coexist. A machine learning engineer may have a real skill gap while also working with no evaluation dataset and an impossible deadline. A manager does not have to excuse the gap to acknowledge the system. The objective is to assign causes accurately enough that the response can work.

This distinction matters in technical organizations because outputs are highly interdependent. A software feature can be late because of the developer, the interface contract, the security review, the test environment, or a product decision that never arrived. An unreliable RAG application can reflect weak implementation, but it can also reflect missing source ownership, unsuitable documents, or quality criteria that were never defined.

Write the performance decision record before writing the verdict

The central artifact is a short record that a neutral reviewer can understand without hearing the manager’s private interpretation. It should answer seven questions.

1. What did the role require at that time?

Describe the expected outcome, quality, timing, and authority in plain language. “Show more ownership” is not an observable standard. “Identify blocked dependencies within one working day, propose options, and record the agreed decision” is closer.

Technical roles change quickly. If an analyst was hired to build dashboards but is now expected to deploy autonomous agents, the new expectation cannot be treated as if it always existed. Record when the work changed, what learning or transition support was offered, and whether the role level still matches the responsibility.

2. What happened, based on observable evidence?

Use work evidence: missed acceptance criteria, incident records, review comments, customer impact, delivery history, support tickets, or agreed milestones. Separate facts from inference.

“The deployment caused three priority incidents in six weeks” is a fact that can be checked. “She does not care about reliability” is an interpretation. The first can begin a useful conversation. The second invites a debate about motive.

Metrics need context too. Lines of code, story points, tickets closed, prompt count, or AI-generated pull requests are weak proxies for contribution. A staff engineer may reduce output while preventing an expensive architectural mistake. A platform engineer may appear slow because the work removes risk for everyone else. If the measure cannot distinguish valuable work from visible activity, do not let it carry the decision.

3. Was the expectation understood?

Managers routinely confuse sending a message with creating shared understanding. Check whether the person could explain the standard, the reason for it, the deadline, the tradeoffs, and what to do when blocked.

This is especially important for distributed teams and cross-functional AI work. A product manager may optimize adoption, a model engineer quality, a platform team cost, and risk staff control. Unless leadership resolves those tensions, each person can reasonably believe another person is underperforming.

4. Did the person have a reasonable path to succeed?

List access, time, staffing, documentation, training, decision rights, and dependency support. Do not ask only whether resources technically existed. Ask whether they were usable.

A data scientist with warehouse access but no reliable label definition does not have what the task requires. An engineer told to evaluate an agent but given neither representative test cases nor permission to inspect traces cannot provide meaningful assurance. A team expected to own production quality without the ability to delay release does not truly own quality.

5. What feedback and support were provided?

Feedback should arrive close enough to the work that the person can change the next attempt. A surprising annual review is usually evidence that the management loop was too slow.

Record the conversation, the employee’s response, the support offered, and the next review point. The record is not a secret diary for collecting negative impressions. It should reflect an actual operating conversation. If the employee disputes a fact or identifies a dependency, capture that as well and investigate it.

6. Are comparable cases treated consistently?

Ask how the organization responded when other people missed a similar standard. Differences may be justified, but they should have a reason connected to the work—not status, likability, protected activity, or convenience.

The U.S. Equal Employment Opportunity Commission advises employers to apply discipline policies consistently, document reasons, and be able to justify different treatment. Its broader termination guidance also warns against decisions based on protected characteristics or retaliation. Exact obligations differ across locations, but consistency is a strong management test anywhere.

7. What evidence would change the decision?

This is the anti-bias question. If the honest answer is “nothing,” the record is being written after the verdict. Identify what would support each hypothesis and what successful change would look like.

The manager may still conclude that employment should end. But a decision that can respond to evidence is more trustworthy than a narrative assembled to defend an intuition.

Diagnose the work at the level where it failed

AI, data, and software work creates an attribution problem. Tools now help people draft code, tests, analysis, documentation, and messages faster. That can increase visible production without clarifying who exercised judgment or where a failure originated.

Suppose an engineer repeatedly merges AI-assisted code that later breaks. “Stop using AI” and “be more careful” are both weak responses. Inspect the workflow:

• Were review requirements explicit for generated code?
• Did tests cover the failure mode?
• Could reviewers see what changed and why?
• Was delivery speed rewarded while review time was constrained?
• Did the engineer ignore a known control, or did the team never establish one?
• Did the same issue occur when other people used the tool?

If one person bypassed a clear control repeatedly, that is evidence about individual performance or conduct. If the whole team is shipping unverified output because leadership measures only throughput, the incentive system belongs in the diagnosis.

The same logic applies to model quality. Do not hold one engineer responsible for an undefined concept of “good answers.” Define evaluation cases, unacceptable failures, escalation rules, latency and cost limits, and who approves changes. Performance becomes easier to discuss when the system produces evidence rather than opinions.

For a broader operating model, see The AI Manager’s Operating System for Better Teams. Its central lesson applies here: people management and system design are connected.

Improvement plans should be experiments, not traps

A performance improvement plan can be legitimate support, a formal warning, or a procedural step toward termination. Ambiguity about which one it is destroys trust. HR should define the formal process, while the manager should make the working expectations comprehensible.

A credible improvement period needs:

• a small number of outcomes within the person’s control;
• observable quality standards rather than personality labels;
• support and resources tied to the diagnosed cause;
• review points frequent enough to correct course;
• a clear duration and possible outcomes;
• a way to record new evidence or changed conditions; and
• no surprise criteria introduced near the end.

Avoid creating a miniature version of an impossible job. “Deliver all overdue projects in 30 days with zero defects” may document failure, but it does not test whether improvement is possible. Choose representative responsibilities and realistic evidence.

The UK’s Acas guidance provides a useful general principle even for readers outside that jurisdiction: for capability issues, employers should support improvement, provide adequate resources, consider suitable changes or roles, retain evidence, and treat dismissal as a last resort. Its current capability and conduct guidance also emphasizes following a fair procedure. Local law and organizational policy still control, but the management logic is sound.

Support does not mean endless delay. A plan needs a decision date. If the standard is essential, the support was real, the evidence is fair, and improvement does not occur, postponing the conclusion can harm teammates who repeatedly absorb the work. Compassion for one person should not become invisible overload for everyone else.

Some performance cases are actually role-design cases

A technically capable employee may be in the wrong shape of job. The strongest individual contributor becomes a manager and struggles with conflict. A careful research-oriented data scientist is placed in a rapid customer-delivery role. A backend engineer is expected to become the product owner for an AI feature without the authority or desire to do so.

Do not romanticize reassignment. A suitable role may not exist, and moving a problem without consent or support can spread it. But test the option honestly before declaring the person broadly incapable.

Ask three questions:

1. Where does this person produce reliable value today?
2. Which essential duties remain persistently unmet?
3. Is there a real organizational need that matches the first answer without hiding the second?

This is also where personal strain and disability may intersect with performance. Managers should not diagnose health conditions, demand unnecessary disclosure, or improvise legal conclusions. They should engage HR, follow applicable accommodation processes, preserve privacy, and keep the conversation focused on work and support. How Tech Leaders Can Handle Personal Strain at Work explores that boundary in more detail.

Conduct, capability, and redundancy must not be blended

Poor performance is different from misconduct. Both are different from a role disappearing because strategy, budget, or organization changed. Blending them may feel administratively convenient, but it makes explanations less honest and comparisons less fair.

If the company eliminated a product line, say that the role was affected by an organizational decision. Do not manufacture a sudden performance story to make the decision feel individualized. If a security incident may involve misconduct, investigate facts and follow the appropriate process rather than disguising it as a coaching conversation. If the problem is capability, make expectations and support central.

This separation also protects organizational learning. A redundancy may reveal a portfolio error. Repeated capability problems may reveal weak hiring or onboarding. Similar conduct incidents may reveal unclear controls. Calling every exit “not a fit” prevents the organization from seeing its own pattern.

Use independent review at the highest-risk moments

Before a consequential decision, ask a qualified, sufficiently independent reviewer to inspect the record. That may include HR, employee relations, legal counsel, an EEO specialist, or another authorized leader, depending on the organization and jurisdiction.

Independent review is especially important when:

• the employee recently raised a safety, discrimination, harassment, pay, ethics, or compliance concern;
• leave, disability, accommodation, pregnancy, union activity, or another legally protected matter may be relevant;
• past reviews were strong but the current assessment changed suddenly;
• comparable employees were treated differently;
• the manager is personally involved in the underlying conflict; or
• the evidence depends heavily on subjective judgments.

The EEOC’s retaliation guidance specifically recommends independent evaluation of a proposed adverse action following protected activity and review of whether performance assessments have a sound factual basis. That is not a paperwork detail. It is a safeguard against a manager’s conflict becoming the organization’s decision.

AI should not be the independent reviewer. A model may help organize authorized, appropriately protected information under approved policy, but it should not decide credibility, infer emotion, rank employees for dismissal, or convert incomplete records into false certainty. Employment decisions can involve sensitive personal data, bias, explainability, and legal obligations. Human accountability cannot be delegated to a score.

The same discipline discussed in Reduce Bias in AI Team Decisions applies to human performance decisions: define criteria, examine counterevidence, and make the review process visible enough to challenge.

The termination meeting is not the place to finish the diagnosis

By the time a lawful termination meeting occurs, the factual and procedural work should already be complete. The meeting should not become a fresh argument, a performance review, or a search for one more justification.

Follow the plan created with HR and legal professionals. Communicate the decision clearly and respectfully, explain the approved reason at the appropriate level, cover practical next steps, and protect privacy. Coordinate access changes carefully, especially for privileged technical roles, but do not let an automation announce the outcome before a person does. Security and dignity are both design constraints.

Afterward, address the team without exposing confidential details. Clarify work ownership, service coverage, decision rights, and how concerns can be raised. Do not recruit the remaining team into validating the decision through gossip.

Then conduct a management review separate from the employee record:

• Were expectations clear early enough?
• Did feedback arrive while it was useful?
• Did hiring or onboarding contribute?
• Did workload or dependencies make failure more likely?
• Did the team carry hidden knowledge that is now a continuity risk?
• Did leadership delay because one person had become operationally indispensable?

That review is not about reversing responsibility. It is about preventing the next case.

A fair decision begins before performance declines

The quality of a termination decision is largely determined months before anyone considers termination. Teams need explicit roles, usable goals, frequent feedback, documented decisions, safe escalation paths, and work systems that reveal blocked dependencies. New managers in particular benefit from building these mechanisms early; New Managers Need Systems, Not Confidence explains why management cannot rely on personality alone.

No framework can remove the difficulty from ending employment. Nor should it. The decision affects income, identity, colleagues, customers, and the credibility of leadership. But difficulty is not an excuse for vagueness.

Diagnose capability, role fit, conduct, and system conditions separately. State expectations in observable terms. Test whether the person had a reasonable path to succeed. Examine comparable cases. Invite independent review. Use local expertise for the legal and procedural work. And keep AI in the role of a constrained tool, never the accountable decision-maker.

Sometimes the evidence will support continued coaching. Sometimes it will point to a different role or a broken operating system. Sometimes it will support termination. A responsible technical leader should be prepared for any of those conclusions—and should know which evidence led there.