Learning what a convenient default can conceal

I completed my engineering degree in May 1998 and joined Penvurli Systems in Cuttack the following month. The company built and supported business applications for regional customers. I worked on data import, report generation and supervised fixes. My early assignments taught me that an input could pass a technical check while remaining ambiguous to the person using the report. A blank field might mean that a value was unavailable, irrelevant or simply not yet supplied. Treating all three as the same condition made the software easier to build and the resulting explanation harder to trust.

I moved to Meralqen Treasury Software in April 2004 as a product engineer working on client implementations. The business served corporate finance teams that wanted a clearer view of expected receipts and payments. I was not making treasury decisions; I was implementing calculations and workflows agreed with the product and client teams. The work exposed me to the difference between a projection and a confirmed balance. I began asking how a user would recognise the source and status of a number after it had been imported, adjusted and combined with other inputs.

In April 2010 I became a product architect. I had responsibility for design decisions across several modules and worked with engineers who knew the technical history better than I did. I learnt to make the reasoning behind a default explicit, particularly when it affected missing values, ownership or permissions. A setting that was acceptable for one implementation could be misleading when reused by a different client. I introduced short design records for those choices and asked the product team to review the business interpretation alongside the technical approach. The aim was to make disagreement possible before a convention became difficult to change. Those records also helped support colleagues explain why two apparently similar client requests required different treatment, rather than offer a workaround whose financial meaning nobody had reviewed.

My appointment as head of engineering in April 2016 added responsibility for people, delivery commitments and support consequences. I led forty-eight engineers by the end of that period. The hardest decisions were often about how much of a proposed feature we could responsibly release. A broad demonstration could be impressive while leaving permission rules or migration behaviour unresolved. I began bringing those gaps into the release discussion with a costed alternative. That sometimes meant disappointing a commercial sponsor, but it also exposed where the sponsor had a legitimate need that our first technical proposal had not understood.

I became CTO in April 2022. The company now serves 58 corporate clients and employs 210 people. I lead eighty-five engineers through four heads within an approved ₹18 crore annual engineering budget, reporting to chief executive Ranjana Tevlari. Product director Martin Joruvani owns the commercial product priorities with the executive team. I am accountable for engineering design, implementation and evidence, not for a client's cash decisions. I present material product risks to our board when invited, but I have never held a director seat or membership of a board committee.

Three recent decisions illustrate the responsibility I want that title to convey. We stopped a missing opening balance from silently becoming a complete forecast, separated a corporate hierarchy from access permission, and allowed an automated projection to decline when recent business changes made its historical basis inadequate. Each decision created work for our team and our clients. We paid for migration support, narrowed a release and retained a manual scenario route. I would not describe those costs as a temporary inconvenience on the way to perfect automation. They were part of the operating choice.

I have become more deliberate about testing my own preference for a technically elegant answer. Earlier, I could defend a consistent default without asking whether its meaning stayed consistent across different users. I now want a design review to include the person who will explain the result to a finance colleague, not only the person who can explain the code. Specialist technical assessment remains essential, particularly for security and reliability. It becomes more valuable when the business interpretation is also explicit. My next role should let me develop that connection at greater scale while building leaders who can challenge a design without waiting for me to be in the room.

Open to Board appointments · Executive opportunities

Languages / English · Odia · Hindi