A career moving closer to the product's investment choices

Mandate

Choose and sustain product capabilities, client architecture and engineering investments that justify their continuing ownership.

Outcomes

• Consolidated ten client forks into a common product while retaining five justified specialist lines.
• Established a fixed-population AI comparison using inference charges per accepted output.
• Completed a purchased scheduling integration while redirecting four engineers to domain workflows.

Decisions in context

I became CTO in January 2019 with responsibility for the capabilities our products should own and the architecture used in client delivery. The current team and 2026 budget describe the present remit, not every year since appointment. I report to the chief executive; a separate CIO runs internal enterprise systems. Product, account and authorised legal colleagues retain their respective commercial and permission decisions. Recent work has included client-fork consolidation, a bounded AI economics exercise and a deliberate purchase of routine scheduling capability. Each required a choice about engineering attention as well as technical design. My former instruments-company directorship overlapped this role untilJune 2022 and was separately governed. I now have no external director seat. The continuing responsibility is to make product ownership intelligible: what we maintain, why it belongs with us and what evidence should cause us to revisit the choice.

Reason for the move

Current appointment; expanded from engineering portfolio leadership to company technology choices.

Concurrent appointment

Concurrent non-executive director and technology committee member at Shenlume Instruments continued untilJune 2022; no current external directorship.

Mandate

Coordinate product engineering commitments and investment across growing client and platform teams.

Outcomes

• Introduced a joint product/delivery review of the maintenance implied by proposed client variations.
• Established named engineering ownership for shared components after their first programme ended.
• Linked portfolio proposals to explicit continuing support and examination work.

Decisions in context

The vice-president role required me to connect several engineering groups whose local commitments could conflict. A delivery promise might consume platform capacity that another product already expected to use. I worked with product and commercial colleagues to make those consequences visible before approving the technical route. By the final year I led 168 employees and held CNY 150 million annual authority; these figures should not be read as the starting scope in 2012. I introduced clearer ownership for shared components and a review of the work created by client-specific promises. The aim was a usable investment discussion rather than an architectural veto over sales. InJuly 2018 I accepted the separate Shenlume Instruments directorship with agreed time and relationship arrangements. The later CTO appointment expanded my responsibility from coordinating engineering delivery to choosing the capabilities and obligations the company should retain.

Reason for the move

Appointed CTO to take responsibility for company-level technology choices and the engineering investment account.

Concurrent appointment

Began a separate non-executive director and technology committee appointment at Shenlume Instruments in July 2018, concurrent with this executive role.

Mandate

Turn recurring client needs into maintained common capabilities with explicit variation and support boundaries.

Outcomes

• Established product ownership for recurring workflow components.
• Separated supported configuration from client-specific extensions in platform planning.
• Made examination and support responsibilities part of a shared component's acceptance.

Decisions in context

I moved from individual client architecture into common product platforms because several engagements were solving related problems without a shared account of the resulting work. The role required deciding which similarities were meaningful enough to support centrally. I learned to distinguish a component available in a library from a capability that a product owner had agreed to maintain. ByDecember 2011 my remit covered 64 employees through four reports and CNY 42 million annual authority, within a company of 2,100 people. We introduced clearer configuration and extension boundaries and included examination and support in the acceptance of shared work. These were organisational choices as much as code changes. My promotion followed the need to apply that judgement across a larger engineering portfolio, where product priorities and delivery commitments increasingly competed for the same limited specialist attention and investment.

Reason for the move

Promoted to engineering vice-president to coordinate the broader product and delivery portfolio.

Mandate

Translate client operating needs into application designs whose differences and delivery obligations could be explained.

Outcomes

• Documented the operating reasons behind client-specific workflow variations.
• Used prototypes to examine ambiguous behaviour before committing the delivery design.
• Identified recurring needs suitable for discussion as shared product capabilities.

Decisions in context

Joining Lanshuren in January 1997 took me closer to the client's work. Similar requirement documents could conceal different approval paths, responsibilities and practical constraints. I used design reviews and prototypes to make those differences concrete before delivery teams committed to an implementation. The final-year remit of eighteen colleagues and CNY 7.2 million design authority developed over the appointment; I did not begin with that scale. Client conversations taught me why a seemingly minor variation might matter commercially, while repeated delivery taught me the continuing cost of creating a separate version casually. I began recording the reason for each difference alongside the technical design. That experience led naturally to product platforms: the next challenge was deciding which recurring needs deserved a common capability and which should remain deliberately specific to their original operating context.

Reason for the move

Moved into product platform leadership to address repeated client problems at a common capability level.

Mandate

Implement and maintain business applications with clear defect explanations and repeatable examination of changes.

Outcomes

• Delivered application changes with reproducible examples of the intended behaviour.
• Documented defects so another developer could reproduce and investigate them.
• Supported maintenance handovers with explanations of the choices made in implementation.

Decisions in context

My first appointment began the month after graduation. I worked in an eight-person development team and was accountable for the quality of assigned implementation and maintenance work, not for a company budget. ByDecember 1996 the employer had 180 employees and CNY 85 million annual revenue, which describes its setting rather than my personal authority. The practical lesson was that a program's behaviour needed an explanation another person could use. A defect report without a reproducible example delayed everyone; a clever change without a clear account made later maintenance harder. I learned to connect code to the work it supported and to ask when a requirement was ambiguous. Moving to Lanshuren gave me the chance to bring that discipline into client architecture, where the reasons behind a technical choice were often more consequential than the implementation technique itself.

Reason for the move

Joined Lanshuren as a solutions architect to work more directly on client requirements and design choices.