 Yeah? Okay. All right. Cool. What did you say? Recording. Okay. That's a word I really don't like to hear. That's okay. Hi everyone. We've got a pretty intimate group, so I think we'll make this more of a discussion, which is cool. I think that's totally great. I'll just very briefly introduce myself, and then these lovely people here introduce themselves. My name is Jacob Singh. I manage Aquia's India operations. So we have an office in India, and we help companies and partners set up their India teams. And why don't you guys go ahead? Sure. So I'm Mike Lam from FISA. I'm responsible for, we call it marketing technology strategy, but what that means is I'm responsible for FISA's global digital engineering team. So we build the web platforms that FISA use for marketing across any markets, business units, all of our digital programs. Hey, I'm Dave Inslee from J&J. We recently transitioned from building Drupal sites for our brands to building our brand sites on a Drupal platform. So I'm managing the build out and roll out of that platform globally. We publish our editorial tools at timing, and over the last year we've also gone from building all of our sites individually on Drupal to having our 100-some-odd sites worldwide stood up on a single multi-site platform. I'm Jeremy Kutner. I'm in the lead web strategy team in the consumer sales and marketing group within Warner Music. So we run our artist website properties, also multi-site on Site Factory. So I guess since we have a pretty small group, we have some things we're playing to cover. That's probably relevant to all of you. But before we get started, is there any particular topics that you guys came here that you're interested in or goals that you're trying to solve by coming here and learning something? No? Crickets? What? Yeah? You can just yell it out too. It's a pretty small group. I can hear you. I think it's a great place to kick off, actually. It's a really relevant one. You want to take that? Anyone? Mike? Sure. So I heard a couple of questions there. The first one was what responsibility do we give to the vendors, especially when it's offshore in a location where maybe, I guess, we're outsourcing something where we don't have fires at colleagues local. And then how do we build those teams, essentially, right? So the first one around how do we hand off responsibility? We have different kinds of projects, right? So we kind of call them platform projects, which is normally the more innovative, harder problems to solve in putting together FISA's digital platform. And then we have individual sites that were then building, or individual campaigns that were then building on that platform. What we have is globally distributed FISA teams that are managing those projects and decide where they're going to outsource them to. So you have somebody who's responsible for that project, who is then working with whichever vendor they go and outsource to. We try and keep it somewhat regionally focused, if that makes sense. So for example, if we have a project that is being run from New York, but it's being delivered from India, we try and have enough critical mass for that vendor that it makes sense to have some onshore people as well managing those projects. So actually Chris, in the audience, he manages a lot of projects in India from New York, but down the hall from his office will be somebody working for that same vendor. So somebody who can hold accountable and somebody who can also do what they need to do in that role and also time shift their day so they have some coverage with India as well. A second question about building the teams and investing the teams. Sorry? It's kind of echoing, right? Can you hear okay? Okay, it's all right. Good. So the second question about investing in the teams and building those teams, it's more of a focus for us now to be honest. Now that we're growing and doing more and doing more complex work. So we're doing that by trying to go and visit some of the teams. So we have a big presence or a big team in India now. I went to India at the beginning of this year to go and meet that team, speak to them about kind of their concerns, learn what their work is like, and talk to them about where we're going in our strategy. And I think that really helps what I'd experienced when I spoke to them, spoke to the team. There were many people there who had worked for that company who have a partnership with Pfizer, who had worked with Pfizer for like eight or nine years. And sometimes Pfizer would make a technology choice or a technology decision. And they would just hear about it, right? They would go, okay, we're no longer using Java, we're now using .NET, we're now using whatever it is. And they don't get any other view of the strategy and what's going on apart from that. So going there, talking about our strategy, where we're investing the technologies we're using, really kind of helped us in terms of getting a lot of excitement in that team and willingness for them to then invest in whatever technology. Knowing the person that's making the decision and knowing that they are committed to it and they're not going to come to work tomorrow and find out they now need to learn Ruby on Rails, for example. I think, just to follow up on what you're saying, there's maybe a willingness to assume that because they're not part of your company, that they're not something that you need to invest in, right? Their company should be investing in them. I think that's a huge mistake, right? They are your team, so if you're not investing in them, they're not going to grow. So the consumer sales marketing team at Warner Music Group is like so many other companies. We were a technology group that was born out of a marketing group, and so we inherited our offshore team from our IT group. It took several years to really grow that process with them, and I love my team now, but there were a lot of growing pains early on. It took the investment of having our onshore involved constantly in all of our meetings and all of our efforts, really giving them the background that they need in order to deliver that message back to the offshore group. So there is overlap, same, and so the team will sit with us during the day at 8 or 9 o'clock. They'll talk to their offshore team, they'll pass off the information that we've given them, but they have this deep understanding of what we're trying to accomplish, and that's super important. Sorry if I could just, Aaron, if I could ask you. I mean, Aaron's situation is a little different. They do mostly internal, right, not vendors. Do you think there's a difference between an internal offshore team and a vendor offshore team? Yes, over the last year I'm terrible to coach my team not to use the word offshore, and if you use the word offshore you're generally invited to leave the meeting, rethink your position, come back in. And the Drupal community I think is a great place to start this conversation, because nobody refers to my team in London as offshore, nobody refers to my team in Seattle as offshore. That term is used almost exclusively to refer to teams out of India. I have found in managing global and hearing teams, much like I think the Drupal community has found, that engineers like to build stuff, and engineers like to build great stuff. And the way that we approach this issue internally is we have an engineering team in Bangor, we have an engineering team in London, we have an engineering team in New York, we have an engineering team in Seattle. And much like Pfizer, we made the decision that you put the platform team together in one location, and much like Pfizer discovered, if you have a team that's working out in a location such as Bangalore, and it's difficult for them to talk to brand people in New York or London, it makes sense that the engineers in London and Seattle and New York are the people talking to brand people in those locations. So for us it made sense to seat the most difficult and challenging problems that we're facing with our team in Bangalore. So we ended up flipping the model on Ted, rather than saying we're going to take the least interesting work and shovel that off to an offshore location. I use air quotes for the audio if we didn't pick it up. We're going to go ahead and we're going to create a great engineering team in Bangalore. And we gave each of our locations a center of excellence, so our Bangalore team is a center of excellence for platform. Our New York team is a center of excellence for front end development for media brands. Our London is a center of excellence for front end development for media brands, and also for DevOps. And our Seattle team is a center of excellence for app development and for DevOps and infrastructure development. So that's how we've solved the problem. And what we've seen in about three months is that making that change to our engineering team and taking advantage of asynchronous communication tools, which engineers are used to working with, has allowed our Bangalore team to become much more productive in working with our New York team. And it's also, by the way, allowed us to get benefits from our Seattle team, relative to our New York team or Seattle team relative to our London team. So we stepped back and looked at it completely as a global approach. What's interesting listening to you guys is that you're also thinking about it from perspective of generally the people you regard as offshore, it sounds like they're not employees of the company themselves and they're not necessarily part of the same engineering team. And it's an interesting problem that starts to tease apart. Yeah, that was actually very interesting. I think at J&J our approach has been similar to Pfizer's. Yeah, Pfizer's. So what we've done, and we're still building this out right now as we transition to a platform model, is we have regional extensions of our engineering team and then we have those folks managing resources from some of those larger partners for site support as an example. Generally, for other activities, for site build or platform development, we always have our resources local to the engineering team. So right now it's out of the US, but we are extending that out on EMEA right now. So I think it was very interesting to hear how you kind of looked at the opposite way and embedded that team in India. I think maybe that's something that we need to consider as we scale out if we're going to be effective working with those larger partners. So, very interesting. I love what you're saying about outsourcing actually. I think at Pfizer it kind of comes from any word that is, we use it as kind of a procurement term when we're trying to get a lower cost resource typically, right? And I feel the same as you about it. And actually it was quite sensitive for me earlier on in the year because one of the companies we worked with opened a lower cost facility about half an hour away from where I lived and I was listed on all the contracts as being offshore. It's like, I'm not offshore. But they were about half an hour away. And yeah, I don't think the term really makes sense there. And also to your point about investing in your Bangalore team as engineering, I think one very interesting thing is happening for us as we're getting a few years into this. When we started out, as you were saying, when people do outsourcing, they're often trying to outsource the most junior or offshoring the most junior roles, right? So I call them like, let's say, rung one, two and three on the ladder of Drupal expertise. Something very interesting that happens when you scale, you get a couple of years in and you need to scale further and further and you need more and more people at rungs four, five and six. And you can't just, people don't jump on the ladder at rungs four, five and six. And if you've outsourced or focused people on rungs one, two and three in a particular location, suddenly they have a huge workforce that's able to go four, five and six. So it's very interesting to see how this plays out as it matures as you stick with one technology and that matures to how you can change your strategies around that. I think that actually brings up a topic that I've heard a lot about from anyone, excuse me, in the world. What are you doing to... Well, first of all, I'm going to ask a very leading question. How is the quality of the vendors you work with for the big IT companies? We're talking more about, you know, global vendors. You guys all know what I mean by that. So the Accenture, TCS, Vipro, Infosys type companies. And how is the quality right now? Where is it trending towards and what are you doing to improve it? Do you want to take that? Well, you know, as I mentioned a little earlier, the investment that we've made over the last several years has really paid off, I think, in the long run. So coming into it, we had great PHP developers. We had great... The team came from IT, so they had a lot of background in technologies that we weren't planning on using. But they didn't necessarily have Drupal experience. And so they really did start at the wrongs that you're describing. And over time, they've developed. And the downside of using an offshore team is that sometimes there will be a lot of turnover around... We've got a team of about 40 people. So the 25% range will come in and out fairly regularly. And so you're losing a lot of the knowledge that they're growing by working with your team. If you can keep that group of people and make that number go down so that there's more regular and a growth of experience, then I think that the quality of the work really shows. And they get to know the designers that they're working with on the other side and they get to know how your teams function and the quality of growth from there. I think we all know that when we're building large, complex projects, large, complex installations, one of the big challenges that you have on an engineering team is just integrating different points of view. So for example, once you've decided on an architecture, you don't need somebody coming in every three sprints and saying, hey, maybe we should completely rethink this approach to the architecture. And the challenge that we find in working with many vendors is that when you have different vendors, working with each brand, you end up having that conversation over and over and over again. So the challenge and the question for us is, are vendors good partners or not? It is, what is the rate at which we can bring vendors into an already existing engineering team that's already in full swing on a large, complex project? We have two vendor partners right now. We're doing a fantastic job of that. Core Kitchen's talked about EW yesterday. We're doing a lot of work with Acquia. And our decision to winnow down the list of vendor partners has been less related to how we found good vendor partners or not, but more related to how well are we able to integrate their approach to engineering to our own timing approach to engineering. As we continue to invest in our own engineering team and invest in the engineering chops that our own engineering team has to take on the increasingly complex, group-related projects we're putting in front of them, we're finding that also investing with our vendors along that same path is beneficial for us. It keeps us all on the same page. You know, for many people in the room, if you're here, it's probably because you have a global team, which means by default you probably have a big project that you're working on, which means that for people in this room, it's not just that we're thinking about how do we build against Drupal 8. Probably some other people in the room, like my team, are thinking about how do we build against Drupal 9 and how do we build against Drupal 10. And investing in our engineering practices alongside our partners is going to keep us all on a smooth path toward getting there. One thing I forgot to mention is we don't actually have an employee in our company that is our technology lead. So we have literally outsourced all of the technology within our consumer marketing group, which brings me to another point, which is that we don't have anyone to really do the knowledge transport from what we've... So we're entirely relying on this group to do that knowledge transfer. So ensuring that you have that built into the program and that when they bring on new employees within their group, whether it's offshore or onshore... I'm sorry. And ensuring that that is built into the workflow, hopefully that's an investment that that company is willing to make for you is critical to making sure that your velocity doesn't fail every time they bring on a new partner or a new employee. So actually maybe to quickly interrupt. From the audience, we have a pretty small group. Does anyone have any specific, any other questions you want to ask this group? All right, go for it. So I'll quickly repeat the question in case people can't hear. The question was that we're doing different geographies, different culture, different groups. There's cultural differences perhaps in India, in the U.S. specifically, mentioned around educational systems and the orientation of developers to their work. How do you manage those or overcome or take advantage of those cultural differences? Anybody? The one thing that we've seen is that there is a real hesitation we do use Indian developers. There's a real hesitation to push back. Pretty sure that's a well-known. Breaking down those, again, it's about investing as if they were your own employees. So going out for drinks, understanding their culture, their community, being their friend, it really opens up and breaks down that wall and opens up opportunities for them to be vulnerable and to really push back on ideas or be creative or incentivizing them to create interesting new technology within the format of what you're doing. So that trait you mentioned is... We see that in India. We see it in Eastern Europe as well. And I'd say what we've tried to do to address that is quite simple in just trying to empower people as much as possible and making it clear in terms of the scope of their role, the power they really have within their individual positions. We've found that in particular where we've had people who have been... We've hired in these locations who have then been focused on contributing back, whereas at the beginning they would partner with somebody at FISA every time they were doing something and it's really been a journey to empower them to be able to do that on their own. And when we've done that and we've made it clear what their role is and what their responsibilities are, it's gone pretty well if you just clear us in terms of what the role is and the scope of that. I wouldn't say we have a full strategy for it, but that's been our experience so far. Yeah, just to add to that. So I agree with what everyone said about our partners in India, for example. In Eastern Europe, we face a different challenge culturally in that those teams are very interested in contributing back to the platform or sometimes going a little off the reservation and custom development, so our challenge there is making sure that we have those teams integrated more closely within our own so that we catch those kinds of things before they get too far along and also that we foster those things in a positive way so that they are successful when we have folks who want to go that extra mile. So I've managed a couple of global projects before and for me, the biggest attraction to using Drupal in the first place is the fact that Drupal is a global open source platform. And what I find is that the engineering culture that you create on your team transcends local cultures to a great degree. So if, for example, you go into an Amazon office in Seattle or an Amazon office in China or an Amazon office in Bangalore, the engineering culture you find within those offices has much more in common with each other than what it may have with this local culture. And one of the best things about using an open source project is the basis for your entire platform is that by nature, people who are inclined to contribute to open source projects are people who are open to being independent, making contributions, looking for documentation. They want to step up and contribute. One of the things that I find I'm able to use is a pretty good filter, whether we're talking about Seattle or New York or Bangalore and hiring people is have you made a commitment to an open source project? If you don't have code that's available for me to take a look at, I'm much less interested in you as a candidate. So in any given local culture, using somebody's ability to be a strong participant in open source projects, particularly Drupal, is a really good indicator as to whether or not they're going to be a fit for the engineering team we're building. If you are in any given location, whether it's Seattle or New York or London or Bangalore, and all you've been doing is implementing Drupal on behalf of some big, nameless company that you've never actually made commitments to the community at large, probably a less attractive candidate to begin with. So for us using Drupal and one's overall commitment to the Drupal community at large, is a really good indicator as to whether or not somebody's going to fit into our engineering culture. If there's any big vendors here listening, take a note. In fact, you know, we've, I was meeting with a guy who leads the open source practice for one of the largest SIs in the world a couple weeks ago, and it was great to hear it. In the conversation, he said, you know, he said, what do we have to do to be successful? And I said, well, you know, it's a competitive field, there's a lot of players. And I said, well, here's my list of things that I want you to help with. One, I want to be able to contribute. I want to learn how to contribute to the community. Like, I want to get our people doing that. And we've never done it before. We don't know how to do it. We're going to have to do it here unless we've got, you know, top tier contributors who are recognizable. I think that's cool. That was really encouraging to hear. Things are going to change. Anyone else from the audience? Anyone else have any other questions or concerns? Yeah. What are the benefits of outsourcing work to, I guess you're talking about lower cost geographies, rather than just costs, what are the other benefits that can go along? As an engineering team to resolve. And what would have happened for us six months ago or 12 months ago is one would have worked on it maybe 12 hours. They would have gone home. They would have started up again the next morning. And instead what we were able to do for 39 hours, for better or for worse, was to hand it off successively around the globe until the, every bug was fixed to resolution. And that is an amazing thing for us to be able to do as a media company. Like, our customers and our audiences expect to reach us all the time. So for us to be able to be responsive, not only to our external audiences, but to our editorial staff. Our editorial teams are checking in stories around the clock. It's just as important for us to keep up our CMS as it is to keep up the site. So hands down for us. It's a much bigger benefit even than any cost savings that anyone might achieve by looking at using global teams. Yeah. Another benefit we've realized is, so we actually operate in 60 countries. So wherever we're, you know, outsourcing, we actually also operate. So one of the key benefits we've gotten is actually having developers in those local markets raise insights that have driven product requirements to improve the platform. So we can remain more informed about what's working well at market. And since they're on the ground there, they have the best insights versus someone saying in an office in New York. Sure. I have one word for that. Thanksgiving. Like seriously, Thanksgiving is one of our highest traffic days of the year. And it's not even just our US team. It's our, sorry, it's not only our Bangalore team that's in the office that day. It's our London team as well. And having those people who are available to backstop us when we're trying to eat turkey in the US is incredibly important. I don't know that other companies have more holidays than we do. Maybe? I haven't really noticed that. India's definitely got more holidays. Maybe people are just working. I think so at Aquia, this has come up this year since we really established a pretty big team there. And there's this sort of thing around, okay, which holidays everyone's taking and people in Aquia are like, it's Labor Day. Why are you making people work on Labor Day? I'm like, why are you making people work on President's Day? Because they don't give a damn. Not your President. Because they're going to take off wholly. Are you taking off wholly? No. We've been trying to figure that out. Are we going to make, you know, is everyone going to take all the holidays? But yeah, certainly the overlap is great. We have a lot of food. Like we tracked the Wally, for example, because of the food associated with the Wally. It's not a good food holiday. We don't really pay attention to our holidays. Sorry, Mike. It's not a strength of your culture. I mean, it's not an answer that you're going to hear, but our project management team is aware of upcoming holidays. It's communicated to the entire group, and we just make sure we're prepared and, you know, we try and reduce the amount of work during that period. And that's the best way to handle it. I think to the same point, it's one of the key advantages, right? It's not giving, we're at work on Thanksgiving. That's fine, it's not a problem. Same thing for Christmas. When the US and Europe are out, we have projects that are still running for other parts of the globe, and they can be taken care of by people in other regions without any problem at all. I think the thing that we find that can be more disruptive than holidays is as time zones change in different areas of the globe we're in, daylight savings or not daylight savings, it can dramatically change the overlap we have in time zones. And you might build a team in the summer where you have people in Brazil working with people in Australia, and that's kind of sensible, but in the winter it just does not work at all. So things like that we've learned that we didn't expect, and you build a team and go, okay, that can work, and a couple of months later, it just does not work. So that's one thing we found being more disruptive that you need to think about when building out these teams and people working across different regions. The question was how do you manage handoffs between different teams? So when one team goes to sleep or they finish work for the day, how do you make sure that Patan has passed successfully around the globe? We first had to solve the problem of how do we hand off knowledge between brands? So we moved from a world where each brand is standing up and maintaining their own brand to a world where a couple of other people on the panel, we have multi-site, we're using the multi-site approach of multiple brands running on the same platform. And we happened to be doing that as we were globalizing our team, so the need for documentation and finding asynchronous forms of communication was acute, so we were solving both problems at the same time. I don't know who else in the audience is using Slack. Slack has been, see, almost everybody, yeah. Slack has been transformed. Everybody has Slack, where I have two phones going right now with Slack on them. Thankfully, no outages. Everybody is on Slack. I mean, everybody is using email. Everybody is getting much, much better documentation overall. So we're finding that having to become a global team has also forced us to just be better at having intra-team communication on the local sites as well. But it was a big challenge for us. Yeah, so how does working with a geographically distributed team influence your development, deployment, sort of management, right? It's a question. So I'm doing it for the recording. I have to do this. You have to have a full continuous integration platform if you're going to be working with these vendors in this way. When we very first started and we had to build that platform out, it was the age-old problem of you would outsource a project and then a couple of days before you're launching the project you get sent a zip file over email of the project that's done and you go and try and deploy that and it's a complete disaster. So if you're working with people in different locations and you're not checking in with them constantly, having a platform where they are checking in constantly and getting the application working on the production like hardware, that's critical. So we've invested a lot in making sure those systems really work and they're truly available 24-7 so we don't have issues of teams not being able to push back to us. That kind of gives back to the overlap between the teams. We don't have so much of a thing with having to hand off a ticket from one team to another to be working on. It's more just having coverage if something comes up. So that means that the overlap is a lot easier. Guys that are behind you actually supports our Jenkins and continues integration environment for like one half of the day and if there's a problem for the other half of the day there are people in Europe and in Australia who could take care of that but that's critical if you're going to be having these vendors in different locations. That's a great call out. We're actually, we were late building our CI platform so it's not quite ready for prime time yet and so we do feel that pain when we have those types of handoffs. The way we cope with it is embedding our central resources into those vendor teams so it means joining their meetings twice a week to ensure that they are on the right track versus getting that zip file at the end of the month because we've also gone that route and it doesn't come together in a pretty way. Systems and infrastructure that will allow us to do everything from continuous integration to automated testing to the sorts of things that you take a friend when you're building on a really large platform at scale. We're four weeks in to our US team to be able to engage in CI and our Bangalore team to be able to engage in CI. We've had two teams, London and Seattle able to do that since inception and so bridging that culture gap has been an issue for us but I agree with Mike. It's 2015, you should be there anyway but certainly if you're running a global team you have to be there. I would actually, interesting to hear you guys are, when you took that question you talked about what's the tooling you use to protect yourself from breakdowns? What are the governance tricks that you do? What are the ethos behind how do you make sure that there's a connection and there's communication happening and balls aren't dropped? Yeah, it makes sense. I think there's a few different components to the question. I jump to the continuous integration piece because I would say that's the investment we've had to make in order to make agile successful. So when we moved to Drupal that's what we did to make that successful and there were communication methodologies that were put in place around that daily stand-ups and these things but related to that again jumping to tooling to support that people use JIRA or whatever tools they're using and one conscious thing that we discovered when an engineer came and joined the team he kind of made this statement that made complete sense which was after the code the data that's in JIRA in terms of the user stories and how we actually got to deliver that code that's the next most valuable thing on the project and when you outsource a project often you just get that zip file at the end you get nothing else and all of that knowledge is completely lost so that's really important number one if you're going to have a project sustained I think more specifically to your point around how do you engage with the business teams and these kind of things to be able to truly implement what it is that they wanted to implement a couple of things there first of all we have two like lead different lead roles that I have on my engineering team one is like a technical lead and the technical lead is some technical background but spends the majority of their time with the business teams helping them understand how they solve their problems using the technology and then they're partnered with a lead engineer who can push the technology as far as they can do so that partnership is really important I'd also get back to the the agile thing there as well the whole point of the what we're trying to get to when we implemented agile and the continuous integration environment was getting around that scientific method as fast as possible I mean this data on half of the software that people write is you know is never used because it's the wrong things built or whatever happens right right so if you can get around that as fast as you possibly can with like a technical lead going and showing the business team very very quickly this is what we've done people can actually actually react to that if you try and outsource a big innovative project where it hasn't been done before by going waterfall doing a whole bunch of requirements and then go building that you're going to set yourself up to fail you do the small little thing and get somebody to react to it then you can you're going to be successful you're going to build the right thing so it's a couple of things really investing in your tooling methodology to get around that loop as fast as possible and then depending on the type of project there's those two key roles the lead engineer and the technical lead that they can partner with the business they're going to get what they expect I would add to that so we have similar roles in our organization as well but in addition we've also found that we've been more successful in scaling communications through platform documentation so we used the Atlassian Suite and we've been using Confluence to build out documentation to share with our vendors what are the usage guidelines so if you're going to do something like creating a custom module whether some of the activities that come along with that if we're going to end up using it back on the platform and without that I don't think we'd be able to have those types of communications effectively because we probably have about 40 or 50 folks in our central team and we've got over 1,300 people in JIRA so it just it wouldn't be possible otherwise we've gone to the same model so we have a very strong technical lead and a strong technical lead with really high EQ paired together on all the major chunks of our project that goes a long way toward helping moving in with an expectation that the stories in JIRA should be clear anyway so if the stories in JIRA aren't clear enough or whatever tool you're using to start out with you're going to run into problems and so getting that discipline around making sure that the end user the stakeholder is taking the time to think through upfront what they need often times I find that product managers for example not at our company and other companies will turn out a lot of ideas very very quickly faster than an engineering team can implement them and when you move up the funnel which is something by the way that our product managers have gotten really great at when you move up the funnel and have the product managers putting in almost an equivalent amount of time thinking through what they imagine is going to be the end result and capturing that in the story and handing that off to engineering you get a much tighter coupling and you tend to have a better experience but there is one other thing we've done which has made a really big difference when we flipped our model on its head and we put all of our platform engineering and most of our platform engineering in Bangalore we did that with an expectation that we were going to double down in investing and having those front end engineers close to the brands in New York and London and having that really tight coupling between those front end engineers in London and New York has also gone a lot in way in cutting down the communication and speeding up that cycle of getting responses back into engineering team and making sure that what we believe in the brands is kept on track The last thing I would add is we not all of our projects but for we have a platform team very similar to these guys that is focused on building out the new innovative type of enhancements for our platform and we try to identify with the lean methodology and really chunking out the work and seeing getting immediate feedback from stakeholders on what every sort of piece of the project so the idea of getting a zip file of the final thing delivered to me in an email is truly terrifying and I can't even imagine how I would react to that so the idea of getting we work mostly with the existing platforms so just iterating on where we're going and having our UX and our design and marking stakeholders all involved in every part of the process super important I think we're just about out of time it's 11.30 so I don't know because it can take off if you want any questions I want to thank all the panelists first if you can please for showing up you guys are very cool very important big shot type people and stuff and thanks for taking the time to come out I appreciate that I think it's a lot of good insights we could probably talk about this for a lot longer and probably should more because I think we're all kind of figuring out the same lessons a lot of times independently without really working together enough on it I feel that's the case anyway I hope you guys enjoyed yourself and for me Jacob Singh pretty findable on the internet and I have cards here if you want to if you want to get in touch later and I'm sure these folks will stick around for a few minutes as well cool alright thanks everyone