Make the Outcome the Boss

Sudeep Acharya has spent the last few years working alongside government agencies on the hard part of transformation: turning strategy into delivery that citizens can actually feel.

Based in Sydney, Sudeep is CEO and co-founder of MTX APAC. Their work sits at the intersection of service delivery, business change, and the practical realities of modernising public services at pace. In our conversation, Sudeep was clear that “digital” is only useful when it changes something meaningful for people who rely on government services.

What stayed with me was not a new technology claim. It was a delivery posture.

Sudeep kept returning to a simple discipline: name the outcome that matters, then make every decision line up with it. When teams hold that line, transformation becomes harder to derail. When they lose it, delivery drifts back toward roadmaps, upgrades, and activity that looks like progress but does not move the citizen experience.

This matters now because the conditions have shifted. Governments are under pressure to deliver faster, connect services across silos, and adopt AI safely. The winners will not be the organisations with the most pilots. They will be the ones that can stay outcome-led, design for equity, and earn trust through how they build.

Digital transformation fails when “technology” becomes the default story

Sudeep described a pattern that most practitioners will recognise immediately:

“When we talk about digital transformation you know, a default muscle memory for us, we always think about technology, right?”

That muscle memory is understandable. Technology is visible. It is measurable. It shows up in procurement decisions, architecture diagrams, and implementation milestones.

But Sudeep’s point was blunt: tech is not the outcome.

“It’s outcome focused. It’s not about, hey, we’re going to update, or CRM into something new or we’re going to move into the cloud.”

Those may be necessary moves. They can even be urgent moves. But in isolation they do not “deliver meaning” to the people the service is meant to help.

“Those are important technical aspirations, but doesn’t really deliver meaning to the end users that are our citizens, our customers?”

The practical implication is a hard one for programme governance. If you cannot state the citizen outcome in concrete language, you cannot steer delivery. Vague outcomes create vague decisions. And vagueness is where delivery goes to die.

Make the outcome the boss, or you will forget it mid-build

Sudeep emphasised that this is not a strategy problem. It is a delivery discipline problem.

“A lot of time what happens is we will come up with this brilliant strategy on, hey, this is the outcome that we’re going to create for our customers.”

Then the programme moves into build. Teams get into the thick of delivering a product. Dependencies appear. Timelines tighten. The work becomes detailed and operational.

And then, as Sudeep put it:

“But when we are in the thick of delivering a digital product, right? We’ve forgotten about that strategy and the outcome that is important.”

This is the drift. The programme shifts from an outcome-led change effort into a technology delivery effort. Decisions get made because they are easier to implement, easier to procure, or easier to explain, rather than because they improve the citizen experience.

Sudeep’s antidote is strict, and deliberately repetitive:

“When we identify those outcomes, every single decision henceforth that we make on that digital transformation journey has to align with that outcome.”

Every decision.

Technology decisions. Timing decisions. Ways-of-working decisions. User experience decisions. If the decision does not support the outcome that was identified, the decision should not be made.

It is a simple principle. It is also rare to see it held consistently once delivery gets busy.

A Queensland example: faster delivery without a bigger team

One of the most tangible proof points Sudeep shared came from Queensland. It captures how outcome discipline and new capabilities like agentic AI can combine to change delivery speed.

“In one of the program of work that we’re doing in Queensland… We have reduced the timeframe of a delivery of a… regulatory process from six to 12 months traditionally that it would take to four months.”

The headline is the timeline compression. The more interesting part is what enabled it.

Sudeep described a shift in how the team spends attention:

“What we have now is our team is pivoting and focusing on how do we ensure that the delivery of these programs are laser focused on outcome for the citizens… leverage agentic and AI to… [do] more of the operational bit and repetitive kind of work.”

The claim here is not “AI makes everything faster.” It is more practical.

AI and agentic tooling can help remove operational drag. They can take on repetitive work that used to absorb time and attention. But they only create meaningful value when the programme knows what “better” looks like for citizens, and uses that as the basis for trade-offs.

In other words, the outcome makes AI useful. Without the outcome, AI becomes another tool chasing a use case.

Government design is different: build for the people who struggle

When I asked what design choices show up in transformations that genuinely improve the citizen or business experience, Sudeep did not start with UX patterns or “best practice”.

They started with equity, framed in the most practical way possible.

“Government doesn’t focus on what is important for the 90%. They focus on what is important for the 10% that is differently abled, marginalized, and needs more support than the general public.”

Then Sudeep pushed it further:

“In public sector world, we have to really cater to that 1%.”

This is a design constraint that changes what “success” means.

In the commercial world, reaching 99% efficiently can be considered excellent. In government, the 1% is not a rounding error. It is often where the harm concentrates when services become “digital only”, when identity or verification becomes too brittle, or when the service assumes people have stable connectivity, time, confidence, and the ability to self-navigate complexity.

Sudeep connected this to real access constraints: people may not have access to technology, may be differently able, or may face financial disadvantages that limit their ability to engage with a service as designed.

Designing around those realities is not just a moral stance. It is what legitimacy looks like in service delivery. It is also what prevents transformation from becoming a programme that improves things for people who already find systems easy.

Connected services are not a platform upgrade. They are a frontline capability shift.

“Connected government” can easily become shorthand for integration work. Sudeep talked about it as a frontline enablement shift.

They described government’s traditional reality as “procurement and bureaucracy and siloed” structures, and noted that there has been real movement: shared data, connectivity, outcome-focused service delivery, and better ability to connect systems.

But the point of connectivity is not the architecture. It is how it changes the work.

Sudeep gave a vivid description of where public servants want to spend time:

“Amazing employees that work for public service are focused on how can I actually create more efficiency… less file moving from one department to another department to more spending more time on the field with citizens providing valuable services to them.”

Connectivity and shared data enable that shift. They make it possible to create a “360 view” of the resident or citizen so decisions can be made with context, not guesswork.

Sudeep also used a simple service comparison that many citizens will recognise from banking and finance:

“Imagine someone quickly answering our phone call. They know everything about us because we have given them access to our data and they can actually solve our problem quickly.”

It is almost mundane. That is the point. This is a Government 3.0 move: “connected government” is not meant to be shiny. It is meant to be reliable, efficient, and humane.

Co-built delivery beats the “darkroom for six months” model

When we moved to delivery alignment, Sudeep described a deliberate shift in posture when working with government agencies.

They acknowledged the contractual reality, but rejected the default behaviour:

“We’re not going in there as a vendor.”

Sudeep contrasted two models.

The old model is familiar: get a requirement, sign a contract, build in isolation, return months later with a solution.

Sudeep described moving away from that:

“We have completely transitioned… [to] co-built, co-led delivery, where we are actually constantly collaborating… with our customer and… the business users itself.”

The reason is practical. Discovery does not end when delivery starts. Priorities change as teams learn. Constraints show up. Dependencies bite. If the delivery model assumes requirements are fixed, you either become rigid (and wrong) or chaotic (and unsafe).

Sudeep’s key lever is organisational: put business users inside the project team as co-deliverers, not just as people who hand over requirements.

And then Sudeep named the downstream benefit in one line:

“That creates change champion.”

Change champions are not a comms tactic. They are how adoption happens. People trust what they helped shape, and they know how to bring colleagues along because they have been close to the work.

This is also where procurement constraints become a real design input. Sudeep did not pretend government can ignore contract frameworks. The question is how to stay agile and outcome-led inside them, rather than using procurement boundaries as a reason to default back to slow, isolated delivery.

Data in dashboards is not enough. Put it in the hands of the “doers”.

When we spoke about data and decision quality, Sudeep made a useful distinction between leadership reporting and operational decision-making.

Dashboards help leaders see the system. But they do not necessarily help public servants solve citizen problems in the moment.

Sudeep described the more valuable pattern: a public servant working on a case should have the citizen’s engagement history and context “right in front of them”, so they can digest it quickly and make a decision that improves service accessibility.

“This is different from us creating a dashboard that enables leaders to look at… how the services are being delivered… It’s completely different.”

Then Sudeep framed the shift:

“Traditionally, all of our reporting and dashboard has been for leaders… Now… we want everyone who is actually looking at solving our problem to have all those data as available to make the decision for us.”

This is a Gov 3.0 move. Data becomes a daily capability, not an executive artefact.

Trust by design starts with inclusion in the decision, not just the interface

When I asked about trust, privacy, inclusion, and resilience as design constraints, Sudeep again started with a human move: include end users in the design process, including citizens where appropriate.

They gave a small example that captures a big pattern:

“If citizens don’t need… a really fancy app… whereas a simple text message could do the trick. We don’t have to build a fancy app.”

The point is not anti-technology. It is about fit to need.

Sudeep described the technologist impulse honestly:

“As technologists, we want to build the sexiest and the nicest and the most advanced things out there.”

But “what impact is it going to create for our end users” needs to be the deciding factor. That is easier to hold when citizens are involved early enough to shape the decision, not just validate it at the end.

Sudeep also made the trust mechanism explicit: when citizens understand why government is collecting data and are engaged in the “why” through the design process, trust increases. Trust is not something you ask for. It is something you build through participation and transparency.

AI is moving fast. Equity and governance decide whether it scales.

Sudeep’s view on AI in government was pragmatic. Agencies are moving quickly, often as quickly as commercial organisations, but they need to be deliberate about governance, data privacy, and alignment with policy and law.

Sudeep offered an education example to illustrate the kind of value AI can create: grading and support based on student trajectories, not just snapshot scores, and using that to recommend targeted teaching approaches.

But the point was not the demo. It was the constraints that make it safe and legitimate: student data privacy, governance, and decisions about how models learn and operate.

Sudeep returned again to the equity lens: government services are used unevenly. Someone who is 65 may rely on far more services than others. Designing AI solutions for government means designing for that distribution of need, not just the “typical user”.

Over-communicate risk, and ship in smaller blocks

On cross-agency collaboration, Sudeep was clear about what goes wrong when accountability and risk appetite are misaligned: projects fail, and data exposure becomes more likely.

Their prescription was simple, and difficult:

“Over communication and not under communication.”

Raise risks early. Bring them into decision-making. Keep communication flowing up and down the delivery chain so governance can act while changes are still possible.

Then Sudeep landed the “next decade” question on capability, not technology. High-performing agencies will deliver in an agile way inside procurement norms, with outcome-oriented, citizen-focused journeys.

And they made a portfolio argument that will resonate with anyone who has lived through a multi-year government build:

“Any agency that is moving towards very agile, fast delivery… two weeks… two months… three months… [in] a smaller outcome focused… project will be more successful.”

The reason is brutally practical:

“When a government agency… spends… three four years delivering something the technology is already too old.”

Speed is not the point. Relevance is. Learning is. Staying close enough to reality that the work remains useful.

Make the outcome the boss

The Queensland example is impressive because of the timeline. It is more important because of the discipline underneath it.

Sudeep’s core message is a posture that travels across jurisdictions:

• Start with the outcome that matters to citizens, and define it clearly enough to govern real decisions.
• Design for equity as a constraint, not as a slogan, by focusing on the people most likely to struggle with access.
• Connect services around the citizen journey so frontline staff can act with context, not file movement.
• Co-build delivery with business users close to the work, so adoption and trust grow through involvement.
• Put data in the hands of the “doers”, not only in dashboards for leaders.
• Use AI and agentic tooling to remove operational drag, but only with governance and privacy strong enough to scale safely.
• Over-communicate risk, and ship in smaller blocks so learning stays alive.

The simplest line that captures it is still Sudeep’s opening diagnosis.

“When we talk about digital transformation… we always think about technology.”

The work that sticks is when government and its partners refuse to let technology become the story. The story is the outcome. The citizen experience. The trust built one interaction at a time.