 I am Shriram Narayan with ThoughtWorks as a digital IT management consultant and I go around helping clients with improving the performance of their departments that they might call as digital or IT or tech or engineering or product, those kind of organizations. And through the course of my work sometime back I wrote this book Agile IT Organization Design. This book is you know not at the level of things like Scrum etc. it's at a slightly higher level what we refer to as the operating model space. So usually you know there is strategy and people say okay we have strategy we have to execute on the strategy but then there is a thing in the middle which is how the organization is set up, the ways of working of the organization and that is called as the operating model. It includes topics such as all this which are chapters in the book and this particular chapter is available as a free download as a sample chapter team design and so this came out about two years ago it was published by Addison Wesley and since then of course I've been continuing to consult with clients and today's talk is about some of those learnings. Yeah and as I was preparing for this talk and you know putting out the content etc. it occurred to me that product mode is probably not such a descriptive title for what I want to talk about today. So I've done a bit of renaming of the title and I think it's more appropriate to the content remains the same but I think it's more appropriate to call it as the habits of digital savvy organizations and before I get into the actual habits itself I want to take a step back zoom out a little and give you my perspective of where I think things are headed in terms of organization structures. So you know traditionally we've had this sort of business and IT or some people differentiate between engineering and IT and so on. Traditionally we've had this sort of setup and nowadays in many organizations you would find either there is a digital organization in the middle or a product organization and then there is engineering and IT. But some of the digitally native organizations or people who are organizations that are even more digitally savvy they are somewhere in this sort of space where they recognize that there is an overall digital business platform that is a key enabler of their business and yes there are there is an there are all of these functions but the boundaries between these functions aren't as strong as they used to be earlier and so we have this overall notion of a digital business platform organization and what used to be earlier called as the business is now more of a commercial organization and it's not just a different word it's also different in the sense that previously you know business strategy used to be set here and then everybody else would basically follow that strategy and come up with their own strategies in accordance with the business strategy whereas here in this sort of model business strategy itself now tends to be co-owned by these two groups. So that's like the overall broader framing of you know where I see things headed and some people many organizations are already in this sort of state and that forms the basis for whatever I'm going to talk about in terms of habits of organizations and so on. Before I go ahead I just want a quick survey of the audience is there anybody here who works for say an IT services company? Okay so whatever I'm saying here is less applicable for the IT service company itself but it's more applicable for its clients yeah so that's one way to think about it. Similarly are there anybody is there anybody here who works at a GIC or as a captive as some people call it yeah okay so again the stuff here is actually a lot more relevant to your parent organizations because in some ways the structure of the GIC is determined by the parent organization and so you know that that's just a useful way of thinking about this like in case you're wondering how does this apply to me and my organization I just wanted to set that context a little bit so yeah this was the very high level view now I want to go to like maybe just a hundred foot or thousand foot level and start describing how things currently work in most big traditional organizations yeah and a common starting point looks something like this where business has ideas about what they need to build they create business cases for those ideas saying if we spend so much money developing these capabilities then over the next five years we will earn so much money or we will save so much money and so on that's called a business case it goes through an approval process right and that's when funds are approved and then the typical IT organization comes into picture which builds those features and the moment you start building features and putting into production it also means you have to maintain those things right the thing that's mostly missing currently in traditional setups is that as you're building those features they might take let's say a project like this might take one year to launch right there is no real ongoing validation from the market of whatever we are building is it really going to be useful in the market is it going to help us achieve the benefits that we have projected out here so because the business case at this point is just projections right there are a bunch of projections but as it hits the market as it gets into production it that's when there is an opportunity for validating it right it need not always be a market facing system it could be like let's say an employee on boarding system or something something that's internal facing in which case your end users are employees right so again there is no ongoing validation of whatever you're building whether that's actually useful for the employees etc etc and generally what happens is the business benefit the actual benefit is much less than the projected benefit what is projected in the business case right but life goes on business comes up with the business or product or whoever is the department deciding what to do next they come up with other ideas business cases funding it kind of the cycle keeps repeating right and what happens if the cycle keeps repeating itself what that means is there is more and more funding getting approved more features are getting built more stuff to maintain and so on but not corresponding level of business benefit right so naturally in this process if you follow this cycle you will see that as a result it budget keeps on increasing right and also the number of number of things you have to maintain keeps on increasing so the share there is an IT budget and out of that the percentage of the IT budget that is directed towards maintaining just keeping the lights on will also keep on increasing as you go through this cycle right so we end up in a situation that looks like this which is you know there is a budget keeps on bloating there is a well in delivery and also somewhere along this point people realize that you know this is not how it should be and so the executives etc they say we need to we need to do a transformation right and often the focus of the transformation is just this they say oh we need to build these features more efficiently you know or more effectively and so on the focus of the transformation is not on this side usually and so even if even if this organization gets its act together you know we let's say they become agile yeah they start doing everything in an agile manner still you're not solving this part right so essentially you're sort of building out a lot of features more efficiently but then they still don't have the expected business benefits and since the budget keeps on increasing the CEO is unhappy since there is a lot of projects more coming into the pipeline the CEO and CIO are ultimately unhappy and since it's not resulting into enough business benefit the CEO is also not too happy yeah and that's that's what I've seen many organizations say hey we've gone through an agile transformation done all we have all scrum teams you know we're doing all the things but still if you ask business they say yeah they say they have gone through as a transformation from our point of view we don't see any major difference you know we're still whenever we ask for something it takes 18 months to get done things like that yeah or more importantly they nobody in the organization is asking okay even if we have gotten better at this are we really getting the business benefits out of it whatever be projected and to give you an example of this I have a short story kind of thing yeah and the you know the board the point the story tries to illustrate it that it doesn't matter if you have an agile delivery organization but as long as there is a some come some organization whose responsibility is only delivery things don't you don't get true business benefits yeah and so it the story is called what happened when product asked engineering to build a bridge right so it goes something like this instead of business and IT I've used the terms product and engineering over here so we start at say January 2017 so product says to engineering here we need to build a bridge give us a quote and engineering does some estimation analysis and all that and they could come back with oh it's going to take 10 months and it will cost 800k right so you know there is a approval process etc etc work work begins engineering begins building this bridge sometime or some time passes and then business comes up with a change in requirement they say oh you we started building a cantilever bridge but you know our plans have changed make it a suspension bridge this is actually a big change from you know if you already started building a cantilever bridge to now change it to a suspension bridge so even if you're agile we are supposed to embrace change and so on but we can always protest right so engineering protests like you know why is suddenly asking us to build a suspension bridge and there is some rationalization business gives some rationalization for that right but then we come back and say fine that's fine but you know it's going to cost a little bit more and take a little more time right so there is a bit of a negotiation that happens at that point right engineering asks for three months and 300k more but they finally end up with you know 200k and one more month right and so the bridge building continues and then again at at a certain point business says you know like are we done yet can we be ready because there is an event that's going to happen yeah so basically business comes and says hey you know what if the mayor schedule is very busy and we would really like the mayor to inaugurate this bridge and the mayor is actually available in December so can we be ready by December right and engineering says no we can't but there is a negotiation again and they say okay we'll do a soft launch the mayor can cut the ribbon but the bridge is not ready for traffic yeah so they agree they say okay we'll do a soft launch so and they say you know it's going to be production ready only in March right so it says no one rides until March so that happens the the the bridge is inaugurated the mayor's photo is splashed in the newspapers etc and it's election time so because public sees the mayor has building bridges and so on the mayor goes on to win her reelection right and the business is happy that a we've you know we've made we've had a good win etc and in the meantime engineering continues to make that bridge production ready so you know life continues and say ultimately let's say the bridges opened up for traffic in Jan 2018 or something right and by the time engineering takes up other projects right this bridge is opened up for traffic but somebody in engineering notices they or has the curiosity around April to go back on that bridge and say hey you know what we build this bridge is it you know what's the traffic like on that bridge is it really is a lot of people is the bridge popular as there are a lot of traffic on the bridge but they find no very few people riding the bridge actually right and so usually these sort of questions don't take place right we build whatever we bought build as engineering and then we move on to building the next thing we don't really have an opportunity to assess whether whatever we built is really being used is it really delivering the business benefits was it worth the cost in the first place etc right because of the place where we are situated in the organization we often don't have the opportunity to ask these sort of questions so but in this case when they ask the question hey how come there aren't too many people using the bridge business comes back to them say oh you know what they the people still prefer seem to prefer an old tunnel nearby yeah and engineering is totally shocked by this answer because they didn't even know that there was a tunnel right and that's that's actually more common than you would think because the equation between product and engineering or business and it is often that hey we've got this thing in mind we want you to do it tell us how long will it take how much will it cost right and that is the equation we are not really thinking about okay what could be the other possible solutions what have users been doing until now etc etc we don't get into our engineering doesn't get into those kind of questions and so I'd the way to summarize that is in this sort of equation there is a organization engineering is a delivery only organization its job is to deliver scope on time and schedule on time and budget yeah whereas when we're talking about habits of digital savvy organizations we want to we're talking about moving towards problem solving teams yeah so if it were a problem solving team then the moment somebody says hey we need to build a bridge they'll say hold on hold on what is the problem you're trying to solve right so obvious it's obvious the problem you're trying to solve is we're trying to solve a transportation problem at a particular point along the river right okay so if that is a problem you're trying to solve are there are there currently any ways of you know at the current any existing solutions there then they would have said oh yes there is an old tunnel but you know we think that tunnel we want to decommission that tunnel or whatever right or maybe the it could take another dimension like okay the bridge is going to cost so much do we really need a bridge can we why not we do a ferry service at that point instead right maybe that is an option maybe if the ferry service solves the problem then that's good enough right but those sort of conversations don't really happen because of the way the organization is designed and what is expected out of each organization it's like engineering is not expected to think about these things it's like build a bridge go build a bridge tell us when when you will be done how much it'll cost right but that is not how digital savvy organizations operate they operate in a way where engineering and product are much closer together and they can collectively think about this problem and they can truly iterate they can actually say yes we're trying to solve this problem but how about we first trial with a ferry service which will only require a bit of an investment and then if the if that doesn't solve the problem if you find that the traffic is actually vehicular traffic not passenger traffic then yes the ferry service will fail and then we have the case for actually building something that can transport vehicles rather than passengers and so on and that brings us to the first habit of digital savvy organizations is that they don't think of delivery of software as a separate function yeah they there is a team and this team's job is to solve problems it's not like one there is one team called as a product management team or something whose job is to think of the solution and another team whose job is to deliver the solution now they don't operate like that they don't think like that yeah so going back to that picture where you know we were showing that cycle in all what does that look like for digital savvy organizations it looks something like this right you what you have is one cross-functional team which is not just cross-functional with respect to developers and testers and system administrators yes it is cross-functional with respect to those roles but also cross-functional with respect to some business roles product my product management market research you know whatever else is required to understand that problem and iterate on that problem and iterate all the way to the market like we say oh our scrum teams also perform iterations right but that iteration is only till the showcase and the person who I didn't this showcase might be a product owner or the business sponsor or somebody right it's not a market iteration here we are talking about taking iterations all the way to the market and that's why these teams are also called as ideate build and run teams so typically in large organizations ideate build and run are three different departments the business or the product management organizations responsibilities to ideate then within it you tend to have two more organizations called the change organization and the run organization the change organizations responsibilities to build and then the run organization of the ops organization their responsibilities to run right so it's about actually collapsing three different departments into one department with several small teams each of which has this end-to-end responsibility yeah and that's a huge change in organizations this is not just about you know adopting practices like stand-ups and retrospectives and sprint planning meetings those are easier to adopt but the moment we talk about changes like this you know the many other senior stakeholders need to get into the picture and that's actually leads us to the second aspect the second habit because so far we when we talked about this bridge building problem we were really talking about ideate and build happening together right so people who are ideating about the transformation problem sorry the transportation problem too much transformation going on nowadays and the build problem right but there is build and run also right and that's we kind of mentioned it but that's the second part which is they do not separate change and run into into two different departments right and partly that's what DevOps is meant to achieve right DevOps is not just about your automated deployment pipelines and you know infrastructure automation and you know using containers and all that those are some of the technical aspects of DevOps but at an organizational level DevOps is about actually making Dev and ops happen in the same team right and ops is not the old world style of ops which is very very manual but it's the newer world and I'll come to that so I have some pictures illustrating that the traditional setup is you know you have these sort of a change organization this is your typical IT projects organization right a project might be to build a bridge that is one project but if you see the in terms of reporting structures that organization itself might have developers reporting to a head of development testers reporting to a head of testing and then you know designers reporting to some head of user experience or something and so on it might have many more verticals like this right and then projects projects are actually organized this way where people across all these reporting structures come together and they help build one bridge after another that's your projects organization in many traditional setups they these are these teams don't have the responsibility of actually performing releases to different environments that is where the release teams comes in they perform things like maybe maintaining environments deployments releases and so on and once it's released then the run teams come into picture where they look at monitoring systems alerts and so on you know they are the people who are probably responsible for SLAs operational SLAs and so on and they are all supported for their infrastructure needs they are supported by infrastructure teams that's the traditional setup right where this this part is this whole part is whatever I would call as change and this is run so change and run are organized as two different departments whereas in what we're talking about as digital savvy organizations you would basically have lots of teams here each but each team is complete in itself it's ideate build and run right and they would depend on not the old world manual infrastructure teams but what we call as infrastructure platform teams you've already had some talks today describing what the infrastructure platform looks like and they've used the terms like platform engineering teams and so on right so I won't go into that a lot more but that's really the whole point about combining change and run yeah but the reality is that you know many big organizations a lot of big banks etc they have a separate change within it they all ultimately might report to the CIO but still there is a development organization or a change organization and there is an ops organization with different heads and you know it kind of goes goes from there and they both sponsor their own DevOps initiatives with different sets of DevOps tooling etc etc right and that's a bit of a anti-pattern I think and also it's somewhat as a side effect of this what you see is that they they spend most of their budget on just running things because you've built so many bridges over the years irrespective of the traffic on that bridge all those bridges need to be maintained right so the 70% of the budget goes towards run and 30% towards change right and that is clearly unsustainable if you want to succeed as a digital business this ideally this should be the reverse you should be able to run everything with 30% of your budget and be able to devote 70% to change so going on to the third habit is that for some of these things to work the whole projects model of working the projects model of execution is not is not such a great model I'll go into this but I won't I won't be able to go into this in ultimate like in a lot of detail but there is actually a lot of detail at this URL so you know or if you just Google for products over projects you'll get it but I'll give you an overall summary of this but also just to lay the context for this right like if you take this whole problem that we talked about the bridge building bridge building was a solution but the problem was I want to solve the transportation problem at a certain point on the river yeah if you take that problem and you say now I want a team that is actually owning this problem and solving this problem right what would be the expected lifespan of this team right it would be that and the lifespan of this team is until that problem is verifiably solved this team has to exist right otherwise it's not problem-solving team which means this team might have to begin with saying okay can we just patch up the tunnel that's existing and solve the problem right and maybe they try that it doesn't work and then they launch a ferry service and that runs for a while and maybe that doesn't work etc and then they finally decide okay we actually need a bridge or whatever right so fundamentally these kind of teams cannot be project teams because project teams are set up as a temporary organization with a predefined scope like this project is about you know delivering all of this right with this team and so the team is spun up for the sake of the project once the project ends the team is disbanded they hand over the running of the bridge to somebody else right whereas a problem-solving team has to at a minimum live as long as the problem is relevant to the business right and some problems you can solve them but you have to like continue to keep attacking them like for example in an online retail kind of scenario one problem might be like constantly generating enough traffic to the site another problem might be ensuring there is enough conversion of that traffic these kind of problems are is not the type which is solve once and then go away you have to continuously keep on solving them right so fundamentally the projects model which is based on temporary teams is unsuitable for problem-solving teams it's okay for scope delivery teams but it's not okay for problem-solving teams right so projects are designed to deliver scope not benefits and also because people move from one project to another and these projects might be in very different areas they'll learn a little bit of this a little bit of that etc etc but they don't like stay long enough in any particular area right so their projects model doesn't really help with growth of knowledge and preservation of knowledge and in turn that leads to actual effort being great much greater than estimated effort right because effort is to some extent a function of the knowledge that you have and then they also contribute to architectural it so let me give you an example of this for example you know you might say that we've we've just purchased the new CRM system and we have a plan to migrate but enterprise architecture comes up with a rule that any new projects should actually integrate with the new CRM system or build against a new CRM system right they might come up with a rule like this however the scope of the project any particular project might not might be very different the project scope is to you know build something and integrating with the CRM system is just one of the things that they have to do as part of the project so during the project people might realize that okay although there is this guidance from enterprise architecture this integration itself is going to be a big effort because it's a new system etc etc right so and that and so the project sponsor might say hey I don't have the budget to figure out how to integrate with this new CRM system let's just integrate with the old system and you know we'll see about an integration later this is a reality in big organizations and so when that happens your architecture roadmap goes for a toss because people who purchase that system might have decided that you know what we will be able to shut down that older system in one year and move to this system but the more people keep on integrating with the older system that timeline keeps on stretching and that's why you have this situation in organizations where there are two or two or three systems that perform the same function right but there is a history and so you will see that for certain functionality the integration actually happens here and then you will put some middleware in the in the middle to kind of patch up between all these systems right so the projects model actually makes it harder to control this kind of architectural debt because the focus of a project is to do whatever the project is and then move on to the next project somebody else will worry about all those other things whereas if you had teams which had custody of systems if you had teams which said I own the CRM system nobody can integrate with these CRM systems without my knowledge right and the moment I have we have made a decision to purchase a new CRM system I'll actually make it you know hard for you or you know you wouldn't be able to integrate with the old CRM system without my knowledge the moment I detect that some other team is trying to integrate with the old CRM system I'll have a conversation with them and say no I can't support this this is not going to happen right so if when we move away from the projects model to a different model where teams actually have custody of systems right because now they are build and run together then you can prevent some of these kinds of problems okay so now I want to go to another aspect of projects you know what is inappropriate for projects in today's times and but before we go there I want I want us to understand this particular thing which is think you know we are all used to traffic in Bangalore right so if the problem statement was you want to improve flow of traffic through a highway right would you would the solution be to improve the pink is the utilization of the highway no right it'll be the opposite the more the greater the utilization of a highway the more you're going to get stuck in traffic right because utilization ultimately means how much how much of the space on that highway is occupied by traffic right so utilization and flow are opposite concepts you can optimize a system for flow or you can optimize it for utilization right but it's almost even theoretically not possible to optimize it for both flow and utilization yeah how yet the projects model if you actually see the projects model is really about optimizing the talent pool available to us for utilization yeah so and therefore no wonder what happens is you will often find in big in big companies lots of projects going on hundreds of projects going on but no project has got completed in the last six months right and that's a typical traffic jam scenario on a highway there are thousands of vehicles but no vehicle is making progress or actually getting out of that stretch of road right because what's happened there is speed has crawled to a halt utilization is maximum everybody's utilized everybody is booked 110% on four projects right that is again something that we've learned over the years maybe it started off with the whole IT as a cost center kind of approach but again now today the situation is different if you're a digital savvy organization responsiveness taking things to the market is much more valuable than utilizing everybody at 100% and doing it very cost efficient there is a tradeoff you have to do a tradeoff 15 years ago maybe the tradeoff made sense more on the other side because IT was more like a utility you just have to automate some business processes or so on so it made sense to to say okay I don't mind losing some responsiveness as long as I can do IT in the most cost efficient manner today the equation has flipped right and and again from that point of view projects as a mechanism they are mechanism that optimizes utilization not responsiveness right so what's what's the alternative then how am I doing on time 10 more things so what's the alternative alternative is to think very differently and to fund teams not projects yeah so think of it as you know think of it as if you were running a software products organization and you had three or four products that you're selling in the market right then you know that as long as the products are selling in the market you're going to have a constant product development team for each of those products right so that's what I call as funding teams you're not when you're funding the teams you're not really thinking about what are the projects they are going to work on at that point of time you will we will get to that at some stage but at the time of funding your funding teams not projects yeah this and as a result of that right what will happen is now you have pre-existing teams in place if you have pre-existing teams in place then work when work comes up you will take the work and map it to the pre-existing teams you will break it up and say okay this belongs in your bucket this belongs in your bucket etc right that is mapping work two teams it is the opposite of the products projects model because in the projects model you don't have pre-existing teams you have a pool of talent right and then when work comes up you say okay what does this require it requires three developers two testers whatever whatever you pull from that talent pool you create a spin up a temporary team right so there in the projects model you are spinning up teams new teams to match the work that's coming in whereas here in this alternative model you're not doing that teams are pre-existing you map the work to the teams yeah and finally and probably most importantly progress reporting in the bridge building scenario if the task of the team is to build a bridge then of course they will report progress on okay we've built 50% of the bridge right and with four months to go so we are on track or whatever whatever progress reporting is on the basis of delivery how much what is the expected scope to be delivered how much have we delivered how much time is left that kind of thing whereas if they are problem solving teams then that sort of reporting doesn't make sense right it's no use building a bridge on schedule if nobody is going to write that bridge right so the the focus changes completely to saying okay what is the problem that we're trying to solve and what is the progress that we've made towards solving that problem okay here is our latest understanding of the problem the progress reporting might be there so far we've tried to patch up the tunnel that didn't work we tried to launch a ferry service that had some adoption but not the level you know that we really want to solve this problem so now we are pivoting to maybe thinking in terms of building a bridge or whatever whatever that is how your progress reporting will be in terms of how how what progress you have made in trying to solve that problem right and there are organizations as we speak that are already operating in this mode you know that's what i call as the digital savvy organizations there are some examples in the articles that i refer to and of course like all the examples that we use all the time like you know if you say a netflake amazon and all a lot of them a lot of the work that they do works like this so what's a what's a realistic example of the whole the big picture what it all looks like okay i'll come to that it's coming up here so this is an online example from online retail where if you want to apply this alternative model to say an online retail platform what might it look like right so a little bit of explaining of this picture here each of these boxes represents a team a problem solving team so it's a ideate build run kind of team and those black dots inside represents the systems that they own so they have custody they are custodians of those systems yeah and there are four layers here to indicate that the that higher level layers are dependent on the lower level layers yeah so the first two layers are more closely related to the business domain the other two layers actually even this one when you talk about legacy this is also related to the business domain but these two tier two a and tier one is more related to infrastructure it's not related so much to the business domain right so here you might see that at from a market facing side you might have a retail website and a team that's responsible for the retail website and for say a call center application another team that's responsible for the sales along the mobile channel and then a store management applications team etc right and he all of them might depend on one or more of the underlying business capability so what are some common business capabilities in online retail you would have things like catalog order management fulfillment and so on and these capabilities will be exposed in some form of API and that API is consumed by the application layer teams yeah these individual teams might also have their own you know fully contained applications it's not does not mean that this team is only building APIs if there is a application for example somebody if there is a like a what is that called like a merchandising person on the business side and they might want to use some catalog application to set up things in the catalog then that application will also be developed by the catalog team so think of each of these team as if you're familiar with the Spotify model think of each of them as a tribe and that tribe can have multiple squads within them yeah what else yeah so I mean they commonly share things like at a base level they share your virtual computing in fact this might be private cloud or even if it's public cloud some sort of mediated access to the public cloud information security team network team legacy infrastructure team and so on at a higher level they're all practicing CI CD and all that right so there'll be some tool that you might have purchased or adopted and there'll be a team that's setting up the common pipeline infrastructure for all of them it's not like these teams are responsible for any any build breaks here then these teams look at it no that is not the purpose of these teams but it is to you know do the whatever is the heavy lifting that is common to all of them in terms of pipeline infrastructure they do it here similarly if you want to run things like ab testing and so on then you need some experimentation infrastructure and so you might have an experimentation infrastructure team and so on and similarly if these guys are doing some if there are data scientists here who are trying to extract some insights again they might need some tooling infrastructure which is provided by a data insights team yeah infrastructure team so that's a simplified sample of how things might look like right but really each of this team is long-lived it's not like each a team here is like is works for six months and then migrates to some other thing no each of this is a long-lived team cross-functional ideate build and run and they're outcome-oriented in in them they are they are reporting progress in terms of solving problems not in terms of delivery of scope then it's useful to think of like if you think of this right it's useful to understand that in this model most typically you would have a notion of software side product owners and business product owners so software product owners would interface with the corresponding business product owners because this whole organization is ultimately a tech organization everybody here would ultimately report to a CIO or a CTO right so software product owners are part of this organization but they would work with counterpart business product owners on the business side in a large organization and like like we said earlier the higher level teams are consuming stuff from the lower level teams and in that sense in a loose sense they are customers of lower tier teams internal customers now how do we decide you know how i should draw the boundaries for a particular or should i draw the boundary around catalog order management fulfillment do i need another checkout team in the middle or all those kinds of things right that's where that's a you know that's a sort of topic in itself and typically that's where i engage with clients and we do a digital org design exercise to understand their landscape and to say okay for your kind of setup and for your priorities and your strategy a certain kind of breakup might make sense yeah but to to to really be effective at this right it's it's not good enough okay you say you have ideate build team build run team so you have developers testers here it's but it's no it's not as effective if the developers continue to report to a development manager and the testers continue to report to a head of quality etc etc for this to be really effective there needs to be a blurring of boundaries between all those kinds of things and you need to have some sort of unified business aligned reporting hierarchy doesn't mean they are reporting to the business but the lines of reporting are more along you know the whole catalog team reports to you know somebody who is like like head of catalog who might who might then ultimately report to a ci or cto or whatever right that sort of thing as opposed to function-based reporting all developers report into somebody all testers reported to somebody and so on yeah there are many other aspects and you know the whole detail is available on on this particular article on martinfowler.com and there's a big FAQ also at the end that you can refer to answers a lot of practical questions based on experience of helping some clients with this sort of thing yeah so to summarize right what we've discussed is these sort of teams digital savvy organizations they operate with the help of teams that have all these attributes they empower they outcome oriented as in they want to solve the problem not just deliver scope right their business capability aligned so you might have a catalog team or fulfillment team and so on as opposed to a middleware team and a presentation layer team or those kind of things like not by architectural layers but by business capabilities they are long lived they are much longer lived than typical project team they are cross functional right not cross functional just like developer tester but all the all the rules that are needed to solve the problem right yeah so that's what I wanted to share if you have any how much do I have time for questions okay okay okay so if there are any questions we can meet outside yeah thanks for joining