From implementing a method to owning the meaning of its product claim

Mandate

Preserve interpretation and evidence boundaries through the spatial-software product

Outcomes

• Corrected coordinate-context and missing-observation handling
• Withdrew an unsupported production cache benefit and deferred a broad performance rollout
• Narrowed a desktop release to the distribution basis established for its components

Decisions in context

I became CTO in March 2022 and lead 130 engineers through five heads. The ₹39 crore expense remit and separate ₹6.4 crore laboratory-capital programme support product engineering, while a separate CIO owns internal systems. I report to the CEO and work with scientific-methods leadership on the meaning of the results our software produces. The role has required corrections to a coordinate interface I accepted, a clearer treatment of missing observations and a more restrained account of performance evidence. Component rights also affect what can be supplied in a particular package. I present technology matters to directors but have no statutory seat. The responsibility is to connect engineering choices with the product promise, including when a qualified finding leaves an experiment unfinished, a rollout deferred or a release smaller than the original proposal.

Reason for the move

Continuing CTO responsibility while assessing one prospective outside contribution

Mandate

Choose engineering priorities and communicate what their evidence supports

Outcomes

• Expanded architecture responsibility into engineering investment choices
• Brought test conditions into product and commercial discussions
• Developed a clearer distinction between a demonstration and an accepted product claim

Decisions in context

The head-of-engineering role brought 86 engineers through four heads and ₹24 crore annual expense. The company had 330 employees and ₹124 crore FY 2018 revenue, and I reported to the CEO. I needed to decide which problems deserved attention while explaining the consequence of those priorities outside engineering. A smooth demonstration could make uncertainty less visible, and a single benchmark could carry more meaning than its test supported. I encouraged the team to preserve the condition beside the result, so commercial colleagues could understand what the work established before making a wider promise. That approach still required judgement about how much detail a decision needed. The aim was not to bury every proposal in technical caveats, but to keep the assumptions that could change the enterprise's choice visible enough to be assessed. The CTO appointment widened that responsibility across the product direction.

Reason for the move

Promoted to CTO in March 2022

Mandate

Keep data meaning intact across import, transformation, analysis and presentation

Outcomes

• Moved from algorithm leadership into end-to-end software architecture
• Examined assumptions introduced when context passed between processing stages
• Built the cross-team perspective needed for engineering management

Decisions in context

I moved to Bhubaneswar in September 2011 and led 24 engineers through three leads under the head of engineering. The ₹6.8 crore expense remit supported architecture across several processing stages. A dataset's meaning had to survive import, transformation, analysis and presentation, often through code owned by different colleagues. I learned to ask where a reference, validity state or source revision lived and whether the next stage could still interpret the result without reconstructing the earlier conversation. Architecture was not only a choice of components. It was a decision about which assumptions the system made visible and which it asked another team to supply. The role prepared me to manage a larger engineering organisation by showing how a locally reasonable simplification could become an unexplained constraint elsewhere in the product and eventually affect the client's understanding of the output.

Reason for the move

Appointed head of engineering in June 2017

Mandate

Make numerical methods implementable with explicit assumptions and test conditions

Outcomes

• Added team and expense responsibility to development work
• Documented the domain and assumptions behind implemented methods
• Learned how a local benchmark could be enlarged into an unsupported product claim

Decisions in context

Algorithms leadership brought twelve engineers through two leads and ₹2.9 crore annual expense under the engineering director. I had to explain a method well enough for colleagues to implement, test and maintain it without depending on my personal interpretation. A concise formula was useful only when its domain and assumptions remained clear. I also began to see how a result could change meaning as it moved into a product presentation. A local timing improvement might be real while the broader claim attached to it was not established. The role taught me to keep the measurement and the operation together and to ask which decision the result was intended to support. Those habits later helped me examine larger processing paths, where several individually reasonable choices could combine into an output whose meaning no one team had reviewed as a whole.

Reason for the move

Joined Tavqemi as software architect in September 2011

Mandate

Implement supervised spatial-software work while learning the interpretation of its inputs

Outcomes

• Applied mathematics and computer-science education to geospatial development
• Learned why numeric validity does not establish a spatial interpretation
• Raised missing-context questions with the responsible engineers

Decisions in context

I began in July 1998 after completing the master's degree that June. In a seven-person group under the development manager, I had no reporting staff or expense authority. I implemented supervised software work and learned that a number's usefulness depended on information around it. A coordinate needed its reference, and a missing observation needed a state that could not be confused with a measured value. I did not have authority to settle every scientific interpretation, but I could identify where an implementation relied on an assumption the input did not establish. That early habit joined the exactness I valued in mathematics with the practical responsibility of software engineering. The later algorithms role added the task of making those assumptions understandable to other developers, so a correct implementation did not depend on one person's memory of what the source was meant to describe.

Reason for the move

Advanced to algorithms lead in April 2004