What a 20‑Person IT Startup Taught Me About Broken Deployment and Team Chaos
The author recounts their first month at a 20‑person IT startup, exposing chaotic onboarding, absent development processes, unreliable testing environments, ad‑hoc code releases, and misaligned product specifications, ultimately illustrating why such disorganized practices drive engineers to resign.
Day 1 – First Impressions
I joined a 20‑person IT company in Xi'an, attracted by the claim that it was a subsidiary of a large internet firm and by fatigue from endless interviews.
The reception was bizarre: the front‑desk staff wore casual clothes, had green hair, chewed gum, and gave me a form to fill out while no one else seemed to be around. After waiting twenty minutes, the HR person finally arrived, printed a contract, and asked me to sign a few pages without any introduction, gift, or explanation of the terms.
Later, the department HR greeted me, opened my OA system account, gave me equipment, and announced a “welcome ceremony” that required me to send a red envelope in a WeChat group, creating an awkward atmosphere.
Day 2 – First Assignment
The next day I received a Git repository for a project and was asked to prepare a PPT explaining my understanding. When I inquired about a test server, the leader said none existed and instructed me to set up a local test environment, assuring me it would be fine.
This revealed a critical flaw: the team had no unified code‑release process, relying on a single leader to manually deploy code. As a result, bugs frequently appeared in production, rollbacks were needed, and the lack of consistent testing environments caused repeated failures.
Day 3 – Suggesting a Deployment Process
I proposed building a proper deployment pipeline and a test server that mirrors production. The leader dismissed the idea, claiming the headquarters was too busy to support it.
Within a month, I discovered that many colleagues came from sales, outsourcing, or teaching backgrounds, with few having formal computer‑science training. The product manager only provided vague textual specifications, leading to repeated misunderstandings and rework.
The Final Breaking Point – Last Business Deployment
During a critical evening deployment, I left to eat while the tester warned me not to go. A minor data‑type bug caused the service to crash; after fixing it, the tester insisted the deployment continue despite obvious issues. The leader repeatedly called, demanding the release, and I eventually resigned, sending a resignation email and taking remaining vacation days.
Efficient Ops
This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
