Why Smart Engineering Teams Still Struggle to Deliver — Lessons on Agile, Ownership, and Tech Leadership from Innostax CEO

Being smart alone does not guarantee outcomes. Alignment, clarity and clear ownership is what will guarantee the outcomes. If a team is responsible for something, then I feel that nobody's responsible. It doesn't scale — the hero nature, the superman doesn't scale beyond seven people.

Today's guest is Prashanth Tondapu, CEO of Innostax, a software consulting firm helping organizations across the US and Europe. Prashanth has spent over 15 years helping thousands of engineering teams improve software delivery. Smart teams fail every day — not from lack of talent, but from missing clarity, accountability, and the right structure. Stay until the end. You'll walk away with a new way to think about shifting from busy agile teams to real product outcomes. Make sure to subscribe and follow on your favorite podcast app and YouTube. If something resonates with you, drop a comment and share your thoughts. I would love to hear your perspective. And now enjoy the conversation.

Welcome Prashanth to the podcast. Nice to have you here.

Thank you Vit. Thank you very much for having me.

Yeah. Yeah. Absolutely. So before we jump into this topic, can you tell us a little bit about your background and the work that you do today?

Sure. So I'm Prashanth Tondapu and I am the CEO of Innostax. We are a software consulting company who primarily work with startups and scale-ups based out of US and Europe. So we work with these companies as their extended teams as well as sometimes their only teams. And over a period of 15 years doing this, I've seen hundreds of teams, and I've also seen that the smartest guys on the team does not automatically mean outcomes. And here we are talking about it today.

Okay. No, that's good. Yeah, this is you're the perfect person to talk about this and um yeah, I think it's going to be fine. So, why don't we start with uh like you said, there are many smart teams, smart people on the teams uh but they still may be struggling to deliver. So, why do you think it happens?

Uh so one common thread what I've seen across uh smart people is smart people are really good at optimizing everything. But what it happens with is like local optimization but for a project to succeed there needs to be alignment. So where lot of people lack in is the alignment piece of it. So that is the biggest threat - the alignment is the missing factor and no clear ownership uh and clarity in the team in who is responsible for what also causes uh problems you know.

I see. So when you say they optimize locally you mean like in their like area of responsibilities that they worry about and and it's kind of like infinite cycle of kind of like redoing same thing or is it a little bit different than that?

So with smartness what we have seen is uh the depth of thinking is very very huge. Like when a smart guy looks at a problem right he's going very deep into it. So when he's looking at a task he's looking very deep into that task. But when you look at a project right it is a combination of lot of things together. So when they're optimizing right they are kind of doing what is best for that particular ticket. But when you go too deep into a vertical right uh it is obvious that it's a zero sum game and you tend to miss the breath part of it. There is where uh a person who is not attached to that particular ticket can see from a little distance and make sure everything is in the right order. So that is where we see as a problem. Yeah.

I see. Okay. Um so then from the companies and your clients perspective when they come to you what are they complaining about the most?

Uh so usually what we see is uh either they say that see we have the smartest people on the team obviously they have hired them so they are smart people that is 100% sure but they are not always sure why the progress is slow why they are missing the deadlines even though everything feels good and like everybody is making progress why is the outcome not happening the business outcome from a stakeholder standpoint so what all these point towards is a symptom uh more than the actual problem. So this is what we have seen across uh most of the clients have come to us for help.

Yeah. So slow delivery. Yeah. That that's seems to be typical things uh of the projects like uh everything getting late some new things come up. Yeah. I'm speaking from my experience as a project manager. That's uh that's very typical that yeah that's a complaint. So it matches everything that I have to go through. Yeah.

Okay. So um what changes like you said what changes if the team starts owning the outcome versus just this busy ticket day-to-day work and things like that what happens?

Uh so when uh people start owning the outcome right what we have seen is uh the motivation level goes up and uh that tunnel thinking shifts from just on a ticket level to kind of a product level. So uh instead of like uh for example you know there was a client who was talking uh about like implementing uh a large SSO where they were talking about like uh we have lot of enterprise customers and we will have to integrate with their uh SSOs and uh they were talking mainly about like okay there are so many use cases that come in there are multiple ways of doing it right then one of our uh guys the team leads said like why Do you want it? Why don't you use Auth0? Like it is such a complicated system to our own. Why not just use Auth0 and kind of configure it and we will use Auth0 as a single SSO. Like think about in the long term in building it, in maintaining it and the bug fixes, the experience. How many thousands of dollars that have been saved just because you know people were not just thinking okay what is the ticket? Okay, you want me to own an SSO or do you or is it like why don't you just buy that?

I see. So in this team setup you mentioned team lead. Uh are there somebody from the business side who's doing assessment like if you like for example let's think about scrum they have a role uh product owner somebody who's talking to clients and trying to figure out the requirements. How does this fits into this framework or you're talking about just team lead? Team lead is a technical person or business person?

So uh our side uh we are a development first team. So our team leads are basically developers who understand product rather than people who understand product and the other way around. So we are not business people. We are not the people who will kind of suggest what is best for the business that is like comes from the teams that we work with. So where we kind of start getting involved is taking the problem and how to solve it in the simplest way possible. That is where the team lead starts uh adding value to.

I see. So it's basically uh technical team lead, tech lead uh who helps make decisions based on the business requirements that they get and just looking at the whole like strategic view at the from the product perspective.

Okay. And then um do you notice anything uh any behavior changes uh in the development team itself when you have uh when you're looking at the outcomes and tech lead comes in and saying this is what guys we're going to do what behavior changes at the team level.

Uh so earlier we were used to be focused on the task level seriously. So what we used to think as a consultant right your job is to deliver what is you have been asked to do. So there what we used to see is like even then our tech leads were focused on the execution of the task rather than a overall view of the product of what is going on. But slowly what we saw is like our clients started saying that you guys are really good at outcome if we give you what exactly you need to do but please try to call out things that uh we we might be uh you know that we might be missing. So that is where this concept came up even more. So what we did after that was like okay let's start questioning some requirements but uh so how the team is structured is we have the tech lead and we have individual contributors at the end of the day. So now what these individual contributors are uh if you need a good analogy right it is like a ship. So ship has lot of amazing sailors but there is only one captain. So we kind of introduced a captain who is the guy who is steering the direction and kind of bringing clarity to the team on what needs to be doing and making sure people are not rabbit holeing into things.

So it is a role which is part execution and part vision as well. So tech leads are coders themselves but the instruction is don't code unless absolutely necessary.

What this does is so what this does is like now there is somebody who is on the vision role. So that he's not able he's not supposed to be focusing on execution because it's the classic role the visionary should not be the exe the guy who is executing because otherwise visionary is not able to imagine all the best cases possible he's always thinking about how I will I execute it so that's why we have separated those roles

I see yeah that makes sense I actually see this in organizations also when they try to introduce this role of a tech lead uh it's not always uh happens because A lot of companies for the last 25 years they got stuck with this agile and scrum so much and that and scrum for example is the most uh used framework out there and it doesn't have tech lead role so by definition nobody's using it but then I see that some some companies trying to introduce this because it's very important I think it's great to have like a a bunch of people together as a team figuring out requirements and doing these things, but then kind of everybody's a lead. You have to have a single point, a single accountable decision maker, right? So, that makes total sense. That's great. And I like what you said about they're not supposed to code. They're supposed to like lead and design and architect and help out and resolve issues and things like that. Yeah, that's great.

Yeah. So let's say there is a team and how to identify or figure out what are the early signs of like the team is not doing good good and time to introduce tech lead or maybe tech lead is there but he's not really up to speed yet. What are some of the early signs um of like issues on the team?

Uh so biggest thing uh what I feel is the updates uh are a narrative. lost of a lot of uh teams that we have worked with. Updates are a narrative when you go for a scrum meeting, right? Like every everyone says on track, done this, done that, but uh the uh the updates feel believable more than you know provable. The progress doesn't appear. So I think that is the biggest part. There's a lot of optimism and like if you go to that meeting it feels like everything is good but nothing actually got shown you know. So that is where uh for us that transparency and the visible progress becomes a very important factor.

Yeah. Yeah. I see. Okay. So they do a lot of work but the overall goal the strategic goal doesn't really move forward. Okay. Yeah. That makes sense. It it happens. Yeah. So um since you touched upon the reviews and statuses and things like that, let's talk a little bit about that. So I know that you're pushing for this idea of like daily visible progress. U so can you explain this? How does it work and why is it better to do this in in this way?

So first thing uh what it changes is uh the culture like from it pushes the team from narrative to kind of demonstrable tangible progress. So it goes into loom videos that are being shared on the PRs and this is the PR that I worked things are more visible. So uh when the work is more visible right the chance for the team leads or the other people to scrutinize it the peer review goes up and the chances to mitigate the wrong direction also is higher and so well when you're looking at that visible progress day in day out right uh it also creates a a culture and a sense of healthy competition among people which they are enjoying in a sense where they are taking ownership of their uh the work that they have on seeing it not just from uh ticket to PR ready but actually seeing it all directly into production so that ownership also increases so all these things ultimately contribute to like higher ROI for the client

But then if you have this daily updates are they done during like the standup or is it continuous it's like a dashboard somewhere how do they talk to like is it visible to stakeholders. Do the team communicate to stakeholders what's going on every day? How does it work?

So uh there is this team lead who is kind of uh making sure what what the what kind of work is going on today and at the end of the day like all our uh IC's uh the individual contributors with the ticket name and the number uh they kind of give like two three lines update okay this is what I did on the high level this is what I did on the high level and if it is something working right they'll also submit uh loom videos for it they'll also create early PRs and attach to it so it's like a four or five line update which goes to the team lead. So now the team lead is able to see that and see okay this is great and if somebody got stuck they're forced to kind of call it out on that particular day and because as smart developers right I am also a developer so we have a tendency I I know what I'm doing so by tomorrow it'll be all right and I'm not pushing it but when I have to give that update what I end up doing is saying I'm blocked by this particular thing at the end of the day that itself is like a flag for other people to kind of contribute in some way rather than an uh individual contributor goes into his own silo and then tries to figure it out. So and this concise updates are shared with the client. This is also part of our invoice like we are a consulting company at the end of the day. So every day the time sheets have to be the updates on what that guy did for that particular day. So the spirit of this is not like scrutiny of the person what they did. The spirit of this is like even if a plumber comes to your house, he's doing some work, right? Like the client needs to know what is going on. Like tomorrow if he he's and the narrative is clean. Whenever you see the invoice, that particular day's GitHub check-ins, that particular day Slack updates, they all in sync give you the right story of what was happening.

So that is uh how uh like we ended up being 200 to 300 times faster than lot of other teams that we have worked with because of uh all these methodologies. Uh and this was measured uh based on the Jira points assigned by the client's team not ours. So that is the star you know how wide that is important. Yeah

Yeah. Yeah. Okay. So it's basically you creating a transparency and you're showing every day uh who's doing what and people are kind of forced in a way to explain if they are blocked and and it kind of removes that and people jump and help each other to move things forward. That's great. I like this idea. Yeah. Okay. So and then um I'm sure there are maybe cases but maybe you can share an example or two of what kind of issues sometimes uncovered by implementing this daily updates and daily progresses.

Uh so this is part of our uh process with so this is done so that large issues do not show up at some point later when people are ready. So what this uh helps us do is like even if subconsciously you're looking at a slack channel right and let's say issue number 122 is featuring multiple times you see okay from 5 days I've been seeing 122 what's the thing over there now when you look at just scroll through that right you see okay this was done this was done this was done and even the stakeholders who had instructed on doing it a certain way kind of think okay why is this taking so much time like because whenever you are setting up deadlines You are setting up the deadlines based on what is the quantum of work you think might be done during that period of time and you know in software when you kind of estimate waterfall right you kind of assume it's going to take some amount of time but agile assumes that you have unlimited time unlimited iterations and there's you know you don't have to get anything done at the end of the day like a lot of people will disagree with that obviously a lot of things get done it's a successful methodology but there is no pressure as such to kind of deliver anything you know in a stipulated amount of time. So when you push this narrative right like what happens is when you have estimated when you when you are seeing that something is taking more time than necessary that's a very important checkpoint in kind of seeing okay so why did it take more time there's always a reason why or not but it helps you like cut your losses and change direction or kind of improve your implementation and if a engineer has rabbit hole into something you know you have spent two days working on something you can't just pull it out right like you're still digging the other day comes and says I don't think this is the right option why don't you try this that itself you know is a huge improvement in itself. So this happens day in and day out usually.

Yeah. Yeah. And it also requires some um uh shift in behavior, shift in thinking, how you train your engineers because some people maybe take a little bit of pride in their work. They don't like to share or like say hey I need help and raise their hand. uh you know maybe they're shy or something like that. How do you is it the job of tech lead to motivate them to bring it up and to to like be open like this or is it the job of a like is it a corporate culture that you build? How did how did this work? I'm I'm asking this because somebody may want to say well my people are never going to be doing this. So how to break through this and kind of give them an example or two or lesson or two and say like try this maybe it will work for your organization.

Uh so when we were a smaller team we were trying to push that through our team leads itself and we faced exactly the challenge that you're talking about because resistance uh so everybody has a perspective like even the engineer who is trying to say that no I will do it a certain way he likes doing it and he believes his perspective is right and the real thing is there are no wrong perspectives right it's all about showing your perspective to the other guy on why it matters so we have companywide discussions on this like uh recently we have started bringing in external training vendors to kind of help our team to understand that perspective. But before that we were kind of explaining to the team that see we are consultants for some other company. They are paying us money to deliver this in one way or the other like we have to deliver and you have been given some amount of time some kind of estimation has been done for that particular amount of work and during any time during your execution if you feel that you're not able to hit it or something is blocking you like when you flag it we are actually helping the stakeholder who is paying for this work it is being dishonest if we are trying to kind of you know satisfy our ego or our creative thirst at somebody else's expense because somebody's paying for that particular time you know so when we bring that perspective in time then people kind of start thinking less about you know that I want to be done this particular way because this is the best way they think that probably like am I am I wasting client's money that itself changes the perspective you know that itself takes away the ego so it is like a corporate culture and kind of bringing that perspective to the table and it's a slow transition. It's not an overnight thing. We have still a lot of people who come up. We are developers. We take a lot of pride in our work. So everybody thinks they have the you know right to do it. So when these things happen right and we have seen things go more than required in that time team leads are told to kind of comp that work off from the client's invoice because client is not supposed to pay for our mistakes. And when the individual contributor also sees that right that we had to comp off this time that means something was inefficient we should have done it some other way and that like irons out over time you know so that's what we have seen

yeah okay yeah those are all good points I was also thinking that maybe also it starts when you start hiring people and you kind of vet them during this interview process if the culture matches or not because they may be coming from some other environment that that is going to be really hard for them to change and adapt which is fine. They can still get job somewhere else where it matches them. And another thing I think is creating some sort of like soft skill training if you will for the developers themselves. So they are not really like you said they don't take too much pride in their work but it's more like a team effort. So everybody have to help each other right. So that could be also some point here.

Okay. So let me come back to the tech lead concept a little bit. I want to clarify something like what are what do you see some of the biggest advantages of having a team with the single tech lead. That so that's one part and second part is like you probably seen environments where there's many people responsible for other outcome and what happens in this environment like why is it bad compared to the single person responsible for the outcome.

So tech lead again I'll go back to the analogy of the ship where there are all great sailors but one captain who is steering the ship so that the vision is kind of aligned and there is one point of contact for the client also like if something goes wrong he doesn't run after people because if there is no tech lead the client himself is managing all the developers and we are over there to reduce the cognitive load of the our client and if we just like so we are kind of cutting down on the time required as well from the client to manage it and then if he's managing individual developer then he has to manage the outcome of the individual developer make sure where the tickets are how they have progressed and if something goes wrong he searches for which developer built that and goes around so all these mess is removed so by one point of contact we are abstracting that from a client perspective first thing second thing obviously I've talked about all the added advantage when we get when we have the lead one of the things what I strongly believe is when there is no one person responsible right and if it's a team is responsible for something then I feel that nobody's responsible it goes into the concept of communism in a sense like there is a story where you know like everybody was asked to kind of contribute half a liter of milk to a cauldron every day so what and there was nobody checking because everybody's contributing so everybody assumed that somebody else is responsible anyways so slowly after some days when they opened the cauldron it was all water because everybody assumed that somebody else is responsible anyways so I can just put water for today. It ended up just being water. So I think that is what it translates into. So if there is one point of contact, one person who is responsible for the outcome and he can kind of break his responsibility into smaller pieces but there is clarity in who is responsible for what outcome that itself changes everything.

Go ahead.

No. So like it's not wrong like if you are able to find that ideal team where all the five people are extremely motivated, extremely like everything, then you have the best team. That means you're talking that you don't have a communication tax on top of your team which is rare. I mean I would actually argue that it doesn't exist because we are human at the end of the day and we are acted by our emotions and only you know probably an AI agent can keep up with it but in other cases for humans I think those layers are important.

Yeah. Yeah. Okay sense. So another question I have then is how do you make sure that this one tech lead doesn't do everything for everybody because I've seen cases like that when everybody saying like okay he's the boss now or she is and if something happens I need to go through that person or when the team starts slacking a little bit the tech lead has to step up and start executing themselves. How do you make sure that this doesn't happen and the tech lead stays as a manager and the team as an executing engine?

Understood. So for that like so the tech lead is also our people manager. So he is responsible for like we have monthly review cycles and so we don't have yearly review cycles but what we had seen early on that if you had yearly or six monthly right people are biased towards the work done by the IC in the last month rather than the complete year. So we don't have those individual checkpoints we have monthly review cycles. Every month the tech lead ends up giving a rating and feedback every month and at the end of every year whenever the appraisal cycle comes in or the review cycle comes in it is an average of everything and what happens is like if the team is slacking right and the team is not in the right place the KPI of the team lead also gets affected for his yearly review cycles. So if he has to step up every time and if he's not able to train his guys the right way, right? What we expect from the team really surfaces that early so that we can start working with the leadership team can also step in to work with that person and see what the issues are and unblock and try to solve that problem before it becomes such a big problem that the team lead is the only hero that can save the day. So these are the checkpoints which will happen in multiple layers and obviously at the end of the year if the team lead say comes and says that I am the one who is doing everything that itself is a red flag on the team lead right because you have clear KPIs for team lead if you are the most amazing team lead that means you don't have to code everything is smooth you just go to client calls and just listen like your presence is not even felt that is the most ideal team lead at the end of the day but you can't hit that level but yeah like the involvement has to be as low as possible.

Yeah, that's very interesting what you just said because I'm as a project manager and scrum master on some teams. What I tell them sometimes is like guys I want you to be at the level that you don't need me anymore and my job is to kind of get out of the way and you continue doing everything perfectly. And they always look at me like I'm crazy and I'm like what do you mean you don't want your job? Like you want to go somewhere else? I'm like, "No, that's not the point. The point is that you have to be independent of somebody telling you what to do every single time. You will learn this over time and you will like be this well-oiled machine that is keep executing and keep working and cranking through the stuff and yeah, it's exactly same thing that happens with tech also." That's interesting. Yeah.

Okay. So um let's talk about smaller companies and like startups. You mentioned you help them as well. So that maybe some new founder who's a former developer or something like that. So can you give them some advice on how to start building this sort of culture this sort of teams in their company in their startup so they can be better at execution.

Yeah. So one biggest problem I have seen from developer founders who are first-time founders right like until team of six or seven they are pretty efficient because they are on top of everything they are like the hero founder hero developer on the team but as soon as the team grows in size right uh they start doubling down on their effort more than the delegation. So the biggest thing what they will have to work on is communication, the clarity and giving clear responsibilities with clarity like delegating with control is what they will need to learn otherwise it doesn't scale like the hero nature the superman doesn't scale beyond seven people.

That's right. So, so delegate with control. Can you expand on this a little bit? Like do you have examples of how that should work?

Uh, so delegation comes from trust. Trust people enough that they will do the job. But at the same time, there has to be checkpoints where you can understand whether everything is going right or not. So trust a person to do the job. But have checkpoints saying that okay how so when it comes to my side of the fence I have my own KPIs which we have with the exec team like what are the projects that we have and which one is in red green yellow so that is my KPI like if somebody says I feel it is yellow then we start looking into it if it is green I don't even start looking into it but for my exec teams and the engineering managers there are different KPIs like they just go around the Slack channel and see what the interactions are happening. They don't intercede or kind of go into it unless they see some kind of discussion going longer than usual like there might be something. So I'm trusting you to do the job but there is some kind of oversight. And kind of giving clear metrics. Okay. You feel the client is not happy with something. You just got a hunch. Come and talk to me once like I will be the disconnected guy who will brainstorm with you and see what his expectations might be and what we are delivering and how they are not matching..

Okay, that makes sense. Okay. And then I also wanted to ask you to kind of maybe outline like the ideal setup for the team like you have a tech lead like with a team of how many people and how they should be interacting with each other day to day, months over months kind of to have this picture in people's mind who are listening right now like where they should be leaning toward in their organization or in their team at least.

Uh so I will start by saying that there is no right or wrong way of doing it but whatever works for people works for people because we are an office-first team like we prefer being in the office and we work for clients. So for us the structure is we have like a magic number which says that anybody cannot manage more than seven people. We came up with that number like if anybody has more than seven we need to break that team otherwise it is like too many people and it is just wasted effort. So that is one principle that we go by. Second thing is every day in the morning right we have a check all the teams have a checkpoint like their leads and the team meet and even though they might be working on the same task it is just a good check-in so that everybody's on the same page and kind of finding out what is going on how it is going on and all. So once a day meeting is mandatory in our world and after that there is this human angle that comes into picture where emotional empathy as well. The leads need to have emotional empathy to understand like what the people are going through and not just push them like they are machines. So that is one more skill probably we can talk about it in a different podcast maybe and right then I think once all these key features are in place right the team magically starts delivering.

I see okay yeah okay I just wanted to see some cadences maybe that the people are doing or how to kickstart this process okay that's great and then also like from all this conversation everything that you just mentioned and explained to us for somebody who's listening right now, if they just remember only one thing from this conversation, the most important one for them, what should that be?

I would say being smart alone does not guarantee outcomes. Alignment, clarity, and clear ownership is what will guarantee the outcomes. That's all I would say. Mhm. Okay. Makes sense. Thanks for that.

So, I also have at the end of the conversations with my GUESTs, I have three questions, general questions about innovation. I like to see people's perspective on this and kind of collect from my library of different people thinking differently about this. So so but the first question is how do you define innovation in a few words?

Innovation is solving real life problems and I quote real life problems in the easiest way possible.

In the easiest way possible. Okay, all right that sounds good. And then the second one is throughout the whole history what do you think which innovation changed the world the most?

if I take entire human life then obviously you cannot beat fire or wheel but I think from our perspective because as humans we can break it into two places right I think it's the internet

Why?

The connectivity that it brought in democratized knowledge democratized understanding democratized perspective I think that is the single thing that has changed the entire course of human history after fire and wheel obviously internet sits on top of fire and wheel. There was no fire and wheel. There was no internet. That's how I would look at it.

Yeah, they tend to build on each other, that's for sure.

Yes. Yes. Yes. Yes. Yes.

Yeah. Okay. And the final one is from all the tech things that we use today, which one do you think we will be laughing at 10 years from now?

Having AI agents on calls, more AI agents on calls than people on calls. I feel that will be something we'll be laughing at. Any meeting that you go to, there are so many AI note takers that are joining the call that I find very hilarious actually.

So you're already laughing at this.

Yes, yes.

Got it. Alright, well thank you very much for your perspective, your information, and good luck with your company and your teams. I hope we can connect again in the future and discuss some other topic.

Sure thing. Thanks Vit. Thank you so much. Doing these podcasts is so important — you're contributing so much back to people by getting so many perspectives in place. That's really a noble thing, selflessly trying to add value in the way that you can. Thank you for that.

Yeah, of course. Thank you very much for your time. We'll stay in touch.

Thank you. Bye. Take care.

I hope this conversation gave you fresh ideas and inspiration. If so, please share it with your friends and colleagues. Don't forget to follow, subscribe, and leave a quick comment. It helps more people discover this episode. See you next time.