 Welcome everyone to this session and we have Shriram who is working as a digital IT management consultant. He will be having a session today on agile outside technology and we are glad that everyone has joined this session. So without any further delay, over to you Shriram. Hello everyone. Thanks for joining this session. Thanks to agile India for inviting me to do this. I know agile conference is mostly a lot of people in the IT industry and in the tech industry in general. But this is slightly different topic. It's based on some of my experience of consulting for an organization in the social development sector. So I'm just a little bit curious about the kind of audience if you don't mind. So Shriram, sorry to interrupt. Can you maybe move your zoom to unbar? So it's coming as a grey box in between. Right. Is that better now? Yeah. It's great. So can you please, the people in the audience, if any of you are currently in the social development sector, could you please just say yes on chat or something and then so I get an idea of if there is anybody at all in the audience who is from that sector. Maybe we can ask them to raise their hands? Yeah, sure. If there is a raise hand icon on your screen, if you could do that as well, that's good. Okay. I don't see any hands yet. So that means there's, I mean, it's not a huge surprise. It's meant to be, there are not usually a lot of people from the development sector. I don't see any hands as yet. Is that correct, Meghna? Yeah, there are no hands. Okay. All right. But nevertheless, it's not very specific to social development sector. The stock is generally applicable to anybody who's not in an IT or software or tech industry. But even those who are, there are some, I think there are some useful takeaways. So good to know. All right. So let me start with a bit of a bit of a history. I won't bore you too much, but I think it provides useful context to how I got here and how I began to do this kind of work. So I really started off long back in 1998. I was, you know, through campus interview, my first job was at IBM Global Services. So I joined as an application developer. And I was in that kind of, I did a lot of jobs and end of 2004, early 2005 is when I joined ThoughtWorks. And that's where I got introduced to a lot of agile engineering practices. I had already kind of read about agile and I had already gotten into trouble with people in my earlier companies who were not, at that time, agile was not such a big thing. And instead, what we had was something called CMM, CMM, CMMI and so on. And there were all these quality auditors. And there was a department called Software Engineering Process Group. And I used to get into trouble with them because I was always intuitively in a way like prioritizing working software over comprehensive documentation. And, you know, they, in my perspective, they were all about documentation. So in a way, it was, you know, I kind of escaped to ThoughtWorks around that time. And I enjoyed myself. I learned a lot. But as time went by, I moved away from a full-time hands-on kind of role to more of a technology leadership and innovation leadership. So I played the role of a director of innovation. And I was a member of the Technology Advisory Board, which is part of the office of the CTO of ThoughtWorks. And then I took a break, actually, around 2009 and 10. I started working half time for a bit. I wanted to like figure out some other things. And that's when I ran the tech. I basically created the tech induction program for lateral hires. So, you know, developers who were joining already with some experience like 3, 4, 5, even 10 years of experience sometimes. But they were not necessarily exposed to the agile engineering and so on. So I developed a program and I ran that program for nearly two years while I was working half time. And around that time, I also did some bit of agile consulting for clients because by that time, there was some interest in agile and people wanted to know like how they can use it and so on. And then around 2011-12, I moved back full time. And this time, there was a products division in ThoughtWorks. And I joined a team that was building a product called GoCD. And initially, I joined as a techie, but since it was a technical product, I got to play a where a product management had for a part of the product. And as part of that, I started getting involved in marketing. You know, when clients are evaluating the product, you would do the sales demo for them, you would do sales support, you would start working on the roadmap, talk to customers about, you know, what features are working out for them, what they would like to see next, keep an eye on the competition, look at industry trends and so on. So I started doing all of that. I enjoyed that a lot. And through that, I also got to understand a lot about the way my client organizations were working. And some of that understanding was also to the agile consulting that I did, but this kind of rounded off that whole understanding. And I began to have a greater appreciation for organizational agility. So the non-technical aspects of agility, things other than what the development team itself does, the surrounding things that happen. I realized that they also need to be addressed if you have to be overall effective as a business. And so I was making notes along the way and all of that came together. I basically, you know, in ThoughtWorks, there's quite a bit of support for people who want to write books. And so I ended up writing a book on this topic agile design and Pearson published it in the US. And it was received quite well in the industry. So much so that I basically, you know, is led to a natural pivot in my career. So from hardcore engineering to product management to now, I started advising organizations on improving the performance of their technology teams and the technology organization in general. So I don't want to call it specific. In some context, this would happen in the context of say an agile transformation program or a digital transformation program and so on. But I think more generally what where at the area I was helping was with improving the performance of organizations. Now, in parallel, what happened is there's one of the aspects of the book is it talks about having semi-autonomous teams and it puts some places that are important on intrinsic motivation. So there are three aspects of intrinsic motivation, autonomy, mastery and purpose. And so it talks a little bit about autonomy, but then it also balances it out with alignment. You need to have, you can't just have autonomy. You also, people need to be aligned to the overall goals of the organization. And there needs to be some amount of accountability as well. So the word accountability was a little foreign in agile circles. It was all about collective ownership and all that. But nevertheless, through my experience, I felt like, no, accountability is also important. And therefore, there was a chapter in the book on accountability. And that was a little bit of a polarizing chapter. Some people really liked that I talked about it. Others felt like, no, I've lost the plot. But nevertheless, through my experience with clients, that whole stream of thinking around balancing autonomy with alignment and accountability, that branched into, oh, by the way, just to complete this picture. Now, since 2021, I've no longer with ThoughtWorks and Independent and doing this kind of work on my own. But that's just to complete that picture. So now coming back to this whole accountability thread, I ended up creating a, I don't want to call it a framework, but it's kind of like a framework called Cleararchy, which is also in some ways a response to self-management. There are some self-management approaches out there, because collective ownership is in a way related to self-management. And there are approaches like sociocracy, holocracy, telogenization, etc. And a lot of people were trying all those things. But my experience of big organizations told me that those things are going to work in very limited contexts. And most of them, they are not going to work. But at the same time, I was not a fan of the traditional, very strict hierarchies. So I've created Cleararchy, which is like a, I think it's a good middle ground and very practical. If you're interested, you can visit cleararchy.com. Actually, a couple of years ago, I did a talk on this at Agile India. So that's the talk is also available on YouTube. But now coming to the social development sector, that's how there is a self-management interest group in Bangalore called Cosmic. And somebody from there, they got in touch with me and said, hey, yours is a slightly different point of view, but we would like to hear it out. And so I ended up doing a talk for this community on Cleararchy. And that's how I came into contact with certain people, because some of the people who were attending that talk, they were from the social development sector. And they were also other people, like there was a sports coach and a leadership coach. So I met a few people like that. And through them, I got introduced to the founder of a social development, of a fairly big social development organization. It's an umbrella organization and there are three or four social development sub organizations under that umbrella. And I got in touch with that founder and that founder, he started, he was already interested in Agile and so on. And so he started, we started talking and eventually I got around to helping them out on a more intensive basis. Like I started having a lot of conversations with them, etc. But I'm going a little bit ahead of myself. During my initial conversations, I asked, okay, so what is the nature of your interest in Agile and so on. And that's where the typical framing, which is very common is people say that what I heard was that they were interested in becoming more agile or introducing agile ways of working into their organization. And over the years, I've become very of goal statements like this. Like people, they say the goal is to become agile and so on. Over the years, because it means different things to different people. We use the same words, but we mean very different things. And one, as I was preparing for this talk, the thing that occurred to me, which I want to share with you is that just asking to be agile is like asking for a sandwich. And I know this is not a very, you might not have heard of this particular analogy before, but I am saying this because it comes from a personal experience. And so I'll share a quick short story about this. But again, to really get a feel of how much you're going to relate to this, I should share that I grew up in Mumbai and my experience of sandwiches are Mumbai sandwiches. The street food in Mumbai is something that I miss a lot of being in Bangalore. I love Bangalore, I love the weather and everything else about it. But I miss the street food of Mumbai having grown up in Mumbai. And one key aspect of Mumbai street food is the Mumbai sandwich. So, I just want to understand, somebody is saying vada pav paranam, but this example is about a sandwich. So can people reply in the chat saying how many of you have tried the typical street food Mumbai sandwich in Mumbai? There's one person, two. There are a few, cool. Then I mean, I don't know how much you'll relate to this, but for me, the way they do it, not everybody does, but quite a few of them, the way they make that sandwich, that's really my formative in my formative years. That's what I knew as this is what a sandwich is. And for those who are unfamiliar with it, I have like a helpful picture. This is what it looks like. It's not always stacked up like this, but this particular picture helps reveal the feelings. So I have put the feelings on the side. It's nearly like five to six different vegetables, some of them raw, some of them boiled along with the coriander chutney, butter. There is a hot garlic chutney paste on the side and it's typically, you have one or two of these sandwiches and then you like follow it up with a nice masala chai or a ginger chai. So this is what I knew growing up. And then I came into IT and soon enough, I was, I had an onsite assignment and that's when I took my first international flight. Because unlike now, during that time, the middle class didn't use to take international flights. So it's a work related assignment. So that's how I got on my first international flight after the age of 20. So imagine my, I mean, this is what I knew as sandwich. So I sat in the plane and I asked them for like a sandwich, like a vegetarian sandwich. And that's what I got, just like a chunk of cheese and some tomato and some lettuce. And that was quite a major disappointment. And so yeah, that's how I feel when people talk about agile also. Our experiences might be very different. And so I no longer settle for just like, okay, let's help you be more agile and so on. I asked for like, okay, what are your measures of success? What do you mean by you want to be agile? What metric, ideally, what metrics do you want to improve by how much, in what time frame? And do you have a current baseline for this metric? That's ideal. But most of the organizations, they're unable to answer the questions in these terms. They're not able to answer the questions in terms of metrics, but at least they're able to offer some measures of success. Like, you know, oh, once we become agile, you know, this should x should improve, y should improve, and so on. So this case was no different. When I asked, when I really hoped a little about, okay, what do you mean, agile, what are your measures of success? What I got from this, this person who was the founder was that although they were social development sector, I'll get to this in a bit. They used to do a lot of projects and, you know, they had overrun on the projects, effort overrun, schedule overrun. And so that was one of the things he said that I won't reduce overrun on my projects. And the second thing was they had already adopted a certain project management tool. I'm not going to name that tool because it's probably, you know, unfair. But the adoption of that tool wasn't great. And so this person, another thing that he said is, I want to increase the voluntary voluntary adoption, because again, this was being a social development sector, the people who worked in it were people who were kind of self motivated to work, right? It was not like, I think the money isn't as attractive as it is in, say, the IT company or in a startup or whatever. So it was a lot of the culture was fairly open and, you know, people weren't really micromanaged or asked to do things, they would voluntarily sign up for things. And so he wanted to improve the voluntary adoption of the tool that was in place. So now we have something a much more concrete starting points. Okay, so this is what you want to focus on. And so you know, I took up that assignment on that this side. Yeah, and at this point, some of you might think, what do you mean by projects here? Because we are used to say IT projects or other technology projects, product development and so on. But what does projects mean in this space? So it turns out, you know, through my work, I learned quite a bit about this space. And I've tried to represent it in this picture here. There are projects in the social development sector. There are people who fund those projects, they are funders, they might be like various kinds of private foundations or government agencies, or there might be fund aggregators, like nowadays, you have these, like you can go to a website and contribute to a cause and so on. So there are fund aggregators. And then there are implementers who actually make proposals to the funders saying, okay, here is my proposal to run this program. The funder will say, I want to run a program in the area of women's health or in the area of like vaccination or something else, something like that. And the implementers, they present the proposal, they win the work and then they execute the work. And again among the implementers, there are various categories of organizations. The primary organization that gets the funds is called the need granting, and they can then rope in other organizations to execute the project. There are higher in the value chain, how organizations that are like, they design the program, they manage the program and so on. And then the next level, they bring in the next level implementation partners, they implement the program. And at the last level, you have the field partners, like say the self-help groups and other kind of people who are directly in touch with the end beneficiaries. But it is a bit of a chain. And the organization that I was helping, they were more in this kind of space. They were depending on the context, they would be a lead grantee or a program designer or a program manager or even an evaluator. Because again in this space, you do the work, you do some social development project, but then you evaluate the impact of that project. Like and you try to assess whether that thing had a good impact or not. And based on that, you know, the funder might decide to give you another project. You might get more funds if the impact report turns out to be good. So in that sense, if you see, you know, we started talking about outputs and outcomes only in the last, I think five, six years. But in the world of social development, they have understood this long back. This is very much part of anybody who enters social development, they understand this chain very well. Like when you begin with inputs, based on that you perform certain activities, those activities leads to outputs and they lead to outcomes which ultimately create some social impact. So they understand this and there are, you know, there are monitoring and evaluation agencies that are only concerned with the impact evaluation, for example. But projects in this place now, when you talk about project overrun and so on, it turns out projects are usually fixed bid, but somewhat variable scope. That means that, you know, funder says, I am going to spend so much money, I know, and in for this kind of a program. But there is a lot, there is some amount of scope variability within that. But only some amount and it is subject to the discretion of the funder. They might say, okay, I agree that you met this milestone and so I am going to release the next tranche of funds corresponding to this milestone. Therefore, overrun matters. If overrun happens with an effort overrun or schedule overrun, it is often the implementer has to absorb the overrun, the cost of that overrun. The funder, most of the time, the funder is not going to say that, oh, it took 20% more effort or it took, you know, whatever, 30% more time and so, you know, I am going to cover that for you. Most of the time that doesn't happen, right? So overruns matter. So with this context, I started talking to a bunch of people in that organization and I started understanding their context, etc. There are the whole variety of projects. And through that, I presented my findings and recommendations which I am going to give you only very high level summary over here because of time. So the first one, right? The first problem segment related to, you know, they wanted to reduce the overrun on projects. I found consistently that a lot of people were saying that they were already working long hours, they were working weekends voluntarily. This is not the typical deadline kind of thing where people are like, whether they like it or not, they are asked to work long hours. Also, there were a lot of part-time assignments to manage. So most of the key people were working on like five or six different projects, right? And, you know, they were potentially allocated like 30% of the time to each project. So effectively, they were 150% allocated. And every time they had to present a project status report to their funders or even internally, there was a lot of manual effort required to obtain the data and then to analyze the data to understand the overall project status. So although they had a project management tool in place, that tool wasn't helping to kind of generate this report, because partly because of the way they were using it. And finally, all of this thing, there was hardly any logging of time. People were not logging time. There was no time. They were time sheets for namesake, but there was very little time was being captured, even among the people in the office. Because in an organization like this, a lot of people are working in the field. Well, at the higher level implementer, they are mostly office staff. But if you want to monitor project costs, you have to monitor costs through the chain, right? You have to monitor costs at their implementers at the field level people and so on. And even in this organization, there were some people who were active in the field. So I understand that field level people, it's hard for them to put in time. But my point is that even the others, right, they were not logging time. And then when I talk to people, I heard a bunch of things. I heard things like, they said, we out of our enthusiasm, people sign up for many things. And then balls get dropped, we fail to deliver. They said, oh, delays are not just because of us, delays are because of partners not turning around things, funders not reviewing our reports and getting back to us, third party delays on account of third parties and so on. And some people also said that, of course, it will delay because we've submitted such a competitive bid. We've submitted a bid even though we know that it's going to take like, maybe say 1000 hours, we submitted a bid of 700 hours just to win the work. And therefore, unrealistic effort estimates and therefore, obviously there's going to be, the actual effort is going to be much more than the estimated, right? So now as an, I was assessing these things. And so I can, I can only like, I can't always get to the bottom of these things, right? But I've made some notes and I've understood some general patterns, but I felt like I still need to know what's really going on. And so as a recommendation, I said that, you know, in a situation like this, where people are part-time assigned to multiple projects, if you want to know what's going on, you need time logging. I am not a fan of time logging. I used to, I used to consider it like a chore and I was not, you know, I understand time logging is not the, like, the most exciting work. But in a situation like this, you want to know where is the time going? Why is the overrun happening? Then you need data. And so you need to institute a practice of time logging to then even to begin to understand what's happening. Otherwise, all you have is a bunch of opinions of different people, right? And so part of my, one of my key recommendations, the first, the first stage was let's get to a stage, let's take some steps. And I had outlined some detail steps about how to improve time logging. But, but the point was the first milestone is let's get to a stage where at least 70% of total time that people are spending is logged into the system. So we know where it went. So that was my first piece of advice. Sheeran, sorry to interrupt, but we are 30 minutes into the session. So just want to Okay, thanks a lot. I have to then really rush it up. You know what? Okay, I might please already type in your questions. I don't know how much time I'll have at the end for Q&A. Obviously, I have not done this particular talk before. So, so, you know, I'm a little bit behind schedule, which is kind of matches the situation. Anyway, Yeah, now with respect to voluntary adoption, again, my findings was that, you know, adopting a project management tool, first of all, there has to be a bad understanding of the purpose of the tool. Whereas here I felt like, you know, some people were using it more like a document sharing tool, or as a communication archival tool, rather than as a project management tool. And even some people were of course, using it the right way, a couple of projects were using it very well. But in a lot of places, you know, they were also this particular tool, it had these sort of concepts, they had a project, which you could break down into milestones and then tasks and sub tasks. And it was not, you know, you had to use them in a particular way very carefully. If you wanted useful reports out of that tool, yeah, if you just use them, whatever way you saw fit, then it was not possible to get useful reports out of this tool. And also some of the guidelines that were already in place, there was a little bit confusing. And some of it I didn't even agree with. And so I noticed all these things and I said, okay, like I made a couple of recommendations that increase voluntary adoption. First of all, there are a couple of projects that are making a good use. Can we free up some key people from those projects and, you know, help them to coach the rest of the projects. And to these two points, right, how to use it and what is its purpose? Is it document sharing or project management award? Usually there is a, you know, a role like an information architect can help in these kind of contexts who basically decide what is the, what are the information flows within the organization and what is the architecture of the information that the organization uses. So I suggested these things. And I also said, I need to get more hands-on and dive into this tool. So I asked for like access to the tool with a dummy project to help me understand its strengths and limitations. So this is what I said as the first step. First step, this is what I need. Then I can do a little more and come back to you with more recommendations. So at this point, I mean jumping ahead of myself. So the reaction was that, you know, this is all good what you're saying, but this is classic project management. Where's all the agile stuff that you're famous for, right? And I was a little bit puzzled, but because I said, see, you outlined your measures of success. You said that your problems with overruns, you have the problems with voluntary adoption of the tool and I'm suggesting you the first set of steps that you should take to address these problems, right? So really what's more important for you? Is it addressing the problems that you've shared with me or is it more important to adopt agile practices, right? So they understood that. Some of them, not all of them. Some of them understood that and they said, okay, yes, we see what you're saying. We are happy to go along. But the others, there were a few others who said, that's okay, but how do we scale it? Like, you know, they were looking for me to come up with like a nice plan, a multi-dimension plan that addresses like processes, metrics, capabilities, culture and so on. And also I'll come to that. Yeah. So that kind of thinking, right? Like, at that moment, I didn't, I give them, you know, I didn't use this picture because only after later reflection, I came up with this picture. Essentially, what they were asking for is like, you know, they've given me a problem statement and then they want a plan and that plan should have basically these dimensions, right? It should have like, okay, what are we going to do on the process trend? What are the metrics? What are the capabilities we need to have? What is the training program we'll do for those capabilities? And how are we going to address culture, et cetera? This is a very fairly traditional approach to a change program. It's a, if you look at it, this is a functional decomposition of the problem space. You're functionally decomposing into here's what I'm going to do into process capabilities and so on, right? And in some ways, this is not an agile way of going about a big change program like this. This is a big upfront, more waterfall kind of way of taking about this, right? Whereas what I was sharing with them looked more like this. It was a problem solving approach where they said, they gave me a big problem. I would break it down into smaller problems. And each problem, like as I investigated, I would break it down into smaller problems. And then at that, at the level where it becomes a solvable problem, at that level, we will say, okay, now to solve this problem, what do we need to do in terms of process? What do we need to do in terms of metrics and capabilities and culture, right? All those things will come into play on a problem by problem basis, right? And each problem might have, might have to be attacked in a different way with a different combination of process meant like one might be a more process heavy solution to the problem. The other might be a more capability intensive solution and so on, right? So this is, I think, a key difference between an agile way of approaching transformation or a change program, as opposed to a more conventional, you know, consultant framework sort of way. The consultants, they like this other approach usually because they are not aware of the client's specific problems, right? So when they are pitching something, this is easy to pitch because irrespective of the client, you can go and pitch that over framework handles process this way, handles metrics this way and so on. But in my experience, that's not very useful. It doesn't lead to actual results. It leads to a lot of ceremony and, you know, supposedly new ways of working, but it doesn't give results because you don't have a problem for this, right? So I realize I'm running short of time. So I'll basically, you know, I basically said, if you really want to be agile, here is an opportunity. I think the way you're approaching this problem itself is an opportunity to be agile about it, right? Like you design your change in an evolutionary fashion. And it's, you know, so transformation itself can be an, take an iterative approach to transformation, right? So we all know build, measure, learn in the context of say lean startup and so on. But when we talk about change programs, I would say instead of build, what you're doing is your plan, you're deciding interventions, what kind of interventions you're designing. You can use the same approach and you can say, I'll intervene a little, I'll measure or assess the result of my intervention, and then I'll learn about it, and then I'll go on to the next intervention. And so that's how, you know, I would say, like, even though you're not in the tech sector or whatever, you can apply agile outside technology by applying principles like this. So build, measure, learn is a lean agile principle, but you can apply that into your whatever change you're trying to bring into your organization could be a, you know, you might be a real estate company or you might be anything, right? But this is how you can apply practices, not by copying practices. Like, you know, I don't think they would have benefited so much by saying, oh, you should do sprints or you should do stand-up meetings or retrospectives, or you should do points-based estimation, or you should move to an open plan office layout. Yeah, you can do all those things, but is that really going to solve the problem? But if you approach it problem by problem, maybe, yeah, maybe on a particular problem, you'll realize that, okay, for this problem, sprints are actually a good idea. They make sense. And for this other problem, maybe retrospectives are a good idea, right? But I would go like problem first and then practice. So what are the domains in which you can apply this? I would say anything that is, you know, product development, R&D, innovation, creative effort, change programs. I've given some examples there, which is across now only the first of them is technology, software development, everything else is outside the world of technology, right? And in general, the rule is if there is a non-linear relationship between effort and output, then that's a good sign that, yes, agile practices principles are likely to be applicable in those sort of contexts, yeah. And even in each of those domains, it doesn't mean it's uniformly applicable to all the departments within that domain. So let's say, for example, you're a marketing company, right? So if you're creating an ad campaign, yes, that process is a develop or change process, a lot of principles apply, right? But if you're like at some point, right, after creation, there is, there might be a mass production phase, there might be a distribution phase, and there might be a run phase depending on the domain that you are in, right? Agile principles are mainly applicable here. Some of them are also quite applicable in the run phase, but not all of them. So here is a quick sample of, you know, which ones that in this color, I would say that especially for scaled operations, they might not work very well. But in general, for change and for run, a lot of these principles would apply irrespective of the sector that you are in, whether it's a technology sector or some other sector, right? And so I'd like to conclude with the key takeaways that I would like to share with you, is that the principles are more applicable than the practices in several contexts outside the world of technology. And, you know, don't just aim for agility, think about like the problems that you want to address and about the measures of success. And for whatever change you want to introduce into your organization, adopt a intervene, measure, learn approach to improving the performance of your organization. Yeah, that's what I wanted to share with you. Let me quickly look at the Q&A and see if you have any. So Nareef has a question. In Agile, people usually thrown upon tracking process state transit and using a tool. However, they keep talking about taking data-driven decisions without systematically capturing events, very hard to get the data to make data-driven decisions. Where do we draw the line? Yeah, without systematically capturing events, it is very hard to get the data. Exactly. Yeah. So sometimes, you know, people have to participate in creating data, right? They're not explicitly doing data entry, but you know, like time logging is an activity where you're actively participating in generating good quality data. Similarly, if you're using some tool and you're changing the status of a work item from like in progress to done promptly, then you're participating in the process to generate good quality data. And that is essential, even though it's not very exciting work, it is essential because unless you do that, we will be making decisions about on the basis of poor quality data. So, we have one more question in the chat section from Narayan Swamy. So, they say that, isn't the we measure learn not the same as sense respond from Sinofin? I have only like heard this term sense and respond. I have not dive deep into it. So, if you think it's the same, it's the same. You know, that's all I can say. Okay, there's one more from Naresh. It's what is the hardest part of coaching social logs? What is the hardest part? Oh, the hard question. I mean, in the I don't have like, I'm not like post pens of social logs. I have one or two examples. At least in my experience, I discovered this later. The hard part is one is getting across this message that it's not really about agile. It's about solving your problems. And solving your problems is more important than like people were seriously talking to me about, shall we shall we hire certified certified agile people? Shall we encourage our people to get certified in all these things? Should we set up a PMO in our organization? So there's a lot of dealing with some of those questions and saying that perhaps you don't need to go all that was a whatever was a bit of a challenge. And the other thing, I think otherwise, I think social logs are potentially because people are motivated and they are mostly working there voluntarily. It's actually I got a quite a good bit of good amount of traction as well. So I wouldn't say it's at least in my experience, there is nothing particularly hard about social log than other although I would say one thing, the feedback loops are much more elongated. So if you hear something, you take something to the market, you say we have product analytics and we are going to based on that, we are going to like build measure low on iterate like that. But in a real, so if you're doing something, if you're trying to improve say literacy levels in some area or something, that kind of program, the feedback loops are much longer to put something in place and to see whether what kind of impact it has had. So there the loops are much longer and that creates some difficulties. But I was talking in the context of bringing about change within the social development organization itself. So there I think the loops are not as long like you can like these kind of things, reducing overrun on projects and so on. You can try a few things and get the feedback and that's where the interweave measure learn loop can actually work with shorter feedback loops. Does the voluntary nature of social or make it hard to get accountability? I haven't experienced this. Everyone that I have spoken to, I found like very high integrity people, they were voluntarily working so long hours and so on. So I personally don't think there is a huge problem of accountability. Although they can always be like, you know, people have pet projects and they have their pet ways of, they have their chosen ways of going about things. And so sometimes we are blind. If I have my own pet ways of working, I might be blind to its ineffectiveness. And in those contexts, yes, a little bit of accountability could help to make sure that I'm not just doing things a certain way because I like it. I think we are towards the end of the session then. And thank you for leaving this. I personally like the sandwich analogy which you gave. And there are just a couple of comments from others from Edina. They mentioned they love the quote with the non-linear effort versus output. And then from Narayan, there's another comment wherein he says that in his observation from volunteering, implementing corporate kind of figure is hard unless there is enough funding of us. So again, I would like to thank you for this experience and the session today. Thanks all for your participation. Thank you, everyone. Thank you. It's a pleasure doing this. Thank you.