Почему умных и продуктивных увольняют?

Why “smart and productive” people get fired (core argument)

• In downturns and tighter budgets, engineering performance is increasingly judged by measurable productivity + visibility + business impact, not just code quality.
• “Smart/productive” employees still get cut when they fail to create a gap-closure loop:
  1. Deliver good work, but
  2. Ensure it is understood, articulated, and owned in a way decision-makers can evaluate (outside their team).

Business-specific shifts in evaluation (a “new playbook” for survive/retain)

The presenter describes 3 organizational shifts in how engineering work is assessed:

• Productivity is now a “hygiene factor”

  • Not enough to be good—employees must be consistently productive.
  • Analogy: clean hands are mandatory, but don’t make you a chef.

• Visibility beats raw output volume

  • Promotion/retention depends on how many people and which leadership roles know what you did, and can explain the business need.
  • In growth markets: visible projects were rewarded; in falling markets: the less-visible become easier to cut.

• AI changes what “engineering work” value means

  • AI accelerates certain tasks; high-quality “manual speed” and “code-writing output” depreciate faster than demand for people who can:
    • use AI well, and
    • exercise judgment.
  • Engineering remains valuable, but the differentiator shifts from writing code quickly to:
    • using AI effectively,
    • maintaining judgment,
    • articulating business value,
    • participating in decisions.

Framework: “The gap” that triggers layoffs

The presenter claims layoffs happen less because of raw incompetence and more because of two specific gaps:

• Gap 1: Productivity definition mismatch

  • Productivity is evaluated differently than “what the person thinks productivity is.”

• Gap 2: Low participation/ownership in decisions

  • Even strong work may not be translated into stakeholder understanding and decision impact.

Concrete KPIs / assessment criteria (what leaders look for)

Directly asked/implicit metrics in the session

• External awareness metric

  • Practical check: “How many people outside your team know what you did in the last month (and can explain why the business needed it)?”
  • If the answer is 0 / 1 / 2 people → “wake-up call.”

• Initiative frequency

  • Meter question: “How often in the last month did you suggest what to do—not just how to do it?”
  • Takeaway: initiative increases odds of being noticed.

• Decision influence

  • Meter question: “Any influence in the last 3 months on decisions outside your team?”

• Performance review clarity

  • Instruction: identify three specific criteria by which you’re evaluated.
  • If you can’t name them → red flag.

• Value articulation

  • Asked as: “Can you explain in two sentences why your latest (bigger-than-task) project was needed by the business?”
  • Uses “conditional epics” as the level above tasks.

“Six zones” of employability risk (self-diagnosis rubric)

The presenter provides a 6-part competency risk map; the weakest area increases layoff probability:

1. Adaptation to AI
2. Understanding evaluation criteria
3. Participation in decisions
4. Articulation of value (internal + external “selling” differ)
5. Technical depth (role track / yes-no competence)
6. Leadership track / growing influence (being listened to; ability to take initiative)

Actionable recommendations (playbook-style)

Weekly/next-week actions to reduce firing risk

• Do an “external visibility audit”

  • Count: people outside your team who can explain your work and its business justification.

• Translate engineering output into business language

  • Ensure others can explain why it mattered (not just what was built).

• Increase “suggest what to do” behaviors

  • Push from “task execution” → “proposal ownership.”

• Find your actual evaluation criteria

  • Ask your manager directly for the promotion/review criteria; retrieve them from documentation where possible.

• Treat initiative as visible, not just executed

  • Initiative is described as “punishable” in some teams due to learned helplessness culture—so initiative needs to be framed to avoid political backlash.

Job-market positioning (high level)

• The presenter argues that “showing yourself as invisible” may be safer operationally because:
  • being least visible makes you easier to cut,
  • but staying invisible also limits new opportunities.
• Overall advice: build new experience/value while staying adaptable (especially as AI changes baseline productivity).

Concrete examples / case studies cited

GitLab layoffs / role archetype risk

• The presenter references GitLab layoffs by country and consulting work on termination issues.
• Hiring/layoff observation:
  • Uninitiated mid-levels are “highest risk” (expensive, limited leverage).
  • Juniors may be invisible in payroll and require faster independence to justify value.

Two-team product example (initiative vs compliance)

• Two archetypes in a product org:
  1. Team executes directives (“salute and do what told”)
  2. Enthusiast team argues/disputes (more initiative)
• Observed outcome in layoffs:
  • More of the directive team got fired; initiative culture performed better.
  • Enthusiasts reportedly reduced layoffs impact for themselves and influenced others.

“Fired for smartness + tone” anecdote (communication as a business factor)

In a termination story (permission-based, personal data avoided), three reasons were given:

• Over-optimizing academic code (strong work advantage) but inability to convey it to management.
• Passive-aggressive communication style in PR reviews (technically correct tone but socially destructive).
• Core belief misconception: thinking emotion/communication tone doesn’t matter for professionalism.

Follow-up concept: “Emotion vs positions” — engineers must manage how decisions are received, not only the content.

AI execution strategy (how to use AI to increase retention odds)

• AI is framed as a productivity multiplier, but retention requires:

  • judgment (knowing when not to accept AI output blindly),
  • better goal-setting,
  • structured reporting (especially for AI-assisted work validation).

• Approach to make AI work “business-ready”:

  • create tasks with measurable outcomes,
  • validate results with prompts and structured outputs,
  • submit reports that describe experiment context, impact, and limitations.

Training/guild “system” (process playbook)

The presenter describes an educational/operational system (“guild”) tied to execution rigor:

• Calibration survey + self-diagnosis

  • Identifies the weak zone among the 6 axes.

• Goal-setting with constraints

  • Goals must be realistic within month / 3 months / half-year windows.
  • Example goal: improve AI skills to deliver more business value.

• Automatic task selection aligned to the goal

  • After setting goal, the system picks tasks; the user must report results.

• Report validation by AI + human review

  • AI checks report completeness; then real humans evaluate and provide feedback.

• Adaptive content

  • Learner sees exactly what videos to watch and tasks to complete, instead of browsing freely.

• Code/research tasks evaluated with business-style acceptance criteria

  • Reports require specific before/after deltas and conclusions.

High-level investing/markets note

• The session doesn’t provide investment advice; it frames layoffs as a macro-driven management response when “money stops being cheap.”
• The emphasis remains on execution: how to be legible and valuable to decision-makers under tighter budgets.

---

Presenters / sources mentioned

• Presenter (speaker): Ilya Klimov
• Referenced colleagues: Timur Gafarovich; Andrey Melekhov; Vitalik (names as spoken)
• Referenced org/process examples: Linus Torvalds; Google; Amazon; killedbygoogle.com; Hacker News; GitLab (company context)
• External concept referenced: “Den Shapira” (mentioned in relation to AI/tool maturity; details not fully explained)
• Tools/platforms mentioned: GitLab, GitHub, Claude, “Аishka” (AI), Mentimeter-like polling tool, Docker/CI/CD concepts