Systems thinking, Social bonding & new contracts with Jithu Gopal

Speaker A: Welcome to the Software People Stories. I'm Shiv.

Speaker B: I'm Chitra. And I'm Gayati.

Speaker A: We bring you interesting untold stories of

Speaker B: people associated with the creation or consumption of software based solutions. You'll hear stories of what worked and sometimes what didn't.

Speaker A: You will also hear very personal experiences

Speaker B: and insights that would trigger your thoughts and inspire you to do even greater things.

Speaker A: Before we jump into today's conversation, a Special thanks to PMpower Consulting for encouraging and supporting this show. Right from the start, with over a thousand person years of collective experience, PMpower has helped many organizations, teams and individuals chart out their own journeys of excellence and make progress. Uh, thank you PMpower. Now let's move to today's episode.

Speaker B: Few conversations flow back and forth in time, not unlike when you meet friends from childhood. In this episode of the Software People Stories podcast, I found myself having tremendous deja vu moments as Jeetu Gopal, our guest, shared his flow of thoughts across various aspects of software engineering through his 18 plus years of work. How his interests and ways of connecting what he reads, experiences and works with have significance and relevance in the AI wall that seems to be sweeping us with it. And what habits and disciplines can hold us through as we begin to figure out new ways of working, learning, and what the future might hold for our children and aspiring engineers. Listen. Okay, so, hi Jeetu. Good afternoon and a very warm welcome to you, to the Software People Stories podcast. Um, I know I've been nudging you for quite a while, so I'm really happy that this is finally happening. So welcome again.

Speaker A: Thank you, Chitra. Um, yeah, excited to be here.

Speaker B: So our first question to guests who come on board is, um, a bit about your origin story. So I guess, did you always want to be an engineer? And how did that come to be? When did it first strike you that uh, hey, this is something I want to do and how did that happen?

Speaker A: Maybe very different from a lot of engineers I think, uh, uh, in our country wherein, um, um, straight off from college joined, uh, one of these consulting firms. It was called, uh, Logica cmg, which later became cgi. This is one of those mass recruiters who, you know, have this huge number of people who are working on software solutions that are outsourced. Uh, and I've been um, um, what I noticed, at least for the first few years of my life when I was there is, um, that the quality of work that we had to do there was definitely a lot of interesting work coming by. And of course not so interesting work as well, but the way in which it was done, I'm not, I was not sure if um, they were of good quality. And something that struck me early on that maybe there are better ways of doing this. And this is also the time, this is like late 2000s. This is also the time when I was like listening to um, like RSS feeds were a big thing. Google Reader was a thing. I don't know if people know these tools these days. And um, all the user groups, right? So the Ruby user group, the Java user group, these user groups were fairly active in Bangalore. And just talking to people and like getting uh, a bit active in the community made me realize that there was so much more to explore. I think that's when I met uh, a bunch of interesting folks who were running this company called C42 Engineering. They kind of helped me unlearn some of the stuff that I had learned from before and sort of, to be honest, relearn programming, right? Using um, test driven development, extreme programming. So just, I've just been fortunate to be among some very good uh, engineers to learn from some of the best. Uh, these were like ex thought workers and very uh, uh, uh, their ethics of working were very different from what I used to do before, which is mostly around um, uh, there's a lot of talking about engineering. And during the. When they do what they call as bike shedding is when a lot of junior engineers also understand this is why this debate is happening right now, even though it feels very fringe. But uh, you're essentially seeing some of these patterns being sort of split open and like uh, like there are like very strong opinions as to why people should use this pattern versus something else.

Speaker B: Example of any of those. It'll be very interesting to recollect because you're the third person this week that's actually spoken about patterns, design patterns, something that I haven't heard for a very long time. So do you want to sort of share a couple of examples?

Speaker A: Yeah, I mean, sure, yeah. I can't uh, recollect, um, uh, let me see, let me try my best. I remember there was this project that we were working on. This was to build a social network for the Ashoka fellows. The uh, Ashoka foundation, they've got Ashoka fellows. And this is like an internal network that they could use to connect to each other and uh, dm, um, like get introduced to others. And so we were, we were sort of helping them build out that network. And I remember I um, was looking at some of the modules, maybe the commenting module which is like uh, we had like severe debates about do we have to have threaded comments or do we just stick to like a single, like how much should you just get layered? Do not introduce threads into it. And a lot of back and forth discussions on the decisions behind that piece. And uh, uh, I mean, don't get me wrong, I was not the senior in the room at that stage, but still uh, actively putting across my voice as to maybe how we should look at this piece. But I still remember there was a huge discussion on um, uh, uh, the observer pattern and the state pattern as to like, you know, it's best to kind of do not make it a synchronous way. Broker it using an observer pattern. Let the comment thread listen onto what other, um, what the post. Uh, like when somebody's posting what else in the uh, in the system should listen to that particular event. So don't make it a direct synchronous event. Let not, let's not, don't let the comment system drive those changes out. Uh, event it out, broker it. Let somebody else observe it. So, uh, those are very interesting times, I must say. Um, and it's only in those. It's very different from just reading a book and trying to figure uh, out what this is. Because in the moment when you're debating your point of view with somebody else's, when you realize, okay, there are these architectural, uh, sort of, uh, stances that if one doesn't take right in the beginning, the rewrite is going to be much costlier later on. So. Yep. So I mean, I, I, I don't know if that made much sense, but that's something that just came to my mind.

Speaker B: It did in fact, uh, uh, and I think this is, this is something that uh, people have struggled to understand. Uh, whereas, uh, natural conversations, I think when discussions and debates are happening about one approach versus the other are something that we're all a lot more familiar with. Uh, and, and one often, like you said, just goes back to a book or an article to read about a pattern and you sort of intuit it in your line of work rather than uh, saying that hey, we'll apply this design pattern here, or this is the design pattern we can leverage in this context and other things. Um, but I also noticed that there's a lot less of those kind of conversations today, or at least what I have been exposed to in the last, uh, decade or so. Why do you think that is? Any thoughts?

Speaker A: I feel it's a byproduct of our education system. Um, therein, um, it's more directed rather than being interactive. Um so you have a teacher talking to 40 students and I mean it's very hard to scale with that kind of a um lever. Right. I mean it's not like smaller groups although I'm sure there are schools that have such like 1 is to 10 kind of setting between teacher and students where you can have more interactive conversations. So to get education out at scale I feel there have been some of these like side effects that has come out in the system wherein um you know just the point the uh. The whole idea of asking a good question, the importance of that even more so important in this day and age. Um I'm not sure um people appreciate the importance of asking good questions uh how much that is. Um again this is a very sort of long short kind of a thing. Maybe it's a byproduct of that the education system. But um we want people to sort of um uh engage more than just take directions like you know you are part of the conversation when you participate and when you push back is when you kind of understand more about the problem statement. Um and uh, I also have a different theory about how TDD is uh a test driven development is a very interesting um background to have especially in this day and age when verification is such an important part of the puzzle and the AI puzzle. So I'll maybe talk about that in a while but yeah that's sort of the answer to your question that I can think of.

Speaker B: Okay, maybe we'll come back to it hopefully later in this conversation in terms of how we can encourage more of that community led um questioning and discussion especially when uh we want people to really build engineer software engineering. Right. Uh so um, what happened after that? I mean what happened after CGI and

Speaker A: yeah so CGI happened, C42 engineering happened and we had a very decent consulting business. So then we um, uh co founded another company. A bunch of my ex colleagues uh co founded this company called Nil enso which was like an employee owned cooperative maybe the first of its kind in the country especially in the, in the tech ecosystem. Um and um with a very um sort of a niche take on how um software should be written. Maybe functional programming was sort of having its renaissance of sort with closure coming into the picture which is. Which can run off the JVM and um uh yeah uh so Ruby used to be our mainstay uh uh prior to that and then sort of the shift to closure started happening because we thought this is, this is a very interesting way of kind of Looking at how sort of data and code they are not necessarily separate and how data moves in an immutable state downstream. Um, so Nilanza was interesting, um, did a lot of interesting work there and um, after that I joined Scrubbox. Um and I really like the mission statement. Uh, I was like also fairly early customer of Scrubbox and um, um um yeah so since then it's been like about 10 plus years now and um, joined uh as an engineer, built uh, up teams, built up systems and then moved to product. So right now I'm running one of the product mandates in SpruitBox around uh, creating good advisory experiences. Yeah that's sort of the compressed version of my career arc.

Speaker B: So interesting moving from actually building stuff to uh, looking at, to broader, broader, much broader aspects of uh, what really moves the needle for consumers. Uh and we'll come back to that a little bit. Uh, in your let's say core engineering experience, what do you think, ah, some of the lessons that have helped you and that you continue to sort of look at today, whenever let's say you're stuck or uh, you feel there's a good way of doing something, what would those, some of those lessons be?

Speaker A: Yeah, um, so I think I just touched upon that the um, extreme program, the test driven aspect of it. Right. So if people haven't read about the Agile Manifesto, this might be a good time to pause and just read about the principles of Agile Manifesto. And this is not capital A Agile like this is this shall be the way that we do things. But in general what are uh the principles that is good to adhere to. So it's a uh, uh maybe that's a good starter to this. Um, and um, what um I was meant, what I meant when I said um test driven development is actually um, kind of has influenced my way of looking at uh, uh how to shape uh, how to shape the solution of a problem or think about the problem is because you attack the whole problem in a different way. Right? You are, you're not necessarily okay, I'm going to solve this, I'm going to write this piece of code. These are the functions, these are the classes. And then whatever images out of this, that's not the way you approach it. You approach from point of, you approach it from outside that solution spacing that hey, this is what I want. Uh, this is what should work when I run this, my expectation when I run a function is this right? Um, so right away you get an outsider in perspective. No matter what the function is doing inside or what the Class is doing inside. Um, uh, it doesn't matter to you. You just have to make that test pass. So um, like I said, you got these two ways of approaching the problem. But I feel like when you have an offset in perspective, you're basically trying to prod, try different permutations of how do I get what I want, my expectation of a class or a function. Uh, when I run these scenarios, you're thinking about different scenarios. You're thinking about uh, different modalities of the problem. Right. You're in the problem space more often than in the solution space. And I find that discipline, uh, is very um, important. I mean definitely helped me. But I don't see enough of that happening wherein people can, they're happy to jump straight into the solutioning aspect. So that's definitely one. And I uh, think it was Andre Karpathi who um, I think he tweeted or wrote in a blog somewhere about this difference between software 1.0 and software 2.0. And he very meant. What he mentioned was software 1.0 is when you uh, can automate anything if you can specify it, and software 2.0 is when you can automate something if you can verify it. So um, uh, uh, and that sort of resonated with me when I read that statement, which is, hey tdd, this is all about verification. You're writing your test cases first before you do something. So um, I think definitely some of those parts of my background has helped in, in this new age as we deal with you know, um, frontier models, LLM agents, all kinds of things. So um, uh, yeah, so that's uh, that's definitely one part of um, uh, my engineering background that has helped me think. The other thing is also systems thinking, um, which is um, like so going. So we have backend, uh, we've got front end, we've got middlewares. Right. And typically if you look at the normal scheme of things, the front end is where things change often a lot. Much, uh, more, less in the middlewares, maybe in the back end when some of the uh. There are certain parts of the core business that doesn't change as much as it is well written and should not change if it can be fairly well written and well composed. Um, so identifying um, how these sort of Metro kind of system works, uh, if you can sort of just design the system design. So when you think that out, um, uh, I think it really helps. Uh, and it's, it helps because you know, these are dispensable layers. You know, the, the one that is closer to the customer, maybe can change a. A lot more. Maybe you can experiment a lot more things. So um, um. And whereas things that's there in the uh. That are more core to the business, more stable and reliable, that parts you wouldn't want to churn too much because there is this larger business impact that will happen. So I think, um, um. There is something to do with maybe organizing ourselves also in that thinking. Um, uh. But I, I think that's all those are. That's another sort of thing that has come from like, you know, engineering roots. How we look at these sort of dispensable, like you know, churning layers compared to layers that shouldn't churn as much.

Speaker B: Yeah, very interesting because uh, as you're speaking it's uh, it's a whole lot of deja vu, uh, for me as well. And uh, I for one have almost held myself back. But I can't help it anymore I guess because more than ever now, um, I find my. All these are just naturally popping in all of what you mentioned, right? Uh, first think of how, um, how you would uh. The outside in view, right? This is what I wanted to do. And so therefore how should I build it out? You know, and in the course of that, because I still remember a couple of years ago, somebody demonstrated a uh, programming environment as a means to teach people. And he actually started out by writing the assertions first and in the window right next it was actually generating code, right? And uh, you could always pause and say okay, does it work now? Am I building it right?

Speaker A: Yeah.

Speaker B: So one was am I doing the right thing? And then am I building it right? So it was uh. I see a lot of that coming into play and maybe uh, also wondering about how we can really bring back this whole systems thinking approach first staying in the problem space, uh, before just diving in and saying okay, I can do this or I can code this, you know.

Speaker A: So yeah, um, and I think uh, um, the way to do this is actually would be again to just sort of invert this thing, right? So we, what do we want? Do we want to run a very successful business through that we need to have happy customers or that we have to have solutions, uh, that are innovative, uh, that doesn't feel stale in place. Ah, like if you start from these like sort of basic first principles, principles of running any business, um, uh, you, you as a team, if you come together and we understand that hey, this is the. To be innovative. Um, uh, and if people are interested to try out new things, to experiment new things to See what's going to work with the customers. We have to uh, you know, a, trust each other. Like the old world of this is what a PM has to do, this is what a designer has to do, this is what the QA or uh, an engineer has to do is kind of collapsing. Right. Um, and maybe you know, to give at least my sense of where the PM function is going, which is not very different from what people are already telling. Um, uh, I just feel like um, going back to those Metro dolls, like those sort of the layers that can churn a lot and they layers that shouldn't churn a lot. Um, I think um, let's say between PM and Eng there is a strong trust wherein hey, these are places where you can run your experiments, figure out what's working with customers. I'll build a sandbox for you to run your systems like you do your cloud design, you do, you stand up your prototypes, you do your testing. Uh, and um, uh, so much more power for that person, um, to actually be part of that system where there's a lot of trust and B, running instead of running two experiments now we can run five, ten experiments. Right? Um, so and net net I think as a team there is a good understanding of where you know, AI can be used fairly heavily and where you have to be more careful, uh, because you don't want the, the parts that are more sort of supposed to be more stable. How do you kind of make sure things don't break is something that you have to keep in mind. Right? So um, and you don't want maybe a lot more people, you don't want to open up the gates to those uh, right off the bat to everyone, right? People committing to a rapport. There are certain guardrails that one has to keep in mind because everybody can become a builder right now, right? The whole double diamond is collapsed. There is like, it should be called a square or something. The second part, the solution part of the diamond is now gone. Now we just have the problem part of the diamond. So I think that's what. So with that trust in naturally it will bring systems thinking, people will understand, okay, this is where I can play more. This is where I have to be more careful. So maybe that's one way to bring us to bring some of this thinking in place.

Speaker B: So you're saying, are you saying, uh, it's also about, let's say PM and engineering having those systems thinking like conversations and sort of bringing in some of these uh, paradigms of test driven development to those discussions as well, and saying that, hey, uh, while our Ah, version 1.0 looks like this version 2.0, we really got to make sure that it, it's working solid. We've been handling the quality, um, without any question so that the experience that we deliver is the best. Is the best.

Speaker A: Yeah, yeah. More like new working agreements between let's say a PM and design. Uh, as to um, instead of, hey, this is my territory, don't get here. Ah, right. You know, rather than that, um, you know, these are the places when I'm creating an option like uh, you go ahead and you know, play in this particular workspace and play in the sandbox. Um, so, so I feel there's more trust if working agreements are defined much better and be more explicit up front. Um, uh, and how do you enable each function? How does the PM enable the engineer to kind of write a good prd? Because there might be some interesting takes that the engineer has because that person has spoken to the customer. So yeah, so it's very nascent. We know the space is kind of evolving, but we need people who can think outside and more often than ever and more than ever.

Speaker B: Which also means that uh, there's a lot more you need to understand about your customer together. Absolutely. Uh, uh, it's almost like you're saying, I'm hearing you say that um, engineers can't sort of only wholly rely on product management to say that. Okay, you tell me the voice of the customer or you tell me what the customer is thinking or you tell me whether this will work or not. Uh, and on the one hand I'm thinking, right, those demos that happen in Sprints with the product manager, uh, are going to be perhaps taking a slightly different shape. What do you think?

Speaker A: Yeah, um, I mean, I don't know the whole um, capitally agile rituals that we used to have of low. Right. Um, how that's going to change. Um, even um, I understand the importance of Sprints and uh, those principles but um, ultimately like the two weeks print, how much of that will still stand when a lot more demos can be done in front of the customer as fast as possible. Right. But in a, in a way where you're validating what you're trying to solve for. Um, and maybe the engine is not involved because they've already built a good place for you to run those experiments. The data, uh, engineer also figured out a way to kind of track your metrics for your experiments. Things are all set up. Um, so the demo might not be like internal. Internal first and then external rather it's maybe inverted, right. And then comes the most stable aspect of actually solving it, going through proper engineering rituals and such. So I don't know, the shape of this is kind of still kind of changing. It's kind of, uh, definitely moving much faster. Um, yeah.

Speaker B: So it's almost calling upon a PM to, hey, we've given. There are now a new set of tools in your sandbox. How are you going to put it all together to do the demo? Right?

Speaker A: Anyone, PM or engineer or anyone, anybody can sort of say, hey, this is how I'm thinking about this. And the moment of inspiration starts mostly with that customer conversation. Right? So, um, it can happen for anyone who's in that conversation, the engineer or the designer. And now if you want to just quickly show something to the customer, hey, this is what you're thinking, uh, you know, just to test it out. Um, that's a demo right there, right? So the builder can be anyone now. So.

Speaker B: Yeah, yeah. And, and, uh, then I have to ask this question. Is that because I, I've noticed for the longest time that engineers are so hesitant to have those first conversations. Would you think that, uh, they should now be, um, building or learning in terms of a skill to actually exercise that a little more consciously, a little more proactively?

Speaker A: Yeah. Um, this is a tough one because I'm also somebody who had that engineering background. Um, and I think it starts with, um. So I don't want to say it's not so much about like, you know, if you don't do this, then you're not worth your salt. That's not what I want to project. But rather, um, I know, like, um, like if you are of high agency, Right. I think that's the key part, which is no matter what profession you are, your high agency, right. You want to solve a problem, you just have this dying passion to solve this problem, or you want, you want to something in this world, or you just want to show your work, your work has to make its mark, right? You, rather than just punching and punching out.

Speaker B: Right.

Speaker A: Uh, and if you have that high agency, you know, people like talking to, uh, it. And it might not come naturally, but when my, my recommendation is people who have not tried this off, uh, tried this enough, go talk to customers, you know, just be in those conversations. You don't have to make the, like do the question. You just be with somebody else who can actually have a question. Your customer support is a great place to actually do some of this stuff, like just listening, um, and not through an Excel sheet where Somebody has put them, put the remarks in. But you have to be in that moment. It is part of your LLM training. Uh, uh, and that's when the moment of inspiration strikes and that's when you would want to solve it. Because ultimately it's a human need. You want to, you hear problems, you feel like, how do I solve this? Maybe how can I improve this, uh, better, uh, for you know, at least one person out there. And I think that's a human thing. I think it cuts across everyone. Um, and uh, mostly because these layers that we have put between engineers of whichever X function and that and the customer, uh, especially when the companies go wide, if uh, you don't have that layer, it's going to be very hard for people to kind of even sort of break their silos. Like. But um, um, you know, change starts with uh, belief. And uh, uh, the biggest thing for belief is like, you know, you're listening to stories, listening to people having complaints and pain and, and that's, that's. So I would like to see more people exposed to customers. That's, that's what I would recommend.

Speaker B: Yeah. Um, you said you wanted to dwell a little bit about the, the age of the ic, right? And when you're talking about all this to me, uh, what's going on in my mind is I need to extend myself out broader out of my silo, need uh, to listen to voice of the customer. I need to listen to people who are listening to the customer first and probably taking, taking on a lot of the heat, um, talking to people who are giving us new business and so on and so forth. So, so what, what's going on in your mind when you say, you know, age of the ic?

Speaker A: Um, I think, um, any um, like sort of technological advance that comes, um, which is, which can bring a step change in productivity. It's not just an incre. Uh, the patterns that you'd normally see is the people who run with this are the ones who are already really good at their profession. They just don't have enough tools to maybe make it even 10x better. Those are the ones who typically lead the pack. Right? So the ICs have kind of become super ICs. That's something that you'll just notice. Even any org that you pick Typically, sure, AI is there. ChatGPT can do anything. Claude can do anything. When you think about your AI mavens in the company, it's not like everybody is now an AI maven. Everybody's not building a replacement for this as software. You Typically have two or three people who are sort of already leading the time and then they are the ones who maybe either get like follow deployed into different teams and maybe improve uh, that for that particular functions. And they're already like no workflow thinkers. These are folks who are already good. Only maybe with automation they would have had some sort of if triple T and those kind of uh, JPE things set up in their uh, in their part of the workflow. Just inauth AI, they can do like way more things because everything was on natural language. So if you break the whole uh, AI stack right the way how I see uh, folks kind of move from one layer to another. So you start for the whole chatbot chatgpt experience and you're using that for brainstorming. Uh, of course it can do a few more things, can create files for you, it can sort of um, you know, play a tag with you to do a bunch of things in that layer. And then um, you sort of start um, creating skills and tools in the next layer where things get automated. You know, this is something that you do time and again so you don't have to necessarily burn tokens all the time. You become, start to become a bit more efficient around some of these workflows. And then comes the social layer where skills get shared and as an organ, as a team, things get unlocked. Right. Um, and then uh, maybe the final layer is where you got agents that uh, are working with autonomy on certain tasks which you have decided as a team saying that this is okay, this is of fairly uh, high confidence that we can delegate this out to agents. So, so this is maybe what I am kind of seeing or at least hearing out from some of the people that I speak to. Um, and I think a lot of folks are still stuck in like layer one.

Speaker B: Right.

Speaker A: Even the number of people who have created a skill might be like much less if I were to look at this based on this definition. Right. Uh, forget. And, and I know a lot of orgs might be stuck in layer two wherein everybody has got their own skills or every machine is, uh, people have got their own workflows. But the social unlock hasn't happened yet. Um, ah, and as a team there is no maybe like you know, rituals that you're following or like guidelines you're creating around. How does, how does an agent deal with your code base or how does an agent, how do you create a design prototype, uh, which is consistent when uh, you're showing this to a customer. So um, uh, going back to the original question, I think Start with the age of the ic. Uh, what I'm trying to tell here is there are the folks who are already fairly good and comfortable with doing some of this stuff on figuring out the right problems to solve for how do I execute on this problem statement? Now they've got way more tools and now the tools that they got is way more powerful. Um, uh, plus since everybody's leverage is kind of increased, you don't need to have too much management bandwidth spent on those things. So all structures are going to get more flattened. Uh, you would want people who are more generic, they are more malleable in some sense. You know, instead of sticking to this is the only thing that I would do. But what more can I try out? Uh, because anyway, these LLMs are also good coaches. They can also kind of train you into things that you always want to learn but you never had got the opportunity to do so right. So you just set the right prompt and then off you. Anybody can learn uh, things right easily enough. So uh, that's mostly what I meant by um, the ICs have got a lot more power in this case and um, especially for a builder at heart, uh, nothing like it. This is like a um, great, great time to be at.

Speaker B: The time is now.

Speaker A: The time is now.

Speaker B: The time is now. Yeah. And I'm seeing that uh, even for non builders and people who, getting back to building like myself, suddenly it's, it's a lot more easy. The stuff that uh, I perhaps struggled with about eight, ten years ago, I don't need to probably uh, just need to sit down for an hour or two and then hey, voila. It's all out there. Right? It's uh, it's amazing. And, and, and I think these are great unblockers because sometimes when you get stuck, uh, you would naturally have to turn to somebody to call for help and say can you just unblock me on this? Or do something like that. But now suddenly, you know, you have at least if not anything, five or six avenues to tell you how to get unstuck. It's just gotten so much easier. Um, and I think that's a great lever. It's a great uh, unstuck um, button that you have, you know, uh, lots more power I think to everybody. Right? Um, but how do you see through all of this? Right. Um, then I think it's going to beg the question of how do we organize ourselves now. Everyone has leverage, everyone has power. Of course the, the way power is uh, is concentrated, is uneven. However, it's, it's To a large extent information is democratized. All of that is there. But how do you get better organized?

Speaker A: Yeah. Um, so from the way I see this there are at least like kind of uh, couple of axes, right? So one is uh, from within the company there's a, there's a strategy and there's an execution side of things that just take one side of the axis and then there is what I'll just make it simple like I'd call it as what uh, is inside of the company and what is customer facing let's say. So, so uh, your strategy as ah, a at least a product leader. How you want to think about this is um, hey um, uh, what are the problems that we're going after right now? Uh, how are we designing our AI systems? Is AI the right solution in this as the world is changing? What uh, are the new solutions that's coming out there? How's competition faring, so on and so forth. Um, um, you're also looking at um, because token maximization is the key uh word these days. Uh, you also want to understand do you always have to be in, in front of state of the art models? Can you, can you be more model agnostic? How are we setting ourselves up for making uh, sure that uh, we don't burn uh, uh you know, uh, capital behind uh some of these things maybe like find the right tools for the appropriate task.

Speaker B: Right?

Speaker A: So those are the decisions that you would think from a strategy point of view right now you need the right set of engineering leaders for that to have those discussions. You need the right set of who are the builders for that to kind of have those decisions. On the execution side, like I just said right now, uh, are people who are, are people set up with the right tools, shared skills to kind of go have those conversations with the customers? Uh uh, are is communication flowing? Uh, uh, so I look at product management layer as the context management layer. That's how I kind of joke inside um, and context uh, management is a key thing right? Like you know everybody has a different shape of what's the elephant that we eventually want to you know, get out of the room. But uh, there one, one what one person thinks of your building could be very different from what somebody else thinks. So how do you kind of manage that context and keep disseminating information, keep this is what we're building, this is the reason why we're building, this is the why behind it. These are the people who asked for it. Um, that doesn't get lost now. You are bottlenecked As a person because somebody always had to come and ask you, which is fine. But you've also got agents who can be on these slack channels who can, who can create some kind of a memory or memory or problem statement memory which is there in that particular channel. Right. So uh, how do you curate these things which can improve execution efficiency? Right. Um, what is a. What are the. Whatever rag equivalents that you want to build within the company for, you know, PRDs to be shared easily for design, uh, documents should be to be shared easily, so on and so forth.

Speaker B: Right.

Speaker A: So those are things on the execution side that one can look at. Um, again I'm just looking at when I think organizing ourselves. It's also about organizing like this is all like system design. This is all org design. Right. How do you think about uh, your execution side of the tools as well as your strategic side of things, um, inside and outside. I think I've kind of touched upon it which is how do you get more people out into the front of forward deployed engineering is what people say. Uh, I don't know what some of these Faxi quotes mean, but broadly speaking, you want people out, you want people to talk to customers as much as possible. You want to show, hey, this is what you're thinking maybe because fairly quickly, fairly fast. Uh, so um, how does uh, the feedback layer flow in instead of uh, getting blocked and sifted through like through these different gates like customer support or some kind of a survey tool that's sitting somewhere so you can uh. It's all the more easier for discovery to flow into one place with sentiment analysis, with all kinds of other things. Of course the raw feedback is very important. But um, setting up these tools and systems become very important as more people get to know. So many issues are happening across these different departments. So that's on the outside and on the inside, uh, it's again augs becoming more flat. Right. So you don't um. Maybe the builders who have um, who have been. Who have had to manage more people, uh, they can now take a more ic, uh sort of um, uh stuff which they have wanted to do or like at least figure out which problems they want to go after. So uh, I feel the uh, uh, on the inside at least, you know those discussions as to how do you do org design when it comes to uh, using some of these tools and how much extra leverage this depends on like how much leverage you can drive as a person also. Right. So, so, so that's um, that's sort of how I see um, us changing when we organize ourselves, it's going to become more flat. It's going to. People are going to have more context as to what's going to happen outside. Um, uh, with respect to customers, uh, and um, uh, yeah, hopefully we build the right thing. There's a much better chance of you building the right thing despite being in a situation where, uh, you can build anything. So there is this whole, like how AI slot that can be built slot now. Right, Anything can be built. So how do you prevent that? Um, yeah, so I don't have the answers to this, but I feel if we organize ourselves better, it might be much. Hopefully we have a better chance of doing it.

Speaker B: Fair enough. I think, uh, maybe six months or one year down the line we should have another conversation and then see how things are shaping up. Uh, maybe start a community to see what kind of experiments people did, are doing or are thinking of and what's working. So I see almost like, uh, uh, you know, newer communities emerging to help, um, people think through this or even have open discussions about it. Which is, which is what I see as the need of the hour. Right. Uh, and I'm, I'm seeing leaders struggling with it. I'm seeing, uh, I see individual contributors also struggling with it. Um, it's a good space to be in. Sometimes it's. You have to be in all of the messiness before something begins to emerge. Uh, but at the same time I think, uh, you know, like what you said, keeping the why and purpose, uh, in focus, uh, continues to remain important. It doesn't matter who gives it, but if, if that person is able to feed that information into something, into a common shared resource which contains org, memory and the context of the problem statement memory and the two put together, at least some of the basic questions can be answered to anyone who's interested in knowing, hey, what's happening in this project or uh, why are we building this for this customer? So I think I'm still continuing to see a very positive side of this whole thing while we go through this churn. Now, why did you put the thing about, uh, post AI?

Speaker A: Post AI.

Speaker B: Um, I was wondering if it was, uh, post the verb or post just the verb.

Speaker A: Um, so I, I'm not an AGI built person. Looks like that's also an interesting term that's going around. Um, and I, I think one of the podcasts with. There's one of the parts with Elon Musk and somebody else where they were talking about, um, I like how it was phrased as conscience and intelligence. Intelligence is getting commoditized with things token being the currency of uh, of this new commodity. But um, that intelligence has come off from a land of languages because it's a language model, right? It does, it has not. The birth of. It did not happen from, from evolution or uh, the need to survive which is where maybe our consciousness comes from. And consciousness is where I would like to keep agency as part of. So you have a need to do something, you have the freedom to do something. You want, you urge to do something and then to do that you have to employ your, your intelligence which is what was before uh to do it. And now you. That is now complemented and maybe in some cases actually it is actually much more powerful than you. Uh, in some cases the jagged intelligence thing. So um, the way I see this is uh, ultimately humanity exists to solve. Like you know, businesses are running, you know, we are there we are, listen, the stories are uh, we are here to solve problems, right? Uh, every business is there to solve a problem, a problem for, for humans. Not. These are not agents solving for problems for other agents. Right. Just said the form of the problems uh, to be solved has uh, now shifted. Like instead of it being code written by a human, it is now code or maybe some kind of a bot interface when, when an agent is sitting uh, where an agent is being fronted. So I believe the AI cycle once it's passed right now definitely I'm of the opinion that we are going through a huge cycle which is going to bring a lot more value at. Not to say that this is a, it's not a judgment on boom bust kind of thing but it is definitely going to bring value at people's expectations of now dealing with uh, elements have changed. Anybody knows that I can go to chat GPT and have something. Every domain expert is having a lot of challenge now because of the questions coming their way. No matter if you are a doctor or a lawyer or a CA or or a wealth advisor. So um, uh, because of it, net net, the quality of output also hopefully should go up because everybody knows that you know, I can be. I have to be on the top of my game. So uh, this is a step change for sure. Um, and uh, I'm curious Post AI, I think it'll. Let's not forget post AI when people right now know that you know, ultimately comes down to asking the question are we solving the right problem? What are we really trying to do here? I think those are the magical words. Um, and uh, and that's, that's a phrase that is the test of time, it will continue to do so. And uh, AI is just going to be another tool in the toolkit, A very powerful tool nonetheless. Um, ah, but you can just go and um, um, like now that building, the uh, now that building is becoming cheap where you will have a lot more, uh, it's going to be a lot more hard for your solution to kind of stand up in front of. There's a lot more noise in the world. So for signals to show and for adoption to come by, for people to feel like this is original. Right. I think that's uh, another key part. It's a slop or is it original? Right. Um, um. And I think that's going to be a larger problem. Ah, so post AI, basically my take here is um, uh, there's going to be a lot more content out there. It's going to be a lot more code and projects and systems, uh, out there. But again if you're not solving the right problem, they are just all noise.

Speaker B: Yeah, no, in fact, uh, you know Jitu, you were a, you were a great uh, mentor and juror at the recently concluded witch hunt hackathon. And as you're talking, that's um, that's one thing that really stands out I think through that whole hackathon is that uh, and it's a question that that many, many of the participants of that hackathon wrote back to say that we're so glad that we spent time in trying to figure out are we building the right solution. So it became a bit of a forcing function for all the participants to stay in the problem space. Uh, but that so many wrote back to say that it, it helped to actually uh, give better focus to what they were building eventually. Yeah, and, and uh, you know I think I completely agree with you here in terms of getting people to spend more time in the problem space. So then I have to ask this question. If you had to, let's say um, envision a primary school, uh, you know, what would that look like? I'm aware that you have um, you know, a young one at home. So uh, what would you like for him to, to know or learn or experience now? Because they are really the ones that are going to. We will be post AI sooner than later. I mean it'll be all around us. And I think we, we've also grown up in an era where we've gotten used to uh, figuring out how things work in some way, shape or form. And we'll continue that I suppose. But what would it mean for that

Speaker A: generation the social bonding is a key part here. Um, so like I kind of touched upon this before, right. We've got at schools like Montessori Systems where you have a class where um, you got like a one is to one is 12, one is to 15 kind of ratio and um, between the teacher and the students plus uh, the way kids explore and figure out things, uh, by either using an experiential mean or working with somebody to go into work towards the problem. Uh, I wish more of that happens. Um, because with directed learning for sure there are standard. There are folks who can score fairly high in exams, they will do better in life. I'm not. This is not a patch on what maybe our education used to be. It uh, but I feel um, there is definitely an edge in uh, working with people, working as teams, uh, understanding, you know, how do you have uh, how do you um, how do you channel attention to a problem, uh, making sure you know, we are. You're not doing. There's an objective to be accomplished. So I, I feel those are the core human aspects that I'm hoping is pulled forward rather than people having to discover this when they are maybe much later in college or maybe um. Like I, I would like more of that happen even breaking in schools. Uh, uh, I am not of the opinion call uh, me a Luddite. I'm not of the opinion that we should be introducing screens and interactive experiences much early in life. Uh, but the, but the thesis is there. I mean I'm still maybe making my mind around this which is you want interactive elements, you want like, like I said, asking a question, getting an answer or maybe fun like you know a play. Play is actually interactive setting. Right. So you are pushing the boundaries, you're figuring out the rules of the game. Uh, you're figuring out who is uh. Maybe uh, the Dominan might want to also maybe you know, you have to figure out how to get around them when you're playing a game. So but in a way those game. How do you bring more fun into learning is maybe a key thing that our teachers have to crack. Not uh, an easy problem. Maybe it can be made easier using screens, uh into some extent. But uh, it also means it might be like something creative about the activities that the kids are, are uh, doing and what they're engaging in. Um, and maybe like you know, uh, you don't necessarily have to learn trigonometry to succeed in life. So yeah being a bit more pragmatic

Speaker B: about also uh, you know, constructing uh, infrastructure that people are going to Rely on, uh, yeah, you know, um, or

Speaker A: you're doing some polygon based GPU math or something.

Speaker B: Yeah.

Speaker A: So, yeah, but when that happens, your curiosity will naturally drive you to pick up those things. Maybe take something that's more humanities. I hope there is a, there is a resurrection of humanities. I know STEM has taken a lot more um, space, but I think this

Speaker B: is, this is relevant because a couple of days ago I was at uh, you know, talking to a group of uh, very young parents and, and the biggest worry was uh, their children aged roughly between 7 and 10 are already. They know their parents are using uh, chat, GPT and perplexity and all of these uh, LLMs. And they're saying, hey, I want to put my question there. And the parents are saying no, you go think about it. And that's, you know, the friction is there and then those conflicts are there and a lot of it. And parents are genuinely worried that, hey, will we really lose our uh, capacity to think? Because we do know that the brain is uh, wired to be lazy or rather conserve energy because it, it, it lived in a very different time. It needed the energy to respond to danger. But now when you don't have it and you don't use it, then what happens to it?

Speaker A: Yeah.

Speaker B: So, yeah, I think uh, uh, it's to me at least being part of this podcast, this has been, I think a uh, totally change of conversation where you know, we want to talk about how building software, um, as creators and creators and consumers of software, how what their life stories were like and, and just look at us having this conversation of what is to come. Uh, it's, it's a very interesting space and realm and, and Jitu, I know you as someone to be, um, you know, who reads, who reads a lot. And uh, you know what, what has that done to you? How has that influenced your, uh, whatever you do in terms of work or even in life. And, and what are books that you feel? Why should, why do you even think people should read books? Now this is a question I get asked all the time. I have my own answers.

Speaker A: But I know, I mean, just like, yeah, I mean it's just like any habit, right? It's um. Thankfully I'm beyond the habit curve. Uh, like it, it is if you don't read, it feels like, you know, something is missing in that thing. So I've, and I completely understand. For somebody who's on, on the other side of the curve, hey, why should I even bother reading? Um, so personally for me it's kind of like A meditation thanks to the Bangalore Metro. That's when I catch up on my reading time. Like some really good books make you think, make you ask some good questions. You can draw a lot of paddles and you can sort of see history repeating a lot of times. And when Marcus Aurelius is writing meditations 2000 years ago and when you're reading through it even right now, you just feel like, just like the number of footnotes that I have in that book is just nuts. Just because I'm able to connect that even to my day to day. Right. So that hasn't changed. The human condition hasn't changed.

Speaker B: Right.

Speaker A: Uh, uh, kingdoms might come and go, technology would come and go. So books for me is that it's mostly to sort of self center myself in this world and kind of give me some kind of anchor as to which, where things are going, which way do I want to go and such as far as ah, favorite books is a very tricky question. This is, there's a lot more uh, there's a lot of really good books out there. But I'll maybe mention two, three books that I've read in the last few years. Um, so given we are talking about AI and intelligence and consciousness, I think one of the books that really stood out to me was Vilayanuramachandran's Phantoms in the Brain. Um, and this is basically um, uh, Mr. Ramchandran's forays into understanding how our brain works. What happens uh, when uh, like what we think about vision, sight, thought, um, consciousness like you know the, it, it might, it might mix into it on the surface it might make sense but actually if you go a few layers deep, uh, it's a very different world that we live in. So he talks about the patients that he's a, I believe is um, a neuroscientist and he's also a practitioner. Uh, and uh, with the patients that he's worked with what he has figured out like uh, uh, how the mapping in the brain works and in sense how you actually have two consciousness and one that hasn't expressed itself but the one that can express itself has the uh, power of lang, uh power of um, speech. So um, but what happens when that. So, so very, it's kind of very interesting. I don't want to spoil the book for me. Kind of read like a thriller in some sense.

Speaker B: Yeah.

Speaker A: So that's one. Yeah. Um, something in the same lines, um, would be um, I think it's called History of Intelligence by Max Bennett. A uh, Brief History of Intelligence by Max Bennett. Um, this came up through one of the podcast recommendations I think. And this. I haven't heard many people talk about this book, but um, it's uh, uh, it also explores like, you know, how from, from an evolutionary standpoint, how did our intelligence evolve? Just uh, only that part. Forget the entire anatomy and the human this and the human life, uh, form itself, but just how intelligence evolved. And uh, what are the there these five stages that he walks through, uh, where he says which is critical for our evolution. And uh, I remember fifth one was language. So there are um, how language in. Has unlocked the next layer of intelligence as we become, as we become more social creatures. So I found that book very thought provoking and uh, really good read. Um, yeah, these are a couple of books. Maybe the latest one that I've read is also very interesting if people are into product strategy and such. It's called, it's called Crux by Richard Rumelt. He's a, he's a guy who also wrote Good, uh, Strategy, Bad Strategy, which is also a famous book. So Crux was interesting. Um, I would recommend Crux as well.

Speaker B: Thanks. Thanks. That's, that's interesting. And we rarely get people that actually talk about books that have influenced them. So this is, I'm sure something interesting for all our listeners. Um, so in conclusion, I know we spoke through multiple um, ways within this conversation. What are some messages uh, that you would like to leave for people that are seriously, uh, considering a career in software engineering today?

Speaker A: So, well, the Boris Journey, the head of Claude Code had mentioned coding is solved. Right. Which is a very bold statement. I personally believe coding is not solved in a sense. Uh, maybe it might be at some point. Uh, it currently gives the impression that coding is fully like, it's kind of, uh, agents have taken over. Nobody's writing code. Definitely that is there. Um, and there is definitely going to be huge parts of the stack where it's going to be written by agents for sure. But at least my take on this is, um, especially since you mentioned software engineering, um, if you are into building things, if you like, you know, breaking things apart, keeping things together, like you know, uh, you know, building things, be it a maybe computer at home or uh, you know, as a child, maybe even Lego blocks. Right. So if, if that building is innate to you, I would, would say to, not, not to give up on the computer, uh, science as a. Like, I know that the enrollment in computer science has come down dramatically across colleges. Um, I, I would say like, you know, keep the flame going maybe for sure. Look at data science. Data science is a huge one. Look at um, um, look at even systems. From a systems building point of view, understanding how a compiler works, understanding how, how um, uh, algorithms work is kind of key because even when agents are writing code, uh, sometimes you don't want the most optimal solution. Yeah, you want a solution that is more social in nature, which means because humans are managing code. Right. So you would have heard of this phrase called merge help. Because agents are writing tons and tons of codes, it's very hard to figure out the review stages where now everything's getting blocked because people. Yeah, you don't know, should I merge this or not? So the underlying problem is what does good look like? Is this good enough? Is this good? Should I merge this? So you will not get the taste of what is good or what is not good if you don't write code by yourself or if you don't understand patterns when you look through code. Uh, and if you are seeing certain patterns in code, if you think that this is not right or this is right, if you have to have that intuition, developer, you have to do the job yourself. Right. So um, ah, yeah, so it's very easy to delegate the work to the agent. But maybe do a rough draft yourself first and then maybe try to refactor with an agent or uh, always, uh, make sure that you, you should, you should. If you are in a position where the agent is doing everything for you but you have no idea what the agent is doing, then it's going to be very hard. But rather you understand the scope of the problem, you understand the shape of the problem, you understand this is the patterns that I would like to follow. And then sure, I've got the agent to execute on those thinking. Because the plan is fairly detailed. Fairly detailed. It's laid out really well. The spec is fairly detailed, it's laid out really well. Uh, so you have an upper hand. So, and, but writing a good plan, writing a good spec doesn't come easy and that only comes with more reps in it. So don't leave the knack of coding, be it competitive coding, maybe outside of work or whatever it is. Just make sure that you have the uh, you have your hands dirty in code once in a while is what I would say, especially on software engineers, engineering.

Speaker B: Okay. Okay, great. No, that was nice I think because uh, what I see is a lot of uh, these conversations also happening with young folks saying that, hey, I, I've done this, this, this, this, this. And they're either citing the subjects that they've studied or you know, bits and pieces of project work they've done and, and uh, what I find myself telling them is also actually go out there and do something for someone else else that um, that would change something in their lives or make something easier. So for example, helping senior citizens navigate the digital complexity of banking or managing their finances some. And uh, for them I think these things have become so hard because things have changed so rapidly. It's not that their fundamentals are still in place. They can answer most of the questions with regards to, to what, how they want their will to work for them. Probably we can learn a lot of that. Right. But managing it and uh, not feeling the loss of control in it. So what, what would those kind of solutions look like if you could go out there and really solve something?

Speaker A: Yeah.

Speaker B: Or, and people need uh, when you look at differently abled people or uh, people struggling with, handling civic issues that are just, just a plethora of problems out there. Uh, it's a lovely conversation with you Jeetu and I hope we can do this sometime further down the line to explore all the topics that we sort of touched upon. And a lot of this conversation was very future looking, um, answers that we don't know yet or are yet to reveal themselves. So until then, uh, thank you very much. Uh, if there's anything else that you'd like to say or share, you can do that now as well.

Speaker A: No, thank you Chitra. I mean this has been great. Um, um, thanks for inviting me for this podcast and I uh, hope uh, something some of the stuff that I've mentioned either resonates with people who have seen and seen this before or at least they have some new things that they would like to try out. So I'd be happy if uh, something has instilled in them. Have uh, nothing much. So I, I just want to live with a note on like I just want to leave with an optimistic note which is that uh, play AI is here and it's a great thing. Uh, do not be pessimistic about this. Don't think that oh my job is lost or like you know, uh, it's going to be very hard for me to do xyz, uh, rather um, play uh, play on the front foot, play the offense on this. Like you know how I'm going to learn this uh, tool. How is this tool going to make me uh, 10x version of myself? Because you might have different streng and with the right prompt the AI can also help you do really well. So think about this. Everybody's got an assistant. Right? So, um, it. The job is not for the. It's still an assistant. It's helping you to do certain things. So reframe it. Framing becomes very important. Um, and, uh, uh, that's sort of my parting thought. It's a very. I just want to leave this with a very optimistic note. There's a lot more interesting, uh, uh, areas that will open up, up. And, um, uh, we just don't know that enough. The application layer of this is still getting cracked. So, uh, but when it happens, uh, you can be ready by then.

Speaker B: So.

Speaker A: So that, that would. That would be my parting thoughts.

Speaker B: Great. Thank you so much. Thank you. This has been a fantastic conversation.

Speaker A: Thank you. Thank you so much.

Speaker B: Foreign. We thank Siddharth for the music and Anita for promoting the software people stories. If you like this episode, please subscribe

Speaker A: on your favorite podcast client and spread

Speaker B: the word in your network. If you'd like to share your story,

Speaker A: contact us at, uh, podcastspm hyphen powerconsulting.com.