Scott: Welcome everyone to episode two of the digital difference podcast, where we talk about all things digital in today's companies.
So, hi Oli, how are you doing?
Oli: Yeah I'm not too bad. How are you, Scott?
Scott: Yeah all right, it's been a busy week as it goes, to be honest but, yeah glad to be talking to you again.
Oli: Yeah absolutely. Okay Scott, so today we're going to be talking about combining internal teams with agency support, so why do you think you've chosen this?
Scott: Yeah so I thought this would be a good topic to talk about at the moment. So agencies are obviously brought in to a lot of big organisations, most of the time but you know we're talking about kind of any team size here, and really, the problems that can arise when you combine an existing team with agencies, and you know often agencies are brought on for distinct pieces of work that perhaps a company isn't quite prepared for. In that case actually I think it's a lot simpler in many cases, you know, they can kind of roll with whatever structure they have in place and just put it into a kind of void in the company almost. But when you are combining an existing team; so that could be an existing development team within the organisation, an existing design team, or even beyond that you know, it could be an existing marketing team say that you're bringing an agency in to do some branding work for, I think when you need teams to work together there are probably some things that you can think about. Hopefully, we'll cover those off today - how to make that work really well for both sides.
The other thing as well is that as projects get more diverse and more complicated I think that companies are often looking for outside support for agencies to provide more kind of specialism around their core services. So, I'm thinking for example a development team that might be doing a mobile app and they may be bringing some specialist support from an agency for perhaps the marketing launch of that, or even it might be better than that. Say, for example, the security around something like that so again I think as time goes on we will be probably relying more and more on bringing agency teams into existing teams.
Oli: Absolutely. I think it's getting increasingly important as well to do that especially with companies with a lot of resource, but also cutting resources in certain areas. I find it more productive to actually bring in these external teams, so definitely I think I think we're going to be seeing that a lot more so that's that's great that's a great starting point there.
Oli: So Scott, you've prepped a few points today that we're going to be discussing for this podcast and we're going to start with the first one that you've written down here and it's "have a good idea of the goal from both sides". So do you want to go into a bit more detail with that one.
Scott: Yeah Oli, so having a good idea of the goal of what the agency's being brought on board to do I think is really what I'm saying here so this is especially important to consider within an agile context which so often are you're looking at agencies bringing in into existing companies. It's fine I think to apply agile principles and keep things fairly loose and pretty well iterative towards a goal but I think that goal needs to be really set from the start. It's really important to avoid things like scope creep for the agency point of view, and also from the client point of view. But also especially when you're combining teams I think that it becomes much less black and white around what the goals are. Having a clear definition of what the the goal is for the agency to provide alongside the team they might be working quite closely with, it's really critical right from the start just to set expectations and boundaries and get all that up front and I think in terms of how to achieve this meeting in person is obviously the best situation for these these types of things. Although I think that can be pretty well effectively done at virtual meetings as well but the key thing is to get things down into a document ultimately you know there should be pretty clear goals set in the documents and whether we can refer back to timing time time again throughout the project and yeah as I said I think you've got teams working so closely together it can become a lot less black and white as to who's delivering what. Especially if there's lots of overlap and people working day-to-day with each other so again having that document to go back to is pretty key in this.
Oli: Absolutely, and I think clear communication is probably the best thing here from personal experience as well working with outside teams I know what my personal experience before, we've had many times where there's been a mix-up because there's been the external agency that we brought in thinking that we're doing half the work when we've actually thought no we're hiring you to do this whole job this is just us just to check over what you've done and then you're handing it over, and then there's been this massive discrepancy in terms of what we thought they'd be delivering. And then, you know, you've got trouble.
Scott: Yeah, totally, and I think actually the initial meeting you have to talk about goals can actually be a great place for both sides to really talk about what they might be able to achieve and gain some goals from that.
Oli: Okay, so that brings us on to our second point that you wrote down, which is "be clear on dependencies". So should we go into a bit more detail on that one then?
Scott: Yeah, for sure. So I think what I'm saying by dependencies here really is which side is going to be dependent on the other for certain things. For example you might have a development team in-house that's developing, say, a piece of middleware and an agency developing an app for example. And obviously in that case the agency can be pretty dependent on the middleware piece being ready and available to to work with within a timely manner and often what you'll find with these types of development pieces is that they are happening concurrently, and it's pretty key to make sure that both sides are aware of the dependencies they have - that they're both causing, and that they're going to need. I mean development is quite easy in this case - we can use tools like mocking, mocking out services before they're ready, to at least preempt some of that work. And there may well be other things, but for example if you're looking at marketing and a design team, they may not be able to achieve that without deliverables given to them so it's being pretty on top of that from the offset really. And I think these types of things, if the project is thought out well enough, you can actually figure a lot of these dependencies out from the start and get them at least on the roadmap so they're delivered in time, and people aren't waiting on other things.
Oli: Yeah, and one thing that you said really important there is like dates and about like deadlines and things like that. And I think it's so important to be really clear on that before you even go into any sort of build or anything like that. Especially if you're a design team, or whatever you're planning to do, because I think the worst thing you can do is to give a false estimation of what you think you can deliver so if you give a shorter time, for instance, because you want to make yourself sound better. You know, let's be honest, all small agencies or anything like for all digital agencies that come in will want to impress and say yeah we can do this amount of work in this amount of time but if it's not viable. It's pointless trying to do that, and what's going to happen is that you're just going to make yourself and your company and your team look bad at the end of the day. So I think it's really important to be honest and upfront with how much work you have, what resource you need, and how long you are going to need to deliver it.
Scott: Yeah totally. The agency side for me is actually, I think the easier part of this. Again, like you said being honest and upfront on what you can actually achieve, I think it's pretty key. The side that's probably harder in this is the company that's bringing the agency on board. I think what I've seen in the past is often that the deadlines or timelines have pretty much agreed on both sides, but due to external work being factored in some of those dates can slip internally, if they're not given the importance that they need - if they're not given the status they need. You know, these are important things ultimately, it's the company that's paying for the time of the agency in a lot of cases, or at least on hook for getting things delivered by the agency in time. So if it's for a product launch for example so it's pretty important for the companies bringing the agencies on to actually keep honest with their deadlines as well and make sure that they're not going to be blocking certain things for the agency
Oli: Yeah absolutely. If they're not and if you find that you're having trouble with the company, and with their communication around the deadlines, the timelines, and them not being clear with what it is; you need to be honest with them, be upfront with them and get an answer. Again it's not just affecting their time, it's affecting your time. It's a collaboration, it's not a one-way street. I know they've hired you to do a job, but equally they need to provide a certain amount of information for you to complete that job, and if they're not pulling their end, you need to say. Don't be afraid to say, I think that's the key message as well. I think a lot of companies go in thinking, okay, this is our employer so we will do whatever they say and if we are behind, oh we'll have to pull out the hat and stuff like that. It shouldn't work like that, both companies need to be working together collaboratively. I think that's the main important thing, especially when you're being clear in the dependencies
Scott: Yeah, this actually takes me nicely into my third point which is having just enough project management. Project management is key to getting both sides working really well I think. Often that needs project managers from, or at least people acting like project managers, from both the agency and from the company side. I think just like we've said in the past couple of points, where you need to have a good idea of the goals, and actually keep people honest with dependencies and make sure that we're spending time in the right place. Having a good project manager, or at least someone still taking that role, on the company side is crucial to be able to make the agency effective in this way. So if we think about where they are likely to be involved, I think it's probably worth thinking about the different phases of work. The level of involvement is probably different depending on those phases. I think that's one of the busier times for the project management need.
So again having someone on the customer side, the company side, to really make sure that we've got a team in place internally that can facilitate work, and also help the agency along with their piece of involvement. But actually as well, from the agency side, it can be really effective especially when we've done these types of pieces of work before, to have someone who knows who to get ready and around the table at the right times from the agency side, to actually get work done. I think when the work's getting done, which is almost the next phase, project management isn't necessarily needed as much and actually I think you can almost get into the micro management side here which can drag both sides down a little. Then it probably starts to ramp up again on the handover point, and we need to make sure that we've got enough people again around the table together, and talking effectively to hand over whatever is needed to the client at the end of the day.
Oli: Yeah absolutely. I actually want to go back to your actual point in itself, just enough project management. That in itself is such a key point, because on so many projects you can find you'll have three or four project managers, that they call themselves, and you don't know what they're doing. They are taking a certain section of the project itself. They don't collaborate with each other very well. Someone tells you one thing, someone else tells you another thing. Before you know it, going back clearly to your point before, the dependency dates are all mixed up, timelines are mixed up, and it's a whole shambles. So if anything, sometimes you can get a project where it's over project managed, and there's not a clear leadership role in that. I think that project manager role is a clear leadership role, and you need it in every single project. Especially when you're collaborating between both sides. So when you've got for instance a project manager with a big company that you're working for, and then the project manager within your team, they should be collaborating together. They should be communicating well, and that message should then be delivered down into the team, and they should be picking up on the leadership roles and talking. If you have got more than one on each side I think it's overkill really, and it's just going to over complicate it. That's where you get problems.
Scott: I mean you and I talk about culture a lot, and I think actually the leadership part of that project management you speak of, that is really important. They can actually help some of the relationship between the two sides, factor in well into the piece of work. I think equally though, and you were definitely mentioning this, is that time is super important for the agency. As the company that's bringing the agency on, you're paying for their time essentially. You need to make sure that you're not going to be dragging them into, especially if you look at the corporate environments that we have, where it's so meeting heavy. It's important not to necessarily drag them into all meetings that we have, just because that's the way we do things. Equally I think on the other side if that's the case, agencies should be totally within their right to speak up. The project manager, whoever's taking that role, might be the perfect person to leave on that front really, and give the feedback constructively that our time could probably be better spent doing the work for the most part.
Oli: Absolutely. Okay, so I'm interested in your next point here, and that's co-locate. So can you explain what you mean by that.
Scott: Totally. So co-location I don't think is the thing that we see a lot within companies to be honest. However, there are situations where internal teams are almost bolstered, that's kind of all the agencies brought on for. So it might be that they still brought in the specialist work, but they're expected to physically be embedded within the team. Now at the moment obviously, everyone's working from home within this virus situation we're at the moment, but when people do start going back to offices for the most part, I think co-location does make sense in some situations.
So if you're doing a lot of the same work that other people are doing, for example you might bring an agency into almost helping an existing team, better their ways of working, to maybe just help with the work that they're doing at the moment, because it requires some specialist input. I think actually co-locating might make sense in that instance, especially if the team is already in one place together, and literally have extra people just in the room with them. It's worth noting though that that can bring problems that you need just to be aware of. For example scope creep can be pretty prevalent here, and actually having a physical split for the teams might be a good thing for setting some of the boundaries, and just keeping expectations on the table. The other thing to be aware of of course is that teams, although it might make sense theoretically to have all the people under one roof, teams might just naturally have a different culture. Bringing two teams together might not make sense for shorter term projects. I think for the longer term actually, this is probably a pretty good idea and can shape things up a little bit for the company, or even the agency in some situations. In that situation, it's probably imperative for the team that's being brought in to actually adopt the culture of the client team. Especially if it's a type of thing that's expected to have a long running effect after the external team has gone, otherwise you'll find that the shaken culture might just be a temporary change.
The other thing to bear in mind of course, is that actually a lot of agencies work with multiple clients, and are typically set up to work well remotely anyway. Actually having them physically in the place where you are, might not be the best way to get them to work. They may have good practice already that works pretty well for a lot of other clients. So it's worth just considering that when you're when you're thinking about this option. I think in some instances, especially when there's hopefully a welcome challenge to the norm of what you're doing, getting other people in the room with you might be a pretty good way of working in some cases especially to speed along those probably medium to long-term projects, that require really close collaboration with each other.
Oli: Absolutely Scott and I want to go back to what you've said about the culture, because I think that is really important in terms of small agencies working with big companies. I think that it's not just small agencies either, you have a big agency working with a big company but I think it's when the big company brings in that agency, I think with co-locating especially, it'll only happen within small teams. So small teams from that agency coming in. You'll find that with massive projects where the whole agencies working on this one project for a big company, they'll probably stay in their own location. It will still work, there will be a lot more communication across teams because it just be financially viable for these people to travel. A lot of the time you'll find these agencies will be in the south, some of these big companies could be north or vice versa. So it doesn't always work. But I think that co-locating more comes into where people bring in a smaller team. Talking around culture as well I think that's very important, because a lot of the time these big companies want these small agencies to work around their brand. Work around how they like to work. I think that bringing those people into the business themselves gets them to understand and learn the business, you'll probably find they're having a couple of days onboarding of how the business works, and what their values are. That in itself is really important to get an understanding of the business before we start working with it. For me and my experience, I've only really seen that within smaller teams that get brought in from agencies. I've never seen big agencies come in as a whole. Usually they would work in their own areas every now and again. When a big agency does come in as a whole, it would only be for a day or so. It wouldn't be working on site permanently. So I think for me, from my experience personally I've only ever seen this with smaller teams from agencies coming in to work with bigger corporate companies.
Scott: Yeah. I think that's for sure the norm. I mean, I have seen myself a sizeable agency on board a team for a client. Again that was for this longer term project where they were really trying to upskill and hopefully change the internal team, in terms of ways of working and other bits. That worked pretty well, but I think for sure it's a case-by-case basis here, and I think co-location is one of those things that's worth just having the back of your mind as an option. It's another tool to go to here, but it's only going to work in certain situations.
Oli: So this brings us on to our next point then Scott, and that's regular reviews with the right stakeholders. A really important topic here, so should we delve into a bit more.
Scott: Yeah, this kind of goes back really to the first point we're making. Essentially having a good idea of the goals from both sides. Having regular review sessions of course is always a good idea. I think sometimes under use to be honest, and you'll get a good amount of interaction at the start and a good amount at the end. This is super important when teams are working together, and actually having the right people in the room is something that's often not thought about too much, but it's again really important. So I think as the main company it's probably important that you make a priority to bring the right people along to any review sessions. By review sessions I'm talking about maybe design reviews, for a company that's providing design work, development or demos, those kinds of reviews for a development team. Maybe for branding people, it would be something along the lines of early insights and feedback sessions. So those kinds of review sessions. The one thing, although I think they are given importance from the agency side often, I think the one thing that I do see is the right people not necessarily being there on the client side when you're looking at this. So these review sessions really should be good touch points, and along with the kind of day-to-day collaboration, they are a chance for both sides to really step back, take a look, ensure things are on the right path. You can only really have that interaction if the right people are in the room. So again it should be a priority for the main company to bring the right people along. Also as an agency, I think they can go a long way to helping facilitate that. So ahead of any review sessions, let the company know exactly what's going to be taking place in those sessions. Give a good idea of what the context is, and hopefully that should help with them making the decision on who needs to be there.
Oli: That's really interesting Scott. One thing that you said that's really stood out for me, is about the client side reviewing and you're not having a lot of the right clients. But I also think that you don't have a lot of the end users in these reviews either. A lot of the time your clients just want a result, and they're not too interested in terms of the diversity of your end user. That can always be a problem. Especially when it goes live. Whatever you've done, whatever you've created, goes live. You get the feedback or the initial feedback and it's not always what you wanted. Then the client looks to you as to why that's not the case. So I think these review sessions should always have the end user in as well. I think it's really important to have that end user in, because then you can get honest feedback as to what you're designing or what whatever you're doing at the time. I think for me, that's really really important. I think that has saved me a lot of hours in previous projects myself, just bringing in that end user.
Scott: Yeah totally. Having the voice of a customer there is key and that might not be the customer but it might be someone who knows them well enough. For our agencies as well, where they're taking on work they may not necessarily always have a 100% concrete view of what the end customer exactly wants. The company's the best people to be able to provide that information, or at least have someone there that can challenge things, and can see things from their point of view. So yeah they're definitely a key stakeholder in some of these conversations. One other thing as well to mention is that often when teams come in externally, you know we hate to think it's there, but politics can be a factor. Bringing people along for the ride in these demos and reviews can be pretty helpful in making sure that that relationship works well from both sides. I've seen lots of places where external involvement can be seen as a threat, especially to some companies who are a little bit more embedded and more old-school. Having someone who can really or bring those people into review sessions to make sure that voice is heard and that they are actively involved in the work. Even if it's an external team doing, it is pretty helpful in mitigating some of those downsides. Of course when the teams are working a little bit more closely as we're discussing here, I don't think that's too much of a factor but it certainly can be when the teams are working on pretty different things.
Oli: I think it's also really important to establish key stakeholders within this. It's all well and good if you as a small agency, having new stakeholders from your client side is great. Obviously you want to deliver your work to as many of these stakeholders as possible, and you want as much feedback as possible. But there is also a point where there's too many stakeholders. I can speak very honestly about having so many projects, and working within a company where they've had 30-40 stakeholders on one project. That's when it can get messy, because too many people disagree. Some people are higher up than others, some people are on the same level. So like you said, it comes back to politics again as to who is going to win this battle between stakeholders. And what you will find is that you are caught in the middle doing lots and lots of work that you don't need to be doing, and in the end of the day the result really doesn't differ. You are just making changes to the work, or the content that you produce, that doesn't really need changes. For me actually just trying to establish who the key stakeholders are, and making sure that you get into the room with key stakeholders, and not any of these other people and let the internal battle stay internal within your clients business. Just make sure that your key stakeholder manages that. That comes quite nicely back to your project management as well. As to having too much project management or just having enough project management. Again just having that key stakeholder, which is probably going to be your project manager, to manage that situation on the client side.
Scott: Yeah I think you're right. That's why I think project managers are pretty key in maintaining these relationships and keeping them working well. I think in modern teams, quite often the PM role is somewhat overlooked and maybe, especially when we're bringing an external team on board, can be forgotten about pretty easily. But it's pretty crucial to getting this right. As you say, this is a great step in making sure that the right people in the room, or that task can be given directly to someone who's owning this project, and making sure that we're running this effectively.
Oli: Absolutely, and you'll find that if you're working with regular reviews, you'll probably both be working within an agile way anyways. So you'll be having regular scrum meetings, usually every two weeks where you'll have your scrum masters really be your key project manager. They'll be running those meetings, and it'll be just updating every two weeks as to where the progress is. That is really important as well, because it will make sure that those regular reviews keep you all on track, and make sure that not too many people are getting involved. If there are so many opinions, it cuts out which opinions are important and which aren't, instead of having all of these opinions come in at once, then it comes to the delivery date, and you've got so many different pieces of content and you just have a mess of work really. So again I think this works well with working within an agile way.
Scott: Actually I think this probably brings us nicely onto our next point which is providing good documentation and standards. If we start with the standards first, I think ways of working definitely fall under that. Actually what I've seen quite often is exactly what you're saying, which is that both sides tend to have a good process of review. The worry comes when you're combining a team that might have a good idea of this already, but then embedding that into one that works a little bit more traditional let's say, it doesn't necessarily have these reviews in place all the time. So standards are crucial to set out from the start. I think they're one thing that can really be influenced by both sides. Agency teams have the benefit of seeing a lot of good and bad being spread across multiple clients, and seeing what does work or tends to work really well and what doesn't. I think suggesting those, especially in those early stages or even along the way, if there's a good opportunity and something's cropped up, I think giving feedback on what might help both sides work more effectively in the relationship is a really good thing. It should be encouraged really. In terms of the ways of working, I mean getting a little bit more specific if we're thinking about development teams, things like coding standards. The design teams design standards, or design patterns, or a design system they've got in place already. They will be useful things to hand over for sure. Also things are a little more tangible than that, things like what type of outputs are expected from both sides, what's the quality of those, what's the format of those, how do we hand their design work over, and how is that facilitated. Getting those across in an early stage will just make it much smoother down the road for both sites to work well with each other.
Oli: Absolutely. As a designer myself I find a lot of the time that you go into a company and you immediately need to understand what their design standards are. A lot of companies will have their own brand. A lot of companies will have their own style of how they want to design things. A lot of the time you'll find that you'll create really good content but it'll be shut down because it's not in keeping with their design standards. So I think it's really important that when you go into any company to first understand their visual branding, their visual design standards, only speaking as a designer myself, as a coder I'm sure there's other standards that you would follow as well. But it's for me personally, and for any designers out there, is to understand their visual branding, understand their design standards, and really look into how they format things. Because you can go and create a great piece of content, but they'll shut it down straight away if it doesn't fall within their standards, and before you know you've wasted two, three weeks worth of work coming up with all these great design ideas, and they say no we don't like it. It doesn't, it's not in keeping with our formatting. It's not keeping with our design. So I think that's the first thing you should really do is actually understand the company, and understand their brand and design themselves.
Scott: Yeah, and to be honest I think for good reason though as well the work that an agency would be brought on to do will have to live in the ecosystem that's already in place for the most case. So actually endearing to standards is unfortunately the way it has to be. That might not necessarily be a bad thing. It's good to certainly have some structure around what you're doing, especially when you're just being dropped into a piece of work. It's good to have a lot of structure around one.
Oli: It's a great starting point. It's definitely a great starting point. You'll go into a company and they'll say design this. If you haven't got any brands, you haven't got any design standards, you have no formatting to follow, as a creative it's great because you can think freely, but also it can be a bit daunting because you think "well, where do I start". So yeah it's a great starting point. But like you said, really important because again it makes the content timeless. Especially if you design it within a way where you can just edit it. then you can hand over your documents or your files after you've created them. Just make sure you work timeless for them as well, so that they get a good quality piece of work that they can continue to use. Both sides are happy then. The Clients are happy, and that's what you want at the end of the day.
Scott: It certainly makes life easier. I totally agree, especially when we start thinking about teams working closely together. Having those standards that both sides agreed to from the offset, is important. The company can make that really easy by thinking about how those standards are going to be made clear to the agency. So if it's about having documents ready, then that's great. It might be about giving access to some sort of system internally, that provides some help. It might even be someone internally, going and explaining their systems for a day to the agency for some of those long-term projects. So I think getting across those standards in a clear way is important. The next logical step from standards it's kind of a standard anyway really but his documentation. This probably applies less to creative work, might apply to setting the boundaries, but as an example here development teams are going to probably need to document some of their existing API's for example that the agency might need to look into. This is somewhat overlooked typically when you bring teams close together, because what happens is communication tends to naturally work this out, but it can go a long way to shortcutting some of that conversation and the time spent in figuring that stuff out. If you just have good documentation around your existing code, or existing design systems, or existing brand, and being able to come over. Maintaining that constantly anyway is probably a good practice to keep going, it brings a lot of benefits beyond just letting other people know what's up with this, and it will certainly then make it a much easier task when you're getting a new agency on board or a new team on board, and having to up-skill them with this. It certainly saves time when you're then bringing a new agency on board or a new team on board because you've just got things ready to hand them. You don't have to spend a couple of days getting stuff ready for what you've already got in place.
Oli: Cool, brilliant. This brings us on to our next point and my favourite point, something I've brought up a few times already during this podcast and that's established communication which works both sides. So let's go into a bit more detail about that Scott.
Scott: Communication is obviously pretty key to making teams work effectively. Even more so when those teams don't know each other too well, and haven't worked together before. So a few things to think about here. I think firstly probably the biggest one is having open lines of communication. This is getting of course easier and easier as companies are adopting instant messaging, or even good email practices by default. So having good open lines of communication, knowing who to contact and when, and being able to get responses to any questions you might have from either side in real time almost, is really key. Especially in the early stage project when we're still working a lot of things out. You'll find that conversation probably starts dropping off as work gets done. Especially if teams are in slightly different areas. This probably applies not only to the people that are doing hands-on work, so developers and designers, but actually of course we're then talking about people like project managers, testers, stakeholders, and getting good cross communication throughout those people will be important. Knowing who to contact I think as well that's another thing that's often overlooked. When teams first come on board, the introductions can somehow sometimes be pretty quick depending on the onboarding experience, but knowing who to contact on the other side is going to be crucial just to make sure that you you know who to go to for one, but also so that you can communicate any updates or changes effectively to anyone who might need to know about it.
Oli: Yeah absolutely. I think that for me again this is my favourite point. I always bring up communication. I will continue to bring up communication, because I think it's the most important thing. For me, communicate more than communicate less, is the key point that I'm going to say. It's very simple. If you don't communicate, things just don't work. You'll never get a good relationship with your client, or with the stakeholder. There is no excuse not to communicate now. There's so much technology out there that's available to all companies. Most of the time it's available for free as well for smaller companies. For large companies you'll find they've already bought this kind of technology on board. So there's no excuse not to use it. I think something that I've seen a lot is people are afraid to communicate with their stakeholders. They're afraid to talk too much because they think they're bothering people, or they think they're bothering their stakeholder, they think the stakeholders are too busy. No question is a stupid question. I know that that gets said a lot, but it isn't just say it if you're thinking it and you're questioning it, just say it because it's going to save you so much time down the line if you ask that question before you start doing any work. Even if you think it's a stupid question it probably isn't. If you don't ask that question and you go ahead with what you think might be right, you get down the line and it's turned into that butterfly effect in a sense where this little problem is snowballed into a massive problem. Then you're going to be worse off than you are if you just ask the question initially. So my advice is to always, always, communicate. No question is a stupid question. Just keep that channel of communication open with your stakeholder, with the key project manager from your client side, key project manager from your side, and make sure that that communication is continuously open. Like I said before, there is plenty of technology that is available for you to communicate with people. Teams now is super important I think to most companies. I think most companies have adopted it. I think that there's so many different ways of communicating, there's no excuse not to. It will save you more trouble.
Scott: I think alongside that real-time communication though, it's important just to have a bit of a think around how many meetings, and what cadence those meetings are at will work well for both sides. This might be something that you'll need to develop over time, just based on the relationship. But we've already covered a few, you know having things like good review sessions regularly will be important but how regularly they will be would depend solely on the project and the teams as well. Having things like goods progress update reports as well, and that might come out in a report, it might come out in a kind of daily stand-up, but that might be overkill for some as well. So it's worth just having a good idea of what works and playing that. That might come from either the company already having some good structure in place that they just need an agency team to fall into. It might also be the agency that has a good idea of how to work with clients, and can help the client understand the best way to work. I think one other thing that you mentioned, Oli, was about feedback as well. I think you kind of covered that in your communication piece there. Having a good channel for communication and honest communication and feedback, is going to be pretty important to make sure the relationship works but well for both sides, and actually help to improve things along the way. A good way to do this can be with retrospective meetings. Getting everyone in a room together really talking about the phases just passed, and hopefully what's pretty fresh in the mind still, having a good system in place to provide feedback. That might be through anonymous feedback or post-its on a wall. It might be through just a big open group discussion and having someone facilitate that. Having those honest communication points will help to soften some of the rough edges that will always be in place when two different teams come together. It's really hard to predict what it's going to be like, which is why these retrospectives and other meetings are so important.
Oli: Yeah, absolutely Scott. I think that like you just said, honesty is the best policy really. Okay Scott and that brings us onto our next point then and that's utilise outside opinion. I think that feeds in quite well from our last point actually. Again it's that kind of bringing in that communication. So should we talk a bit more about this one.
Scott: The point I was trying to make with utilising outside opinion, is that bringing an outside or an external team into your existing company is just a really good opportunity to get some fresh eyes on things, and get some fresh perspective. So especially when you've got a team that's probably well embedded and doing things as they always have done. Getting a fresh perspective on things like ways of working.
Oli: Yeah, absolutely Scott. I think it goes back to a previous point that I was talking about earlier. It's about the key stakeholders and about having that end user stakeholder coming in. I feel like that's what can tie in quite nicely with this, because again that can technically be outside opinion. I know you're talking about it from an agency side of your point of view sometimes, but also from an end user point of view I think that it's really important to get that opinion. You can get too wrapped up in a project and too many people get wrapped up in the outlook of this project and how it's supposed to look, and how they want it to look, that it might not actually be the right thing at the end of the day. All it takes is one person to come in and say a couple of points that will completely throw the project off course, but in a good way. I think that's really really important to actually have that outside opinion, you can get too wrapped up in your vision of the project and that might not always be the right way.
Scott: Yeah absolutely I think as an agency as well, it's always a good idea especially if you're walking into a solution that's been pretty well laid out as opposed to a problem that needs solving. It's almost always relevant just to challenge that. Even if it is just asking a few questions lightly, but normally using an outside perspective is a good way to find alternate ways to solve that problem. Especially with an agency that might have worked in a similar space or with other clients, it can be a great opportunity just to probe some of that. So I think from an agent's point of view it's certainly always useful just to just provide some of that challenge. One other thing to think about as well is that, whilst we've been talking a lot of this around at the start project and thinking about the solution, it can equally be useful on the wrap up to potentially have something from conversation from both sides around how things could have gone better. About how ways of working might be improved for both sides, and especially if the relationship has been pretty open and honest from the start. There shouldn't be a forced thing, it should be a pretty natural conversation to help both sides mutually.
Oli: Yeah definitely, and it's really important to get feedback from any project you do because that's how we grow at the end of the day.
Scott: I think it's always worth taking outside opinion with a little bit of a pinch of salt, just because they haven't always got the full insight. But for sure, for the most part outside opinion can certainly give you a new perspective on things. You should always take the opportunity to at least take something on board I think.
Oli: Okay so that's been really insightful today I think. So should we just wrap this up.
Scott: Yeah for sure. So I think the one takeaway from this is there's definitely a lot of things you can think about as to how your team might work best with another team. Whether that's through needing to give some key output to them, or whether you're going to be working day-to-day embedded with their team. Those things can make a big difference.
Oli: So I guess what's left to say today is thanks Scott, for your insight on this today it's been really really interesting discussing combining internal teams with agency support.
Scott: Yeah, it's been good to think about.
Oli: Yeah absolutely. I'd just like to thank all of our listeners as always, without you guys has kind of pointless us to doing this so thank you for doing that. We're still getting some of the admin bits ready, so we'll have the email addresses up ready soon. But for now keep an eye out on our website. As always these episodes are bi-weekly, so please tune in in the next couple of weeks and thanks again and we look forward to the next one.
