From implementing the instruction to questioning the abstraction

Mandate

Make shared engineering preserve approved client differences and demonstrate the limits of its service commitments

Outcomes

• Corrected the approved rounding sequence in a shared component
• Required explicit client ownership of inherited configuration
• Reduced unnecessary fields in tested diagnostic traces
• Deferred two features outside the demonstrated rollback boundary

Decisions in context

I became CTO in January 2022 and now lead 57 engineering employees through six leads, with eight contractors counted separately. The company supplies software to twenty-two insurers; its ₹148 crore FY ending March 2026 revenue is not premium. My FY2026–27 remit is ₹12.8 crore operating expense and ₹3.6 crore approved change investment, with finance determining accounting treatment. Joseph leads the enterprise, Reema owns engineering acceptance and client specialists retain their professional decisions. I have corrected two conveniences I previously supported: a shared calculation that omitted the rounding stage and diagnostic traces that carried unnecessary fields. The role requires me to explain why a narrower release or a visible unresolved setting can be more credible than an apparently complete result. The board receives my engineering proposals through the CEO; I participate as a management presenter and hold no director's vote. A first external appointment would require preparation and a different way of contributing from direct engineering management.

Reason for the move

Current appointment; exploring a first external board role

Mandate

Connect release commitments with client acceptance and continuing support

Outcomes

• Broadened responsibility from architecture to engineering delivery
• Examined how release sequences affect records already written
• Learned to retain commercial consequences in technical recommendations

Decisions in context

The engineering-director appointment began in July 2017 with 36 employees through four leads, six contractors and ₹7.2 crore annual operating expense. Qelvazi employed 170 people and recorded ₹92 crore revenue for FY ending March 2018. I became responsible for delivery commitments across several teams rather than the architecture of one platform area. A release date affected client plans, support capacity and the records the service would create after launch. I learned to ask how a change would be explained to the people who accepted it and how an earlier version would behave if it returned. The role also showed me the limits of a technically persuasive recommendation that ignored commercial disruption. Promotion to CTO widened the account to investment and enterprise commitments. It did not transfer client pricing, coverage or claims authority to the supplier, and it required greater care about which business distinctions our shared engineering was entitled to simplify.

Reason for the move

Promoted to chief technology officer

Mandate

Build shared components around explicit client requirements

Outcomes

• Learned the distinction between implementing and approving insurance rules
• Designed reusable services with documented client variations
• Expanded responsibility for configuration and acceptance examples

Decisions in context

I joined Qelvazi in September 2012 after twelve years in industrial software. The supplier had ninety employees and ₹36 crore revenue for FY ending March 2013. My platform group comprised eighteen employees through three leads and four separately counted contractors, within ₹2.6 crore annual operating expense. Insurance introduced professional decisions that a familiar-looking calculation or workflow could not settle on its own. I needed client specialists to explain the approved rule before our team represented it in a shared service. The architecture work taught me to distinguish variation that could be removed from variation that carried a required business meaning. My later rounding mistake showed that I did not always apply that distinction rigorously enough. Moving into engineering leadership expanded the responsibility from designing those contracts to ensuring that teams, support colleagues and client owners could maintain them through a sequence of releases.

Reason for the move

Promoted to engineering director

Mandate

Translate customer operating instructions into maintainable application behaviour

Outcomes

• Reviewed differences hidden by apparently similar customer requirements
• Developed responsibility for team delivery and support
• Learned to distinguish a useful default from an unsupported assumption

Decisions in context

I became engineering lead in June 2006, responsible for twelve engineers through two leads and ₹1.1 crore annual expense. Vaqzeri employed 170 people and earned ₹38 crore revenue for FY ending March 2007. Customers often used the same short phrase for operating rules that differed when examined through examples. My team had to establish those differences before treating a common component as a complete answer. I also learned that a default value could make a demonstration smoother while leaving support colleagues to explain a wrong result later. The role gave me responsibility for other engineers' work and for the maintenance consequences of our choices, not authority over customers' commercial or operational policy. Moving to Qelvazi offered a wider platform problem and a new sector to learn. I wanted to understand how shared software could serve several clients without quietly deciding that their distinct instructions were equivalent.

Reason for the move

Moved into insurance-platform architecture to work on shared services for several clients

Mandate

Implement and test operating rules under engineering supervision

Outcomes

• Learned to work through numerical examples with operating specialists
• Separated a program's successful execution from the correctness of the requested rule
• Developed an interest in the assumptions inside reusable components

Decisions in context

I completed computer engineering at Merqovi Engineering College in June 2000 and joined Vaqzeri the next month. The company employed eighty people and recorded ₹11 crore revenue for FY ending March 2001. I worked in a six-person engineering team without direct reports or independent spending. Early assignments required me to turn short operating instructions into behaviour that could be tested. I learned that a program could run without error while answering a different question from the one the customer intended. Walking through a small numerical example with an experienced operating colleague often revealed more than another abstract description of the requirement. I did not own the customer's process or decide what its commercial rule should be. My job was to implement the agreed instruction and expose uncertainty to the project lead. That habit became useful when I began leading engineers and later designing components intended for several clients.

Reason for the move

Promoted to engineering lead