Three CTOs, Three Lessons: The Key Habits They Taught Me

First CTO – Emphasis on Planning

Although not a technical‑focused CTO, he evaluated product managers by asking whether they could articulate a roadmap for the next six months, the next year, and the product’s direction. The author inferred that technical teams require the same forward‑looking plans for stability work, security improvements, architecture optimisation, and productivity tools. Without explicit planning, such initiatives never materialise. Consequently, the author adopted a quarterly cadence for technical projects—allocating time each quarter to stability, tooling, and architectural enhancements rather than reacting solely to business demands.

有没有规划。

技术Leader没有规划技术需求，团队里的人，哪来的幸福感。天天做业务需求，早就厌倦了。

Most engineers welcomed the opportunity to work on these non‑feature projects.

Second CTO – Maintaining Hands‑On Technical Skills

The second CTO was a classic technical leader who authored the early system architecture and core code. When asked whether a CTO still needs to code, he replied, “A technical leader is essentially a chief architect—design and coding are both essential.” He warned that career longevity means future interviewers will assess both architectural and coding abilities regardless of managerial titles.

The author recounts spending two years focused almost entirely on management, then struggling in an interview where the hiring team expected active coding ability. After that experience, he consistently combined team leadership with core system development, reinforcing the view that technical managers must write code to retain technical sensitivity.

技术负责人，本质也是首席架构师。设计要会，编码也要会。

Third CTO – Business Understanding as a Technical Imperative

The current CTO also oversees the company’s most profitable business line. He frequently states, “A CTO who doesn’t understand the business is easily challenged by the business side,” and adds, “I understand the business better than the business owners, so they can trust my decisions.” Over three years, the author observed business leaders regularly consulting the CTO on solutions, decisions, and strategy—not merely on requirements.

These interactions taught the author to evaluate many requests from a business perspective first, allowing him to flag unreasonable demands during review stages without escalating to the CTO. He notes that as technology work moves further downstream, business acumen becomes increasingly critical.

CTO不懂业务，很容易被业务方挑战。

Summary of Lessons

Systematic technical planning (quarterly allocation for stability, security, architecture, and tooling) prevents burnout and creates team happiness.

Continuous involvement in code and design maintains technical sensitivity and meets future interview expectations.

Deep business understanding enables technical leaders to influence decisions, filter unreasonable requests early, and align technology with revenue‑critical objectives.