04 — The Zoho Creep

Failure mode: Work at Zoho — the day job — expands into evenings, weekends, and eventually the sprint calendar itself. On-call rotations, release crunches, “just one more thing before EOD” days. Learning hours drop from 12/week to 6, then 3, then 0. Within a quarter, the roadmap is on ice and Raghul is telling himself “I’ll pick it back up after this launch.”

Probability: 60% — the highest single-source risk in the entire roadmap.

This is not a Zoho-specific accusation. The May 2026 survey of India-based professionals put toxic work culture / long hours / burnout as the #1 concern for 47% of respondents. Bangalore ranked 3rd worst globally for work-life burden. The pattern is systemic across Indian product tech: Zoho, Flipkart, Zomato, most of the unicorn tier. The specific instance here is Zoho, but the base rate is India-tech.

Why It Happens

  • The extra hour is always “one time.” Every extra evening starts as an exception. Exceptions compound.

  • Career optics. “If I say no to this feature push, will it show up in perf review?” is a real fear, not paranoia.

  • Weekend catch-up trap. A hard weekday makes Raghul push learning to Saturday. Then a family thing eats Saturday. Then Sunday is recovery. Sprint slips silently.

  • Zoho is a good place. This makes it harder, not easier. There is no dramatic villain to leave. There is just a good job that slowly consumes more of the week than the moonlighting plan can survive.

  • Moonlighting stigma. Even though the roadmap is legally personal-time skill-building (not a second job), the cultural fear of “am I doing too much outside work?” makes Raghul preemptively cut personal time first when workloads collide.

Early Warning Signals

  1. 3+ consecutive weeks below 8 hours of roadmap work (target is 10–15).

  2. “I’ll double up next week” appears in Sunday audit more than twice in a month.

  3. 7pm phone-in-other-room rule broken 3+ evenings/week.

  4. Saturday morning 4-hour protected block skipped 2+ Saturdays in a row for non-life reasons (i.e., “just work stuff”, not weddings/family).

  5. Zoho Slack / email checked between 8pm and 8am on a personal-time day without a real production incident.

Mitigation — Hard Boundaries

Three non-negotiable structural rules:

  1. Weeknight boundary: 4 nights per week, phone in another room from 7pm–10pm. Roadmap-first block. The other 3 nights are flexible. Which 4 is Raghul’s choice, but he pre-declares them each Sunday.

  2. Saturday morning protected: 4 hours, 8am–12pm minimum. This is the “half-Saturday rule.” Non-negotiable except for weddings, funerals, hospital, family emergency. Not work emergencies. Zoho does not get Saturday mornings.

  3. On-call weeks are pre-declared light sprints. If Raghul is on-call every 6 weeks, one sprint in every 3-sprint cycle is a “light sprint” — 6-hour target instead of 12. Plan for it. Do not fake a full sprint through on-call and then feel bad about missing it.

Additional guardrails:

  • Sunday audit (from ../13_discipline/07_motivation_sustainment.md) explicitly counts Zoho hours vs roadmap hours for the week. If Zoho > 55 hrs and roadmap < 8 hrs for 3 weeks — red flag.

  • No Zoho work between 10pm and 7am unless a production incident is actively page-worthy. “Catching up on emails” at 11pm is Zoho creep dressed as diligence.

  • Deep dinner rule (../13_discipline/08_health_burnout.md) — one dinner per week with family, phone in another room, no work talk. Protected.

The Honest Escalation

If 2 sprints in a row are missed to Zoho work:

Sit with a real question, in the lab notebook, no BS:

Is Zoho a career I’m committed to for the next 3–5 years? Or is this roadmap the on-ramp to the next thing?

If Zoho is the long-term career, the roadmap needs to stretch — 13 months becomes 16, and the target is enrichment/depth, not a job switch. That’s a valid choice.

If the roadmap is the on-ramp, then Zoho hours competing with roadmap hours is a planning problem, not a work-ethic problem. The plan needs harder boundaries. Consider:

  • Talking to manager about scope for Q3/Q4 to protect boundary-hours (yes, this is uncomfortable — do it anyway).

  • Documenting your on-call load and asking for a fairer rotation if it’s above team median.

  • If Zoho consistently demands 55+ hrs/week for 6+ months, that is not the job you thought you were doing, and the roadmap timeline is not the problem.

Do not fake either version. Do not pretend the roadmap is on track when it isn’t. Do not pretend Zoho is 40 hrs when it’s 55. Write the truth in the lab notebook.

Escalation Trigger

If 2 consecutive sprints missed to Zoho work:

  1. Sunday audit runs long that week — 90 min instead of 30.

  2. Write the two-question honesty above.

  3. Cut next sprint’s target by 50%. Ship something tiny. Rebuild rhythm.

  4. If Zoho load is genuinely a spike (release, launch), pre-declare next 1–2 sprints as light. Come back when the spike ends.

  5. If Zoho load is not a spike — it’s the new baseline — then the roadmap timeline stretches (13→16 or 18 months) and the weekly target drops (10–15 → 6–8 hrs). Do this openly. A slower roadmap that ships is worth infinitely more than a faster roadmap that dies.

What Success Looks Like

  • Average 10 hrs/week roadmap work across any rolling 8-week window.

  • No more than 2 sprints in a 13-month year missed to Zoho work.

  • 4 protected evenings + protected Saturday morning held ≥ 75% of weeks.

  • End of M13: portfolio shipped, job at Zoho still going (or intentionally transitioning), no burnout collapse.

The roadmap is the second job of your life, not the first. The first job is being a functioning human with a paycheck. Do not confuse the two. But also — do not let the first job silently eat the second one over 13 months.

Nav: ← 03_the_DSA_rabbit_hole.md · → 05_the_hard_gate_M9_miss.md