“Start With the Outcome, Not the Execution”

As AI changes how software is planned, built, tested, and delivered, engineering organizations have an opportunity to rethink what successful delivery really means. Faster execution matters, but speed alone does not create business value. The real measure is whether engineering solves the customer’s problem and improves the outcomes that matter.

For Milind Kukday, Chief Delivery and Engineering Officer at Opus Technologies, this shift begins with changing how teams approach their work. Instead of treating requirements as the starting point, engineers must understand the business context, question assumptions, and find better ways to solve customer problems. This is where engineering moves beyond execution to become a strategic partner.

As AI makes technology capabilities more accessible, deep domain knowledge becomes even more important. In payments, engineers must understand the ecosystem, regulation, risk, security, and transaction flows to apply technology in the right context. Combining this expertise with AI, automation, and strong engineering practices allows organizations to accelerate delivery without compromising quality or trust.

In this conversation with Sabeeka Lambe, Director, Delivery Support, at Opus Technologies, Milind explores how engineering leaders can build teams that deliver meaningful outcomes, make better decisions, and improve continuously. His central message is clear: start with the customer’s desired outcome, then bring together the right people, expertise, and technology to achieve it.

Sabeeka: As technology becomes more intelligent, what do you think delivery will look like five years from now – and what should never change?

Milind: Delivery will move from managing execution to orchestrating intelligence. AI will increasingly automate how we plan, build, test, deploy, and operate, allowing engineers to focus more on complex problems, innovation, and customer outcomes.

What shouldn’t change is engineering discipline. AI amplifies capability; it doesn’t replace strong engineering fundamentals, governance, or domain expertise. The future is not simply faster delivery it is smarter, more predictable, and outcome-driven delivery.

Sabeeka: We have become very good at measuring whether we delivered. How do we get better at measuring whether we delivered the right thing?

Milind: We need to shift the conversation from outputs to outcomes. Scope, timelines, and milestones matter, but they don’t tell us whether we actually created value.

The real questions are: Did we solve the customer’s problem? Did we improve an important business metric? Did we make their business better? Successful delivery should ultimately be measured by the impact it creates.

Sabeeka: What changes when an engineering team stops thinking about requirements and starts thinking about the customer’s problem?

Milind: Everything changes. Engineers stop being recipients of requirements and start becoming problem solvers.

When teams understand the business context and the why behind what they are building, they make better technology decisions, challenge assumptions, and often identify solutions the customer may not have initially considered. That’s when engineering starts creating real business value.

Sabeeka: In a complex and mission-critical industry like payments, what does it take to move from being an execution partner to becoming a true consulting and engineering partner?

Milind: It starts with understanding the customer’s business as deeply as you understand the technology.

A true partner doesn’t simply ask, “What do you want us to build?” They ask, “What problem are we trying to solve?” They bring domain knowledge, engineering expertise, perspectives, and sometimes challenge the original thinking.

That shift from executing requirements to co-creating outcomes is what turns a vendor relationship into a partnership.

Sabeeka: How important will deep domain knowledge become as AI makes technology capabilities increasingly accessible?

Milind: I believe it becomes more important, not less.

Technology capabilities will increasingly be democratized by AI. The differentiation will come from applying those capabilities in the right context. In payments, understanding the ecosystem, regulation, risk, security, transaction flows, and customer behaviour fundamentally changes the quality of the solution.

That’s why at Opus we place significant emphasis on domain-native engineers – engineers who understand not only how to build, but why it matters to the payments business.

Sabeeka: What does an engineering organization need to get right when technology, domain expertise, and AI are coming together so rapidly?

Milind: For us, it comes down to domain-native engineers who can bring technology expertise and business context together.

You need engineers who understand the technology, but also understand the industry, the customer, and the problem they are solving. Add the right platforms, automation, and AI capabilities, and you create an organization that can move faster without losing context.

AI can accelerate engineering, but domain knowledge is what helps you apply that intelligence in the right way.

Sabeeka: In payments, you cannot afford to “move fast and break things.” So how do you build organizations that move fast without compromising trust?

Milind: By making quality, security, and governance part of engineering rather than gates at the end.

Automation, DevSecOps, CI/CD, intelligent testing, observability, and strong engineering practices allow teams to move faster because the right controls are built into the lifecycle.

In payments, speed matters but trust, resilience, and security are non-negotiable. The goal is responsible speed.

Sabeeka: Why do some organizations keep getting better while others keep launching improvement initiatives without really changing how they work?

Milind: Because continuous improvement cannot be a program, it has to become a way of working.

The best organizations create an environment where teams continuously question, experiment, learn, and improve. Leaders make improvement part of the operating rhythm rather than something that happens through an annual transformation initiative.

Small improvements, consistently applied, create significant change over time.

Sabeeka: As delivery becomes increasingly intelligent and automated, what needs to change in the way engineering leaders lead?

Milind: Leadership needs to move from controlling execution to creating clarity and enabling decisions.

As more execution becomes automated, leaders need to spend more time connecting technology to business outcomes, developing people, removing complexity, and creating an environment where teams can make good decisions quickly.

The role increasingly becomes one of context, empowerment, and accountability.

Sabeeka: If you could leave engineering leaders with one thought about building better delivery organizations, what would it be?

Milind: Start with the outcome, not the execution.

Be clear about the customer problem and the value you want to create. Then bring together the right domain expertise, engineering capability, technology, and mindset to solve it.

And don’t limit engineering to execution. The strongest engineering organizations advise, challenge, co-create, and partner with the business. That’s where delivery becomes a true competitive advantage.