Beyond Algorithms: AI, People, and the True Measure of Software Productivity

AI actually improves productivity, but we have built an entire generation of technology leaders who focus on cost. I think relative productivity is the most relevant, even more now. Now that we are talking about AI-enabled productivity. But the real new market that’s opening up, which is not the first or the second, is the one in the middle.

It’s translating tech debt into new code. For all the talk about AI transforming our world in the commercial world, I still see hesitant mini steps of POCs. What you’re saying is the complexity of the organizational behavior, yes. And change seems to be a much larger barrier than adopting code generation in the company. Technology is easy. People are the challenge.

Pari Natarajan: Hi everyone. Welcome to another episode of the Zinnov Podcast, Business Resilience series. I have with me Dr. Ranjit Tinaikar, CEO of Ness, an interesting digital engineering firm, which is taking a leading position in the AI-led software engineering area. And we are going to be talking about some really interesting topics in the age of AI-led code development.
One of the concerns for companies is how to measure software productivity. We are going to go into a history of software engineering productivity, and what are some of the latest trends and how companies could adopt some of the modern practices in measuring AI-led product engineering.
Ranjit, welcome to the podcast.

Ranjit Tinaikar: My pleasure. Thank you.

Pari Natarajan: Ranjit, you have an interesting career arc. You started as a professor, then went into a management consulting firm, worked in McKinsey for a decade, then you took several operating roles and now CEO of Ness, an interesting AI-led digital engineering firm.

Your career is very unique compared to other CEOs I come across in tech services. Tell us a little bit about your career decisions as you went through this.

Ranjit Tinaikar: First of all, it’s a pleasure to be on this. We’ve been talking about this for many months, and finally we did it. So thank you for having me.

My career, there are two versions of the story. One is the one I give to my children, which sounds like I have really thought it through strategically and planned it, but the real story is that life happens while you’re busy making other plans. So if you go through my experiences, actually even before I was a professor, my first profession was theatre.

I wanted to be an actor. I dropped out of school. That was my one thing. Then I was a computer engineer, and then my research was on social networks. Then I worked as a consultant, and then I worked as an operator in a couple of FinTech companies. And now I’m a CEO. So you’d say, well, this is all sort of disconnected, but there are two or three themes across all of these, right?

I have always been fascinated by technology and its potential. But I am more interested in how people interact with technology. And so I was a computer engineer and I used to write code. But actually I didn’t enjoy that as much as how technology can drive innovation in organizations. And so my PhD was really using social networks to look at innovation diffusion.

So that just gives you a sense of—I like technology, but not for itself, but as a means to a broader end, how it creates impact.

Pari Natarajan: Yes.

Ranjit Tinaikar: The second theme is, if you look at it acting, research, consulting, and now leader of some organizations—there’s one common theme across all of them: storytelling. I really think when you’re talking about AI or the impact of any technology, it’s not the technology. It’s actually how people engage with it and what stories they believe about it. So I’m sure you’re going to ask me later on, does AI increase productivity by 15 to 20 percent or 55 to 100 percent?

It’s a story. And you have to be able to articulate the story to create value for where you are, but also at the same time give value to others. And that storytelling is often not fully appreciated. It is something I’ve always been fascinated with how do you tell stories? And that’s the second theme.

And the third theme is, I do think that you have to recognize there are times when you hit the limits of your abilities. And every time I’ve made shifts in my career, I’ve reached the limits of my ability. So now that you see me as a CEO, I’ve probably reached the highest limit of my ability. But thanks for asking that question. I wish I could give you a more structured answer, but that’s how I think.

Pari Natarajan: But there are commonalities across each of these that you’re being able to leverage, or you build those muscles as you go through your career?

Ranjit Tinaikar: Yes.

Pari Natarajan: So coming into software measurement, you have all of these hyperscalers with very interesting code generation software tools. And they go out and they sell this software. They tell the CEOs, “Hey, you’re going to get a hundred percent improvement in productivity. You don’t need that many engineers anymore.”

But when the CEOs go and talk to their team, they hear a very different story, right? The numbers are very, very different. Ten percent, five percent, fifteen percent. There’s no real measurement. They’re like, “Oh, maybe five percent, ten percent,” right?

So before we dive into this in a little bit more detail, tell us a little bit about the history of how software measurement came in. All of us read this Mythical Man-Month book, and you’re a student of software measurements and engineering.

Ranjit Tinaikar: Sure. I think it’s a great question. A lot of that history is often—when I tell people they’re like, “What?” But actually, the first attempt at trying to measure, or actually control not even measure—control and improve software engineering, because we couldn’t even measure software engineering in the sixties, really was by the defense contractors who were serving defense agencies.

Now you are building software for all these mission-critical platforms, and you’re giving out contracts to all these companies, asking them to build software. They wanted to ensure a certain level of quality and predictability to their deliverables. You couldn’t measure software engineering in those days.

So what they did was come up with process methods. They said if you do it in a certain way and you make the process reliable and predictable, then the output is more reliable. And that’s the genesis of the Capability Maturity Model, which we take for granted today.

It was actually Carnegie Mellon University—where I was a faculty that was part of that process of building the CMM. The Software Engineering Institute was part of it, and I had the privilege of being associated with that.

So I think the Capability Maturity Model was the first real attempt in the sixties, with defense contractors, to NASA, or to defense companies, where it became a sort of national requirement to give you good quality software.

Of course, then it was adopted by large corporations. It became standard by the seventies and eighties it was going across.

And then what happened? The technology changed. It was no longer COBOL and all that stuff. You started seeing object-oriented programming. You started visual programming. You had Visual Basic, remember?

Pari Natarajan: Yeah.

Ranjit Tinaikar: We started talking about business intelligence software technology, and the solutions you started working on themselves changed.

So this traditional CMM, which is based on a sort of SDLC—as they called it in those days, Software Development Life Cycle where every step in that SDLC was made repeatable, that became less relevant for these new technologies and new applications.

So that’s where you started seeing words like Agile and those kinds of methods. And by the way, I think both the SDLC and Agile are great process solutions, but for different problems. It’s not that one is better than the other.

And then Agile led to Extreme Programming and Scrum and all of that. But it was fundamentally a process solution to the productivity problem.

Parallelly, as we started looking at more and more process solutions, people started saying, “Well, why can’t we automate that?” And so you started seeing automation solutions like test automation and things like that. But the automation was generally limited to testing and some of those very basic steps.

Pari Natarajan: Or document management?

Ranjit Tinaikar: Managing releases. Managing releases, release management software those kinds of things.

Pari Natarajan: Yeah.

Ranjit Tinaikar: Not the core of coding.

Pari Natarajan: Sure.

Ranjit Tinaikar: Which was still considered an art form. So I still remember going to school where we used to have three-hour debates on “Is software engineering an art or a science?” And that’s the time from which this whole Mythical Man-Month came, which is if you just throw more bodies at a problem, it doesn’t solve the problem.

And so people started getting a little bit more scientific about it. And that’s where, for the first time, people started thinking let’s use lines of code or function points and things like that to measure software engineering. They had limited success.

But I’ll give you my view, after having been in this profession for a long time.

Process, automation, and metrics are all important. Don’t think they’re not important. But software engineering is different from manufacturing in the sense that when you produce a car, you produce the same car again and again and again. The way you measure productivity there is very different.

When you do software engineering, you are producing a piece of software for the first time and the only time. You see what I mean? You’re not going to produce the same piece of software again and again and again.

So the way you measure productivity is different. I don’t think personally I don’t think absolute measures of productivity are relevant in software engineering. I think there will be others out there who will disagree with me.

So what we’ve done at Ness is actually develop metrics, which are of course learning from all these process and automation paradigms that we’ve developed over time, but also incorporate the new DevOps environments and the new cloud-built engineering environments.

We say, “Listen, there’s a set of metrics. I can measure a hundred thousand metrics, but let’s focus on the two metrics of productivity that are really important.” It’s not cost. People often use cost and productivity synonymously.

Pari Natarajan: Sure.

Ranjit Tinaikar: Productivity is input upon output or output upon input. So cost is just the input. Productivity we measure in terms of speed. Can you do more work with the same amount of people or less work with even fewer people?

Pari Natarajan: Right.

Ranjit Tinaikar: But that’s the thing. Second is quality, because quality drives productivity. If you do bad work, you have to redo it again. So speed and quality is what we measure, and then a whole set of metrics behind it.

I think relative productivity is the most relevant, even more now, now that we are talking about AI-enabled code productivity. Because the environments are so complex, there are so many variables involved that there is no absolute measure of what should be Ranjit’s productivity if he works in this place.

There are lots of tools, coding environments, architectures, domains and they require different relative metrics.

Pari Natarajan: So it’s interesting you talked about relative metrics, and one of the things we hear from our customers is that the types of projects matter in how they use AI code development, right?

For example, if you’re doing a code migration project, it could be two times faster. Versus if you’re building something new it requires creativity and a lot more brainstorming among engineers and so on maybe the productivity is not so high.

Ranjit Tinaikar: Yes.

Pari Natarajan: Or the type of engineers they have. And you have teams across the globe. How do you bring these dimensions in? I know it’s related, but are there archetypes of projects where you see this impact higher or lower?

Ranjit Tinaikar: I think it’s a great question, actually. Thank you for asking me. But you know the answer to this because you and I worked on this research together about a year ago. You should chime in on your views too.

I do think to your point the type of task, the level of experience of a software engineer, and the architectural complexity are three big drivers of how anything affects productivity, including artificial intelligence.

You and I did this research where we found that if it’s existing code, the productivity impact of AI on it is much higher than if it’s a new piece of code.

Similarly, more repeatable jobs like testing see higher impact than requirements definition.

Or if it’s a more senior person working on a piece of code, the productivity impact of AI is much higher than if it’s a junior person.

So we do see that the impact does vary by environment, task, and individual. And that is why, again, relative is a better way to measure it. Because what relative means is that if you were having a completion rate on a release cycle of 85 percent, then you need to be 86, 87, 88 for that same team, same architecture.

Pari Natarajan: Sure.

Ranjit Tinaikar: That’s a more practical way that CEOs and CTOs should look at it.

Pari Natarajan: Yeah.

Ranjit Tinaikar: I don’t think absolute metrics will help.

Pari Natarajan: Got it. Got it. So, one of the other dimensions you maybe talk to clients, right? Nobody is reducing the spec.

So one thing you say is, “Hey, I’m seeing a 15 to 20 percent improvement in productivity.” But the numbers seem like the work is expanding to capture that additional value to capture more value.

So one of the ways companies spend money is in taking care of tech debt. And we talked about tech debt just now, because you could build the software much faster. Companies seem to be rewriting the software rather than maintaining code.

So how do you see, in a product, you understand the product development lifecycle really well. Do companies now just completely refactor and rewrite software compared to maintaining software? How do you see this pattern changing?

Ranjit Tinaikar: I think AI is really transforming that. The need to get out of legacy debt tech debt has been around since you and I joined the industry. Every year, someone says, “This year, I have to.”

Pari Natarajan: Yeah.

Ranjit Tinaikar: But we haven’t done it. Why? For two reasons.

One is operational risk. A lot of the mission-critical systems are sitting on COBOL platforms, which were written by this gentleman or lady who’s now 80 years old. It runs the core banking or manufacturing system. Which CIO is going to say, “I’m going to rewrite this,” and take a massive career risk and an operational risk?

So you typically kick the can and try to layer stuff on top of it to make it look pretty. But inside of it, it’s still that COBOL core. And that’s probably the primary reason. But it is a problem that needs to be solved.

Now, what AI has done is reduce those operational risks reduce those career risks. Because what AI does is actually, just as we use AI to convert English to Spanish or whatever, it can convert COBOL to full-stack Java much, much faster. So it has compressed that time.

Now, the interesting thing is the conversion of COBOL to full Java—the translation can happen. It used to happen even 15 years ago with technology. The difference is that AI can also take into account semantic aspects.

In the past, you could only do syntactic translation. Now, you can look at the context, understand what a particular variable means, see its usage, and optimize it.

Now in this translation, I think there are two flavors of AI.

Stochastic—which is Gen AI which means it predicts the probability of the next word.

Pari Natarajan: Sure.

Ranjit Tinaikar: And then there is deterministic, which is you actually have machine learning models.

Pari Natarajan: More classical AI.

Ranjit Tinaikar: Yeah. I personally think that both—though we talk a lot about Gen AI both of these types of AI are very relevant to reducing the barriers to knowledge and reducing the operational risk. That allows you to move from old tech to new tech.

And I think personally, that’s one of the largest target addressable markets for people like me.

For all the talk about AI transforming our world, in the commercial world I still see hesitant mini steps of POCs. AI is still a feature on a product that already exists. Most of the people who come to us who are building new products they say, “I want to have this AI-enabled feature. I want to spend USD 250,000 on it.”

But that’s it. Nobody’s rewriting their software platforms in a completely new way.

Pari Natarajan: Right.

Ranjit Tinaikar: And that’s the opportunity.

Pari Natarajan: That’s the opportunity.

Ranjit Tinaikar: But a long-term one. It’s not going to help me hit my quarterly target or full-year 2025 goals.

And then there is the, “Hey, can you do it cheaper and faster for me?” Which actually, for the large incumbents, is a compression of their core revenue.

Pari: Mm-hmm.

Ranjit Tinaikar: For mid-size attackers like me, it’s an opportunity.

Pari: Yes. Got it.

Ranjit Tinaikar: But the real new market that’s opening up which is not the first or the second—is the one in the middle. It’s translating legacy debt, tech debt into new code.

That’s a whole new market that’s growing, and that’s where we are playing a lot.

Pari Natarajan: So if you are a board member of a large company which is a tech-enabled company or a tech company or a CEO, what should be the question they should be asking the CTO and product teams on how they measure software in the context of all the things changing in AI? What should they ask them? Very sharp, specific question.

Ranjit Tinaikar: It’s a good question because I’m trying to give you the answer that I actually see in the battlefield. See, I think most technology experts and leaders are quite smart and competent around the measurement question.

The question one should ask is they know this why aren’t they doing it?

Pari Natarajan: Okay.

Ranjit Tinaikar: And the problem is the same as what I did in my research 25 years ago. The problem is not the measurement. It’s the people.

So I’ll give you an example. I was in a workshop where the CFO of this company said, “Well, I think this platform that Ranjit is talking about, we should use it. I would like to see the measurement every day.”

And I said to him, “Listen, not every day. You can see it in real time. I can pull the numbers up on your dashboard. You can see it anytime.”

And I could see a deathly silence go through that workshop. Which software team wants their CFO to see their productivity in real time every day?

Pari Natarajan: Sure.

Ranjit Tinaikar: So that’s probably the first one nobody likes to be measured. I don’t like to be measured, although I talk about it. But it’s a fact of life. Nobody freely says measurement. You have to figure out a way for them to get the incentive out of it.

Pari Natarajan: We are carrying trauma from our school days.

Ranjit Tinaikar: Yes, exactly right. So that’s the first thing why are you not measuring?

Second is, AI actually improves productivity, but we have built an entire generation of technology leaders who focus on cost. And who talk productivity, but actually have because of the first barrier never really looked at productivity. Or have not been held to it.

Even in their governance process, when the annual budgeting cycle happens, they’re not held accountable for productivity, really. They’re saying, “Well, this time it’s a current earnings problem, cut your costs,” or “Hey, this time we want a new product, spend more.”

Pari Natarajan: Sure.

Ranjit Tinaikar: It’s a cost-driven thing.

Pari Natarajan: Interesting.

Ranjit Tinaikar: And so the second problem is governance. For you to truly make a shift from cost to productivity, the outcomes of the software have to be clearly articulated and defined. And this doesn’t mean business outcomes every time those may be harder but you could say, “You need to be able to do all your sprints at 95 percent completion rate and reduce your costs or increase your costs.”

I think there is a productivity metric that’s just not standard in most governance.

Pari Natarajan: Sure.

Ranjit Tinaikar: So it’s not relevant. So why should they measure it?

So that’s the second one.

And I think the third one is this pertains to my industry and my interface with technology standards.

Pari Natarajan: Sure.

Ranjit Tinaikar: At least in outsourcing, that cost paradigm has gone to the next level. Most procurement departments when they outsource they want rate cards. I can tell them the big story about AI productivity.

Pari Natarajan: Sure.

Ranjit Tinaikar: They hear you out and then say, “Okay, can you send me a rate card?”

Pari Natarajan: Yeah.

Ranjit Tinaikar: Well, that’s not a productivity discussion. At the same time, the middle manager in IT also is used to talking to his vendors or her vendors like that.

So, there’s also a way of how you source business and how you get work done. All these three factors.

Pari Natarajan: So, what you’re saying is the complexity of the organizational behavior, yes, and change seems to be a much larger barrier than adopting code generation in the company.

Ranjit Tinaikar:
Technology is easy. People are the challenge.

Pari Natarajan: So when companies come to Ness and say, “Hey, I’m really committed to doing this,” how would you help them? What is your approach?

Ranjit Tinaikar: There are two, three scenarios. One is where they don’t know us. That’s a very different scenario from where I’ve worked with them to build out their product for the last ten years.

Pari Natarajan: Sure.

Ranjit Tinaikar: The second one is easier than the first.

Pari Natarajan: Okay.

Ranjit Tinaikar: In the second one literally today we have a German automotive company. You know all the German cars they have these mapping navigation solutions.

Pari Natarajan: Mm-hmm.

Ranjit Tinaikar: We build those for one of the software providers. And we went to them and said, “We’ve been doing this with you for ten years. So why don’t we take this product and we will define a set of outcomes for you we call it product sustainment and we will guarantee you these outputs. We will take this work on, and we will use AI, automation, process whatever are the levers to improve the productivity.”

Pari Natarajan: Sure.

Ranjit Tinaikar: And literally on day one, I will give you the benefits of productivity, although I have not received it. The only thing I would ask for is give me a three or four-year contract, so I have time to improve my productivity.

Pari Natarajan: Sure.

Ranjit Tinaikar: I think this is a new way to do business. And AI can be a big accelerator of that.

I think for existing customers, that’s what I go to market with.

Pari Natarajan: Interesting. And the point coming back to the point on change management behavior becoming harder but it also could create opportunities for you to go after larger opportunities. Because you can take over that team and transform the team, rather than you being purely a tools provider.

Ranjit Tinaikar: Correct.

Pari Natarajan: People provider.

Ranjit Tinaikar: Correct.

Pari Natarajan: And you take the team in, transform it, provide them outcome to the client.

Ranjit Tinaikar: Absolutely.

Pari Natarajan: It creates opportunity for you to get the larger deals.

Ranjit Tinaikar: Absolutely. I mean, I think that’s the… But to do that, you need to have a progressive client and a client in the right state of their economic journey to be able to do that.

And we are seeing that more and more. I do think it’ll become standard over the next five years. We are just seeing the trickle. At some point it’ll…

Remember when we started outsourcing? I remember this. The Indian IT outsourcing industry, NASSCOM, which is the industry—I was working with them, and they said, “Well, I think this industry has a lot of potential. I think by 2010, it’s going to be USD 2 billion.”

And somebody in the room said, “Two billion is nothing. It’s going to be at least USD 50 billion.”

And they looked at what was happening then, and they said, “Well, I’m already hitting… I’m barely hitting USD 500 million.”

Pari Natarajan: Yeah.

Ranjit Tinaikar: And so I think it’s the same with this situation. It’ll happen to us much faster than we think.

We are in the initial stages. Eventually the machine will start, I mean, the commercial machine will start playing this role.

Pari Natarajan: Yeah.

Ranjit Tinaikar: Yeah. As an industry observer and a student of tech services.

Pari Natarajan: Right. We see this as a massive opportunity for companies like Ness. Because you have, I would say, three types of customers. One are these large leaders in that area maybe JP Morgan and companies like that they would figure out how to do this.

Then there are these cutting-edge AI-native, VC-funded Silicon Valley and New York-based companies. They will figure out how to do it.

In between, there is a vast number of companies. And those companies exactly for the reasons you’ve mentioned will find it very difficult to transform. And that’s an opportunity for a nimble company.

Ranjit Tinaikar: Yeah, absolutely agree with you. I think it’s the mid-market, where they may not have the technology maturity.

And in the mid-market, I would say there are sub-segments that are particularly right like private equity portfolio companies.

Pari Natarajan: Yeah.

Ranjit Tinaikar: I think you’ll find that they have a very urgent value creation agenda.

Pari Natarajan: Correct.

Ranjit Tinaikar: And that also drives a change in behavior.

Pari Natarajan: And there’s a significant top-down behavior change it could drive.

Ranjit Tinaikar:
Correct.

Pari Natarajan: But thanks a lot, Ranjit

Ranjit Tinaikar: That’s all right.

Pari Natarajan: I see Dr. Ranjit everywhere now. But thanks for the time. It was great to discuss with you what’s happening overall in AI and software development more specifically around metrics and how the tech services industry is changing and the opportunity for a company like yours.

Thanks for your time.

Ranjit Tinaikar:
My pleasure. Thank you.

Pari Natarajan:
Thank you, everyone. Thanks for joining the podcast. Till the next one, this is your host, Pari Natarajan. Bye.

Thank you for listening to this episode of the Business Resilience Series. Stay tuned for more such interesting episodes. You can listen to our podcast on Apple Podcasts, Google Podcasts, Spotify, or wherever you get your podcasts from.

To know more about Zinnov, visit our website www.zinnov.com or drop us a note at info@zinnov.com. Follow us on Twitter @Zinnov for regular updates on our content.