 Yeah, the microphone doesn't actually project anything, it just picks up the audio for the recording. So it's best to hand it to the other one. Sure. Just double tap the phone until it goes green. There we go. Brilliant. Have a good talk. Thank you. Check, check, check. Check, check, check. There's no mic. Speak loud. Before the lights, speak loud. You guys will do the party last night? 10. 10, right? Yeah. Yeah, it was a long day. It's too loud, right? Yeah. I agree. What kind of disadvantages are there? The party. I came nine and a half nights before that. They said that if it went going until eight, so they had an initial tap of 1,000 homes, and then someone else... 500. 500, then someone else finds it. So it went twice. Oh, here it is. That's good. Zero of you. Zero of you. Are you guys heading back today? Yeah, I'm staying. I'm staying. I'm staying. It's always good. Yeah, yeah. Looking forward to it. The thing is, the new thing is in the desk. Hi. Looking forward to it. Yeah, yeah, of course. Sure. It's green, isn't it? Not at the minute, no. Double click here. Oh, it's green on the end. Okay, yeah. Let's see where it starts. We'll probably switch to two more minutes. Let's start. So, welcome everyone. Through my session on transforming outsourcing to driving easy success. Good afternoon. Last session of the day, I guess. Before Kino probably. So, yay. And food after this, so double yay. Before we start, can we just, you know, have a very quick show of hands for all those who are outsourcing or, you know, either providing outsourcing services or outsourcing the partners or time to do that. So, quick show of happy. So, my name is Piyush Podar. I'm leading partnerships at Accelerant Technologies and I'm leading UK and Asia Pacific regions. And I live in India in Jaipur. And, happy holding. We just had this festival yesterday in India. It was a colorful festival. Although I'm here saying only white everywhere. But, yeah. So, the challenge. The, so the Drupal Agency space, and I believe, you know, the majority of people are from agencies, either working with agencies or leading agencies. The Drupal Agency space is looking like an ocean. And what I mean to say is, Drupal is a vast ecosystem of ever-evolving companies and businesses. But, every company, every organization is, is fighting for a same pie, a bigger piece of the same pie. The pie is pretty much the same. It keeps growing a little bit at times. But, everyone wants a bigger pie, piece of pie, in terms of business opportunities, market precise, and talent. And today we are going to focus on the talent aspect of agencies when it comes to growing their businesses. So, because of this consolidation in the market, because of these challenges in the market, what leads to this competition and consolidation? So, oftentimes, you know, you are fighting or you're trying to attract the same talent out there in the market. There aren't good developers out there, but there are not too many of them, right? But, you still have to grow. You have so many business opportunities. Business is growing, size of your business, the count sizes are growing, these sizes are growing. You need to deliver those projects. You need to deliver those solutions. But, the available talent code, the production capacity is still the same. And you're still fighting to find more developers, developers are there, but they also look for good opportunities. Now, how do we, how do we solve this is something I take you through. I did a quick research and found out this recent survey conducted by EY and Tech North. This survey was based on north of London as a region. And the interesting finding from this survey was that the digital scale gap is still a significant factor across the north with 58% of digital agencies in the region say that finding talent is their key concern. And I believe a majority of other companies in the other cities of this country are also facing similar patterns. You can see, you know, you can go to this link and you can see the details of it. There are other data points that are going to go there as well. So, how are companies doing it? So, there are two or three ways that companies are trying to do it. One, you're trying to hire interns, juniors, fresh crats, developers, and trying to train them and upskill them so that they can become good developers. But there are certain challenges to deal with that. I'm not saying that this is a bad way of growing your talent list. We also do it sometimes. But it's not very effective in the short term, especially when you have demand spikes. You have, you know, some big projects coming up very soon. Hiring developers, training them, needs a lot of resources, consumes a lot of time. Experience will only come with time. So, a fresh developer will only become a good experience developer in a couple of months or years. He cannot be completely productive and start delivering projects all by himself day one. And then there are issues of attrition, churn, which every company is facing, right? Other developers are, you know, trying to move too. So, you know, if you train developers, oftentimes you also found this happening in other countries outside UK, is that you train developers and then some, you know, after a few days or, you know, a few months or a few years they start moving to other companies. So, few companies have become training grounds for development while other companies have become, you know, places where they would like to go. Also depends on the HR advertising and, you know, how they attract those developers. So, it's again a challenge. One other way is at Rehigh. You identify a company, agency, who's got good development capacity. They want to grow, but they're having growth challenges. They have good production capacity. So, you go and you acquire them. This is a strategy that has been pretty prominent in the IT industry, but then again, it has got challenges like it's very costly. You have to, you know, up and you have to pay a lot of money to these companies to acquire them. It's risky. Indeed, it's a lot of vision alignment. The, there's a lot of talent available, but the culture mismatch is something major that can fade here. Then there are communication and management challenges. Poor program management challenges, you know, and they may be having different programs and you may be having different projects, you know. Having a solid program management system in place is needed and that takes a lot of time. Leadership alignment issues are there unless the leaderships are aligned. We have seen a lot of such examples where companies came together, worked for a while and then subsequently it fade. Risk of impacting company culture. So, you know, even if it fails and when you decide that, okay, we are gonna, you know, end this thing. Poor company's culture still gets affected, which is a problem. So, the third option then comes, which is outsourcing. These are some of the common benefits that we are all aware of, traditional benefits. Compared to others, launching, you can launch new services and revenue streams based on the capabilities of these new companies. This allows you to maintain focus on your core business. It provides you greater off-specibility. You don't need to worry about managing the operations of the company that you are partnering with. It gives you more credibility. The two companies are still separate entities, so there's less challenges and less chances of cultural mismatches or problems appearing and risk-sharing. So, this is a definition I googled somewhere. This is not an exact authority space from where I got it, but it says outsourcing is a business practice used by companies to reduce cost or improve efficiency by shifting tasks, operations, jobs or processes to an external contracted third party. Functions that are contracted out can be performed by the third party, either on-site or off-site of the business. Sure. But does it work? So, a few of you just raised your hand and said that you have outsourced. Anyone who has faced problems in outsourcing, anyone has come across that problem is like... Yeah, we did that. We tried a couple of companies, we worked with them, but it didn't work out. Anyone would like to tell us, you know, why it failed, what was the problem you had faced? Sorry, yeah. It's supposed to be great. I think on our part it was due to not having sufficient orders of details and such as creationism. We had to be very, very, very specific. Right. Plus, not necessarily having any point of contact with the country we outsourced to, but not being able to collaboratively enough and regularly enough to outsource things. Yeah. Yeah. So, I see that the common problem that you mentioned was a huge gap between expectations and delivery. Right. Anyone else would like to, for any point, any thoughts on that? I also have something I also welcome to share with you. So, these are some of the challenges, some of the failures that we over a period of time and we don't say that, you know, we are also not so syncopated by the way, but we don't say that we have been best from day one. We have faced, we have seen a lot of these issues coming up with our early engagements, our clients and partners, you know, mentioning that these problems we have faced with them, other companies and others, and overall in research these are some of the things that we found out. So, I just quickly touch base on each of these, starting from two o'clock, unqualified members, the partner that you work with, they often will tell you that they have great developers, but when it comes to delivery, when it comes to development, as you just said, what was expected and what was delivered, either documentations were not clear or requirements were not clear, they didn't ask the right questions, and that is competency issue. So, unqualified members who are broad hiring funnel, oftentimes they say that, yes, we can deliver this project, we can hire another 20 developers in six months, but when it comes to, when you're there in three or four months, you know, they may tell you, okay, no, we don't have this as many people, it can be done with four, it can be done with five. So, an untrained in-expert recruits are there, oftentimes they'll do this to save cost and bring the average cost of their operation slow. A mature workflow adoption, ad hoc transitions and agile in-experiences, a lot of companies still don't understand how to deliver projects in a real agile manner, agile as a term is great, they try to adopt it, but they really don't have the right coaching and the right training in-house to be able to deliver things. Scalability challenges, hindered escalations, availability constraints, if all of a sudden, you know, you're looking at hiring or a new opportunity and you need more developers, there may be constraints that these companies may have and not have those developers available. Processes, their processes may not be aligned with your processes or they may not have the complete standards in place. They're the typical supply excitementality, lost priorities and misalignments. And then there are more, like stakeholder confusion. The owners, the leaders may not have a clear vision in terms of what these companies are doing, but when it comes to a joint delivery, there may be challenges that they may be facing in terms of roles and activity alignments. Diversted employees, unhappy, low energy ownership. Now this is a very common problem we've seen in companies. They're building companies like sweatshops and, you know, developers working 9 to 5, but then oftentimes there are work pressure, quote is not very good, equality is bad, so what they end up doing is, you know, work over the weekends or late hours to try to fix those problems, which leads to pressure and stress and then, you know, the developers are not happy. They don't have a career path that they are chasing, they don't know where they're heading, so overall they are just doing something on a 9 to 5 basis. What ends up is, you get a bad quality of code, you get a customer who is not happy because what was promised by you never got delivered. Post project QA issues. So projects get delivered and then testing what really happens, right? The site is online and now you're fixing problems. A lot of these companies, a lot of these developers are good at fixing bugs, but not good at preventing those bugs from coming. So that's also a basic challenge that we have to think about. Developer QC dual role. So developers and testers. So developers are doing testing, you know, lack of clarity in terms of what they should be doing, what. Communication gaps, obvious soft skill dependencies. A lot of people have these complaints with dealing with outsourcing companies. Delayed global response cycle. You expect a response or a resolution within a day or two, but then what happens is, you know, it almost takes weeks and there's no response from those people. And obscure operations, ambiguous service reporting, ROI and GVM. So your project which was planned to get delivered by maybe, you know, quarter three, it's already the next year and you're still developing the whole thing. So does this sound common to you guys in terms of your outsourcing experiences or things that you've heard about your friends or the companies that have done outsourcing? Okay. There are some numbers that are there from the same survey, the Deloitte's 2016 global outsourcing survey that we have developed which kind of validates these numbers. I'll just touch upon the top three highlight ones, which is providers are reactive rather than proactive. Almost 46% of providers are reactive than proactive, right? Good at fixing bugs, but they don't do anything to make sure that bugs don't happen. Problems don't come up. 33% don't provide enough innovation, right? Code is there, but there's not enough research, not enough efforts being put to think about the future roadmap of that project, you know. How is a particular feature going to be like so that there's less effort and better value given to the client? 29% have high staff at recent rate. This is almost three out of every 10 developer that you probably working with in an outsourcing company. He may not be there in a couple of months or now. And then the whole problem of, you know, transitioning to another developer on boarding of the person and then communication and all those things. And there are a bunch of other numbers from the same survey which talks about, you know, what are the key concerns. And from the same survey, why agencies still outsource? So this is an interesting number that he came up with which is 59% of these agencies are looking to outsourcing as a cost cutting tool to stay almost 57% are doing this to enable focus on their whole business. Strategy growth, greater operation flexibility, global talent acquisition, shared knowledge and experiences. Now the question is how do you change this? If this is how outsourcing is, if these are the problems that every agency is facing but you still need to do this because your growth goals, your scalability concerns your problems in, you know, hiring people based on your project demands and spikes. What do you do to transform outsourcing? So we have a very simple way of explaining how you do that. First point you need to find the right partner, the outsourcing partner. Now there are some of the trades that we suggest to be there when you are identifying or getting a good partner. They should have complementary strengths and weaknesses, like very important. You are looking for someone who can actually do a job better than you or who has more bandwidth of delivery to some aspects that you cannot. So you have good project management, they have good delivery capabilities that doesn't come together, they can deliver products. Common shared goals, it's very important to have common shared goals, have at least some roadmap that, okay, you know, this is what we are trying to achieve. This year we are trying to reach us, we are trying to acquire maybe 10 new customers for that. We need X number of more developers. We need to develop new capabilities and we will be able to do that in the next quarter. How is your outsourcing partner going to support that? And is he able to do that? Can he hire more people? What is the process? What is the normal time? Having shared goals other than just, you know, making money together is very important there. Experience and expertise, the developer should have, the partner should have the right technical capability, domain expertise, you know, multifunctional areas, talent development process should be there, they should have proper training systems in place. They should be focused on community contributions and community involvement. It is very important for open source ecosystems like us because the partners are not really caring about community. They would not have a strong grip on those technologies that we are working on, right? And they should have a strong emphasis on people empowerment, people development because end of the day people is what we are partnering for. That was the key challenge. That is what we are getting as part of the partnership. So they need to make sure they should have a system in place and you should be convinced that yes, these guys are actually taking care of their people in the right manner and the way you would have done had it been your company. And other things like they should be scalable and all. They should have a strong governance and track record. They should have a global delivery team. They need someone to work from a single location, that's fine. But oftentimes we say companies look for partners who have people and production capabilities in different zones, different time zones. This gives you advantages of 7 support or continuous development in different time zones. So that when one team is going to finish their job, there is some other team that can take the job. And then the regular set of operational tools, processes and standards, like they should have agile capabilities, proper engineering standards, delivery standards, development best practices. Again, those practices, if they are aligned with your practices, that's very important because oftentimes your team would also be working with them. So we'll come to how the partnership can be evolved to that we just saw was identifying the right partner. There are a few more aspects. Let me just take a look at their customer service agreements. So this allows the partner to make the right promise and be able to deliver on those promises in terms of the reservation time, maybe response time. These are easy contracting, multiple engaging modelers. Oftentimes we have been seeing something called agency of record say you will not be interested in dealing with multiple vendors all by yourself. You prefer that when it comes to say technology solution, you develop a long-term partnership with your partner and then it's their responsibility to develop those new capabilities, either in-house or as a contractor or whoever, but then deal with it themselves. You should be dealing with one single partner and have a very strong, very closely integrated systems and processes in place and let them worry about the other stuff. So they should have capabilities of being able to do that. Only then you can focus on your core and let them provide the value that you have got into this engagement form. Then other aspects like team allocation, they should have a system of team allocation. Transparent team allocation, we should be able to see who is available who is not available as opposed to a lot of people, there are companies who say okay, I have five developers, you don't need to know what those developers are, you should know those individual developers on a personal basis. And last but not the least, these references and proper industry cracks should be able to check with in your industry or references that they provide, call them up and confirm that yes, these are the right people and they have delivered what they are promising. If you provide the partners, then you can follow a framework, now we have created this framework based on our experience. This is still a work in progress but we tried to take all of our partners through this process step by step. There are these five major phases or broad phases you can say on which we map the entire partnership management and so-called partnership maturity management and we, when I speak about the company that I represent here, we are bringing in the perspective from the outsourced partner, so the other side is where you are looking at this. So building confidence in the first stage then establishing trust, we will get into the details of these in the next slide. Third is delivering quality, exceeding expectations, shared reputation. Oftentimes the relationships are pretty much do not go beyond the second stage. You build confidence, you get into a contract, you start working together, quality is being delivered, sometimes work is being done, trust is being done, but then beyond that, quality problems comes, your expectation gaps are there and then the whole partnership relationship goes down for a toss. So exceeding expectations, shared reputation is totally missing. So these five stages can help you plan and maintain successful partnership journey as well as also keep measuring your partner on various levels at what stage your partner is at with you. So what we have done is we have created a sort of partner success journey and we had a session in, for example, in fact, same group I remember about the partnership success journey. Did you, anyone want to take that session? Right. So you must have seen this chart there. So this is a journey map, but basically this journey map is mapping the partnership development journey on these five broad phases that I just talked about. Building confidence, where you're actually getting into discussions with the partner, defining the engagement or the integrity of the engagement, defining the processes. This is when you are doing technical discoveries, when you are trying to align your technical plan of the engagement as well as the technical capabilities of the client and then you come up with a structure of proposed roadmap and then you propose that to the client as part of the engagement. And then you kick off the relationship from the stage. Confidence and you know, somewhere around that's where the establishing trust aspect comes up. This is all about onboarding your partner successfully. Then comes the delivery quality aspect. Now a lot of these touchpoints are missing in a traditional outsourcing model which is why they lead to failures. Things like, you know, they don't have systems of nurturing those stages. Heal member feedback. They don't have proper 111 system happening inside. Continuous delivery is missing. A lot of companies don't have proper KPIs. So you need to also get into details of those companies and see how they are managing their teams, how they are managing their talent. What are the KPIs? Are their KPIs aligned with growing those team members and subsequently providing you better quality so that the project that you get delivered is online with that, right? So you know, by all of these constant check-ins you would be moving from delivery quality to exceeding expectations. Some say that, you know, exceeding expectation is a variable and should not be there, but different talks about that. I believe that a partner who's really committed to a long-term relationship will ensure that all these checks and validations are in place and they make sure that they keep exceeding expectations time and again. And subsequently then you would be at a shared stage with activities like proactive consultation, extended teams, extended teams and then you may have contracted them for maybe 20 developers if they see a need of you know, looking at maybe two or eight migrations or developing a new platform for you, they should be able to develop an extended team either on cost basis or aligned with your business priorities and be able to offer you they should be able to stretch cones they should have that DNA in there to be able to stretch cones. Now these are very tough things to really judge at initial stages, but once you move through this partnership journey once you move through the different phases of a partnership you should be able to see that. Again, these are perspectives these are both the perspectives the client's perspective and the supplier's perspective but oftentimes client is not having a visibility on these kind of things and that's where the whole thing goes down So shared value creation, stretching goals new horizons and joint thought leadership you know, these are basically mapped on onboarding nurture and inspire the feedback of a successful partnership maturity model if I may say so and by doing this this is how we have created value by following these things properly internal alignments empathy centered, knowledge sharing we have developed knowledge sharing in-house and with our clients with our partners quality team members low churn turnover Now again, if developers and outsourced resources and quality resources they keep moving companies it won't do anything good for you so they should have a system in place to make sure you should also know what's your retribution rate if you are an outsourcing partner how many people would stay there get some data get it validated dependable forecasting, they should be able to tell you you know how you can forecast their source availability feedback cycles so we have followed a lot of check-ins checks and balances and these activities things like net promoters code we often keep checking with our partners what's their satisfaction levels with the engagement the quality of our delivery there are routine touch points between different managers on projects which you should be careful about the workflows should be custom tailored and the processes should be partner priority focused again, priorities may change the partner should be able to accommodate those changes try create a plan and help you and be able to solve it as opposed to know this is the only thing that we had contracted for this is only what we had delivered without this stuff in the original code contract or engagement we developed a lot of key performance indicator aligned with these codes and we enabled this learning these are all part of the people development then maturity models relationship framework partner journey mapping so what we saw was a partner journey mapping so what we do is we use those phases and those touch points the partnership relationship through and ensure that even marketing is aligned with the buyers with the partners on that level clear communication facilitated by tech and hiring efficiencies so preemptive selection less than 1% people are hired we made sure that hiring is not done for us to get the company but to help partners deliver what they have come and last but not least having the key ownership in place things like success managers should really not just focus about projects they should be focused on the partnership success on the whole so they should have their eyes on the bigger picture and a grip on that they should be able to tell you that yes this project is fine but there is another opportunity that we discussed so we can do something about that and how can all of these come together so more matured and well rounded success management professionals at that level to be able to push the whole agenda forward and operational streamlining so again lot of work needs to be done in terms of operational efficiencies matrices are there records and checks and buyers are there and once all of these happen creation of consultant needs support and shared value creation as part of value to the decision so what I just showed you was using those phases and those actions and touch points and plotting the relationship in a journey, it would take time you will have to spend some extra time on each relationship keep nurturing them over time but then you can turn around the challenges and concerns and failures and outsourcing to a more transformed outsourcing so that the outsourcing strategy becomes your growth strategy and plays the role plays the role of strength so that's pretty much what I had to share based on our experiences of working with partners would be happy to have any questions if you have any this slide would be there on I think with me about this slide right about the resources you can refer to the resources to understand a bit more about each of these concepts that I just tried to elaborate upon and my contact details are I think email and Twitter how many years have you been in with outsourcing so around 19 thank you like in half and you've seen all these problems, all these negatives all these failures happening either as an audience or as a party myself so that's where and I'm sure everyone who's doing outsourcing has come across this problem so in terms of team projects do you work with the rest of the world you're learning new skills so see team sizing really depends on projects from our experience we've had two team members on one project as well as 15 team members on projects those are bigger projects with different development teams there have been instances where we've been working actually something that we've been working with in the last couple of months is trying to build an extended outsource development center model where in you know the partner has let's say 20 developers and they are working on say 5 projects so they elevate those developers and these are in-house developers in their premises they elevate these developers as leads of these individual projects and then our outsourced team comes in and forms the development block of the entire team on site near to the client lead the project and work with say 5 part developers for that project again some of the projects may be smaller may be larger yes yes because the one premise is that the agencies prefer owning that part they prefer owning the relationship with the client and they also prefer retaining and growing projects in areas like consulting you know, business design system design, UI, UX discovery workshop and those things wherever they meet partners should be able to help them and provide more bandwidth and they should actually be involved from the get go so it shouldn't be like 3 months down the line we'll get in contact with you and then we start development and the project is being signed up or that should get involved with you that's a very major winning strategy that we have experienced from our site at times partner is the client is not very keen on investing effort or money for that we go out and we say ok fine we'll have at least this guy shadow you for some time even on a class basis that's fine subsequently success is what we'd like to end of the day it's going to come for us project delivery has to be successful and what's the sort of project for us we've been working on 10 years this was 1 year, 3 year so it kind of feels that if it's too long then I don't know how well it will work for an incredibly long project it's too short if you get the economics of sales to be able to develop the team and up it up so is there kind of an average as you always said from my experience we have been working on certain projects which are product engineering examples for almost 4 years now while there are certain projects that we've been working on for 3 or 4 so usually from our experience we've not been working on smaller projects than 3 months or 4 months but that's probably because we don't go in for smaller site projects and most of our partners who work very closely with us do not have 1 month projects, 1 month stuff instead of documenting stuff and working with an Excel team they simply get the smaller part done by themselves the long term the long term plan is where this is more successful than short term critical and then you should also define the nature of work so projects should be separate and have different dynamics and different projects and support engagement should be different operational rigors and systems should be there these should be properties on those parts and then there are other elements like continuous delivery of this have you also had an experience with my working freelancers or independent developers, remote developers see the whole idea is they are great right? independence is nothing like independence but the problem is partnership is all about making a commitment right? and then delivering that commitment and then exceeding it with freelancers or partners, freelancers and contractors managing and having a grip on that delivery availability is very tough so if it's a company that's only interested in getting something coded and delivered it can probably work with them but if you apply all of those if you go back and see those steps those activities you know check-ins, coaching, mentoring you know maybe hiding a life coach instead of a HR person so that would work with freelancers right? so you need to you need to make sure that you have equal control equal connect and you equal people you are empowering everyone you don't know how can you inspire freelancers how can you empower freelancers except you know sharing and meeting with them in conferences and spreading some of those because oftentimes freelancers may also have different priorities but having said that we are talking about outsourcing model and my point of preference is from a remote perspective this probably does not apply to on-site freelancers which I feel is a good tool of short term from my experiences and talking with a lot of agencies it's a good short term for short term and on-site project is great but for long term they kind of try to avoid that no personal comments for any freelancers out here I've been a freelancer I've said that somewhat the financial system works good for outsourcing for the number of chances of number of hours monthly basis or for some of the mass participation so what can be best well that really depends on you know the company itself I cannot stress that what may work for us what it will do but from my personal experience of delivering the last 19 years I can definitely say that developers are not resources and you know you thinking about selling hours is not the right way of looking at it then you're only looking at selling a commodity that's the whole point of failure in this ecosystem you need to look at solving the problem of your client with that a lot more comes in than just you know couple of hours so right then maybe times when you need to stretch yourself and do some additional research or you know maybe try to fix that technically you can't really build them on every hours you have to build all of that in your in your rate contracts rate cards second is you know we prefer doing mostly contracting it gives us better visibility it gives the partners better visibility and they know how much this is going to cost like in the next couple of months and predictability in terms of talent planning is also important how will you say the partner says okay I need you know it's like you know can you give us $35,000 development for next week I hope I will say what you want to say what is your experience in terms of startups that want to go from NDP to their own projects startups as outsourcing options a startup that wants to develop a project using you so we we work with startups and but they haven't been very early stages so because at Accelerated we don't provide the business consulting services so you know a startup has to reach a certain stage where they have a basic product to play or at least a product design and business play if this startup doesn't have their own in-house capability I think going to the outsourcing route is the best in that case because then the startup also needs to look at a lot many other things expand the business plan maybe get some funding and they've got limited resources there for a time so they should look for partners who can work with them in I don't know revenue sharing they say project ownership basis something that I've seen work quite well in the Indian ecosystem for that I haven't been attracting much with these startups in the UK this week thank you so much do the outsourcing a lot I just want to talk about how to work with the project so I just want to make this closer so we can talk about it there yeah it's okay you can just like that okay we'll see you in a minute yeah yeah yeah same thing we're similar yeah okay are you already outsourcing maybe I did there you go it was a better product okay it was a it was really the IT university younger ones younger ones well much more experienced and what I have to develop but the knowledge and the the apprenticeship yeah yeah it's not easy it's not easy what we're trying to do is kind of different though I mean it it invests a lot of resources and time in the model I mean the model is very similar to kind of in terms of management it's in sourcing it's basically in sourcing in the long term but I guess the challenge possibly will be over in the UK is the definitions around the I know 35 issue that we have so someone's on a project so if there's that level of engagement with the contractor they can potentially see the input yeah but we do that we do that with SAP organization like they say play and we found that to be actually very successful model I mean you open stuff how long do you open this example what do you mean by the needs yeah some of these products now we play we have teams of 6, 7 people 4 here they build it it works well and then they need a bigger team so why would they leave they have some technical needs so that they can leave before approval it actually works out much better than you because you may think you don't know you don't know and we understand the way it is did you share cards to get your experiences with maybe to talk about that because we're always looking to gather the experiences people have without sourcing the capital because it helps us of course that transparency is important so thank you that's fine it's going to be a short one are you based in London no I'm not Pune Jaipur India so you don't have someone based in London we have an obvious no one goes there it's 600 kilometers it's a remote culture so it works it's seamless that's why we had to put so much of talking after things like our CEO things we should put instead of office, just the cloud maybe that would inspire everyone so yeah what's your name is that in the end he said he's a marine frost developer hacker kind of look well not yet he'll take care of all the big banks don't worry about it dad also was like hacking trading I think I saw some activity I saw some of your Minecraft projects the case of the startups we know what exactly we want well we have them okay you have a problem I have a problem