Alright, so before we get started just to tell you guys that about this tool like you can actually ask questions throughout the session on the Q&A tab on your right and we will answer them at the end of the session, right? Yeah, so this session is going to be about how Purple is using platform engineering to scale, right? And myself is Anshul Sao and I am the CTO and co-founder of assets.cloud, which is a modern DevOps platform which enables platform engineering and our guest here is Suresh who is the co-founder and CTO of Purple, which is like Unicorn D2C brand and I am sure you have played a significant role in this journey. So with that, let me just start with some questions Suresh. So could you just start with your brief introduction about Purple and yourself and a little bit about the journey to becoming a Unicorn? Sure. First of all Anshul, thanks for having me. Super excited to be a part of this initiative. Yeah, I mean about Purple, where do I start? I think it's been about 11 years now that we've been a part of this journey. For people who don't know about Purple, Purple is a beauty tech company. We have two business units. One is a D2C beauty platform, which is purple.com. We see about 12 million monthly active users on app and web there. So pretty scaled up platform for beauty in India. And the second part of the business is about CPG, which is we have our own brands where which we distribute offline to tens of thousands of touchpoints, brands like Faces Canada, Good Wives, Carl Meesey, which are all into the beauty and personal care space. So that is about the business. Well, being the co-founder CTO, of course, a lot of time initially was spent on building the platform itself. And it is truly endearing to see the kind of growth that we've had, especially in the last two, three years. So yeah, that's a bit about the business. Great, great. And I'm sure, although it's so scaled up in a massive system now, but it must have had its own humble beginnings. So if you can just describe about how the technology landscape has changed on Purple over the years, so that our audience can relate to different stages of being in a company. Sure. I think, I would say we were very fortunate to be a part of this evolving tech eco space where the macro trends are also changing, right? So right from the beginning in 2012, where AWS was also in a nascent stage into India and you were kind of seeing players between having dedicated servers and managing everything on their own and we were one of those in the beginning. Now, where infrastructure was available as a service and now platforms are available as a service, that evolution is truly being really remarkable. As for Purple, I think yes, typically when I speak to new joinees in my company, I just draw a square and I say that that was our architecture back in 2012. So we had one machine and that used to do everything, the database was also set there, the couch base servers were inside that and everything was that, right? We were always a very lean team, right? So till about 2019, 2020 when even at that stage we had 3 or 4 million now, we had only 15 to 20 engineers. And hence the evolution for us is one of grit and a scale up in the right manner. The evolution of technology, obviously we took the same route, right? I think we started with a monolith, it was easy to manage, lesser people were collaborating in the code, right? So it was fairly easy to manage from that perspective. We started out by branching out the databases into different servers, started introducing new kinds of databases like Elasticsearch or RIDIS or MongoDB to ensure that the right kind of database is used for the right use case. We started with a logical division first in our application where, you know, while hosted on the same physical server, same repository, but logically it was segregated into APIs and front end code. So we started breaking the monolith in that way. But I think over the last 2-3 years it has really evolved into a truly microservices based architecture to, you know, to stay true to the use case that we have right now because we are operating at tremendous scale. And the evolution specifically in the last 3 to 4 years has been one of breaking the entire back end system into one giant monolith into multiple domain-based services. And that is the journey that we are still on right now. We are about 80-85% there but, you know, that is a journey that we still take. So we have seen like increase in massive complexity over the years. We have witnessed about 7 or 8 different kinds of databases that we use for different use cases and just for everybody's perspective. The kind of applications that we use, that we build for our customers are obviously the storefront applications, but also the martec applications as well as the supply chain applications as well as data driven data applications. So it's a plethora of things that we do to ensure that we are able to serve our customers right. Right. So it's safe to say that it has become a very diverse system and a very contrasting of, you know, how it started. And yeah, so in this journey where you were actually breaking down monolith into microservices and all, were there any specific challenges related to infrastructure per se which you faced? And of course these challenges would have been different at different times but something which comes in top of your head if you can talk about that. Right. I'm sure you remember few instances very distinctly and I think till the time we were a small team and we were on a monolith. Right. We used to feel very powerful, very empowered. You could, you know, you could change, deploy changes very faster. You can actually ensure that you are actually contributing to the value creation side rather than the operations side of things. And that is exactly where everybody, you know, wants to be right. But I think the moment our scale started growing, we realized that this architecture is not going to be our friend for too long. And hence we decided to take off, you know, branching out different domain-based services whether catalog became a different service and something else became a different service and that journey. When we started doing that journey, right, I think the first challenge that we faced was that the dynamics completely changed for us from an infrastructure perspective. Right.  So interactions between services. Right. So suddenly that complexity started increasing and just like a frog in a boiling pot, we didn't realize it initially. But when we started with three or four services, that became a very big problem for us.  So, you know, we had a dedicated DevOps team because prior to that, it was hardly, you know, it was a very easy thing to manage on our own few servers and, you know, and the observability management and all of these things are managed.  The way you are engineers are able to understand your context. And I think the sheer lack of, you know, that context avoids people from prioritizing in the right manner. And, you know, there are many cases where people were trying to go buy the book, but probably, you know, there is a combination of a short term plus long term solution we required. So that didn't work for us. We also, you know, tried some bits of automation at our end where, you know, from a stage where we were at where individuals had knowledge on how to do specific things. We graduated to a checklist manifesto where we had checklists of, you know, what things need to be done and I'll give you specific examples, right? What happens if, you know, you add a new server or a new service into the mix, right? There are n number of things that you need to do. You need to provision the right user accesses in your database. You need to ensure the certain observability and the right kind of logging at an infrastructure level is done. You need to ensure that the right scaling of that infrastructure is done and so on and so forth. So a bunch of things that we had in our checklist, but again, and, you know, loosely written automation for some part of it. But what we realized was that again, we landed up on the same problem of, you know, tribal knowledge. There are few people who knew how to operate those and again, at the end of the day, engineers did not feel empowered and they did. They've always felt that there's this separation of responsibilities that, you know, my role is to develop the application and then somebody else will take it to production and run it there. And that sort of really, you know, time and again, stifled that growth or that ambition of transforming the infrastructure at the desired pace. Yeah, yeah. In fact, yeah, that I totally agree and relate to because as engineers, if you don't feel that your time is going into the value creation or you get bogged down by some other, you know, external factors, and it just doesn't work, right? Like you just feel that maybe this is like I'm hampering the growth of the company or something like that, right? And most of the time, these factors are not in your control and we have designed it in such a way that developers feel, OK, this is not my cake. Like if it was a monolith, I could have owned it, but now it has become too many things to, you know, manage it, right?  Like how it should be done so that maybe you don't have the solution yet, but maybe the opinion, OK, if we somehow enable this and maybe you can relate it to the monolith days, right? Then maybe it will start working for us. Did you have something like that? No, absolutely. And I think around that time, I also, you know, was reading a lot on how to structure things internally. And I came across this concept from Spotify, which talked about giving developers the autonomy, right? And engineers the autonomy because at the end of the day, engineers are your best problem solvers, right? And you want to give your best problem solvers the entire autonomy of right from development stage to deployment to managing the infrastructure blueprint to performance management, you know, right to iteration of, you know, what should be the sizing of this infrastructure and so on. And that is what you would want to give as, you know, as a leader to your developers and you would want to empower your developers, right? But in such a case, right, what ends up happening is that if it is truly autonomous, then there will be a lot of inefficiencies built into the system. Every team would want to do things in their own way, which might not be aligned to how we want to build an engineering org. You know, in many cases, many teams will repeat the same things. For example, everybody will try to solve for logging is a problem. Everybody will try to solve for configuration management is a problem. And there is a lot of inefficiency built into this, right? And hence the one thought that really stuck into me was the concept of aligned autonomy, right, where there is true sense of autonomy for the engineers. But at the same time, you invest into the platform which ensures that this autonomy is given to them in a very aligned manner, right? Which is aligned to the way you would want to run the organization, the way the garden is that you would want to put on top of this. And that is something that, you know, I thought would be the perfect way that you could solve this problem. But at that point of time, it was still just an abstract thought, right? Yeah, and what you said, it truly applies across the companies also, right? Even like a one company solving certain things is not helping, like there are hundreds of engineers doing the same thing across the companies as well. And it totally would make sense if there is something which can enable this aligned autonomy. In fact, in recent times, like in the last couple of years, this platform engineering term has come up, right? And if you just go into the depth of it, like what exactly it is, I feel that it is totally aligned autonomy, right? That is what they preach. And what they are saying is that, okay, your DevOps should become enablers and, you know, a developer should be able to self serve. If you like build it yourself and deploy yourself and all those philosophies actually come to the same point where you build but build with gardens, right? And I would say then it is pretty much like what you just mentioned, right? All about achieving aligned autonomy through platform engineering, if I may put it that way, right? Absolutely. And I think, you know, if you go into the core tenets of platform engineering and till, you know, very recently, maybe a year or two ago, I didn't know that it was officially called platform engineering. It was just very intuitively you felt that this is the right way to go about things, right? And I think that concept has also now taken a very formative shape in my mind in terms of how it should be. I wouldn't say that we are 100% there, but at the core of it, the basic tenet is that given that you would want to give autonomy to your developers, there are a lot of common problems that they would want to solve for, right? That is point number one. Point number two is that, you know, while they are solving for these common problems, they will also have their own set of individual problems, right? And the role of the platform engineering function in my head is to ensure that they create tools or platforms on top of which developers can feel empowered to solve their problems, right? For example, if I'm building a search application, you know, I might want to spin up an elastic search instance just to try it out on Sandbox. If it did not work, I might try something else. In the historical times, people used to raise a request to DevOps team. It almost became like a government office because the DevOps team is getting requests from all the application teams. And the core job then of the DevOps team was also to manage the operations which is provisioning, optimizing and things like that. Whereas they should be focused on solving the problems. How do I make sure that, you know, I automate the operations? How do I ensure that there is security tenets built into what I'm doing? How do I ensure that observability is built into every application that has been up by default? How do I ensure that I give five options of different kinds of logging to my developers, which is all inbuilt and complete driven, right? If these are the kind of things that either DevOps people or the platform engineers solve, then you truly reach a stage where the developers are truly empowered and they are truly aligned and still have the autonomy. True, true. Now, it's perfectly bang on point. And in fact, even when we were solving our engineering problems in capillary, this was the one observation which was uncanny. In fact, there was a term for it called ticket ops, you know, because if you just go and see the cadence of DevOps team, they just talk about tickets. They just say, OK, 100 open, 30 closed, this I cannot do this. So it becomes too micro, you know, we are losing the macro level things by doing very day to day things. And it's a waste of talent and time both, right? Like, those people are talented engineers. They should not be investing time in doing one of tasks, right? So yeah, totally, totally agree with what you just said. OK, so for my next section, let me take you back some year, like a year or so, where we came and pitched facets to you, right? First of all, I would like to know, were you looking out for something at that point when we came? And what made you choose facets? Because it was a very early experiment for you as well. We were just starting up and, you know, the credibility was actually not there as such. So how did you make that difficult choice that you should try us out? Right. So I think, you know, at that point of time, like I mentioned that, you know, that was becoming a big bottleneck for me to carry on the transformation journey, right? Imagine a company not being able to solve for the problem of scale because you are bottlenecked at the DevOps level, right? So at that point of time, I was actively looking for automation options, right? And automation for both QA as well as for infrastructure automation.  So if I was looking at, you know, if there are tools that can automate infrastructure for me.  And, you know, that we can maybe do an Ansible or Terraform combination. And that is something that we can do. So these are the options that we were evaluating actively when we reached out to Fazit. But, you know, I think there are problems in both, right? While at an abstract level and at a theoretical level, it sounds really, you know, beautiful and really utopic that, you know, there is one platform which will come in and the automation scripts will come in and they will automate your infrastructure. But if you really think about it at a tactical and an operational level, right? You would need a lot of collaboration because unless there is collaboration between teams, unless it is a very declarative kind of a infrastructure management, you would always end up still going to the teams who are managing the scripts. They might have written it for once, but somebody needs to then manage it. Sure, the thing that used to take X amount of time might take X by three, but the problem will still reduce to a ticket ops of that sort, right? So unless it is a declarative format, which is controlled by my developer, that all those solutions were not really solving our problems. But we still wanted to go ahead with something because that could have been still better than what the stage that we were. And it also needed to be collaborative, right? Because, you know, just the versioning control between, you know, what is on Sandbox versus what is on development infrastructures. Plus, the extensibility was just not there that, you know, I can just tweak a few things and spin up another thing. So for achieving all those things, we still needed to go through some hoops. And that is where I think we spoke and that really stuck a chord with me because almost everything that I was looking for was something that was available out of the box. Or at least the platform was extensible to accommodate that, that as well. And sure, you're right that, you know, I wouldn't agree on the credibility part because, you know, managing from the same platform, managing an infrastructure of a company like Capillary, which in itself has a lot of complex clientele and different kinds of deploys in different regions. I'm sure that that definitely lent credibility. But, you know, one thing that really stuck me was how, you know, capable the team was and how open they were to listen to the feedback that we had for them. As well as, you know, there are certain things that we wanted in a certain way, which was not probably available out of the box, but over a period of time were built together. So that was, I think, the rationale on where we were in the journey and how did we pick facets. True. And we were also very fortunate to get purple in that sense because, you know, the kind of requirements which were coming from your side. And we built, co-built many features together, right? Like running your production workloads on spot or whether it be the very pine-grained R-back control to actually put in those guardrails. And it was very aligned, right? What you wanted and what you were building was so aligned that it was a natural partnership. So yeah, I totally agree. And regarding the solution which you said earlier, like getting the Terraform scripts written, it is still, you know, a choice for many people. But I just feel that, you know, building is just the 10% of it, right? The majority part is maintaining it and people generally, like, overlook that part. And so basically, they are generally investing in something which will work for them for six months, right? But what after that? Yeah, because there's always a question of instant gratification, right? And especially now in executive way, you can, you know, can very easily generate scripts that can automate bits and pieces for you. But will it fully work for you when things go 100x or 10x in complexity is the real question. And that is, that is, you know, the kind of long-term thinking that you need to do as leaders. True, true, true. I totally agree. So I just wanted to now see, okay, we were fitting the bill of what you wanted, but now that it has been here and we have been running purple, a part of it in production, right? So how has been your experience and what has changed, you know, before and after FSS? Do you see some positive changes and is it in line with what you wanted? Oh, absolutely. I think so two parts to this answer, right? One is the primary goal with which we entered this partnership, right? And we started using the tool. The primary goal for us was to just add agility into our transformation process into microservices, right? And I think that definitely has happened for us.  The pace at which our developers were then able to move services into microservices was just unparalleled or unthinkable, right, for us. From a process where team did something, asked the DevOps to deploy on Sandbox, create an in-front Sandbox, then validate and replicate again on production or pre-prod. All of that is now, you know, completely eliminated the need for that and the developers are empowered. So I think that definitely has added agility into, you know, us moving into microservices.  So all the problems of people who were already on microservices were not there for us at that point of time. But that brings up to the second point that once we are on the platform and now we have also have an evolved architecture. Now we see that there are a bunch of byproducts, so to say, as benefits that we are getting, right. For example, to bring about a change across the org. For example, recently we upgraded the hardened image, you know, or if you wanted to use a certain kind of infrastructure unit, right. That, that, that was the instance that was, that maybe we have committed now. Whatever these kind of use cases, we, the application of that pan application is like supremely easy, right. So that is obviously one part of it. That enables you to ensure that there are no misses in terms of, you know, missing out on installing the agents of your observability tool or, you know, forgetting to add certain things to Grafana or things like that. So those things have completely been, been eliminated. So that is like, like the byproduct of that, that there are no manual misses now because of course everything is more declarative, more, more guardrail driven and so on and so forth. Apart from that, you know, obviously there are things like we get a bird's eye view of, you know, what is exactly happening in a very structure. There are things that, that are problems for us right now that we can work with, we have actually worked with you guys to solve for it. For example, things like service mesh or circuit breaking and all of these things which become a problem when you actually, you know, go into the microservices architecture. Those are the kind of things that you need to then incorporate into, into your, into your tool so that everybody is able to use it. So there are many byproducts as benefits, right? Obviously usage of spot instances out of the box, which ensures that you are able to control your costs. You know, ensuring that there is extensibility in the use cases that you are building for so that in future if you want to, for example, institutionalize a certain way of doing logging, you are able to do that. Or if you are able to institutionalize the presence of say observability tool, you are able to do that. I think those are just the byproducts of what we have seen. But I think the primary goal with which we entered, I think we have definitely achieved, which is a lot of agility in, in moving into the, moving ahead with the transformation. And now that we are a complicated architecture, so we have never seen a day where we are without this tool. So for us to appreciate how it would have been for us without this is slightly difficult, but I can, I can only imagine. Sure, sure. And there have been times when we also were amazed by the way your team was using it. Like I remember this spot rollout which you just mentioned, your central DevOps team too was able to roll it out without the developers even knowing about it, right? Like at least in the sandbox environment for the developer, the day to day life didn't change, only the garden is changed. So yeah, that was a good testament of, you know, the philosophy itself, not maybe the product needs more work, but then at least the philosophy is in the right direction, right? Absolutely. Yeah. So, so given this, I feel, do you see us fitting in your future as well, right? Like you are, you must be having like long-term roadmaps and, you know, do you see facets fitting well there and or do you see that we need to evolve a little bit more to be part of you when you evolve further big? Like what is the size till which you are comfortable using facets to be blunt, yeah. Sure. So actually like I mentioned earlier, right, I think even while evaluation because of just the fundamental construct of how the tool is made, right? I could see the complexity going 5x, 10x and the tool still working for us. And I stayed true to that evaluation even right now. If I think about, you know, purple in the future, we are obviously in the journey of ensuring that we achieve a properly distributed application architecture where, which is a good balance of, you know, domain-led services plus microservices, you know, don't want to overtly go into only microservices just for the heck of it, which means constant reevaluation of, you know, what should be clubbed as a one-service, one-service and so on and so forth, which obviously adds to that layer of complexity and definitely see the solution facets, the tool still working for us with 10x more complications with 10x more scale. So that is definitely takes the box there in terms of it staying true to the construct with which we started, which is empowering the developers, as well as the tools capability to handle that complexity as well as an orchestrate everything beautifully. The second part of it is obviously when we look at, say, developer experience or, you know, developer productivity or basically from an engineer's perspective, right? We would want to empower them even more. Even now there are certain use cases for which they are, you know, feeling slightly, you know, limited by certain things not being there or so on and so forth. And over a period of time that we have implemented, like, for example, our engineers mentioned that, you know, we need to have role-based access control for us to control every, every finer aspect of, you know, who can release what and, you know, what kind of applications, sub applications can be selectively released by whom and so on and so forth. So that was something which was very important for them to really get on board and that is something that we built together. So anyway, so coming to the second point, which is the first point definitely is that I can see the complexity and scale going up and the solution still working. Point number two, long story short is I definitely see this extensibility in the tool that no matter what our developer problems will be in the future, it can be incorporated. And I see, you know, Facet Steam also playing that role of keeping an open ear to our problems and being very proactively in solving our problems where, and that is extensibility that I see. So definitely I think on these two aspects, you know, that is, that would be my request to you as well that, you know, keep working with us to keep identifying what are the next level of problems that we can solve for the developers. Because at the end of the day, if you truly want to achieve aligned autonomy, they need to be autonomous in truly every sense, which needs a lot of tools and platforms to be institutionalized. True, true. It means a lot coming from you. So yes, and it's a great validation for us.  But when it actually gets used, it is a different kind of satisfaction and the kind of feedback which we get then is really relevant. So yeah, we're happy to keep collaborating. Thanks a lot for this insightful session, Suryash. Before we take questions, I will just like to walk through our audience through what exactly is changing in platform engineering and what we do. It's just a couple of slides and then we will open it for questions. Okay. Sure. Okay, let me just share my screen. One second. Sorry, it's a wrong presentation, which is okay. Okay, anyway, I will get started while this is opening. So basically, I just wanted to introduce our audience with, you know, what is happening in platform engineering and what exactly is it about.  But, but the main shift which is happening between ops and platform engineers, and these are the same guys, you know, who just shift the role which they're playing. In case of ops, they were mostly owner of the infrastructure, especially production. And it was like we talked about right it was about ticket ops. And it was very people oriented and things like tribal tribal knowledge and those things came into the picture because you know we were dependent on few set of people and a process to get through any changes. And, and challenges for their role were mostly like how to keep my, you know, uptime fine. And how do I maintain my infrastructure and and these these challenges were not at all shared with the developers right developers were just, you know, catering to creating business value. And they used to then only selectively support of steam in running of those things. Now as a platform engineer, the major shift happens is you don't be the owner of infrastructure, but you become enabler of these infrastructure. You know, so, like we said about the autonomy, so it will automatically drive developers to do it themselves. So you are saying you are the owner of what you develop, but I will enable you to do it in the best possible way. And I'll give you the right level of extraction so that you don't go and, you know, learn all the skills which I have. So it becomes very process oriented. And the challenges are now more like a product, you know, you are building a product for your team. So and so you are taking a request for them you are taking, you know, things which they want to do it faster and in this process you are also putting in standardizations and guardrails in place so that none of the changes which they do are going away. Right. So this is how ops is evolving going forward. Where do we fit in. So if you see now right now, the developers and platform engineers were stacked together before the infrastructure. Now imagine a self serve layer coming in between, which is owned by this platform engineering group and facets, right. And together they create this thing on this platform, which will enable their developers to directly manage their production infrastructure. So and in this process, we are enabling platform engineering because these people are able to shift, you know, to the role of enabler rather than, you know, being in between and doing all the automations. Right. And how so ever good your DevOps team is they will never invest in building a UI and and you know, make it intuitive for the developers they will always focus on the automation side. Even if you work with facets platform, you'll be able to focus on the right things which will definitely increase your developer productivity. The standardization will come in because the automation you write are centralized and are used by multiple people. So it's a truly collaborative platform and eventually it will lead to a lot of innovation. You know, and I like this quote a lot by charity mayors, who is the city of sunny come that it should be easy to do the right things and hard to do the wrong things. And this is the core philosophy which we follow while we are building facets. Yeah, so that's that's about it. Now, we are open to questions. So feel free to just post them on the Q&A channel. Okay, I have a question by Gaurav. There are organizations like that are quite dependent on people rather than tools. What are the baby steps they can take to move towards more automation. There is a cost to everything. Yeah. So, Suresh, would you like to chime in on that? Sure, sure. You know, so if you think about it, right, you can predominantly map everything out in the maturity curve, right. And if you if you think about, you know, even purple or other in other organizations as well. And if you look at, say, infrastructure management as a fundamental engineering tenant, now that will have a certain maturity curve, right. The maturity curve is everything is ad hoc at the lowest maturity, and everything is data driven and automated in the highest maturity, right. Now, constant strife should be towards moving in the positive direction always, right. So, if something everything is ad hoc and people dependent like you mentioned, right, can you start by creating a catalog of all your infrastructure into a central blueprint can you start by creating checklists of what are the steps to be done so that the things become repeatable, right. The next stage to a completely ad hoc people dependent thing is making it repeatable, right. Once you reach that stage, that is when you realize that, you know, now you're ready to take the next stage, right. Because even if you move to any developer platform, it will also need you to create your infrastructure blueprint which application is using God. You know, how, you know, what are the database connections required between which applications and so on and so forth, right. What are the crest like and so on and so forth, right. So, I think the first thing you should do, if you are in an organization which has a lot of people dependency is to start documenting everything and ensuring that it has a certain format target repeatability and consolidation of information as the first stage. Because even if you are going to the next stage, I think that will be something which will be required. I think today's day and age a lot of these things are available pay as you go. So, you might be surprised with, you know, what you're able to achieve, even if you are at a small scale with a minimal investment, you will be able to, you know, take yourself up the maturity curve by using certain tools, right. I think that is bang on point and, and like you said, I feel that, you know, the first step toward this is making your mind open, right. Sometimes that is the most difficult part, you know, because obviously there will be cost to things like whenever there is a change, whether it is towards the automation or bringing a new person in and training him or if that person leaves or maybe the process breaks or a new technology comes. So the cost is always going to be there. So having that long-term vision and investing towards the right future, which you did like right before even facets came along, right, at least that vision was there, you know, once that starts happening, I think things will fall in place. Yeah. So let's just wait a couple of minutes for any more questions. Just one more thing to add on to this because I feel a lot of these, a lot of people have these kind of questions and in many cases I've also, you know, offline interacted with the people who always, you know, ask me this question that how do I make a business case for this, right. What should be the rationale of, you know, how do I convince, because if you talk about purely the company dynamics, every company is a different dynamics. I was of course in a position where I could take the decision, but in many companies, people might not be in that position to make that decision. So what is that rationale? Because pure finance people or leaders will see it like an additional cost, right. I think the way about it is that slightly look into the future, maybe one year, one and a half year, think about where your infrastructure could be or, you know, what kind of scale you would be operating at and in fact, get your finance team only to give you this information and just tell those people that, you know, if you are targeting this in one year, if we go by the things the way the things currently are, I might meet two more people. So instead of us having those two more people, can we invest the same amount into something right now? Are we willing to make this investment today so that tomorrow we don't need to invest continuously, right. So that is something, you know, which is the right way to look about it that, you know, can I ensure that by doing certain things and by investing that amount right now, I am able to, you know, not have an investment and in fact, get a return on my investment right now because at the end of the day, it's all about the investment and the payback period, right. Any investment is going to be paid back in a certain amount of time depends on your company in terms of how much payback period is okay with them, but that is typically the way to convince people in my opinion. Right and your bang on and we have met many people who are trying to tie this down with the, you know, business ROAs and trying to figure out a case to put in front of business, but, you know, some things are intangible, you know, you can't put numbers to all of the things, for most of them you can, right. But that is really a good input like how to convince your finance team into, you know, and with this tools crawl which is out there like there are so many tools, which people don't even think about before buying because it's just in line with their thinking. Once a tool comes which is more disruptive and will require more investment that is when problem starts happening, yeah. Okay, I'll just wait a couple of more minutes if any questions are coming, otherwise I think we can end this. But it was great, Suyash, like it's always great talking with you, you know, I always get new ideas and this one was specially helpful, which you just said, yeah. Sure. No, no, I think my pleasure to answer. Thanks for having me always invigorates me to have these kind of conversations. I just hope I'm able to influence even one person to take this approach of empowering the developers and, you know, operating in aligned autonomy. I think it would be time worth, you know, worth spending. Sure. Right, then I think people are shy or they're not asking any questions, we were too clear. So I think we can end this and thanks a lot everyone for your time and especially Suyash for your time and see you again. Yeah, we'll do it sometime. Absolutely, thanks for having me. Thank you.


Welcome to Spotlight. I'm Robin Basilen. And I'm Bruce Gulland. Spotlight uses a special English method of broadcasting. It is easier for people to understand, no matter where in the world they live. We are all under the same moon. These are the words of film director Kevin McDonald. What do you think he meant when he said them? McDonald said these words to the Telegraph News Organization. And he was talking about a film he recently directed, a film called Life in a Day. McDonald worked on this film with the famous film producer Ridley Scott. Together, they created this film about life around the world. However, they did not record it themselves. Instead, they used short films or videos recorded by people all over the world. Life in a Day is a film recorded by people like you. It shows the many differences between people and cultures. However, it also shows that there are things that connect all people, like the fact that we all live under the same moon. Today's spotlight is on the film Life in a Day. On July 1st, 2010, Kevin McDonald released a video on the internet. He used the popular video sharing website, YouTube.  And he asked everyone to do this on one particular day, July 24th, 2010. In his message, McDonald asked YouTube users to film all parts of life. He wanted to see both normal and not normal life. He asked users to answer questions like, What do you love? What do you fear? What makes you laugh? And what do you carry with you? McDonald asked users to put their finished videos on YouTube. From these shared videos, McDonald wanted to make one long film about global life. However, this is an unusual way to make a film. It uses a method called crowdsourcing.  In crowdsourcing, the group completes the project for less money or even for free. Usually there is a public announcement for a crowdsourced project and often people use the internet to send in their work. Crowdsourcing can be helpful in completing many kinds of projects. For example, companies have used crowdsourcing to find just the right picture for a particular project. Other people have used crowdsourcing to find the answer to difficult science problems. In recent years, crowdsourcing has become more and more popular. Now, Kevin McDonald has made the first ever crowdsource film produced in Hollywood. At first, McDonald did not believe the project would be very popular. However, people sent over 80,000 videos and they sent them from over 190 countries. This made McDonald and producer Ridley Scott believe that their idea could work. McDonald and Scott paid 25 people to sort all the videos. These people spent months watching all 4,500 hours of film. Then, McDonald and Scott chose the best pieces of video. From these, they created the 95 minute film, Life in a Day. Life in a Day began playing in theatres during the summer of 2011. The film includes great stories of birth and love. It also includes terrible stories of fear and death. One of the main stories from the film is about Oh Kwon Yoon. Yoon is a Korean man. He travels around the world on a bicycle. He rides this two-wheeled vehicle from country to country. His purpose is to teach peace, patience and discovery. He does this by meeting the local people. He talks with them about kindness. Yoon believes that understanding people is the first step of showing kindness. He has travelled to 191 countries to understand people everywhere. Another emotional part of the film shows a Japanese father and his young son, Taiji. They are in their apartment. This living space is dirty and not organized. There are many clothes on the floor. The boy quietly watches television. His father performs the morning work.  The father lights a candle. The father and son honor the woman in the picture. It is the man's wife and the boy's mother. And they are showing respect to her because she has died. The film's producers wanted the film to show life from all parts of the world. So they sent 400 cameras to people living in places with little or no internet connection. And these cameras produced some of the most beautiful parts of the film. One example is the story of a boy named Cain Abel. Cain lives in Peru. And he is about 10 years old. Cain is friendly and he works shining shoes.  However, Cain is joyful. His smile makes everyone's day better. It brings joy to the people he meets in the film. It also brings joy to the people watching the film. Life in a day is interesting because of its method and its message. When people watch it, they will see their own lives. They will also see what life is like for people who are not like them. But most importantly, they will see what is common to all people. As MacDonald told the Telegraph News Organization. This is what people chose to film. Those of us in the news and film industries think we know what films should be about. But most people are interested in a few simple things. Family, children, love, not being alone, not wanting to live through a war, feeling frightened of illness and death. That is it. That is what life is. What do you think about the idea of crowdsourcing? Do you think it can make a great film? What would you put in a video about your life in a day? Tell us what you think. You can email us at radio at radioenglish.net or you can leave a comment on our website. You can also learn more about the Life in a Day film at www.youtube.com. The writer of this program was Graham Bates. The producer was Robin Baselin. The voices you heard were from the United States and the United Kingdom. All quotes were adapted and voiced by Spotlight. You can find our programs on the internet at www.radioenglish.net This program is called Life in a Day. We hope you can join us again for the next Spotlight program. Goodbye.


Who wants to get their business to the next level within two weeks? I mean, not with Scrum, with me and my aura. No tie. Oh, yeah, new work, right? Company fit, huh? All right. Agile, right? Can we do this one more time? Agile to look better. Agile, agile, manifesto. Yeah, I mean, scrub faster, find out faster, fix it faster. Rinse and repeat. Jaira, agile, Scrum, Jaira, doing agile. And being agile are two completely different things. You need an agile coach to understand this. Collaboration, Kanban, agile.  And now I'm an agile coach at NASA. Microstatasing, microagiling, microworking. But in a large company, you probably won't even get approval to write a single line of code within the first two weeks. So then everyone spends a bunch of time in meetings to talk about how nothing happened and how work should be done. But nobody actually does anything. And that's where I come in to moderate that nonsense. I was the one who introduced agile to a company in the first place. No wonder everyone loves me. Oh, hey, Greg. Greg? That's Greg. Hey, his birthday is on day two of Spring 7. It's not a task, it's a story. I forced it down our throat. Yes, increases visibility, continuous integration or how they call it professionally. CI, discipline, product owner, scrum master, agile coach. All right, sprint retrospective and my favorite product. Where is the agile coach? Courage. Do you get that in focus? Focus, commitment, openness, whatever that means. And here we have the six key scrum principles. Refactoring, forecasting, planning, poker, poker, fast. Do you got the movement on tape? Time-boxing, time-unboxing, stakeholders, brain damage. My watch actually shows the second since the last sprint and the timer for the delivery date, plus minus one sprint. Command and control, divide and conquer. Voice of the customer, ridiculous voice of the customer. Respond to emerging requests. Is it emergent? Oh, we can do it later. No worries. All right, whatever. As I was saying, as I was in my tie, we're agile here, right? Yeah, a new worker. All right, adapt to emerging technologies. Is the beamer working? Oh, is this beamer? A crew tech-tap, gaslight, colleagues, investigate, new job, evangelize, scrum, leave job when debt causes problems. Evangelize, scrum at next job and start all over again. Folks who don't have anything valuable to add deserve meetings. Customer collaboration over contract negotiation. Just accept the price. It will make collaboration easier. The team optimizes itself, tunes the process, identifies problems and waits for them to go away and calls an agile coach and reviews that in scrum retrospective. Responding to change over following a plan. Always change, never finish. We really reduce our meetings by introducing scrum meetings. Oh, because there's just no more time left. I mean, you have to obey the agile manifesto. Unless, of course, the agile coach has different ideas, right? So I have different ideas. So I'm doing my version of scrum, change all the time. We don't really get to do stuff because of so much change. Yeah, it's a lot of things going on here. They're just having a daily stand-up. No, they're missing me, but sometimes you got to do sacrifices for the team, collaboration. Let me just quickly get my business card. What does the agile coach do? Pretty much everything. We just keep things running. Make sure we obey the scrum guide or my personal guide.  Yeah, managers love me. Yeah, like we get things done in more time, more things done in time. We don't even define requirements until after production. Yeah, actually, we delivered on time in the past two years. But then scrum came and everything changed. There is a scrum, there is enterprise scrum. The one and only real scrum is mine. We called it scrum, it's really waterfall with meetings every two weeks.


Cubic's approach is to investigate the needs of individual people and figure out the design principles that are most useful for addressing those needs. This often involves talking to people directly, bringing them into the lab, showing them the devices that we've created, see how they use those devices and see how we can adjust them. So initially it was myself and a few other faculty members from other disciplines sat together and talked about what might we do in order to advance this concept of designing technologies and devices for assisting individuals. So I think of ability as a spectrum and anywhere anyone can fall at any point in that spectrum and we think of someone who we may say has a disability, that person may fall on this end but with assistive technology we can move forward. I'm legally blind and so there's some challenges with navigation, with being able to affect my own transportation, with being able to socialize with people in a way that is sort of normal and cohesive and seamless. I imagine wearable computers that don't interrupt us when we're engaging with others but at small points in time can give us little bits of useful information just in the moment. You know, if someone's frustrated or if someone is excited that maybe we can get a little bit of that feedback to connect with each other better, to engage with our world more. I'm working on a project that's called the VibroGlove. On the back of it you can see vibration motors attached onto different points of the different fingers that you have and by turning them on and off at different times you can create a variety of different patterns or sensations across the back of your hand and by doing this you can display different kinds of icons or symbols that mean different things and the meaning that we want to convey is the emotion or affect of another person. By conveying a person's emotion in the middle of a conversation you make the conversation a lot more rich and a lot more engaging. We also conducted a few studies having actual people wear the device to see whether they could recognize the patterns and they were able to with a surprising amount of accuracy. We devised a number of technologies, a number of devices and a number of solutions for haptic based communication of situational awareness, communication of information relating to what you might see, what you might read. All of that through haptics was an interesting way of communicating information. The entire process is not just very personal for the people who are using the devices but also very personal for me as a person who is creating the devices because I get to directly interact not just with the technology but also with the people that are involved in the process. If you can imagine going to an airport and all signage is removed on no screens to give you any indication of where flights are you just literally have to guess where the gates are and ask as you go along. So it's a tedious means of navigation. What we have realized in working with individuals who are blind and visually impaired is that blindness is not a disability but it is a concept. For example sighted people are also blind, 180 degrees of their field of vision and a soldier in the battlefield can be blind to a situation that is 2-3 miles ahead of them. One could think of how we are blind to Mars from a touch perspective. While we see images from Mars, if you want to explore Mars through touch you want to think of it as we are not able to do that right now. So how can this work that we are doing with individuals who are blind and visually impaired most importantly impact them in terms of innovative solutions but also then is extensible to solving a variety of other problems in terms of the concept of blindness. With age or with circumstances or with situations we all face certain challenges in terms of how to extend our abilities. People are looking at how to extend their abilities to become more super able if you may. So again these technologies and solutions are also finding solutions for the spectrum of abilities and super abilities. Cubic was a very nurturing space for me to really build a ruled view that enabled me and continues to enable me to work on technological solutions for everyday problems. Research matters because it sets a course for the future and it allows us to explore ideas and we get closer and closer to technologies that can positively impact people and help them out in their day to day lives.


So, nowadays consumers have various different ways of expressing what they would like to have. For instance, when they would like to order food in a restaurant, they would do this by speaking to a waiter or waitress. So they express their decisions by speaking, by saying it out loud. At a vending machine, for instance, or at a drive-through, they express whatever they would like to have by pushing a button. And in our research, we compare these different ways of expressing your decision, speaking to manual modalities, such as button pressing, and we find that it matters. It makes a difference.  When I say more indulgent, for instance, when individuals choose between chocolate cake and fruit salad, they would go for the chocolate cake when they speak, or they would choose a snack that is higher in calorie content. How do you test this?  Our first study was at a restaurant, and we asked all diners that didn't order dessert whether they would like to participate in a free dessert tasting study. And if they agreed, our waitress would walk with them to a separate room and on the way to the room, give them some information and tell them that they would choose between two different desserts, and she would tell them how to do this. And here comes the trick. Half of our participants, we would tell that they have to say whether they want option A or option B, chocolate mousse or fruit salad. The other half, we would tell that they have to push a little button that was positioned in front of these options. And we would tell them that this button records how many people choose each of the options. This was not completely true, because actually we used these simple doorbells here. I bought them and do it yourself, supermarket, and they didn't do anything. But for us, it was perfect because we could compare the influence of speaking to button pressing, keeping all else constant. And we find that individuals that speak were more likely to choose the unhealthy option, the chocolate mousse, compared to those that pushed the button. They were more likely to choose the fruit salad. So normatively speaking, we would say there shouldn't be a difference, because there's nothing that changes about the chocolate mousse or the fruit salad as a consequence of whether you express this decision by speaking or button pressing. And it took us some time to figure out why this could be happening. And we think that these different expression modalities trigger different ways of making your decision. When you speak, you seem to decide very spontaneously. You seem to follow your intuition and go for something you really like. Well, when you push a button, when you engage in a motoric movement, you seem to be a little bit more reflective. You seem to consider what is good for you to choose. And we base our argumentation, for instance, on research in neuroscientific evidence that shows that there are different brain regions that are activated, depending on how we make our decision. And there seems to be more cognition, more thinking, when you engage in motoric movements. And when we choose, we all know this between chocolate mousse, chocolate cake, and fruit salad. Well, the chocolate cake or the chocolate mousse is desirable. That's what we want. Only after really carefully considering that it was just Christmas, that we should eat healthier, we might go for the fruit salad. And that's our explanation for why speaking results in more indulgent and less healthy choices. So we think that it has very important practical consequences. First of all, because nowadays we have various different ways of expressing our decisions in various different contexts. And there are many situations in which, for instance, restaurants switch from one modality to another one. We used to express our decisions in restaurants by speaking. Now there are many restaurants that already offer you an iPad or a self-check-in. And there you nowadays push a button. And our research would suggest that actually if we want people to make healthier choices, it would be better to let them express their decision manually by taking an option or by pushing a button compared to speaking.