7 Toxic Practices That Can Destroy a Small Tech Team

Old readers know that Mr. K started as a programmer and, after years of struggle, rose to a senior technical executive at a listed company.

As Nietzsche said, "What does not kill me makes me stronger," meaning that what doesn’t kill you will eventually make you stronger.

In this article we discuss a hard‑core topic: how to build a technology team that drags down a company.

First, define the scope: the "company" here refers to small‑to‑medium enterprises. Large firms have enough cash to recover from mistakes, but small companies are fragile and cannot afford reckless experimentation.

From many painful experiences, we have distilled seven common tactics that sabotage a tech team. Use them with caution:

1. Poaching talent from BAT (Baidu, Alibaba, Tencent) . Start‑ups often hire a few “big‑company screws” hoping to build a carrier‑grade product, but the newcomers can’t contribute effectively and alienate existing staff.

2. Blindly adopting Agile . Agile requires skilled Scrum Masters and mature team members; without them, it becomes a burden.

Typical small‑company development flow:

Product manager drafts a month‑long plan.

Leader checks progress every two days.

Code review occurs bi‑weekly.

Release once a week (twice in emergencies).

Following this rhythm usually avoids major issues.

3. Strict role ratios . Insisting on a 1:5:1 ratio of product‑dev‑test staff wastes resources and doesn’t improve efficiency. Developers are expected to be full‑stack, so unnecessary specialization should be avoided.

4. Over‑emphasizing technical management . In a team of 20‑30 people, excessive management indicates the leader isn’t contributing technically.

Simple management steps:

Organize: group developers by module.

Control: hold weekly meetings.

Execute: warn non‑performers twice, then let them go.

Motivate: reward high performers with bonuses or raises.

Culture: leaders should still write code.

5. Promoting a fake startup culture . Unless every engineer is a co‑founder, pushing a “startup” vibe creates a false sense of partnership; employees are still motivated by compensation.

6. Performance based on lines of code . Counting code lines to determine pay demotivates engineers and is impractical for small teams.

Simple incentives work better: promote and raise good performers, let under‑performers leave.

7. Building a middle‑platform . Small businesses should avoid unnecessary middle‑platform or micro‑service architectures; they add complexity without delivering value.

In the first two years, keep the business system simple and feature‑focused.

Finally, to all tech staff in small companies: if life tricks you, don’t lose hope—tomorrow brings new challenges.