 Cool. Good morning, everyone. How's everyone doing today? Good. Good. Is everyone excited after that first keynote? How good was that? Just a quick round robin. Is there any locals in the room? Any locals? Any locals? Brisbane, Brisbane, Surfers, Surfers. Cool. Good stuff. So how far away is everyone come? Over East or? Far and far away, far away. Cool. Very nice. Very nice. All right, so today we've got me, Simon, and James. We'll do introductions very shortly. We're going to be talking about how Flight Centre and Doghouse do outsourcing and how we partnership and how we make that work. There's about 30 to 40 minutes worth of slides. If you have any questions, keep them up here and we'll answer them all at the end. We might try out Google Slides question feature as well, which should be pretty cool. So we'll give that a spin. Take a seat. Take a seat. Cool. So who the hell am I? I am Simon. I'm a digital producer at an agency called Doghouse. Our room is just next door. And I've been in digital agencies for about 10 years now, about eight of those I was a developer and about four or five of those I was a Drupal developer. And we also have... I might steal that. Thank you. I'm a senior developer, Drupal developer at Flight Centre in the digital experience team. I have about four years sort of working with the company and sort of deal with our sort of say architecture performance and code standards. So a super quick intro about Doghouse, just so we have some context on who I am and what we do there. So we've been in the industry about 10 years. We set up in 2006. We have 26 staff, 17 of which are developers. So we're very developer focused. We have UX and very talented UX and very talented solutions as well. We are developer focused. They are spread across two offices. We have one in Perth, where a lot of us have come from today. And we also have one in Melbourne as well. So Force Flight Centre alone over the last year or so. We've done three and a half thousand hours worth of development, which is down to a very great relationship that we have. And on average in the Perth office, there's not many people when we go through around two cartons of beer, because that's the kind of people we are. So yeah, James is going to give a little intro about Flight Centre. Thank you. So just out of curiosity, how many of the audience here has booked with Flight Centre before? Show of hands? Awesome. So we're not just Flight Centre as well. We've probably been to this side occasionally. But we also have a few other brands just to give an idea of the scope of the things that we deal with. So Student Flights, Crews About, has anyone heard of Escape Travel? Us as well. Travel Associates. Travel Money as well, Travel Money Oz. And we also have international sites. But just to give you more of a scope about how we work in sort of a drooper world. I'm just going to skip in here. We've got quite a big code base. In fact, we have 80 sites on a single dot group, which for some of you might be a bit of an eyebrow razor. We see about 100,000 lines of code entering into our code base every month. There's a lot of removals as well, but that gives you an idea of how much flow we see throughout our code. We have about 160 custom modules. So we have a lot of custom setup for business logic, for performance optimization, especially given that we've got that many sites running on the code base. And we see about 200 pull requests a month. So we have about 200 pieces of work on the go in a month. Not at the same time, but it gives you an idea of the kind of features that we're dealing with every single month. And we have about 51 developers on the code base at a time. So that's including internal and outsource teams as well. So we've got a lot to manage. It's a lot more than dog eyes. Quite a bit. So I'm going to start talking about our team structure because that's quite important at Flight Setup. We usually have project teams, sometimes varying in size, but we have a designer, sometimes taking on both UX in the UI role, multiple devs, a BA and a team leader. Sometimes the BA and team leaders sort of merge roles depending on how the team's resource. So each of these teams sort of have a focus and goal. They take on multiple project after project, try and work instead of an agile short sprint method. Each one of these have different focuses. So one of these teams might be for platform architecture and site health, another one for performance. And there's a corporate team as well and a global team at Flight Center. So with these different teams, we have these sort of fluctuating goals. The business is sort of a bit of a fluctuating basis, you can imagine. Travel industry can be a bit full-on sometimes. You have different products open up, different suppliers having different flights cheaper. There's a huge deal on. It changes quite often. So how do we deal with, say, changes in the business? So like, if business comes up with, we've got a new product line, what do we do? We've already got all these teams already working on their projects. We need to spin up a new team so that we can deal with this product line and actually deal with it in an agile fashion. But then comes the question of resourcing, which I'm sure many of you have been through before. And there's two possible options we can go through in corporate land to begin with. And these are the more conventional methods, so you can hire someone new. Or you can resource from one of your other teams to bring up this new project. Because sometimes business sees something new and it's like, ooh, shiny, this is our priority now. And that can sometimes shuffle away from your other teams. So this obviously has some pros and cons. Some of the pros are bringing on a new hire. Obviously you're bringing in innovation, some new ideas. They could end up being a long-term asset to the team. And ultimately, it's a good investment for the future. But there is some cons. Sorry, I flipped the wrong slide. And that's one, finding the right person. Has anyone here dealt with a new hire before and sometimes it hasn't worked out? Yep, I see a hand up at the back there. It can be problematic. And then the training and outskilling, there's a lot of time. Also in corporate, we've got a lot of systems. We've got a writer passage just to set up your environment. So if you survive that, that's 50% of the way there. But then we also have misfires. And that can be, if someone comes on for a week, they actually had a better offer. Weekend, they're already out. We have to search for someone else. That can be a bit of a headache. Then there's also the resourcing from inside the company. So the plus side is you're bringing on standards. You don't have to upskill them, but you're crippling your other project. And that's where outsource is a bit of a silver bullet here. What happens is now we have, if we bring on an outsource team like Doghouse, we have a whole team of skilled developers that are good at working together because team dynamic is one of the hardest things to get right. Especially when you've got all those different roles like designers, devs, BA. They can be process aware. If we've worked with them in the past, which we have, they've built up a knowledge base and they're familiar with our code base. And so we can spin them up and down as we go as well. And so that's really good for those fluctuating ideas that come from the business. So now we're actually able to have a team and resource to then meet that business goal. So now we're outsourcing, which is pretty sweet. But the catch comes in is to how do we make it work. It's one thing to say, well, we've got a team resource, but then where do we go from there? Because in actual fact, the business goes, okay, cool, but we ask for this. So some of the things that we need to maintain obviously is good code quality, efficiency, reliability, meeting those business needs and obviously not crippling our platform in the process. Because we've got a big amount of things going on at Flight Centre with all those different brands and sites. It's a high-risk platform. So I'll first give some context about our project structure. So some of these next slides will make a bit more sense. So in the outsourcing, we have a team of developers and project leads. And they will work externally. And we've got an internal team member, project lead, usually project manager, sorry. And they'll coordinate with the outsourcing team. So communicating from internal stakeholders, managing the project, make sure it's hitting all the business requirements and ticking the boxes. They may sometimes also bring in other designers and developers just to help funnel that project into something that is in line with, let's say, our design ideas, our scope, also our architecture and our stack. Because it can be a little complicated sometimes. So that's over there, Simon. Thank you. Cool. So let's talk about talking. So one of the main things that we realise along this process is that communication is one of the key things behind making this work. So bad communication can result in many, many things. Obviously one of the key things is an architecturally unsound solution. We've also got incorrect solutions. So you might have done something really fantastic, but have you actually solved the right problem? You might have solved another problem. And inability to use the platform. Now this is very vital in Flight Centre. The Flight Centre websites are humongous. We didn't quite realise how big they went until we got into this. There's a lot of systems, a lot of modules, a lot of different ways of doing things. And having that understanding within the business is vital. And having that communicated to you is also vital as well. So what actually is bad communication? So over the time of doing this in previous history, we've learnt ways to do things and not to do things. So one of the things that is across any business really is communication siloing. Whether you've got offices across the country, across the globe, wherever it may be, when you turn around and have a quick chat to the developer next to you, to your lead developer across the room, and say, oh, how do I do this? Maybe I should do it this way. And they go, oh, okay, cool. Right then you've made a decision and someone over the other side of the country has absolutely no idea what you've just talked about. So some of the ways that we've solved this is through documentation and chat and assumptions make an ass out of both you and I. So one of the things that we do is we have a chat tool. We have a centralized chat tool, which I'll go into in just a second. And it's all about breaking down walls. So the outsourced team, us and Flight Center, we are one. We're a partnership. We work together on things. We solve problems together. We drink together. We're a partnership. We might as well be the same organization. So some of the things that help us do that is Slack. Now, I'm a big believer in Slack. I've wrote a blog article about this and how to adopt Slack. So Flight Center have their own Slack and we join that Slack. I'm going to keep saying Slack quite a lot here. And each project has their own project team, their own project channel so we can join that and see what's going on. There is also a release channel. So whenever there is a release done on Flight Center, it gets posted up there through one of the bots. And that also gives an incentive for people to review the code and see what everyone's doing, whether it's us and other outsourced partner or Flight Center themselves. We also use Hangouts for daily catch-ups, which I'll talk about later on. And we also use Jira and pretty much the entire Lassian suite of tools. We use Confluence for an internal documentation, as do Flight Center. We use Bitbucket and Flight Center use GitHub, but same, same. So the other thing that we come across is knowledge hoarding. Now that's kind of like, all right, I have this piece of information and that's my piece of information. I don't want to tell anyone. That's my trade secret. But us, Flight Center, we're all the same trade. There are no trade secrets. So not having this big umbrella of yourself thinking, I don't need to tell anyone, it would be good if you could tell everyone. And the system is complex. Now, the Flight Center system, as I've already mentioned, is extremely complex. There's a lot of documentation around that. And we've also created our own documentation around that as well. And that gives everyone the beauty of when they join the project. They know what's going on. There's no days and days of, oh, how do I use this module? Should I use this module? Should I write this line of code? Et cetera. So we break it down. We work as a team. We give knowledge wherever it is needed. And we also, because we're a team, we take ideas. If Flight Center have an idea of how we can change a process or how we should develop a little bit better, we'll take that on board. And equally, if Flight Center have an idea that are, have you thought about doing it this way, they'll take it on board. We're a partnership. It's not, they tell us what to do and we do it. We, there's some liaison going there. Because best practice can come from everywhere. Flight Center have been doing this a long time. We work together to make the best practice. So some things that we like to do is clear documentation. I spent a very long time creating a process flow diagram, which is the most mammoth thing I've ever seen in my entire life. But it clearly defines what to do. So on JIRA we have a few columns. And what to do when you move between each of those columns, who to talk to, who to assign it to. Flight Center have this really awesome command tool called Flow, which centralizes all of their Git commands. So rather than saying Git commit and doing all of the things that you need to do, you do Flow commit. And it does all of the commands that any developer would do. So you know every developer is doing the same thing. And keeping all that documentation in-house to make sure that when we upskill, they do it as well. Face to face is one that we love to do. I don't know if anyone knows, but Flight Center just moved to a new office in South Bank. And on the floor that James is on there is a slide. It's very Google, but it is awesome. So yeah, I'm hopefully going to do some pictures and stuff on it, maybe a blog post, but we'll see how that goes. And they'll also come to Perth as well. We've had James visit us in the Perth office. And it just breaks down that you're not just some text. You could just be a robot. There's a face there. There's a personality there. Maybe they're into the same thing as you and you very quickly build up a bond. And finally, constructive criticism. James is actually really good at this. So Flight Center, he's not one of these people that's really shit, like to delete it. He'll actually say, OK, this may not be so good. How have you tried this way? It's not just because we're outsourced, doesn't mean that you tell someone what to do. You help them do it. Ultimately, the code goes into Flight Center's code base. It's their product. It's their code. So help each other to get better. So an agency worth their weight will create documentation. If you're outsourcing and this agency is not creating documentation, you might want to start questioning what they're actually doing with their time. We have a very big documentation code base and it helps onboard new members. And it helps build some trust as well. When Flight Center says, oh, we have a new project, it's humongous as we're going through at the moment. And they say, oh, all right, we need to start next week. We can start next week. We can start tomorrow because we have that documentation build up. If you have an agency and they say, oh, can you give us a few weeks because we need to onboard new people, maybe they're not the right agency for you. All right, so through bad communication, that's what you get. And then through good communication, you solve those issues. So you're able to consult with internal developers and build the right solution. Now that's developers, designers, Flight Center have designers within their own team. They have UX, so building their own IAs and stuff like that and making sure that the work that we do, the wireframes that we do, work within the stuff that they need to do. We also have the ability to readily communicate with project managers. So project managers, we will be assigned a project manager. And our developers can speak to them. Our developers can speak to other developers. They can speak to designers. There's no barriers there. Obviously, a project manager sometimes firewalls really dumb questions, but nine times out of ten, it speaks to the developer and see how we go. And obviously the final one is the platform. Getting to grips with that platform is always difficult and communication always helps solve that. So thank you, Simon. So the next really major thing in making this work is process. As a big company, we've got a level of accountability in making sure that what we put out as the digital aspect of it is sound. It meets the business requirements. It's efficient. It's not going to damage any of our other products. So in this, we have to define a little bit of a process that... And we've knocked this out several times, had a few changes to it, and this seems to work for us. So I'm going to separate this into two parts. So doghouse up the top and flight center down the bottom. So let's start a project. Usually we get something that comes in from the business, usually something with quite wide scope, lofty ideas, as business does. No real limit there. But it's then having to bring in those stakeholders and start developing that idea So we start having the inception of the actual project itself. We start defining some brief rounded, some goals, a bit of a scope. And it usually happens internally just to begin with, just to give it direction so we're not in meetings, out of meetings, having lots of stakeholder discussions just to try and find out what the business actually wants. But then once we've got that idea, we start communicating it to our partners. And that can often go through levels of refinement because there's often new ideas, different ways of doing things, different technologies that we haven't thought about. We're very, very used to our own stack. And as you can see with that many custom modules that I mentioned earlier, we're very familiar with modifying it, but we might not necessarily be thinking about new ideas. And this is where some of those new ideas and exploration can come on, especially from outsourced guys as well because you guys touch a whole bunch of different things. Beyond what flights and it does. And those can sometimes spark a lot of new ideas. So when scoping those details as well and communicating with the outsourced team, our project manager may bring some of our devs in, different stakeholders, designers, just to help funnel that discussion in the right direction. So I'll pass on to Simon. All right, so we've got this brand new project. Sometimes it's fluffy. Just we want a new web page on our IK call. What do you want? So what we do is we go and define that solution. We haven't done any work here. We're just confirming the solution. You need to make sure as an outsourced partner that you're delivering what the client actually needs. It's no different to any other client. So we've got the task and we're going to break it down. We've got the project and we're going to break it down into tasks. And then what we do is again, no different to any other project. We start estimating those tasks. And through that process, we start working out how long each one is going to take. What more information do we need? Is there some documentation missing? Is there some new knowledge there? Sometimes Flight Center has some new ideas coming in that we need to bear in mind. Start to use React. Start to use a new platform website where everything's just a white label and they rebrand it. So trying to take all of these things into account when doing the work that we need to do. So we're going to start some work and we're going to just draw down into a task. So when working on a task, it's really quite important that we don't cut off that discussion, that communication that happened earlier on. I think we mentioned about chatting and that inter-team communication. This never stops. And this is where it's really important to bring on to go through a task. You'll find that there's things that you come up against and problems, there's sometimes architectural issues, sometimes design issues as well as just testing out your solution. And this is where communication with the internal guys is really quite important. And our project manager helps coordinate that a little bit but also just having that open communication tool of Slack. So throughout this process, I mentioned earlier that we use Hangouts. So every single day we have a Hangout. A daily stand-up. If anyone's familiar with agile methodologies, I can't say that word. You know exactly what I'm talking about. These have to be a maximum of five to ten minutes. If your stand-up is going longer for ten minutes, there's something greater wrong with the project. A stand-up is just for talking about what you did yesterday, what you're going to do today and if there's any blockers. It also gives space for everyone to understand that every single day there's a partnership, there is work going on, and it gives the perception that every day I have to do something for Flight Center and Flight Center every day have to do something for Doc House. And in terms of who owns that, it's always the outsource partner. It's the outsource partner job to deliver something. It's not Flight Center's job to chase an agency to see how things are going, what's the status with this, when are we going to get this? It's our job, my job to make sure that they understand every step of the way how things are going, and any outsource agency should be doing that. So throughout the development life cycle, both through our already established processes and some help from Flight Center, we've established a means of reviewing code, both reviewing code and functionality. So you make sure that the code that you're delivering is both safe and also that you're just proud of the code, right? That your code is going into this great website, you need to make sure that you're happy with what you're doing and also that ultimately your reputation is upheld. If you commit bad code and all of a sudden the whole entire website is taken down, obviously Flight Center have their own means which we'll go into shortly to make sure that doesn't happen, but then all of a sudden everyone's saying, oh, that outsource agency screwed up this one line and took our whole website down. You need to try and avoid that, so make sure you have your own internal processes to make that, to stop that happening. However, QA is not always required. Sometimes there's moments when there's just, there's an extra line at the bottom of the file or there's, the if is slightly wrong. Sometimes just code formatting and stuff like that, you don't need to go through the entire process again. You have to apply some common sense to this and obviously that's a communication issue. Making sure that you communicate, hey, I've got this issue. Does it read to go through the entire code review process again? Obviously code review takes time, you have people doing things and sometimes code reviews can take half a day to a day. Does it really, does something need to be delayed that much just for something that might not be so small? So on the flip side, we have reviews internally as well. We have to do this to obviously say to our business, hey look, we signed off on this, we can put it out onto our stack. And also it means that we test it like we go through it and review it against our knowledge of our design, our development, and we can properly break it down. So we do it in two steps. We have a functional design review and we also have a code review. And we do try to provide a lot of feedback through that. And as we mentioned earlier, this is one of the really key things is building constructive knowledge. So not saying, no, this isn't right, try it again. Or even things that you think you might have mentioned before. It's about remembering that these guys are building stuff on your code base. And it's that ownership of then going, these guys are a part of our team. We've got to build up their knowledge base so that they can keep building better and better solutions. We do that with internal devs. We do that with these guys as well. So once those requirements are met, so we've checked to make sure it ticks all the boxes for business, ticks all the boxes for sort of architecture, we have to sort of own that deployment as well. That's just the nature of our stack. And usually in the corporate world, that's the nature as well. There's a bit of control when it comes to websites about how it's deployed. So we take that on. And once it's deployed, we go into a review process. So that's both internally and with our partners as well to make sure that it's on production. The business case is checked against. We check the architecture, the performance of the site, making sure the platform is working as it's intended. And once that's all sort of signed off and any feedbacks are given, then we can go through and start retro-ing the process. So in the agile world, retro-ing is pretty important to make sure that your process isn't really creating bumps. It can do with parts of the process or even just the beginning of the process and how the things are signed off as well. It's about making this whole thing a lot smoother. And we go through iteration and iteration of this. And it's really important to make sure this timeline, because there's a lot of steps, works efficiently. And once we get that working efficiently, things move a lot quicker. So we really try and aim down at stopping repeating issues. So we've talked about a lot here. So I'm just going to quickly recap. So you've got your task, you've got your estimation done, and you're going to start that task. You go through design, you go through development. You'll be doing stand-ups every day. And we have stand-ups across the whole project. So in that one stand-up, we'll be talking about many different things. We have a backlog of work and we work through them. If we're working on two projects, we'll be in the same stand-up. We then do our own code reviews, our own QAs as well. And with the help of Flight Center, we've worked out a really cool way that they have a dashboard on JIRA where anyone that works on the Flight Center project goes to and they can see if there's a code review waiting and they'll pick up a code review. Anyone can review code, right? You don't need to know the system in its entirety, I guess. Knowing the system does help to a certain degree, but if you know PHP, you know Drupal, you know what you're doing. We do QAs, so for everything, we write QA steps and we've, again, we've got documentation on how to write QA steps to make sure that they meet. And, yeah, at the end, we go for a retro every two weeks to make sure that we've captured everything that we've done wrong, everything we've done good to make sure that we don't have any repeat offences. So there is a little bit more to this, though, more than just getting good code. So innovation. We visited Flight Center a few months ago and we demoed a piece of software called Sketch and it kind of blew their minds, really, that, oh, my God, there's more to life than Photoshop. As it happens, Flight Center now very rigorously trying to adopt Sketch and that's partly because of the knowledge that we've imparted on them. So being an agency, we have the luxury, I guess, of sometimes being brave, sometimes we fail, sometimes we learn new things of how to do things and we can help Flight Center do that. Equally, Flight Center, sometimes they have their own technology group and they have their own learnings, which they can feed back to us. Flight Center now trying to use React and we have to, and it's a partnership trying to work out how we do that, how Flight Center do that. So just some quick mutual benefits. So rather than using local agencies, we just have a quick flight across. We can quickly spool up new projects because we have the team there, we have the knowledge there to quickly do things. Knowledge sharing between the agency and the client. The Flight Center have a lot of devs, they have a lot of brains there and Doghouse have a lot of projects so it's good to match those two together. We have a diverse talent, so we don't just have developers, we have BAs, we have UX, we have to help them work stuff out. And yeah, improving both parties code and process as well, so Flight Center have helped us improve, we've helped Flight Center improve and of course every businessman in the room knows about contractual obligation. I have a notification which has got rid of her. Cool, so finally, how do you convince your boss to do this? You need to be outsourced or be outsourced. So you need a use case. You can't just go in there and be like, I want to outsource or we need to go get an outsource partner. It doesn't just work like that. You need a business case. You have to think at a business level. You need to have a problem that needs a solution. So on the idea of going along to outsource, you then need to really convey to your business what the situation is. So you've met capacity. You need more devs. You usually low on time in our scenario and the market's moving rapidly. So you need the fresh ideas as well and you need a team that can work together and you also need a team that's process aware because we've got a lot of those and they know our stack. That's pretty important as well because we have a lot of uptime. So hitting those points and making sure these tick all those boxes, that's really important to business. So from our point of view, from the agency point of view, maybe you have gaps in your schedule not through lack of work but sometimes projects have a review process with clients and you have some time to fill. Maybe long term you're thinking maybe this is a good idea and maybe you have the processes already in place internally. Doghouse already had a code review process. We already had deployment processes. We already had documentation processes. So it kind of makes sense that maybe we can step into this big corporate world. So a $10 an hour developer is not outsourcing. They do what they're told. Nothing more, usually less. They'll usually give you the code in a zip file or something worse. There's no process there. There's no accountability. There's no project manager. There's no time frames. There's no hangouts that just make me a module and you'll get a module. That's not how outsourcing works. Outsourcing is a partnership between client and an agency. So on a part of our action plan here, just reiterating why do we want to make it happen. So you want to analyze the demand because you're going to need to know what you're filling and so you need the resource. And as I mentioned, you're low in time but you have that still that has pressing business need. And you've got to really break down that spin-up time. How much it's going to cost is an alternative to bring people in and new hires and resourcing from internally and what it's going to mean to your current projects. And so then you start outlining those potential benefits that outsource can bring. So one of the key things as well is innovation. We've been at flights and we've been doing this for a while and sometimes we get caught up in the limits of our platform. We just go, cool, we've done this before or this is the way we're going to do it and we just keep building the same thing. And what it means is that eventually we start building up trailing technical debt because we just keep building on top of something which actually it was efficient when we started but it's not now. It doesn't actually meet that growing amount of sites that we have. So innovation is really important. Just as a little thing, hopefully we can give out the slides after this, there's actually a hidden puzzle in here. So if you download the stack here and take a look at this in the notes it's a bit of a puzzle and it has to do with this exact point. So hopefully if any of you guys download it see if you can work it out. Cool, so going back to what we've already shown you is can you do it? Does your business allow you to do it or does your business allow you to make room to do it in future? It's not necessarily that you have the process in place but can you build on the processes to allow this to happen in future? So just some final tips, we're nearly there. Just going back to that puzzle, it's a really cool puzzle about who can see what and how to communicate who can see what without communicating it. It's really cool, so yeah, when the slides go up have a look in the notes section for that slide and it's really cool. So just some final tips. The client needs a gatekeeper, both an agency and a client needs a gatekeeper and an agency needs a PM. That's to ensure that the entire outsource code is good, it meets scope and actually does what you need it to do both from our side, has our developer built what we need the client to do and has the agency built what we've asked them to do. You also need process and to be transparent it's not about we made a mistake let's just quickly do something else it's about talking to them and saying but we messed up how do we resolve this as a group. You also need to allow the employees to communicate directly. Now that doesn't necessarily mean that every single day, every single hour you're having a conversation it's just about have you exhausted all of your internal knowledge to fix this problem? If yes, have you spoken to the internal project manager, me or whoever it might be within your agency and seeing has anyone come across this problem before? If not, how about have a chat to this developer? And within each client there will be certain people that are specialists in certain things. So yeah, thank you very much for watching and paying attention. So we've got about 10, 15 minutes. Is there any questions? Yes. Thank you. Now I'm still seeing the same as a threat by internal developers to these kind of companies. How do you go about allowing those to use? I can probably answer that one. So, especially for Flight Center we've got so many different needs that the business has and we've proved ourselves as being reliable and we've actually had a few scenarios where projects have been outsourced completely and then they have no awareness of the tools and the systems that the company has. And so what happens is what's built has no context to everything else your company owns. It becomes a little difficult after that point to keep that model and structure happening. So we're there to really provide some of that integration but also to help build and expand. So they have a high level of trust in us and then they trust us to go and find and bring on extra skills that we need. So it's about really keeping that trust internal as well, understanding that you have a unique relationship with your business and nothing's going to beat that. And it's always about showing that you represent these really tight integrations with the rest of your platform as a business. And then one of the other things that we find helps and I know that sounds really stupid but just that human factor, just go and meet the people that you're doing the work for. Go hang out with them, go see how their internal processes work and just demonstrate that as a business, obviously there is risk because there's always risk but how you can mitigate those risks and have a plan put together for, say you know what, stuff will go wrong, it may go wrong, but this is how we're going to solve it and that's how we find the awesome trust. And we always want to say yes as developers. We like saying yeah we can do that. And you know sometimes resource, time, allocation, we just can't do that. So we want to be able to keep saying yes to our business but also be able to expand that need and we need partners like Doghouse to make that happen and we need to trust them. Any other questions? Yes. Yeah, I think so long because we see Council, James, at Doghouse the only agency you work with or do you have other partners? No we have other partners as well. Do you balance that in terms of other separate projects or often that can be tricky when you have model agencies living in different places in the project? Definitely and I think that comes down to understanding your outsourced team. One of the things, the core strengths that we found with Doghouse is they're really good at projects and teams. They work well together and they execute really well together. Some of our other outsourced partners are really good at our constant tickets that come in and work. So it's about understanding those two different needs and finding out which outsource is better suited for those needs. And we really discovered that we have different strengths there and we can rely on Doghouse for those big projects and those really meeting tasks and they're really good. Yes. I have two more questions. All right, cool. I'm sorry about the agency, how do you support any of your work? I suppose there's flights in a phase and if there's any kind of risk mitigation there, is there a proper overnight or do you need to schedule stuff with them? So not to give too much away, but Flight Centre, they have a support retainer as like any other client would and they essentially, they have a set amount of hours that we are contractually obliged to deliver. Once those run out, if they run out, we say, hey, these are run out, do you want to buy some more or maybe you need to maybe have a project and we can do an estimation for that and that's how we're now working. So they'll come to us with a project and we'll estimate it like a new client almost, an existing client and we'll say, all right, there's two weeks worth of work there, there's six weeks worth of work there and we've scheduled that in. If Heaven forbid Flight Centre were to drop us overnight, there's no issue there because we've got other projects coming in and we've scheduled those around. So there is risk there and look at some stage, Flight Centre does account for a large chunk of our billables so we've gone back to Flight Centre and to be transparent, we say, right guys, we need a roadmap. So what's the business doing over the next 12 months? What resourcing do you need and opposed to going down a traditional retainer route, we look at a project. So we can actually map out what resources we need from UX, PM, DEV and that reduces the accountability. But you're right, it is risk and you can't work in this high-end corporate world without sort of taking on some business risk. One more question. Yes. How do the relationships start? Probably in a pub, I imagine, if this relationship is aimed to go by a pub. I'm not actually sure how we... an email. There you go. As easy as that. Just send an email to Flight Centre and they'll pick it up. Again, more than likely. More than likely. Yeah, definitely. Cool. All good? Yeah. Just a quick grab-up. So just a heads-up, there is something going on, it's called BOF, a pair of feathers. Everyone knows about it. So make sure that you have a look at the whiteboard outside. There are different topics. If you're interested in one of those topics, you just show up and it will be a conversation. It won't be a presentation. You could contribute to that or you could ask your questions about those topics. Thank you. Let's go to the next panel. And just as an aside, me and James are here over the next two days. So if you don't have any more questions, just come and grab us. We're more than happy to have a chat. Thanks. Cheers.