 Hello. This is Successfully Integrate Teams of internal and external developers, so hopefully you are in the right spot and are comfortable. I'll get started now. My name is Meg Ponkett and today hopefully I'll be able to provide you with some insight and possible suggestions on how you can work in a team or project manager team that is not just made up of in-house people. A little bit about me. I'm a senior front-end developer at Volunteer.net. I have about five years experience specifically managing and working with mixed teams in a developer capacity and so internal and in-house development teams are being inundated with requests for more and more work. These are development teams at large organizations and medium-sized organizations and groups that are finding that they can't support the amount of requests being made for new apps, new web properties, products, integrations and services. With this influx, it's even difficult for them to maintain their current properties and services that they already provide and because they're overwhelmed by the sheer number of responsibilities and properties that need to be refreshed and new features that needed to be added to existing applications, they most of the time do not have the resources to feasibly implement the work. So they then need to supplement their team or department in another way. So here are some situations when organizations decide to hire externally. They need additional resources. They don't have HUD count or budget. They need to supplement their internal team with a missing skill set or if there's a lack of expertise for a new product or service and if they're unable to find suitable local development talent and also if remote full-time work or telecommuting is not an option. It could just be that project development needs to move faster or they need a specific service like consulting, external project management, design, analytics, etc. So what do I mean when I say a mixed team? It's really a development team that consists of members that are not all employed by a single company or organization at the top level. So how does this affect project management? I believe that managing mixed teams provides a unique but not unusual set of circumstances in talking to people. A lot of groups are experiencing that they are not only or are no longer just working with an agency and having them do all the work. They're really trying to work with the people they have in their organization along with the people that the agency or vendor provides. So mixed teams can certainly successfully deliver a product or project. They just need to work together to accomplish the goals of the project in a different way than a strictly in-house team might. These teams do have the same goals of an in-house team like completing work on time, coming in under budget and making the stakeholders happy. The only difference is that they have some added challenges. So positive, possible positive outcomes for projects of mixed teams are that the project can finish ahead of schedule or on time because of increased velocity. The work could be of higher quality because of the expertise of the developers or project managers that you've brought on. They may have previous relevant experience in what you're trying to build and the project can finish at or under budget as the people who are not on your in-house team can switch to other projects when they're not allocated or resource to your project. Some cons though, this mixed teams can mean more work for project managers or scrum masters or team leads. Building trust and reliability, which are both fundamental to achieve success, is harder to accomplish with a mixed team. The project can take longer than expected because you're dealing with a lot of different resources and then the work quality can take a hit if the project is not ruined or it's rushed or untested. And if your project is close to being over budget already, hiring more people definitely pushes that budget over. So before we discuss what can go wrong, let's talk about preparation in an effort to maybe avoid some of these things. So I think as a project manager or scrum master, you're situated in such a way that with the right preparation, you can set up your team for success. So in order for internal and external individuals to work well together, I think that in-house teams need to be invested in the idea from the beginning. So it's likely that the external individuals that you're going to be bringing on are experienced with working with mixed teams due to the nature of them being at an agency. But your internal team members may have not worked already with people from an agency or developer. And so if, for example, an internal team member doesn't really feel that they want to make the effort to work well with external or temporary contractors, that can pose a very large issue for you later. So getting them ready is great, and if you can build enthusiasm for the idea, that's even better. And so I would encourage including your existing team members in the agency selection process. So a lot of times when an organization or company is going to start working with external people, it kind of happens over here, and the development team doesn't have a lot of say in who or what or when it's going to happen. So getting your team on board with the idea and working with vendors or external developers from the start of the process can be beneficial. And you can even ask your team, like, what roles do you think we need to fill, who would be best suited to help us with this new project, and so on. You can do some research with your team, request references, ask for recommendations, examples of work, case studies, ask to see work from the agency that is similar to what you might be trying to build, and you can even request recommendations from that agency or vendor's previous clients. And I think if you also ask to meet with the people who may be working with you from the agency, you can ask them what project did they recently work on, how long have they been working professionally, in what ways can they add value to your team, and then allow your team members or select set of them to review the code of the applicants if you're hiring specifically for a dev role. And I think that this increases that team buy-in that you're trying to build. So once you've narrowed down some options, ask your team if they've worked with the agency before, if they know anyone who's worked with them, and then for Drupal-specific work, you can look up the company on Drupal.org because you're trying to review and come to some sort of consensus about who you're going to go with. So just in summary, investment from your internal team plus preparation equals a strong foundation. You want to set your team up for success, and you also want to set expectations that the internal members will be collaborating with the external developers. Like they're not just going to come in, take the project away, and then all the stuff is going to happen, and no one will have any say. You're building the idea that it's going to be a collaborative effort. But then there are pitfalls. So I'll go through some and then quickly review the main ones that I've seen in my experience. So pitfall is a hidden or not easily recognized danger or difficulty. So number one is over-resourcing the team. And this may seem a little strange, but an over-resourced team is one that has excessive or unnecessary resources, especially one that is overfunded or overstaffed. So having too many people on your project can actually lead to an inferior result. And so if you start accepting or bringing on additional developers that are offered to you because they're available from an agency due to your timeline and deadlines, even if they're not needed, that's going to add some complexity to your project. Likewise, requesting developers with skill sets that duplicate skills you already have on your team without enough work to cover all of those people makes things a little bit more complicated. And then keeping on developers that you aren't able to keep at capacity due to the ebbs and flows of your project makes the team quite a bit larger and more, that means more work when you're managing them. So pitfall number two is neglecting to leave room in your budget for additional costs. And these costs can be things like bringing vendors on site for kickoffs, big meetings, and product launches that travel on the onsite accommodations and meals need to be billed to somewhere. So that's what I'm talking about, leaving some room. Also if you're having a long term onsite arrangement, like you need to take into account the commute costs, again, housing meals and incidentals because you're having those people live where they're working. And then you may need to improve the external developers tech stack to match what your in-house developers are using. So that could be hardware, software, licensing accounts, which I'll get into a little bit later. And then if you are bringing on people from outside of the country you're where you are, you'll have to get some temporary work reviews for international vendors. So you need to leave room in your budget for these types of costs. Pitfall number three is filling to allow time for additional communication. And I know that communication is a big thing that a lot of us struggle with, but maintaining the vendor relationship can take more meetings, more calls, more check-ins, and that's additional project management overhead. So regularly communicating with the vendor side management about the project takes time, like this update emails, communicating changes and decisions, coordinating between multiple vendors, that's all added time. The extra communication and feedback with the vendor's management when things aren't going well is also an additional communication cost. And negotiating the ongoing terms of your arrangement will, as the contract ends, will need some extra massaging and probably some extra calls. So external work will stop on the end contract date if you don't have a new agreement ready. So it's really important to start these discussions early with enough lead time before that end date. And then it can also be justifying the cost of adding external developer time to your upper management or stakeholders. So that can result in extra meeting time that you were anticipating during your week. Pitfall number four is attempting to save money by hiring less experienced people. So if you're signing on with developers who may be less experienced in order to save money, that can end up costing you more in the long term. Their hourly rate may be lower if they say you're going to learn some things from your team and like get up to speed, but that might mean extra time for them to complete tasks. They may not be able to identify problems early. They could be less confident in promoting great solutions and or conversely overconfident in promoting a flawed solution. It could take more revisions to get the work 100% right and you could have that work done again by a more experienced person later if you can't just like figure out what's going on. Generally, you'll have more questions coming to you about the requirements or if things are looking the way they're supposed to, like with more explicit instruction. And this all requires you as a project manager to dedicate more time to documenting and specifying tasks so people aren't left guessing. And last my pitfall number five is adding more developers to a project that is behind schedule. So if any of you have read or heard of the book the mythical man minds essays on software engineering. It is a book on software and project management by Fred Brooks. The central theme is that adding manpower to a late project makes it later. This is idea is known as Brooks law and it's presented basically in that signing on too many resources at once in order to get work done faster on a late project instead of ramping it up will cost more time, money, effort, etc. So you can think about this as onboarding and resourcing per person multiplied to an already late project. So this is just a quick summary of those five pitfalls resource the team based on the work that you have and need them to do already budget for unexpected costs allow time for extra communication hire the right experience level for the work and add and remove developers deliberately from your project. Okay so those are things that can go wrong but most of the talk is about how to identify things in your organization and then some team building that you can do to make your internal and external developers work together well. So issues can arise on these mixed teams due to the fact that the external developers don't have the same organizational exposure as the in-house developers they haven't been working with you for a long time they may not know for example how the politics of higher ed play out and so they're kind of just coming on to the project and with the desire to help you but they need a little bit more context. So these are my suggestions on how you can onboard new members to your team whether they're external or not. So these developers will not necessarily be familiar with your organization or industry and with that in mind it's helpful to bring people up to speed during that onboarding process. Excuse me so if you leave adequate time for onboarding or the training when I mean when I say onboarding I mean the training time needed to bring new members up to speed. If you leave adequate time then you're really setting them up for success so if you cultivate a culture of documentation in your project not only will that help people get to know what's going on then you also have a resource going forward and a strong set of onboarding documents helps external team members and new hires in general have a great integration experience and so another thing I like to point out is introducing the external members to your team as though you would introduce a new internal hire. So that only lets people on the team know who it will be joining them but it makes them feel like they're part of the team and not just some hired person that's going to be writing code. You can explain any acronyms that are widely used in your organization and similarly define or clarify any internal jargon and what I mean by that is special words or expressions that the team uses and it's also helpful to explain the hierarchy of your organization like who reports to who and additionally if there are changes in the hierarchy it's critical to update the external team members promptly so if they had a contact with one person and they're not there anymore that they know what's going on. So defining project roles and responsibilities this is critical especially on larger and multidisciplinary teams. It's important to make sure that the role each person will play on the team is clear so you don't have overlapping role responsibilities and define who is responsible for what so who is the overall project lead, who is the scrum master, who is the release manager, so on and so forth and maybe these things seem obvious but if they're not then it helps to make it clear from the beginning. You can delegate the management of an external developer or any contractors coming on to other employees on your team that aren't yourself in-house and that can save you time if you have a large amount of responsibilities as the project managers on the project but assigning that responsibility to a team member who's not expecting it can cause issues so they may not know that they need to keep that person busy and assign them work or they may not have the time to check in with them regularly and review things while additionally getting their work done so you just want to make sure that if I'm paired with the front-end developer on the in-house side that we both know that and we're going to be checking in with each other and that she's going to give me work and I will keep her updated on what I'm working on so before developers start work it's helpful to get them set up with whatever they'll need to do their job so that means providing necessary accounts and granting their permission granting them permissions where they need it so this is a very dense slide but just some examples of things that if you can get them sorted ahead of time make work progress a lot faster initially so that can mean email account access to any sort of document services you use any project management software chat accounts SSH keys to servers VPN access all these things kind of make sense but fall through the cracks when you're starting to bring new people onto your team things like giving them grant github permissions to your projects software licenses and if you're going to be having the external developers come into your office think about getting them set up with the building that you work in office access keys or badges id cards and then any security clearance training and of course a desk or workspace and along with that is optimizing calendars and scheduling because this can get very complicated as I'm sure you know if the entire team is not using the same calendar software it's possible to double book meetings for people to miss meetings and so on and so forth if you ask for and note the external team schedule holiday vacations and then communicate those dates to your team and then also similarly share your team holiday vacations it clears up who's going to be working when and why if they show up to the office no one's there it's happened so it's also nice to let the external team members know if you have a holiday whether they're expected to be working or not you can make sure to add meetings in the calendars of people that need to be there that doesn't always happen and then mark individuals as optional if possible and I'm very sorry if like all of this seems obvious but these are just things that have happened and cause issues with projects getting completed on time so you can also share any type of organizational office expectations you have because it may not be obvious for example we work from home on Fridays so please also feel free to do so would be a great way to let everyone know what is going on or we bring in lunch on Tuesdays and we eat together and learn so that way people coming in will know that they will be encouraged to participate with your team building or professional development time so let's get into resourcing and resourcing both internal and external developers is challenging keeping everyone tasked and unblocked on a large multi disciplinary team can be complicated and I have some ideas you can preserve the allocated time that you're paying for and what I mean is that sometimes people will rotate external developers on and off the project quickly on short intervals and every time you do that it adds more time to environment setup onboarding ramping up time and energy from you and the rest of the team so if possible you want to set yourself up in a way where you're starting with the developers from the agency and they're going to work with you throughout the end of your agreement might be mindful of not allocating developers beyond their contract that can cause issues and that means like reconciling their time against how much time you're going to be paying for and then also in the beginning when they're starting to work with you if you can assign clear and straightforward tasks that don't require a lot of background or context of the entire project initially that will help them like get warmed up in your code base and with how things on the team work so that they feel like they're productive and that they add value to your team early on and if you are resourcing to be a fast approaching deadline as I'm sure we've all been in that sort of scenario before if you can figure out what work is in the external developers wheelhouse and assign it to them when possible that means that they're going to be getting that work done really quickly because they already know what they're looking at and they're just going to get it done and you want to give the long-term work to your internal team members in circumstances like this whenever possible because you never know what's going to happen and you just want to make sure that you're setting everything up in such a way that it's not going to cause problems lit down the road if someone was working on a huge migration and then they're not working with you anymore. Just being pragmatic about who's doing what at this stage and focusing your internal members on the highest priority or sensitive tasks like be it security or what have you whenever the skill sets align in such a way it's it's better when a stakeholder comes in and is very motive about what's going on if you can say the internal developer that you know and have seen in the face of before is working on this problem to address it as opposed to having this person that they've never seen before and haven't had the opportunity to get to know yet so kind of um creates a little bit more comfort for people who aren't necessarily in your day-to-day team happenings so let's talk a little bit about team dynamics and as a project manager or scrum master you are in the best position to impact the dynamics of your team specifically being clear with all members on start and end dates time and availability so for example D will start on June 1st and will be working with us through the end of December or we have 30 hours of SAM's time for the next four weeks you know these things as a project manager and you're situating everyone on the team in such a way that they know what's going on and can adjust the dynamics of the team accordingly no and that also prevents surprises later on so fostering the experience of a cohesive team it's imperative to set the tone an example be an example of how the team will function as a unit the external developers do have an extra layer of management and responsibility to their company but you can still make them feel like they're part of the team um so that means create creating and follow a set of processes that work so maybe what was working for your in-house team before you brought on people isn't working now that you have some external people coming in to work with you to work with you I'm sorry so being flexible and adjusting some of those norms can be immensely helpful and you can adjust and iterate just as you would with bringing on a new internal hire uh it's nice to have higher-ups or stakeholders in your group recognize and thank external members for their work just you as they would an internal employee for work well done it just allows people to feel like they know that what they're doing means something to um ultimately the people who care the most and then um you can engage in team building just as you would uh with any other team so that means that if you want to go um to of some sort of sport event or um something outside of work and and you have external developers that are working with you on site feel free to invite them to come and like have them be a part of whatever you're doing in order to make it feel like you're all in this together increasing productivity on your team um you can make some of those process changes like trying heads down blocks of time that uh don't have any interruptions um you can scope work well for all the team members not just the external ones and not just junior or new members and you can set realistic goals and deadlines and obviously that's very simplistic but I think it's worth mentioning again that um these types of process changes can take time but do allow for things to go better and then maybe upgrading tools or making changes to your tools can increase productivity um if you provide better equipment if you're able or the next tier of software because you're hitting the max capacity um even something like the finally getting down to it to figure out why the internet keeps going out um all of these things contribute to increase productivity on your team so how can we improve collaboration when we're adding external developers um check in with your team frequently about whether you think the work being done and how things are going are going well I find that once we get into a project um we kind of stop talking about how things are going it's more about just getting through to the end of the sprint but I think it's valuable to really assess and step back if not in a retrospective but just casually like so how do you think things are going because those uh conversations do help create change for the better you want to know if the quality of the work is suffering and if tasks are accomplished in a timely manner but you also want to know if people are happy with what's going on um so in addition to checking in with just the internal team you can have check-ins with the entire team including the external developers if they're getting enough work not too much not enough or not the right kind of work for them and it's nice to do these things even in stressful sprints because then it feels like if people had something that was going wrong you could they have an opportunity to share that with you where they might not have been comfortable doing that if you didn't ask directly um because non-internal team members may not have the trust or feel comfortable pointing out blockers issues or so on and so forth if they've only been on the project for let's say three weeks um of course you if you're using agile you're going to be having scrum but one-on-one check-ins are also helpful and um this is especially true for people who are working on things that are hard for them because you want to keep the line of dialogue open to make sure that they're not just drowning in this long-winded task that may not ever have an end um I would to prevent that sort of situation encourage your all developers to work together and that you have a type of team where people can ask each other for help so that doesn't mean like only the internals asking other internals that means that there's communication happening across the team in all directions um and if possible if you can make the right people available to the other people that let's that those channels kind of happen naturally because if some of the critical team members are always in meetings or always um heads down that means that some things that could be solved in 10 minutes may take uh two hours because a quick conversation wasn't possible and then you can always ask for insight or ideas from not just your internal team members but the external team members and could be pleasantly surprised with any suggestions they may have for you communication is critical to success um so we want to communicate with skill uh some small things are uh learning everyone's name on the team and it happens it's difficult we struggle but it's really important and I think even making the effort to pronounce their name the way that they want you to could make a huge difference in them trusting you and feeling that you are valuable that you value them on your team uh this can also mean learning their preferred pronouns and using them and so when you make an effort in this way it makes people feel like they're an individual that is important other ideas for skillful communication uh you want to consistently communicate across the team this is assisted by using the same communication tools across the team whether that be chat email phone video calls what have you um you want to share any meeting links if you're working with remote people or people that aren't in your office in the calendar invitation because that means that they know where to go so that they can be in your meeting on time and ready to go and you also want to communicate changes or new decisions in a way that is accessible to all like posting meeting notes in a sock channel or in a google doc or sending out an email what have you a lot of times um this doesn't happen and then some time is lost to getting people up to speed recognizing barriers is also something that i think a lot of us struggle with um and don't really address so recognizing and adjusting to any language barriers be that um either technical terminology or what language we're using to communicate um that can be a barrier on your team and if you recognize it earlier then you have the opportunity to make changes as you go along you can if you also can recognize location barriers like if someone is unable to join the meeting remotely or if they can't clearly hear because half of your team is in a meeting room around a small um tablet device and everyone else is remote on a hangout um that is a barrier for them to clearly hear and know what has been said and what decisions that everyone else knows that they didn't get um and if you're following the agile methodology you really need to have all the team members participate in the stand-up as a developer i think the most important meeting of my day is often the stand-up and when you're working with people who either are in a different time zone or location if they're not making the stand-up that's a problem if they're a blocker for me or i'm a blocker for them because then we don't know that so if it's not feasible to have everyone participate in real time in the stand-up um using other ways of communicating the status and blocker information like notes in Slack or JIRA or google.com email getting that out on a regular interval helps keep the momentum of the sprint rolling uh just and of course everyone's unpleasant experiences do happen so how can you address problems and mitigate issues before they arise on a mixed team? I would encourage you to discuss the issue with the individual before going to their agency side manager um because if you go to their agency first before discussing with them you don't really give them the opportunity to work it out with you um as you would with maybe internal member you would take them aside and have a quick conversation if you neglect to give the opportunity to an external member um that can cause some uh conflict in an already probably unpleasant situation um and if you aren't sure if something is not if if something is not going well or something's amiss you can ask your internal team member that is working with that external member to see if they have suggestions of why something may not be working in a constructive and positive way but in an unpleasant situation for example if you have a developer that has become unreliable their dates are slipping um and even if you discuss it with them and nothing really seems to change my first step would be to reassign their priority tickets to other team members and assign them lower priority work and I say that because sometimes these things can take time to work out but you don't want your project progress to take a hit while that is happening so um you can try to meet with the team to resolve any group issues but if all of that doesn't really seem to make a difference then it's time to go and have a conversation with the representative from the agency or vendor so in a specific well specifically I've been talking a lot about how you might have your in-house team and you have external people coming in to work at your office but I didn't specifically talk about when you're working with external people and their remote and I know that a remote work is becoming a lot more prevalent especially in our sphere but I think there are some things that specifically relate to project management um that you can do to help to keep your team in sync um I will mention one of the benefits of having the external developers be remote is that they're less exposed to the politics and turnover in your company so if something is going on then they're able to continue working when there are issues um and then but one of the downsides could be that team cohesion and continued trust in the working relationship when you have external remote people could require further reaching out an effort on your part in order to prevent them from feeling detached or excluded from your team um so you need to go the distance to keep all members engaged and I think that external developers working remotely are a great asset to a mixed team and some ways to reinforce that they are an integral part of the team are to make a point that you acknowledge their efforts and provide positive feedback when the work is going well you can also find creative ways to include them in your team celebrations so if you had a great launch and you had shirts or water bottles made you can just mail them one so that they have the water bottle too or you can invite them to FaceTime or video call during a team happy hour or coffee break just making sure ahead of time that they know to have coffee or beer or what have you on hand um if you're going to have a team lunch you can send them a stipend or credit so that they can have lunch at their place of work at the same time and it's nice if they've chosen to share their birth date with you if you send them a card or just acknowledge it and stand up all these little things kind of make it feel like you are a part of a group that cares um it's also nice to provide updates on things that are meta to your external remote people so when someone receives a promotion letting them know that they can congratulate that person or if someone is going on leave that they can like let them know um and then any public announcements that happen in your office just translating that to the remote people is very helpful it's always nice if possible to pair an internal member of your team with an external remote person specifically because it provides a teamwork opportunity for them to work together and get to know each other on a more individual level as opposed to only seeing their face during a stand up time zones are difficult but they can be an advantage or a disadvantage a team that works across multiple time zones can definitely speed up progress but it can slow it down and a great thing is when you have a team working around the clock because you have them offset by six or nine hours but if they miss a day or blocked then you have to wait a whole another cycle for them to be back on track but if you establish working hours and have some overlap at the beginning of the end of their working day i think that helps prevent that sort of disjointed this person is asleep when i'm awake and vice versa um so clarifying who is supposed to be working when and then if you have early or late meetings or after hours meetings switching those off so that it's not always the one person missing dinner with their family but that you just have to get up earlier sometimes so that it's more fair oftentimes larger in-house organizations will work with multiple vendors or agencies on their projects and i just want to talk quickly about how you can have successful handoffs and transitions so establishing and maintaining documentation and spending valuable time on specific on specifications comments read me any testing documents when you're switching from one partner to another will definitely save some time because you have a central document that everyone can read if you have a clear start date and end date for each agency or vendor and you can possibly have them overlap then they can hand off their design work to the next agency's developers and get things quickly moving a lot of times people don't feel comfortable having their vendors talk to each other um but i think if you can facilitate that in a way where it's not a contentious transition um you can be in the room and just make sure that they can maybe have some knowledge share of what was working why they made some decisions and what's not working you never really want radio silence when you're working with agencies or vendors because that means that you're not up to date on what's going on with your project or product i always think that always having concise deliverables what is expected at the end of a arrangement or contract can be make things a lot more clear when you're switching from one to another or an agreement is ending so what should we do when we're done working with an external team um maybe things went great maybe things didn't go well at all but i think it's valuable to hold a team retrospective so that those things are clarified um you want to make sure that the site app or deliverables whatever they were working on are in your possession before you leave before they leave i'm sorry so that means having the designs in your dropbox or driver server and not theirs um making sure that you have access to all the accounts especially the admin accounts that were created in the process of your website development um that can mean hosting services and critical emphasis on the administrative accounts um so that you have control of what you've paid for today and then i'll think that a lot of people forget is to then recent permissions from agency or vendor developers on their last day and changing your passwords and you don't even have to feel bad about doing that it's just a safe way to protect your investment and not have any sort of um question about whether things were going on that you weren't aware of so thank you very much i hope that you have some good takeaways to go back to your team with and i appreciate you coming during lunch um if you please have time take uh or please take the opportunity to provide some feedback and uh again i'm sure everyone's been telling you but sprint day is tomorrow and everyone is invited so we need product managers we need bug reporters qa testers people to help write documentation so um please come tomorrow if you will still be around and uh if you have any questions please come up to the mic i'd be happy to answer sure how do you deal with slacking jira do you have any recommendations so you know you have all of these jira tickets flying into your inbox in the mail and you know pilot the members of the team are going off in in this last channel how do you get that so uh for me personally i always have my inbox empty so for example if i'm getting jira tickets and notifications i have some filters set up but i'll open the jira ticket in a new tab in chrome and um know that if i'm supposed to be if that's my priority i'll start working on that and close all the other jira tickets that i was working on um with noisy channels be it hip chat slack uh chat what have you um it is a lot but it helps to make an effort to set up channels and provide some sort of structure for your people in this channel so if you have a main general channel and that's it and everyone's talking in there that can be very noisy because you are seeing all of these messages fly by as opposed to having like this is our be hat channel where we talk about testing and this is for the front end things and this is our release channel so kind of being mindful about what needs to be talked about where and then you can mute channels during like i will have the release channel muted when i'm not responsible for being part of a release and then you can also set up and enforce people to use like at someone and not have at here or at all or at channels so that kind of creates a bit more space around people's resource and energy and ability to focus