 We have said 1230, okay, okay. This is like one of those cases like the Indian Railways like, even if you reach the station before time, you cannot take off before time because you've already committed the time to the passengers who will join the next station. So we just want to respect that. But I'll just get it started just informally there. So all the people who are here, how many of you are coaches here? You provide some kind of coaching, okay? So roughly about one-third. The remaining two-third of the people, do they use any coaches in their organizations or teams? They would like to raise their hands. Do you have internal or external coaches? Okay, so I saw some hands going up. So one question to all the people. Have you come across this term before? Minimum viable coaching, okay? Because I didn't invent it but I just thought of, I just did something last year and after I was done this nice-sounding name and I thought minimum viable coaching sounded very cool. And I haven't come across that as a term. I don't take credit for that but I thought this was, I just wanted to kind of mix up those, mash up those two things and create something there. But when you hear this term, minimum viable coaching, what comes to your mind? Anyone would like to share whatever comes to their mind? Anything? You still have an impact but the minimum that you can do as a coach but you still have an impact somehow. Yeah, fair enough. That's fair. Anyone else? Know your limits and still create some kind of an impact. It's still be of value to the teams that you are serving. Fair enough. Okay, you will say something. What's the best you can do in a very short period of time? Okay, fair enough. We'll see. Come again, learn when to let go. So that's interesting as well. So we'll see what I, I mean, this is an experience report. This is something that I did last year and I'll talk about what I did. I'm not by enemies professing or claiming here that this is the way to go because I don't even know whether what I did was right or not. I'm just sharing it and you be the judge and you tell me if it makes any sense to you as a community here, right? So this is a short session and we'll probably finish it in 15 minutes. I have very less number of slides. And then depending on how much you can hold it off not going to the lunch table, we will still continue doing that, right? So this is about me. My name is Tathagat Burma. I'm mostly, most people call me TV. That's more handy. I'm trying to be a flat TV rather than a curved TV. So that's a fun part of that. Yeah, I did something crazy 20 years back. I went to Antarctica. I lived there for 16 months and that's a real penguin there in my hands in Antarctica. So 16 months, one six, not six zero, one six. Yeah, yeah, I would love to go there again. So that's the thing. Okay, so when we talk about coaching what comes to your mind? I just want to show you a visual here and kind of get your sense of it. What in your view is not coaching? Anything that I would like to, I can learn from all of you. What do you think is not coaching? I've just put one visual here. Maybe that probably biases your opinion but I'm just trying to get all of us to think about it. You can call out words that come to your mind when you think of, hey, this is not coaching. This is not something that really I would relate to coaching. So mentoring is not coaching. So that's, okay, you've taken the discussion to a very high plane then. I was just trying to keep it a little lower level and saying this cannot be coaching, right? But I agree with you. I think mentoring and coaching are two different words. Directing is not coaching. Giving solutions, right? So giving something in the hands of people on a simple plate and say, hey, this is a solution. Go run with it. It's probably not coaching. I agree with you. You were saying, come again? If you yell at somebody, okay. So yeah, that's another part of it. Yelling at somebody may not really qualify as coaching there. As we can probably see here, there's an angry coach here. Anyone else? Training is not coaching. So yeah, we heard that once. Training is not coaching. And of course, we all might have different take on that, but I think broadly we agree. Training is not coaching, right? Being not transparent or being manipulative is not coaching, okay? Fair enough. Leading or walking ahead of the team is not coaching in your view. That's leading. That's not coaching. Okay. There might be a very, in my mind, at least there might be a very blurry line between these two things. And there might be on and off kind of a thing there, but I take your point. I'm not saying that that's not the case, but I do take your point there. Dictating probably may not be coaching there. Not actively listening is not coaching as well. I think as coaches, we have to probably have a very active listening capabilities there, right? So that is my personal definition. I think the way I look at it is coaching to me is enabling self growth. It's just like how a child self-growth. The child is already programmed to grow. The mother nature has already programmed a child. Billions of years of genetics has already gone in. Without you, the child is destined to grow. Make no false impression about it. As somebody who's really helping the child, we can only facilitate the thing. And that's why I mean, in my view, each of these three words, enabling self and growth is important there. So this is at least my perspective of what I look at it from a coaching point of view. So with that, let me just talk about the journey. I will not name the client. This was one of the clients with whom I started working last year. And this is a small company which is duly based out of, it's a software products company based out of India and US. And they, between these two locations, they basically had the team there. Great set of people, wonderful success in the past, and they were really looking at, hey, how can we be more agile? They were not really looking at cheap version of adopting agile per se, but they really wanted to change themselves internally. So that's where I got involved there. And my coaching stance was really, I said, hey, so I was discussing with the sponsor of it and we kind of mutually agreed upon it. I think it was not by design, but we kind of stumbled onto that, which was like, okay, I'll do something. And then I started calling it minimum viable coaching. And I'll explain that in a moment what it means or an MVC. So here is how the MVC, and people are familiar with the whole notion of minimal viable something, right? I mean, this is something that we have learned so much from Steve Blank and Eric Ries about the whole customer development and the lean start of thinking that this whole minimum viable something, something is basically all about the Pareto's law. And the Pareto's law, we all remember, right? The 80, 20 of something, which basically says that 20% of the root causes are responsible for 80% of the effects. So it's basically focusing on vital few as opposed to trivial many. That's the thinking that we have basically. So I then said, okay, I think that's an interesting idea and we probably can take, instead of really having the whole nine yards of coaching happening here, maybe there's an opportunity to kind of pick and choose some of the stuff there and see how we can make a difference to this team. So this is how it happened there. And my engagement was there for about six months. So here is what I did on the month one. The month one, I went there and spent about three days with the team and the first two days, first two days was really about teaching the way, right? I mean, the teams were kind of new to agile. We are thinking and scrum as a framework or something that was chosen. We all were in a room like this and basically the idea was that, let me teach you the way, right? And then at the end of the day, I mean, at the end, so it was not like a regular kind of a scrum or agile training. I'm of the school of thought that anybody who undergoes an agile or a scrum training, at the end of the day, they must come out of the room by defining their own agile process. I think none of us have any business to embrace any ready-made standard agile process because in my mind, there is no such thing as an agile process. It's a misnomer. So what actually happened was that even though I was kind of teaching them the nuts and bolts, the ulterior motive of that session was really to teach them to find their way. So the idea was not to really come prepared with a very canned presentation script and then download everything of them for the next two days and then they go away and start implementing something in a very scripted manner. The idea was that for one and a half day, have an immersive set of conversations, explain the context, not sell it to them, let them make their own informed decision about it and then at the end of the day, have a working session where the teams will define how they want to become agile, right? I mean, they have all the data points in front of them, they have all the anecdotes, they have all the frameworks, they have all the standards in front of them. Now trust them because here is my school of thought. If you really believe in your teams, you talked about trust, great perspective there. My definition of trust is that if you do not really trust the team to decide what software process is good for them, then you don't really trust them at all. So if you believe that trust is there, then there cannot be boundary lines around it, which means if the team says scrum is useless, throw it away. Kanban is useless, throw it away. Let the team decide what is the right thing for them. Why are we imposing something on them, right? So my point of view was, I'm just going to be there in terms of teaching the way and tell them, hey, these are some of the things that people are finding interesting. You guys decide, and these are the context, these are the pros and cons, this is where it has worked, this is where it does not work and let the people figure out what is the right way of doing it. More importantly, teach them to find their own way. Or even I can go to the extent of saying, teach them how to pave their own way, right? That kind of stuff there. So this happened in the first rendezvous, right? I mean, the first time when I met up with them, we had these conversations and I did that. And the second month onwards, my role changed dramatically. I was only doing a show the way kind of thing there. So I was the lighthouse that was basically coming and telling them, trusting that there is an able captain, there is a ship there, the guys know what they are doing. But once in a while, they might get caught up in the fog and my job as a lighthouse is only to help them and say, hey guys, you need to turn. That's the only thing that I was doing basically. And this is something which was very different from what a lot of us coaches are used to, because this is something that I was doing only one day a month. I was not in situ, located with the teams. I used to travel to that city in the north, I would spend only one day with the team. And during those, during that one day, I would have a bunch of meetings. If there was a knowledge gap that the team had stumbled upon, I would make sure that I would, actually I would start interacting with them like two weeks before that. And if there was something, they would say, hey, we are not really getting it. We have tried that stuff and all that kind of thing. Then I might create like a one hour capsule and we would have some kind of a training. But then most of the time it was like, okay, show me what you have, what are the results there? What have you learned from there? What is it that you want to do? And majority of the times they would come up because these guys were not something, they were not looking for my visits to learn something from them. They were looking for my visits so that they could show something back to me and say, you know what? While you were away, we were able to learn so much. So I would basically go and have a very high level conversations about it and say, hey, you know what? This is what is happening. These are some of the things happening. We would discuss something. Once the team came up and they started. So after one month, they on their own, they dismantled the role of a manager. They decided to self-organize themselves. The managers themselves said, hey, we are happy that we have a framework now which doesn't expect us to be managers anymore. So they had abandoned the role of a manager. The next month I went, they had become a self-organizing team, dev QA all together working as pods together. Nobody was telling it to them. They were figuring out and they were discovering patterns by themselves and doing that kind of a thing. And whenever I would go there every month, once in a day, this was the kind of news that they would tell me. And they basically were not looking for a social proof from me as much as they were looking to basically have a dialogue with somebody and say, hey, we did this and now because of doing it, we are seeing these are the challenges. What do you think would be the way to get forward? So they were not looking for social proof. Don't get me wrong. These guys were young stuff. I mean these guys were, and the results were very astounding. I was something, these were beginning to happen. So for example, in three months, I started seeing that they are, so I will use some conventional measures also. And I'm not saying that I got simply blinded by them. So I started looking at the velocity of the team. And these guys for three, for four or five sprints after sprints, their velocity was like going at 40 degrees slope up. And I said, this cannot be happening. I said, it's a zero sum game end of the day, right? I mean, who's pushing, who's cramming all that work into there? So I went, I wanted to talk to the people and I said, hey, are the people really signing up for it themselves? Are they looking happy? Are they looking cheerful? Is there a kind of a collateral relationship that I can see between the throughput of the team and the employee engagement? Because if these are orthogonals, agile is not working, right? We don't want to really squeeze the juice out of people and say, you know what, you don't matter. That's not the agile way of doing it. So these guys, I was surprised actually when I found that the employee engagement was moving in tandem with the team capacity, team productivity, team throughput. And these were some of the things that you cannot lie, right? I mean, these guys want, these guys already had their number which was working for them. So my engagement went on with them for six months. I was very happy that I had fired myself out of that engagement because I was not needed anymore. These guys had gone to the point where they were truly self-organizing. I mean, the only thing to, the only thing they didn't do to tell the cell, the founder of the company was, hey, we don't need you anymore. Everything else was on kind of a thing there. So based on all the things, let me just share with you my learnings here. These are some of the things, I think these are the five things that I learned from this engagement. The first thing was respect the Kochi. Now I know there is no such word in English language as Kochi, but if you Google for it, I assure you that you will actually find a word with the description that there is no such word in English language. So I think you can bear with me for a moment, right? But I think you all understand. It's like we have created a word mentee instead of prodigy in the mentor mentee relationship. I'm just using the say, I'm just giving a little spin to that word and saying Kochi. I think a lot of times we go with the mindset, as I said, that I'm sitting on this high pedestal and telling people, you know what? I am this great guru in agile and I'm coming here and I'm going to teach you guys how to do agile. I think to me, this is nonsense. Now, to me, the person who deserves the most respect in the food chain is the person who's sitting in the trenches and is closest to the problem being solved there. Everybody else is only doing power pointing. And the more you do power pointing, the less respect we have. I mean, I'm doing power pointing, so I'm careful here, right? But that's just been my thing. And these guys, so this was a group of about 50, 60 engineers and these guys were cross functional. They were about five product managers whom we were kind of aligning them to the thought process of what it takes to be a product manager in the context of scrum. And these guys changed it very well. I mean, nobody gave them detailed guidance. They figured out, they would go out on the web and read the stuff and come back and do that thing there. So my respect for this whole conversation has shot up a few notches actually because the more you trust people and the more you say that I may peer to you as a coach, I think it can change the equations in a big way. The second is discard the coach's ego. A lot of times we go with this massive, massive chip on our shoulders is like, hey, I have these like, have you seen those people on LinkedIn whose list of credentials and certificates is longer than their names? I normally take snapshot of it and put it on my Facebook stream actually, right? Because there are some, I mean, these are some very funny conversations like tak, tak, tak, tak, all the alphabet soup and the credential soup is right behind them, right? I think we get into un-voluntarily this whole coach's ego and we get into this point that hey, you know what? I have done this $2,000 certification. How can I be wrong? That kind of stuff. To me, I think the most important advice I have learned for myself and I would give to the fellow coaches is hang your ego outside the door and then walk in humbly. I think that's the best way for a coach to really be of value here. The third was adapt your stance. A lot of times, okay, let me just back it up a little bit. Most of the times we don't even understand and know our stance. We typically have a one track mind and we just go with that thing. I think the first thing is to really understand and say, hey, what is my stance as a coach? How do I really attack the problem? How do I really go with a group of people? How do I really start having conversations and so on and so forth? And then after that, really be able to understand and say, you know what? Probably horses for courses is a better strategy. We may never be able to do a one size fit all and say, come what may? I'm just going to repeat the same thing. Repeat the dose till the patient dies kind of a thing there. I would rather want to do something like a horses for courses strategy. The fourth point, again to me, very important and very dear to me. Teach thinking. Don't teach techniques. Don't teach tools. And for goodness sake, never teach tools. It's sometimes you might have to teach techniques, but I would say if I were you 80% of the times I would teach them to think. That's more important to me. It goes beyond even the whole the Chinese saying of saying that teach a man fishing and he will thank you for the whole life kind of thing. I'm not talking about teaching a skill here. I'm talking about teaching thinking. How do you really go out of the box? How do you really change it? Which is, what I would say is I won't say I'm an accomplished teacher of thinking, but I was an accomplished student of how to teach thinking during this because six months that I was with them, I think my only value addition to them was that I was able to teach them a little bit of how to think, solving their own problems by themselves. And the last thing is enable self growth as I said in the beginning there. I think it's important a lot of times, and I know I've been in the software industry for the last 25 years. A lot of times as a manager and a senior manager, the more number of people report to you that your ego is actually more and more inflated, that you know what, these 200 people, they cannot do anything without me. And it gives a major kick. You talked about the vacation test. I think it's an awesome thing. I've tried that in my career 15 years back. Went on a vacation for two weeks without telling where I am. Team was much more effective without me. I went to the town hall and I told the guy, this is the guy who did better than me, he should be made the manager. I think that calls for a lot of courage for people to accept it with humility and say you know what, people are actually doing better than me, let's give them a chance there. So in my view, it's not important to really say that, oh as a coach, I have to be there five days a week. A lot of times, how many of the people here, since we have a room full now, I just want to do a quick test here. How many of the times you as a coach or you have a coach who's coming in is in your organization, let's say more than three days a week. Can you raise your hands? Okay, so I see about 15% of the hand. Remaining people, is it like how many days? Five days a week, three days a week? A one day a week, anyone? Okay, I see one and two days a week. Okay, few people. Five days a week, anybody? Like your coach is totally embedded with the teams that I see a few hands going up there. A lot of times, it can actually give me a false sense of prowess about myself and say, you know what, I have to be there in the office. I have to be with these teams. These teams will not even be able to do it. Retrospective without me. You know what, I'll say, who cares if they cannot do retrospective today? The point is, if you as a coach do not have a disengagement strategy, you probably are not the right coach for the team anyway. Because you are not grooming the team to be independent by yourself. You are grooming yourself to be a parasite on the team, which to me is a big anti-pattern by itself, right? So this is how I would see that. I think as a coach, I've got a great opportunity. And again, I won't take credit for that. It's something that originated in the conversations. We stumbled upon one day a month and we found that pattern would extremely well. So one day a month was a pattern in which we would like do the stuff that I talked about there. I just want to end it with one of the famous quotes that I love, if you want to build a ship, don't drum up the people to collect good and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. I think that to me is the essence of coaching. A lot of times we really go and very get fixated on the method process and tool, this is how you have to do daily stand up, this is how you have to do planning poker, this is how you have to do CFD. I think that's not important. That's of no value to be honest. What's more valuable is, if after talking to you, even if it's 15 minutes a day, people go back with so much of charge left and so much of spring in their feet that they want to go out and do something there. I think that to me is much more important than that. So these have been some of my experiences there. Since it's a short experience report, I'll be writing the report and putting it up on my slideshare as well, but this was a small presentation I wanted to talk about. We are done with the presentation. We still have 10 minutes there before the official lunchtime. If those who have any questions, I'll be happy to take them. Six months. Yes. Yes. True. I think the biggest role of a scrum master is to fire themselves. If scrum masters are believing that they are going to be a permanent resident of the team, they are in a wrong business. The first thing the scrum master should be able to see is, and in my view, a better scrum master will be able to, because we have to understand the deliverable of the team is an increment of a software or a working software or whatever we call it. What is the deliverable of a scrum master? Anyone? It's a self-organizing team. So, and does a self-organizing team require a scrum master? I worked with two clients who actually fired their scrum master because they were so good as a team, they said we don't need a scrum master. So in my view, a good scrum master should have a strategy to get fired as soon as possible. If a mediocre scrum master will take 12 months to get fired from the team, a good scrum master might need only six months to get fired. I mean, jokes apart, but that's how I see the whole thing. Oh, absolutely. Yeah, and I think I've seen, I mean, when I was a manager, I used to think the same way that as managers, our job is to make ourselves redundant. If you are not willing to, I was doing one session with the team earlier and I was asking them, do you guys want to get a promotion? I'll give you a sure shot remedy for how do you get a promotion? And that solution was fire yourself out of the job. If you don't have the courage to fire yourself from the job and create a successor for yourself, there's no way you are going to be going up to your manager and saying, hey, I think I can do something. Why don't you delegate something to me? Fair enough. I'll just give a indirect answer to that. I spend a lot of time with startups. So I go to incubators like Google Launchpad or there's a French accelerator, Numa and a bunch of other places where I go and spend my time with the entrepreneurs. Most of them are in an incubation or an acceleration program for something like three to six months, which means in three to six months, they have to come out with something that can be put on the table as a product, something that can get a little bit of traction and something that might be of interest to the VCEs or the investors in some shape or form there, right? And 90% of the time, these are exactly the same personas or the same type of people that you talked about. In fact, much more junior. They are like two years to four year experienced guys there. The problem with us in the corporate sector is that our mental model says that unless you monitor them and micromanage them, these guys will not work. We are still in the theory X. Whereas these guys cross the street, go to and say to help with this corporate thingy, I'm just going to do my own startup. And they say, we don't know, we'll figure it out. We don't, we'll make mistakes. We will learn from these mistakes there. And in the same six months period of time, forget about being self-organizing. For them, this is a matter of survival. If these guys cannot develop something, the burn rate will actually blow them totally out. And these guys will be obliterated completely. So their survival is at stake. Everything that we talk about in the classroom, these guys do that and much more, without the framework, without the jargon thrown in. But in my, and that's where, that's the reason I go to those watering holes. Because I learn so much from them, not from the classroom, not from sitting in an agile classroom, but actually seeing it on the floor of an incubation center, that these guys are actually innovating on a dime. These guys are sprinting on a dime. These guys can change their direction 20 times a day, without worrying about what is agile, what is XP, what is what there. So, and these guys are not just doing at a code level. If we typically look at the whole business model canvas, so those who are familiar know all the nine boxes of that, we are basically iterating literally on all the nine boxes of that. Because your product is the entire nine box business model canvas and not just one single the value proposition that we talk about. So, I haven't given deliberately a direct answer to your question, but I hope you've got the gist of that. The point is, I think we have to change our mindset as leaders, coaches, and managers. Because these guys, if they don't, I mean it's not, what's not important is whether we trust in them or not. What's important is whether they trust in us or not. Because if they don't trust in that, believe me they will just cross over the street, go there and in two years they might float a company and they might hire you as an employee. So that's a call whether you, I mean there's nothing wrong in working for them. They are great, great set of energy, high energy, you know, but that's a call we have to make there. We have to change our mental models of what really makes a team self-organizing. And unless we change that, none of Agile and Scrum is going to work. I would, again, to me, salary is actually a function of the wage market that we are in. And it really depends on that. I mean if you do a startup in the Bay area today, within six months, your valuations, each of the person, if they don't see a valuation of a million dollars, they'll walk away from there. But if you are in Bangalore today, they might start from there and they might reach the same kind of a number in like one year or one and a half years kind of a thing. I think everybody is probably having the same thing. What is more important to me is, as Nareesh talked about Dan Pink's autonomy part of that, I think the whole notion of autonomy and the ownership is to me much more important in the context of a startup, then going up 27 layers in the hierarchy and asking for it, hey, can I buy a photocopy, can I photocopy a page or something? I mean I'm exaggerating for effect. But the point is most of the organizations are, most of the 20th century organizations and management structures were built for efficiency and scale and not for creativity and chaos. Whereas these startups, they thrive on creativity and chaos and not an execution and scale because that is not the problem they are solving today. And that becomes the problem. The moment you talk about efficiency, you are talking about predictability and the predictability can only come when you are going to repeat the same thing 10,000 times in exactly the same manner. So the only way, I mean, how many of you have read here Frederick Winslow's scientific management book? I would encourage you to read that book. He wrote it in 1911 and he actually refers about a guy who was like six foot six, a recent immigrant to the US who was working in Bethel and Steele and this guy says his job was actually to pick those iron things and move from this point, point A to point B. And he says, hey, I'm going to pay you a few more cents. Are you going to pick up more iron in that? And that's exactly what he did. So this guy was built like a bull and he actually said, okay, you pay more money, I do more work. Unfortunately, for last 100 years in our industry, we have just picked up that word from Taylor's book. You pay more money, I do more work. Unfortunately, as Daniel Pink demonstrated, it doesn't work in the knowledge industry. So pay and motivation have no correlation. I mean, sorry guys, I'm a result I know and all that, but money does not motivate us. It is the autonomy that motivates us. An autonomy mastery and purpose which Daniel Pink talks about. So at least I firmly believe that it's not about money. These guys and a lot of guys I've seen in the, I mean, look at the guy, what's his name? The WhatsApp guy, the founder of WhatsApp. I'm sure all of us have read the story about him if he was to stand in the food stamp line and actually get the food stamp and do the stuff there. What kept the fire in his belly going all these years? It's not about the money, nobody knew that WhatsApp is going to be a $20 billion what it became. He just was possessed by the whole idea of solving something and the autonomy that he had in terms of, hey, I am the master of my, I'm the CEO of my destiny. As Robin Sharma says it, Robin Sharma in the book, the leader without title, he says, be the CEO of your destiny. I think that is something which is missing there and that is something we heard about Doc actually talking about the 20% earlier in the morning. I mean the whole 20% of Google which actually incidentally came from 3M. 3M has been doing 15% for the last 60 years and Google basically copied the whole stuff there. The whole idea was that when you do the 15%, it is actually, it's your own baby. It's not your manager who's telling you do it this way, do it that way. It is you who's deciding when to do, what to do, how to do kind of a thing and that actually has a rub off effect on rest of the day because you are able to feel empowered that, hey, this organization allows me to actually take decisions about what I really do. I think we all human beings suffer from a very incurable disease and that is known as reciprocity. So if I am nice to you, there's no way that this niceness will never be reciprocated. You will find a way to reciprocate it back. So if the organizations are good to the people, people invariably find a way to reciprocate that back to the organization. And that's what we saw. I mean, it didn't come in the early morning thing, but I remember when I was at Yahoo, one of the things that we talked about was, hey, this 20% thingy, how does it really, and Marisa had come from Google to Yahoo and this was one of those interviews that came up. So like, hey, 20% means we barely are able to get the work done in, so 20% means that people work 80% of the projects and 20% on that 20% thingy. And the whole thing was, no, that you don't understand this 80 and 20 part of it. People actually don't work 80% and 20%. People work 100% and 20%. The reason why they go out of the way without getting paid extra for that is not about money. It's about the autonomy and the ownership of whatever idea that they want to do that. So I hope I've been able to share some perspective there. I think you had a, instead of this, the Richard Feynman book actually, surely you're joking Mr. Feynman. Because when he was actually, I think he was at Caltech and University of Chicago gave him a job offer to join at four times the salary. There's a very funny letter which some of us, it is not politically correct for me to share in this forum but I would encourage you to have a look at it but the sense of that was Feynman told University of Chicago that by giving, when you pay me four times the salary that you are going to pay me, I'm going to be able to enjoy all the vices that I have always secretly thought of sharing and that will derail my physics research completely and that's the reason I must politely decline the offer of four times the salary. I think it's important for us to know what is important purpose in my life. Money, there will be always somebody who will throw another 10% more and that's a call people have to make. Not so much but now that, I mean I never thought of it that way but now that you asked me, if I have to go to a startup I'm actually much more respectful to the people for what they have done as opposed to having a taking a higher pedestal and saying that you guys don't know because I have a lot of respect for anybody who goes, who has a life outside PowerPoint and is actually able to put something on the table as a real live working product. Whatever domain they are doing it. So these are the guys who are actually when I go and talk to the startup guys and they show something software, it's an app, it's something there. There's one of the team that I was actually grooming. These guys are making robots that do painting for example and these are four bits Pilani graduates, four year pass out. They're just living a dream actually. They're just working day in and day out. They're based out of Hyderabad. They're just doing that kind of stuff there. So these, I mean you, the only thing that comes out from you as an individual is respect for them and as a coach I change my stance completely because I'm not at all saying that hey, oh you guys don't know what to do. What is daily stand up? You guys don't know what to do that never crosses my mind. It's always like, oh this is awesome. How are you guys doing that thing? How about this? And then I have to be in a very, I have to nudge them to think in a particular manner as opposed to even showing a mirror. In a corporate I might actually, I think as a coach my job is only to show a mirror and help them discover their blind spots but in case of the startups it is actually encouraging them because believe me that set of people is the one that their heart breaks 10 times a day. Not too many of us can actually take that level of rejection that community takes actually. So I would say and I asked people actually how many of you go and volunteer your time with the startups there and I literally find the number very close to zero and that's when I really request people from the bottom of my heart. Please go and spend time with these people. It will change your perspective. It will really change you as a person because when you have to face rejection 10 times a day it all the theory of agile and everything goes away for a toss. You come out much better human being, right? So I think my stance is actually more respectful towards what they have done and it's only to kind of say and because again the thing is it's like I think Jared Spool had written that article on the UX thing. What is the difference between criticism and critique? And he gave a very nice metaphor and said most of the time in the industry like code review somebody was talking about it and said code review or some design review the biggest problem in our industry is that there is a bunch of five people who have never spent any time on that understanding the domain. They come and start evaluating the work of someone who has spent last six months working on the design document and they start trashing the work there immediately. That's exactly how the design reviews happen in our industry today. Now that would be the fastest way to lose the respect from those entrepreneurs, right? So you have to be, I'm not doing a favor out of the way and I'm just not being molly-coddling them. I'm actually just being a little more sincere about the fact and being more respectful for what they have already accomplished there. Okay, I think the lunch is served outside. So thanks for being here and yeah, see you around. Thank you.