 Hello everyone, welcome to the session. We have Veda and Priyanka with us and they are going to be talking about your role as superfluous. So with that, the floor is all yours, Veda and Priyanka. Let's get started. To paraphrase what Robert Heinlein said, a human being should be able to change a diaper, balance accounts, design a building, build a wall, take orders and give orders, solve equations, program a computer, cook a tasty meal, comfort the dying, fight efficiently and die gallantly. Specialization is for insects. Together here we are to refer some feathers. Hi, I'm Priyanka, Solution Consultant at Saheb Software. Hi, I'm Veda, Solution Consultant from Saheb Software. In real life, most of us are polyskilled and multifaceted. We do not want but many things. You definitely agree with me if you're a parent. Then why is it that at work we trap ourselves inside the proverbial box called roles and we draw boundaries around ourselves? How would it be if everyone came together to build something and became more outcome driven rather than remain focused on what they did or did not do? And what if not only work but actually led to better results? But the key in this pursuit is willingness to push the boundaries of our comfort zones. Priyanka and I are here today to talk about our experiences in building products for our clients with self-organized skill-based teams at Saheb Software over the last seven years. We believe skill-based teams that self-organize build better products faster and at lower cost by eliminating waste in the entire process. Before we jump into the topic, I just want to reiterate that we have time for the Q&A at the end of the session and we'll also be available. Priyanka and I will also be available in the Hangouts area after the session if anyone wants to chat more and have more questions. Yeah, so before again I move on to skill-based teams. I'd like to talk about traditional delivery models that are most popular in the industry today. The list you see up on the screen, it's not all possible traditional delivery models that you are used to, but some of the models, prevalent, prominent models that I have experienced over the last 18 years of my career as a technology consultant. In all these models, the overall objective has stayed the same. Everybody wants to deliver a quality product as quick as it can be done in an iterative fashion. And that's a given and everybody wants to do that. That's great. And I just want to spend 30 seconds on each of these just to reiterate what these are. The most prevalent one I have come across is cross-functional product teams, which is a pretty standard cookie cutter team that's made out of specialized roles. Your business analyst, quality analyst, developers, tech lead, DevOps, product owner, product manager in some organizations, UX, project managers, Chrome master etc. These cross-functional roles come together and form a product team and they work towards building a product and delivering value to the client. Another model I have seen is a platform or you can also call it centralized team where a group of developers come together and then form a development team. There's a quality team where a group of quality analysts are taking care of quality gates and testing aspects of the system. And there's a group of infrastructure specialists and they form themselves in call as DevOps and architectural services who second themselves into development teams to provide design and architectural support to the developers and network specialists who kind of take care of the network aspects of the systems. And another one is a silo team. This is predominantly influenced by the layers and the system architecture. Typically you would find a front-end team, a group of UI developers and the designers come together and form a front-end team. And then there's all these back-end developers forming a back-end team who's taking care of back-end aspects of the system, infrastructure team and anyone who's working around the data and data warehousing reporting needs call themselves a data team. All these models, the most common thing across all of these is the specialization and that's prevalent across all these models in different, in practice. So a biggest side effect of these models with specialized roles is a fitment drift. I just threw a buzzword at you all, a fitment drift, but Priyanka is super equipped to take us through what that means in simple terms. Over to you Priyanka. So hello everyone. I think delivery models have obviously evolved over the last decade or so and I think maybe for a good reason. But one of the things that has actually has remained unchanged across them is the fact that they continue to introduce layers of specialized roles between a user and a maker of the product. And there is a trade-off for the process and the other trade-off is that you're introducing a fitment drift. And just to expand on what fitment drift really means, it's the delta between the intention and the outcome. So stuff that you're trying to build and stuff you end up delivering, there's information loss in between and that's what we are terming as fitment drift. Our observation over the years has been that fitment drift is directly proportional to two things. One is the number of layers or number of roles within a team through which the information needs to propagate. And the second bit is the complexity of the problem. And before I go any further on that, I think let me expand that with a simple metaphor. I mean, I think you see the image on the slide. There are a few people actually playing a game of draw on my back and I'll guess and draw it further. What you can see is the first person is actually drawing something and the other person is actually using their senses. But along with that, using their intuition and possibly biases to understand what is being drawn. And unfortunately, when you pass information in layer or through people, the information propagation happens exactly that way. You lose something, you reshape it, you do interpolation, you do transformations and all of that. And that is a reality of teams that have multiple roles built into it. And by putting this distance between the maker and the user, you're sort of shifting the focus of somebody who's building a product from the problem that they are supposed to be solving to how they're actually going to solve. And that's why a lot of tech teams are actually focused on technology than the aspect that they should be considering, which is the business problem you're solving. Like I said, Fitment Drift is a lot more aggravated when the complexity of the problem is really high. And because at least in our business model, we constantly work in a complex problem space or systems that have massive challenges in terms of volume or data. I think this has a pronounced effect for us as a business. So for the last six years, we've been experimenting with multiple models where you can reduce Fitment Drift. And I think there is value in only reducing it because I think elimination is going to be fairly expensive. So you should be comfortable having a bit of Fitment Drift, but it should be fairly reduced. And I think skill-based teams in that sense have actually worked out quite well for us. And I think that's why we are here to talk about them today. Skill-based teams sounds very interesting, Priyanka. But what exactly do you mean by that? So I think skill-based teams in some sense are exactly like regular teams. But there are two key defining characteristics for skill-based teams. One, I think there's a strong focus on the outcome rather than the process. Second, what you do on the team is not driven by a role or a function. It is driven by the fact that everybody on the team inherently believes that there is value in doing multiple things. And there's an advantage, both from an individual point of view and from a business point of view. And so all the individuals on the team tend to be polyskilled. Second is there is an open-mindedness about actually picking up new skills and actually people on the team helping each other pick up those new skills. So the overall learnability question on the team is fairly high. And I know this is not in line with the prevalent world view where I think the need for specialization is seen as a lot more acute than the not. But I think I'll still go forward and try to contrast how it actually looks like when you try to build minimalistic or lean teams in both the models. So for example, one of the examples that we've presented here is that if you were to set up a minimalistic team in traditional models, you will have two devs, one BA slash PM, one UX, one QA, one DevOps. And with a very competitive rate, you'd probably be still burning about 100k USD a month. But if you are open to skill-based teams, if you're open to the idea that polyskilled people will be able to work across functions and you can set up a leaner team, then you can possibly get away with one UX and two solution consultant and you can charge a premium. So you can actually spend a lot more money on the people and you can find people who really have a sense of high ownership, which is what you really need in these teams. You'll still be burning only half the cost. So the individual price point for the people actually can be a lot higher, but the total cost of ownership for the solution is actually a lot lower. And so from a business point of view, it actually makes a lot of sense. Now I don't know if I can really offer my past experience as an empirical evidence, but I definitely like to call it a couple of things. So for the last six years, I've been working through various skill-based teams. The one that I'm working on currently, that has been running for three and a half years. We've actually been tackling some really hard problems in the UK. We work in advertising tech industry at the moment with one of our clients. And we've been building a platform that has been a first in the domain. And not one, actually, we've done four platforms now, but I think the team has been there for more than three years. Our sprints are two weeks long. We've done 96 releases to production, which means every sprint we deliver value to production. Our uptime is around 99%. When we started off, we were a three-people team scaled up to five. Our beta was released in six to eight weeks. We went live with our GA or general availability release in about 20 weeks. At peak, we were about 22 people, which were set up as five autonomous sub-teams. And they had some shared rituals, but they operated pretty independently. And at a peak, so I already talked about peak, but I think through these three years, we've had 50 people move through this team. So we've actually seen quite a bit of churn as well. All the teams in this setup are fairly autonomous, but I think they do have some shared rituals and practices, which we probably talk about later. Cool, get that. Now I get what's up on the screen. More pizza for everyone makes a lot of sense. You've got a few people on the team, and there's more pizza for everyone. Sounds really cool. But I have a question. How do you kind of justify the quality aspects of each phase in the software development? By quality, I don't mean only the testing aspects, but quality in general at each stage of your software development. How do you justify when one person is taking care of everything, such as analysis, development, testing, releasing into production and supporting? How have you seen this work, Priyanka? So I think before I try to answer that question, I think there is something that I should basically call out specifically. So the argument against specialization is not about not having specialization. Obviously, you can't build a rocket if you don't understand the depth of, I mean, physics in depth and other related subjects. But the idea is that having specialization at all times in all roles and all contexts is really wasteful. And I think that's the view that at least we subscribe to in our team. If you look at the example of the lean team that I've set up here, I've actually put in one UX. It's primarily because the user experience is such an orthogonal skill that even if an engineer from a point of view of picking up that skill wants to do justice to it, it's going to be hard to be able to do that. And so you need to recognize a skill and you need to really figure out if it's an important one in the context of your business. And I think then you need to provision for it. But getting a skill all the time is like I said, is not really required. For other aspects, I think we believe that engineering mindset can expand and pick up other skills to actually do a pretty decent job. And not only a decent job, but if you have a sense of high ownership and a product mindset, then somebody will actually do a lot better job of tying those functions together into a cohesive solution that you're really after. You have a high bandwidth communication with your customer and that's one driving factor. But one of the other important factors is that the solution space that is available from an engineering standpoint is pretty vast. And to take an example, if you're trying to solve a problem in technology, if you understand technology in depth, you can basically reason about what the peripheries of the technology are. What is it that you can get away in technology today? What you can't feasibly do and what you can feasibly do? And having that awareness available in the context of solving the problem is really, really empowering. And finally, again, just to re-emphasize, the argument is not against these skills. So we provision for it. We groom people to know analysis, do testing, do project management. But it is done by the same people who are also going to do the coding or development or all the release and develop aspects. And so we recognize these skills. We pick them up and that's how we work efficiently as a team. Yeah, it makes sense. I guess it's safe to say quality is a mindset more than anything else. And that does resonate well with me. Very interesting. But I'm trying to put myself in the shoes of these technologists on these nimble teams. And I'm thinking, if I were to do that, if I were to play a role of solution consultant on the skill base team, there's a lot to do for me. There's so much coming my way. How have you seen these teams manage the workload with context switching and the deadlines and dealing with the deliverables for the customer on time? How does that work? It's a hard question. And the truth of the matter is that context switching is very hard. But it's also quite rewarding because I think in a high ownership structure, you get an end to end view. And at least in my career, I got a sense of how to build things end to end and all the aspects only after playing a bunch of roles over a decade. And I'm actually quite excited about the fact that young people who join my team at least get this exposure very early on. And I think it's something that I find very useful. And I think it's something that they really value a lot. So I think the context switch is hard, but I think it's also rewarding at the end. Yeah, I agree. I've personally experienced the same as well. When the shift happened in my experience, when the shift happened to the skill-based mindset, I found it very rewarding to kind of own the whole thing end to end. And it makes you feel very accomplished. Yeah, totally agree on that one. And yes, a small nimble team with a smart set of people can solve hard problems and deliver value to the customer in court time. It sounds like a win-win situation where a customer is happy because they see the return on investment as quickly as they can and then feedback and see their product evolve maturely over a period of time. On the other hand, technologists are happy because they get the adrenaline rush, like I said, and it's a very enriching experience for everybody. But I still wonder how do you manage the forecasting needs or reporting needs for all the various stakeholders when you work with your clients? A small team of polyglot engineers, who takes care of these things if there's, there isn't a dedicated project manager or as a delivery manager in the setup? Yeah, so I think anybody who's trying to extract a planning roadmap or an estimates or visibility from a bunch of developers, they would not be alien to the size and the groans that you hear from the group. And I think it is hard to get technologists to commit to timelines and probably to scope both. Maybe there are justified reasons for that, but I at least want to share one incident that I've experienced in my past that has actually shaped my belief on some of these things. So we were working with a client and we were trying to restructure an existing banking platform from being a monolith to microservices architecture. It was a platform deployed all over the world, massively complex and very aggressive timelines. We were a skill-based team which basically meant that everybody was from an engineering background. And I think when we actually planned out how we are going to change this whole platform, our initial two months were going to go into these prints, which were going to be focused on building a walking skeleton of some foundational elements like an orchestration framework, core libraries and a bunch of other things. And I think they were very technical in nature, no visual feedback, no visual outcome from that. And we went to these showcases and we basically showed a bunch of STPI calls, Postman and XML and everybody over a period of time started to grow nervous and they were like, we don't see progress, right? And I am fairly confident that if there was a person who did not understand technology at depth, they would have probably felt the pressure a lot more than we probably did. But I think there was a chance that they could have diluted the effort by saying that, hey, guys, I think we need to focus on something that will demonstrate visual progress. But because we understood the value of what we are trying to commit to, what we are trying to build, I think we stood our ground and I think we got into this tussle of, this is important. This is going to help us differentiate later on. And we continued down that path and I think two months later, we were able to turn around everybody's opinion on it. But one of the things that actually happened in the process is that we got so invested into what we were committing and what we were promising that this is going to deliver that there was a huge recognition of first, the business constraints that need to be able to push things faster and empathizing why business people were actually pushing for things that they were pushing for. And then I think we were really tied to the commitments that we were making. And I think in retrospect, I don't know how it was ever a bad thing. And I feel that the need to shield teams from business pressures is an artificial one. I believe that people should understand and work closely why something needs to be done and basically understand that. That being said, I think we have like a roadmap that we plan for. I think this is the end of the year. We are building a roadmap for 2022 right now, which is high-level functionality. We do a very lean exercise every sprint to basically see when we are going to run out of work, how we are tracking, when we are basically slipping, we break the bad news early. When we finish up the job sooner, we bask in the beauty. But I think there are rituals that we execute to actually do that on time to time. But I think these are not the only rituals that you basically do. I think there are a bunch of other things that we sort of do. And I think it's worthwhile probably talking about them. In traditional teams, I've seen that, you know, business analyst or one of the lead developers will do the showcase. One of the things that we really want to do is build a sense of what business functionality have you actually delivered, not story, but what business value have you actually delivered. So our showcases are done as a roaster. Like everybody on the team will have turns to do these showcases. Despite the fact that you have five subteams, one person will take the context to all the subteams and basically understand how to cohesively tie this as a business value and basically talk about it in the showcase. So our showcase is more about not the stories, but what business value will you have after today's split, right? The production support, the release, all of that again done in roasters helps people empathize with the challenges downstream, plan for it upstream, right? And I think so some of those things are all done by all the people interns and there is support available. We started, so we have a heavy automation focus, but we started a mock testing exercise just to do a catchall of things you can't automate or are very expensive to automate. It evolved from a mock testing exercise to an exercise where people loved the exercise for the fact that they could, they could get exposed to the part of the system that they have not worked on. And I think that was pretty useful because I think here I'll admit that we don't have a specialized QA on the team, right? Which basically means that you are not testing system end to end. So there is no SME who can tell you how all the flow in the system will actually work, right? And as developers, a lot of people will not actually work on all the parts of the system. So having a practice in place that basically allows you to explore a part of the system that you've not worked in before is pretty useful. And I think we've made that as a standard practice at least for our team. Finally, the way these teams exist are usually small and everybody is sort of a tech lead from a mindset point of view. So they have a sense of ownership of feature as well as implementation and delivery. But what you do need is in a small team, you need a person to hold the context or the threads on all the features that you're actually building. And that role is a taxing one. So we rotate in that role. It's also a grooming exercise for people to basically say that how do you evolve those skill sets that basically require you to think about features, plan, and, you know, break down work. So all of those things are some things that we do in our team. But I think one of the things that Vera said at the starting that there is no rule book in some of these things. And I think what I want to emphasize is that these are, these exercises are driven in a lot more context. For example, I know whether you operate in a very different context, right? And I'm sure there are rituals that, you know, you drive and they're very different for your team. Maybe it's worthwhile hearing out, you know, how things have worked out with you in that sense. Yeah, absolutely Priyanka. So yeah, our setup, the current client I work with, it's a co-sourced delivery model setup. So we've got engineers from Sahaj and engineers from the client and also the clients operate somewhat the traditional delivery model I spoke about earlier. It's sort of a cross-functional team setup. We've kind of gone there, adapted to it and gradually taking them on a journey and changing their thinking process and how skill-based teams are more beneficial. I'll talk about the feedback in a bit. But before that, I want to highlight a few rituals that practices that have helped us to sustain this model at the current client. Picking up on what Priyanka already mentioned about the feature anchors and rotating tech leads, we follow most of those rituals plus in addition to the ones that you see up on the screen, these are not brand new invented rituals by us. These rituals exist as XP practices and we've known them for years and decades now but it's just a matter of picking up what works best for the context you're in, the set of people you're working with and the culture of the team, the behaviors on the team is a key here. Feature champions, as you all know, we organize ourselves into one or two small feature squads and these two people kind of work together end-to-end to deliver the feature until it's fully complete and the product owner has signed off the feature and they're happy with it delivered into production. Beta testing has happened. The feedback has come back to a whole entire cycle. The whole cycle is complete. What this does is it enables the folks who play the feature champion roles, not only the depth in the implementation but also the breadth of how the functionality has been built, how the product is evolving and that has enabled these guys to come back and suggest ideas to the product owners or the client and the client's product owners have gone back and said, hang on a minute, what you both are saying makes a lot of sense and that has helped them change the direction at some instances on the current client. This is from the feedback I've received and along with that pragmatic pairing, we don't always pair but when there is a need and there's a complex piece of functionality that you're implementing, there's a design aspect, you need some feedback, you need some extra pair of eyes to help you with brainstorm ideas. We do pairing and it also helps when you're onboarding new members of the team especially pairing is a great practice to have on skill-based teams, especially there's a small team who's responsible for everything, sharing context and understanding every part of the system is very, very important. And one of the ways we can scale out these skill-based teams is Priyank already touched upon smaller teams and subteams as the team, as the account grows and the number of problems we're solving for the client grows, we kind of consciously split the team into smaller subteams who are autonomous and they kind of cohesive and they kind of decide their own cadence and rituals they want to follow. There isn't a rulebook like we said earlier, there isn't a rulebook, pick what works best for the people on the ground and that small team and follow that cadence. However, these rotating techniques kind of come up and stitch all these small teams together, collaborate across the account to help keep the pace and consistency of the solutions across the board for our clients. Last but not the least, automation is absolute paramount for us. There is no way that can be deep prioritized. I have seen historically on other engagements I've been on, constantly they get deep prioritized. When there's a functional feature that needs to be developed, they go, okay, you know what, we've got people to handle these things manually, we can work around it, let's push it to the bottom of the list. In the skill-based team setup, that won't work because it's a very, very small team and there is no scope or bandwidth for anyone to do things manually, be it performing releases, be it promoting builds into higher environments, regression testing, so on and so forth. So with these are some of the rituals and practices we have been following across different engagements we have been working on. I wonder Priyank, if you've seen any instances that have reinforced skill-based teams work, any real-world examples you'd like to share with the group here that make you actually believe in this whole thought process? Yeah, I mean, I think definitely a quick one. So I think we built an algorithm that automated something that was done in a manual way and it improved the efficiency of the whole process by 250%. It was really well received and I think we built not only that capability, but also a list of optimizations that you could do further. But I think we did not implement them and I think over a course of evolution of that framework, somebody came and asked that, hey, why have you not made it more efficient? And I think one of the answers that one of the team members actually gave around that was actually quite profound. I think so the person who was from a technical background said that if you optimize it further, it didn't stop making commercial sense because what will happen is that you would bleed out the margins and it will not work. So you can optimize it further from a technology point of view, but is it going to work commercially and is it going to work as business? It's going to work for our partners, right? So it doesn't remain a win-win situation. And I think having that awareness is very crucial. And I think that is one of the things that I believe that this model sort of promotes. It's a very product oriented set of thinking and I think that's what it really results in. And I love that whole aspect and whenever I continue to see a statement like that, it helps me reinforce my belief. But I think whether you operate in a, like you said, you operate in a very different environment, add an experience of your own, and you've seen some feedback around how clients see the whole structure. Yeah, absolutely. So yeah, like I said earlier, it's a co-source team setup where we've got a mix of everybody on the ground. And it's also not only a cross-functional product teams and a mix of clients and our folks on the ground. We've also got a multi-vendor setup at the current client. So the client does work with different services companies to build their products in different areas of their business. However, one feedback, consistent feedback I've heard from the clients is from the likes of head of engineering and head of business division and the folks on the ground as well, is that they absolutely love the way our engineers on the team who's organized as a small cohesive team kind of approach to these requirements and the problems at hand and the culture that's prevalent on the team and the attitude the team kind of work with. Even if the requirements are ambiguous, we don't kind of stop there and say, hey, this is a business analyst who need to go and refine the story, come back to me with a set of experiments criteria and then a QA to put in a list of test scenarios. Once that artifact, which is a story ready, only then I'll go and develop. That never happens on our team. We kind of say, okay, this is a requirement that needs to be built. Yes, there are questions. There's ambiguity. Some things need to be answered. Let me see what needs to be done. And that's where we start putting on an analyst hat, a QA hat and a developer hat, a tech lead hat. And then think about the whole requirement in a holistic sense rather than just, okay, my bit is once there is an artifact ready, I'll go turn that into code and then deliver. And that's been well appreciated by the clients. Whereas they are dealing with a challenge on another vendor currently where they go, this is a DevOps job and I don't, I'm blocked right now and then they throw it over the wall and they sat there waiting for the DevOps person to come in and help them with the infrastructure work, which doesn't happen on our team at all. And that's something they really see it as a massive value for them. I guess, yeah, in my own personal view with the skill-based teams, I have seen all the traditional delivery models prevail and also set up teams in such a way in the past before I was exposed to skill-based teams. In my skill-based teams, I really believe in this model. This will also thrive in small teams set up and it's super optimized for delivering value to the customers in the quickest possible time, taking out all those delays that you would have otherwise that I personally experienced. And it makes you feel that you've optimized your team to deliver the best value to the client in the time you have. And yeah, let's move on to some of the benefits. We've talked about a lot of benefits for these skill-based teams throughout the presentation, but I'd like to summarize them all in one slide very, very quickly and then move on. So yeah, skill-based teams definitely encourage self-organized autonomous teams. That isn't somebody to kind of bring them together and no one's waiting for anyone's orders or instructions to go on and do stuff. They kind of get on proactively and work on individual features and stories and deliver value to the clients. And there is no rulebook. It's open for innovation. However, we also collaborate across the teams and make sure that the solutions are consistent. Although there isn't a rulebook, we do have some guidelines that the teams follow across the board come together. There's a lot of crossing collaboration happening to make sure we are delivering consistent solutions for our clients. And because the teams focus on the ground or working closely with the product owners and the users sometimes, there's a lot of empathy built into this whole process. They understand why a product owner or a customer is asking for something without thinking twice. They kind of go in and put themselves in their shoes and empathetically think about the decisions made and then eventually come up with solutions that work best for the users and the customers. And the whole focus with this approach is on the delivering value and it's very, very outcome-driven rather than clocking in hours, which is a great approach to have. And the whole process, each technology, it's very rewarding for the folks on the team as well. They're groomed to kind of put themselves in front of the customer, talk technical, non-technical with all kinds of technical, non-technical people on the ground. It kind of breaks the myth of developers can't talk business language and it breaks that myth and everybody's groomed to operate in that maker mindset. And in the end, it shapes, this model helps shape a well-rounded technologist on the ground. So yeah, all of this sounds great in terms of benefits and everything. However, we just want to call out some of the trade-offs and things to watch out for if you were thinking about skill-based teams based on our experience. It does have its own set of challenges and trade-offs. These are the ones that we've called out on the list based on our experience. So happy to take more questions later on if you have more. One of the things I have noticed on my teams is it's a pretty steep learning curve for anybody who joins new on the team. The moment they start, even when they start to join the organization, it is a steep learning curve. It's a lot we ask from these engineers to do. When I say lot, it's not in terms of quantity. It's more about expanding your horizon from I only write code to I need to analyze the problem at hand. I need to think about the solution. I need to think about the users. I need to think about how I'm going to implement this. How am I going to release this? How am I going to automate the release infrastructure and production support? How am I going to do all of it? It's expanding that thinking process rather than quantitatively. Oh, I need to spend more time now on this. Recently, I've had a junior member of the team join us and she did give me this feedback. It is a steep learning curve, but on the positive side, she came back to me and she said she was super happy at the end when she felt really accomplished and it gave her an overall picture of what we're trying to do and how to do things on the ground. The context switch is very taxing. It's not easy. I'm sure you all agree with me. It's something to watch out for. It's very, very effective. It is very effective in small, passionate teams. I wouldn't say it's hard to scale out, but there is a way to scale out. You would have to consciously split the teams into smaller as the team grows, as the account grows, and then make sure these teams are autonomous and cohesive. There's also an evidence that smaller teams build better products to solve business problems. WhatsApp was a small team of 32 engineers, which we all use. It's massive. Notion was started with a 13 member team just to quote some examples there. Yeah, that's what I would say. But Priyank, you must have seen some of the challenges on your current setup around this model. Do you want to take us through those? Yeah, sure. I think I'm just going to zip through some of them very quickly. I think blind spots. I think people who tend to join skill-based teams from a traditional background, they tend to take testing analysis for granted, for example. Right. And I think there are a bunch of other skills that you can't take for granted. You need to plan for them. Otherwise, they'll come back to bite you. And so I think you need to consciously plan for the blind spots that you will typically have. I've already touched upon the fact that because you don't have a dedicated QRO, you need to plan for activities, and you need to think about your tests, the way you write to retain the domain context. So beyond customers, so customers and the product owners will sort of have their business context. But when you're working with them, we need to ensure that there are mechanics in place to retain that context in place. Staffing is a massive challenge. Because you are not tracking roles, right? You just can't put in people in a group and assume that they'll be successful. You need to focus on a dominant skill that you need on a team, and you need to create the right skill spread. So you need to have still the DevOps capability, the UI capability, the back-engineering capability, and have those skills be there. And then structure teams, right? If you think hiring a good technologist is hard in today's environment, I think try hiring somebody with a good technology background and competency plus all these skills. I think the way we address the hiring challenges, we hire for a dominant skill and a generalist mindset. And then we use culture as an leverage to basically build up a polyskill outlook. So what you do is you find a person who's got depth in one or two areas but are open to expanding their skills and sets in other areas. And then you basically put them in a culture which is pretty comfortable working across different functions. And that's how you basically groom people. And apart from that, we run various other initiatives internally to be able to groom people very early on. I would say this, I know that this is a very polarizing topic because I think it basically make people feel that my specialization is not valued. I think I'd repeat that the argument is not against specialization. Argument is against specialization context. And I think these teams are very high ownership structure teams. They are going to be always in conflict with a hierarchical set. So you need foundational organizational cultural elements to support this. If you are in an organizational that is hierarchical in its nature, then there is going to be a constant tension between these teams and it's going to be hard to sustain them in that kind of an environment. But I think I know that these are some of the top orders in terms of challenges. But I know that they are worth it because this is the way forward and that's primarily because you've seen that teams build better products and have fun building them. So thank you for hearing this out and not shooting this down my way. Like I said, I know it's a fairly polarizing topic, but we are happy to take questions and answers now. Thanks, Vedha. Thanks, Priyanka. It was definitely super interesting. There are quite a few questions coming up. I'll read the first one. Even the UX can be removed. We'll still save the cost. What happens to the output and delivery? Are you expecting the lean team to burn the midnight oil? But how this approach works on practically? Vedha, do you want to take that one? Should I take the one? Yeah, I'll give it a go. And then you can add. It's a very interesting question where you're saying, oh my God, suddenly you've got 10 member teams down to three member teams and you're expecting the same to be delivered. But if you look at it, for example, Priyanka gave earlier on one of the slides where you had a BA, a QA, a UX, two developers and a PO. Technically, if you look at it, you still have two developers working and building stuff and the others are supporting in their own specialized way doing analysis, doing testing, but then switching that context from that to that and then shifting that over to the developers, that will take time, that will take consume time. And then you can say, okay, I need to build this. How am I going to build it? This is the state of the code base. What do I need in order to incorporate this into the existing code base and deliver that functionality? In my experience, that has taken a lot less time to me than waiting for somebody to explain to me what the business context is and somebody to tell me how this will be tested and verified in an end to end scenario situation. So it's a lot. It would take less time for me to do it, think about it end to end rather than in isolation and also the thinking process, solutioning process in the whole setup will be very different. If I were to look at just the story with already defined ACs and express criteria and then the test scenarios, I'm only focused on that and I'm not looking at the overall picture and that's what I have seen shift in my mindset when I used to write for 10 years ago in that model and then now when I write code how I think about it. It doesn't feel like I have a lot to do all condensed in a shorter period of time. It's more of, it's exactly the same how I think about it, how I expand my horizon is what has changed. I completely believe in work-life balance. I don't work late nights. I don't ask my team, folks to work late nights. It doesn't happen in our setup for sure. I just wanted to add one thing to it because I think there's a buried point about two things. I think one is the efficiency of these teams and I think the second point is the practicality of these teams. I think in my life at Sahej I don't think I've ever turned up in an office on a Saturday. I think and I've been here about close to seven years. So I think doing multiple roles does not mean doing more work. It's about working across multiple functions but not doing multiple modes. I think the second thing I want to talk about the efficiency of it and I think it's hard to grasp what that information loss is. I just want to take a story and I know that I've got a minute remaining here and I want to answer multiple other questions. Actually, I'm going to skip this part but I just want to reinstate that there is a certain efficiency that you can work with because I think there are a bunch of other questions that I wanted to take on and we'll be happy to chat on this but I think talking about another question I'm going to bundle up two I think is there a preferred starting role skill set dev analyst that you look for during hiring and how much time it typically takes you to grow to be polyskilled. I think a short answer at least in my experiences that we typically look for an engineering skill set as a primary or dominant skill set and that could be in DevOps that could be in various areas. It takes about from the hiring to actually being able to drive a certain team of your own it takes at least about a year for you to be able to get a right balance of various skills that you need to be able to address all the blind spots and everything and I think just to take an example of how this actually works so I will just explain the structure of my current team we are a team of about 11 people right now we are split into three sub teams we have a very very well doiled machinery our sprints are two weeks long out of a 10 day work sprint that we have we account for five days of development and the rest of the five days are all about so one day it actually goes in mock testing making sure that we have got release branches cut deployed and all of that so all that process automatically happens and there is a lot of automation around it the other day goes around into looking at roadmap planning detailing out your stories understanding talking to users figuring out what you are signing up for and so out of 10 days you are effectively spending five to six days on development including automation and then another four days that you are spending on actually all the other rituals that will make things work right so you are testing stuff that your teammates have done you are actually looking at roadmap you are agreeing on the overall design and you are doing a bunch of other things I think that's the model that we sort of work with and there are people switching these roles right so there are people who have made some of these conversations they are not the same people after every couple of months people switch it's not based on seniority so it's based on everybody gets a chance to be in a driver's seat empathize with what it takes and all that I hope that we did justice in answering this question Thanks Priyank, thanks Veda it has been an amazing conversation and I have so many more questions now and I am sure a lot of participants have a lot of questions