When a Tech Team Shows 3+ Red Flags, It’s Just a Makeshift Crew

1. Ad‑hoc technical decisions

Strategic direction is driven by the boss’s spontaneous inspiration rather than systematic analysis. Examples include announcing an “All‑in large model” after reading a public article or demanding immediate VR integration because an investor mentioned the metaverse. The resulting roadmap behaves like a Brownian motion—each new idea causes a sudden shift, forcing engineers to discard partially built architecture and restart, which quickly exhausts motivation.

2. One‑person technical authority

The so‑called CTO or technical director is often the best at upward management, not at deep technical judgment. Technical review meetings become platforms for the leader’s personal will; dissenting opinions are labeled as “narrow‑visioned” and can lead to marginalisation in promotions and resource allocation. This mirrors the “magic‑number” anti‑pattern where all decision logic resides in a single mind, producing a team of “pseudo‑experts” who can create polished PPTs but cannot resolve real production incidents.

3. Multi‑head demand management

In a healthy R&D flow, requirements flow from a stable source (product) through a clear process. In a makeshift crew, demands arrive from multiple directions: a boss tags a developer at midnight with a new idea, an operations director bypasses product managers to request a “small favour,” and different leaders give contradictory specifications. Engineers receive conflicting commands, the technical manager’s authority collapses, and the team resorts to tactical busywork that masks strategic chaos, causing the system to become increasingly bloated and fragile.

4. Process formalism to extremes

While strategic choices are arbitrary, low‑level processes become rigid: inflexible 996 or alternating‑week attendance, overly complex code‑formatting rules, two‑week approval chains for a test server, yet emergency incidents must be resolved within five minutes. This “bicycle‑shed effect” diverts energy to easily measurable process metrics (overtime hours, code line counts, approval steps) instead of substantive technical leadership and business growth.

5. Performance‑over‑output culture

Engineers are evaluated on PPT polish, weekly report completeness, and meeting demeanor rather than on solving hard algorithmic problems, optimizing QPS, or preventing outages. When “overtime length” becomes a de‑facto KPI, staff engage in “performative overtime” and superficial technical sharing, while those who quietly fix critical bugs are marginalised for lacking “showmanship.”

If a technical team exhibits three or more of these characteristics, it functions as a makeshift crew. Time, skill, and professional reputation become the most valuable assets; prolonged exposure erodes technical enthusiasm and hampers competitiveness, making departure a legitimate professional choice.

Code example

往
期
推
荐
1、
Firefox为什么掉队？15年老员工离职发声：它本来就是一款小众浏览器，别再模仿Chrome、Edge了
2、
2025 年使用最多的编程语言
3、
裁员后效率没变，老板想不通：人减了一半，活也少了一半
4、
领导禁止使用Codex和Claude Code，说国内用不了、价格死贵！我怒了：这不胡扯么？2 分钟包你用上
5、
2026 年 06 月编程语言排行榜｜Rust 走出平台期，排名创新高，迎来关键转折
点
分
享
点
收
藏
点
点
赞
点在看