Ten years ago, an IT leader’s job was simple: keep the systems running, handle ticketing, and solve technical issues. Show up, fix problems, go home. Today? You’re expected to be a business consultant, a change agent, a value creator, and somehow still keep all the lights on.
Welcome to the new reality of technology leadership in restaurants, where the goalposts have multiplied.
The third and final panel at RestroTech Circle Middle East 2026 brought together four technology leaders managing this transformation across some of the region’s largest operations: Hany Yahya Sherif (Head of Digital Transformations at Galadari Brothers), Daryanand Shetty (Executive Director IT at Shamal Holdings), Suresh Chacko (IT Director at Al Sayer Franchising Company), and Satya Kanth Potumarthi (Director IT at Herfy). Moderating was Ajay Singh, Chief Growth Officer at Restroworks.
The conversation revealed something most job descriptions won’t tell you: technology leadership today is 30% technical skills and 70% organizational psychology, business acumen, and the ability to drive change through people who don’t report to you.
The Shift: From Support Function to Business Partner
Hany framed the transformation bluntly: “Last 10 years, the world has changed. IT leaders were focused on ticketing systems and solving issues. That’s all. Currently, we are leading the transformation across the entire organization.”
The implications are significant. “You become a very important part and factor in this organization. You are not alone; you have finance and operations, and you’re sharing your KPIs with them. The expectation is very, very high right now, more than before. The game is changing.”
Satya echoed this from his experience: “A decade ago, IT was treated as just a support function. Today, it is no longer a support function. You need to understand the requirements of each and every department, sit down with them, understand their pain points, and then come up with solutions.”
But understanding pain points is just the beginning. The harder part is determining which solutions deliver value and how to measure it.
From Cost Center to Consultant
Daryanand articulated what might be the most fundamental shift: “From an IT leader perspective, you have gone from becoming a cost center to becoming a consultant.”
The business expects IT leaders to identify opportunities they can’t see themselves. “In a lot of cases, especially with new technologies, the business cannot think of how this will help them. They don’t have the knowledge when it comes to AI and so on. You need to educate them first on what the technology is, maybe bring them up a bit. You need to understand their business, and then jointly come up with the problem statement, what is the ROI, and how can it be solved.”
This creates a peculiar challenge: technology leaders must simultaneously understand business operations deeply while staying current on emerging technologies, and then translate between these worlds in a language both sides understand.
The stakes are high. “The expectation from AI, there are two kinds of people,” Daryanand noted. “One who believes everything can be done by AI. The other is ‘my job can never be done by AI.’ You have to come to a middle ground and say this is what is possible today with the tech we have, and this is the ROI.”
The KPI That Changed Everything
At Shamal Holdings, they’ve implemented something that fundamentally shifts accountability: shared KPIs.
“Every project, every initiative has a value that is derived,” Daryanand explained. “That value is tracked, and it’s part of your annual KPI. And it’s not only you; it’s also each department. So a finance team is also measured by the value they can generate from technology.”
This changes the dynamic entirely. “It makes it a joint responsibility for them to define the ROI. Otherwise, you’ll be running behind them, saying ‘you want this, but what’s the ROI?’ and they’ll say ‘we just need it, it will improve customer experience, operational efficiency.’ Fine, nice words. Translate that to a number.”
The principle is simple but powerful: unless you can translate technology investments to measurable business value, nobody’s approving anything significant. And if the business stakeholders are measured on technology outcomes, suddenly, IT isn’t pushing adoption; the business is pulling it.
The Information Expectation Gap
Suresh described how expectations have evolved around data and insights: “Business leaders expect technology to make profits, control voids, refunds, and reconciliation to be very fast. They expect information to be real-time.”
He contrasted this with the past: “Previously, you had all information passed by the end of the day. Now they don’t want to wait until the end of the day because there could be a lost sales opportunity. Everything to be visible at the same time so they can act fast, sales, out of stock, wastages, and fraud activities.”
But speed is only part of the equation. “They’re also looking at why we need 10 or 15 systems in the framework. Reducing systems, where one system can provide four or five functionalities, multiple optimizations, and integration.”
This creates a challenging mandate: deliver real-time insights while simultaneously simplifying the technology landscape. These goals can work together or against each other depending on how thoughtfully the architecture is designed.
The Ground Truth: Spend Time in Stores
Every panelist emphasized a practice that separates effective technology leaders from those building ivory-tower solutions: spending significant time in stores and understanding operations firsthand.
Hany was emphatic: “Every digital transformation I’ve done has the same challenge: mindset. You cannot control mindset, but you can manage it. Go to the store, feel the pain of the cashier, and feel the requirement. Sit there for a long time, even for one month. You will understand every single point of the business.”
Satya went further, describing his onboarding: “About 13 years ago, when I came into this industry from a core IT background, I didn’t know what a restaurant was all about. After taking over the department, I went to the store for a month. Two days I worked on making fries, two days on the grill, and I worked at the front counter. I had to understand what they’re going through, what their pain points are. That’s when you get sensitized about their needs.”
At Al Sayer, this is policy. “Once a month, all head office employees need to work from the store,” Suresh explained. “Nine to five or nine to six, they need to send a report to the department head about any challenges they see. In that way, everyone in the head office knows the pain of operations and can act based on that.”
This isn’t just cultural, it’s strategic. You cannot architect technology for workflows you don’t deeply understand. The best technology leaders aren’t the most technical; they’re the ones who understand both the technology and the business well enough to bridge the gap.
The Kernels Strategy
Daryanand introduced a framework that’s proven effective at Shamal: identifying and nurturing “kernels”, people in each department with growth mindsets who can champion change.
“That comes from having buy-in with management where they nominate the right kind of people to work with you,” he explained. “Not everybody in every team will have the growth mindset. You need department heads to identify the right resources who are ready to work with you, learn new things along with you.”
The key is passion. “Once people get nominated and they have the passion, they will find the time. Otherwise, nobody has time. Everybody is busy, everybody is working 12-14 hours doing their day job with no time for change.”
How do you develop these kernels? “We do sessions bi-weekly with these so-called kernels and expose them to new things and then ask, ‘Now you’ve seen this, do you think it would help? Where would it help? Let’s come up with a use case.’ Apply business value, ROI, use frameworks, and then take it to management.”
Critically: “When it succeeds, it cannot be an IT success. It has to be their success. Then others are motivated around them to do more.”
This is organizational psychology at work. Change doesn’t happen because IT mandates it. Change happens because respected peers within each department demonstrate value and create pull from their colleagues.
The Psychological Battle
When Ajay pressed on how to get already-busy people to take on additional transformation work, Daryanand’s answer revealed the real nature of the challenge: “They have to believe that this is going to save their time at the end. They have to believe it’s going to help them leave at six and not work till night.”
But belief alone isn’t enough. “It also helps them stand up in front of the rest of the team. Everybody has annual appraisals. They need something that sets them apart from the rest of the team, and they want to grow. So the growth mindset also comes in, where they are more ambitious. They want to be part of projects where ultimately they get kudos for it.”
As Ajay summarized: “It sounds more like a psychological battle than it is.” Daryanand confirmed: “Yeah, it is.”
This is what technology leadership really looks like today. Technical skills get you in the door, but succeeding requires understanding human motivation, organizational dynamics, and how to create conditions where people want to change rather than resist it.
The Ownership Transfer
Suresh outlined an approach that’s proven effective at Al Sayer: “We need to get the confidence of the team. When implementing something in operations, we conduct many POCs and involve all stakeholders, from the head of operations to team members. Take feedback on how it will help. Let them be the business owner for that.”
The distinction is crucial: “As IT, we execute the project and hand over the project. But let them take ownership because they are the ones who will continue in the system. Let them get trust and confidence.”
He also emphasized staged rollouts: “Let’s stabilize, then let’s scale. Let’s introduce modules one by one. Don’t introduce everything; they’ll struggle. Step-by-step.”
And critically, he called out an internal IT challenge: “The main challenge is on the IT team itself, we don’t have enough bandwidth. My suggestion is to let there be a specific team for any digital transformation or specific projects, so it won’t disrupt day-to-day work for the IT team.”
This addresses a reality most organizations ignore: you cannot expect the team keeping systems running to simultaneously lead transformation. Those are different jobs requiring different skills and, critically, different time allocations.
The Measurement Framework
Multiple panelists emphasized that alignment on success metrics must happen before projects start, not after.
Hany was explicit: “Clear plan, alignment, and most importantly, being aligned with the measure of success before you start the project. At the end, no one will come and say, “This doesn’t meet our expectations.” You have to align before everything. How will we measure the results together? What if this happens, what will we do? Not as a tech guy; I’ll do it by myself, be aligned with them first. You will fail together or succeed together. This is the secret.”
He emphasized transparency: “Put everything on your papers. Tell them this is what we will do. Let’s go together because digital transformation is a journey, not a project. I will not deliver the project and rest for two to three months, then start another. No, it’s a journey. We have to collaborate. Otherwise, we’ll be far off the technology.”
Daryanand described how Shamal makes this operational: “Before you start a project, you have alignment with the business on what the value you’re going to get out of this. Whether it’s increased revenue, optimized operations, or even risk reduction like security stuff.”
For measurable items: “We measure usage. We link that measured usage to their KPIs and put it on a dashboard that everybody can see. Who’s using, who’s not using, who has a license but has never logged in. Unless they start using these tools, their mindset won’t change. We make it like a leaderboard and competition on who’s really delivering more value.”
This gamification of adoption drives both usage and cultural change simultaneously.
What Gets Measured at the Ground Level
Suresh provided concrete examples of operational metrics: “For technical things, we measure the outage of the system. For real things, what is the speed of service, from taking the order till executing it, going to KOT? Is order taking seamless, and is integration done properly? We measure every week or once every two weeks, checking system performance.”
But it extends beyond technical metrics: “Also, variance, refunds, voids—we measure if there’s any extra voids coming up and what’s the reason. And we hear the customer voice—that’s critical. How are they rating us? Are there any pain points from the customer side on the journey, specifically on apps or dining experience?”
Satya added: “You need to have a conversation with respective teams—finance, operations—look at their pain points, have constant interactions. When implementing a new system, don’t go with a big bang approach. Look at milestones, break bigger problems into smaller solutions, show them results, and make them the winners. That’s how you get buy-in.”
The pattern is clear: successful technology leaders measure religiously, communicate constantly, and frame wins as shared achievements rather than IT victories.
The Trust and Confidence Game
Throughout the discussion, one theme emerged repeatedly: technology leadership success depends less on technical prowess and more on building organizational trust.
Suresh captured this: “The confidence and trust we gain from the team—that’s what matters.”
Hany’s advice for facing transformation challenges: “Prepare your paper first before facing those people. Based on your skill and how you get those people confident about what you’re saying, this is the game. I believe you will succeed 100% if you prepare your paper first.”
He emphasized meeting people where they are: “Ask them where they come from, what they need, why we’re doing this change, do we really need it, what will we gain. Put it all in your paper, present it, I believe you will do it very smoothly.”
Satya reinforced the ground-level approach: “You need to have constant interactions. When implementing a new system, break it down, show results, and make them the winners. When you have better ROI coming out of a new solution, it’s always a win-win.”
The Reality Check
As the panel wound down, a few hard truths crystallized:
Today, technology leaders aren’t primarily solving technical problems. They’re solving organizational, psychological, and business problems that involve technology.
The expectation that IT leaders understand every department’s operations, stay current on emerging technology, educate stakeholders, build business cases, drive adoption, measure outcomes, and still keep systems running 24/7 is objectively unreasonable, but it’s the job.
Success requires time in stores, understanding ground reality, identifying and nurturing change champions across departments, framing technology wins as business wins, measuring everything that matters, and building trust through consistent delivery.
The title might be CIO or CTO, but the real job description is: organizational psychologist who happens to understand technology well enough to translate it into business value.
As Daryanand put it: “Unless you force them to start using some of these things, their mindsets are not going to open up. You basically make it like a leaderboard and competition, and that drives more people towards it.”
That’s the new mandate in a sentence: IT leaders must orchestrate change through influence, measurement, and psychology, not authority.
The technical part? That’s table stakes. The hard part is everything else.
