From the scanned page to the product commitment

Mandate

Make product assumptions, service allocation and continuing support commitments explicit enough to sustain institutional use.

Outcomes

• Narrowed an automatic matching path after 54 wrong suggestions in an 8,200-pair historical test
• Introduced bounded client allocations after one import delayed nine other institutions
• Funded an ₹18 lakh repair to a customer export with 2,400 unusable attachment references
• Replaced a proposed customer-specific branch with an approved ₹38 lakh supported extension

Decisions in context

My work as CTO begins before an engineer receives a delivery specification. A sales promise can establish a deadline, an allocation of capacity or a support obligation that the architecture will later be expected to fulfil. I bring the engineering assumptions into that decision while there is still a choice. The five heads in my team lead the specialist work; I set priorities with the CEO and make the trade-offs visible to the board when relevant. The cases here belong to this appointment and include costs that did not become immediate savings. Client institutions retain their accounting and settlement responsibilities. I want our product to give them usable evidence rather than a claim of authority we do not possess. The external role I am considering would draw on this experience without interfering with the executives responsible for another company's design and delivery.

Reason for the move

Current role; considering a first outside directorship where product and commercial governance intersect.

Mandate

Develop engineering managers and account for the continuing work created by customer commitments.

Outcomes

• Included maintenance and upgrade implications in estimates for exceptional requests
• Established a joint review of delivery assumptions with commercial colleagues
• Developed four managers able to own product areas through release and support

Decisions in context

Leading engineering required a different kind of attention from being the architect on a difficult design. I needed managers who could make decisions and explain them, rather than bring every disagreement to my desk. We examined the recurring work created by customer exceptions and made it part of estimates before a contract was agreed. Commercial colleagues sometimes found that discussion inconvenient, but it gave them a clearer account of what the company could offer. The ownership change in 2018 increased interest in repeatable product economics. I used that interest to connect development plans with support and upgrade costs without treating every exceptional requirement as undesirable. The role prepared me for the CTO appointment by making the organisation, its commitments and its management capacity as important to my judgement as the technical design itself.

Reason for the move

Appointed CTO after the previous holder retired and the board expanded the product-engineering remit.

Mandate

Separate shared product behaviour from client-specific business meaning and approval responsibility.

Outcomes

• Documented the evidence behind matching and exception rules
• Introduced explicit configuration for supported workflow differences
• Reviewed proposed common components against the obligations they could not decide

Decisions in context

Architecture placed me between the desire to reuse code and the need to preserve distinctions that mattered to a financial institution. Two clients could use similar words for processes with different approval requirements. I worked with delivery specialists to understand those differences before turning them into a common component. The product needed a way to express the supported variation and a clear boundary where the client had to make a decision. I also documented why a rule existed, so a later engineer could judge whether a requested change was compatible with its original purpose. My role provided technical direction rather than unilateral control of the development budget. The move into engineering management followed the team's growth and the need to carry this reasoning into planning, recruitment and the day-to-day decisions made by several product groups.

Reason for the move

Promoted to head of engineering as the product group and institutional client base grew.

Mandate

Connect source records to the product without losing the meaning needed for comparison and review.

Outcomes

• Recorded source-field definitions alongside interface mappings
• Identified reference collisions across files and reporting periods
• Built a six-person team able to investigate integration exceptions with client specialists

Decisions in context

I entered financial software with an engineering background and had to learn the business meaning carried by apparently ordinary fields. A reference that looked unique in one file could repeat in the next reporting period. A date might describe processing rather than the event the customer wanted to compare. I worked beside client specialists and preserved examples that exposed those distinctions. The team learnt to ask what a field represented before writing a transformation that made it fit our format. I later led six colleagues and coordinated implementation investigations, while commercial and approval decisions remained with their authorised owners. This period gave me a practical understanding of why reusable software needs explicit assumptions. It also made the product-architect role attractive because I could address recurring integration questions in the design instead of solving them separately at every institution.

Reason for the move

Promoted to product architect to apply integration knowledge across the common product.

Mandate

Investigate defects between original documents and their digital representation under actual scanning conditions.

Outcomes

• Built repeatable tests from customer documents that failed ordinary demonstrations
• Separated feed, calibration and software causes of unreadable images
• Developed the evidence-tracing discipline later applied to financial records

Decisions in context

My first engineering job made me attentive to the difference between an output that looks plausible and one that preserves the source accurately enough for its purpose. I tested scanners, investigated customer examples and worked with colleagues responsible for mechanical and software behaviour. The work often began with a faint mark or a missing edge that seemed insignificant until a user explained why it mattered. I learnt to keep the original example and reproduce the conditions instead of adjusting settings until a single page looked acceptable. I did not manage a team or hold spending authority. I was developing the craft of investigation and an interest in the systems that used captured records. Orevathi offered the opportunity to follow that interest into financial applications, where the interpretation of a record could be as consequential as the quality of its image.

Reason for the move

Joined a financial-software supplier to work on the interpretation and use of captured records.