 Thank you everybody for coming. So this is GitLab for non-tech and project management use There's three of us that's going to be presenting today Myself, I'm JJ Kordes. I'm the marketing operations manager here at GitLab Thank you Jackie Gregnola she's a marketing program manager on the marketing team and then Ty Davis. He's a technical marketing manager at GitLab as well Thank you So this is our rundown real quick. We are gonna, well, we just did our introductions We are gonna be playing a game and then we're gonna be doing some basic concepts a couple case studies and then We will get to Q&A and possibly a live demo But to kick this off, I'm gonna hand it over to Jackie so she can explain the game All right, so we're gonna be very hands-on. Oh, not okay. We're gonna run a game. It's the gumdrop exercise Some of you may have done this. It's a good opportunity to learn hands-on how project management is done So we're gonna break you into groups and Ty's gonna come around and just form five people per group So you have to be close and I'll describe the rules. So in this game. We have One seer and you're the person who's going to be looking at the gumdrop Yeah, I don't know what to call it like structure and you're able to describe to the runners What you're seeing they can't ask questions and the runners are gonna be running back and forth getting any information and passing it off to the Builders the builders are the ones who are is the one person who is going to be building the structure Using the information received from the runners and you'll have one observer as well in your group And they're just gonna be watching everything choose somebody who is Comfortable with public speaking because you'll be giving a little bit of a rundown on your group at the end So just a quick note observer feel comfortable with public speaking. So choose one seer One builder one observer and the rest are runners The seer is the person who will see the structure. They're allowed to describe to the runners What the structure looks like the runners cannot ask questions? There's no back-and-forth, but you can use nonverbal cues and the runners are gonna be running back and forth taking what they've heard from the seer and Describing it to the builder and the builders gonna be trying to put together the exact replica of the structure of gumdrops and toothpicks Okay, you've got 15 minutes starting now The runners can come over here get the information from the seer and run back to their group Yeah, multiple runners can be over there talking to the seer at the same time You can't ask questions of the seer the seer can just say what they saw Runners can't see the structure Runners no talking observers no talking seer You can talk I Would recommend not eating the gumdrops as they have been handled by other people All right, will the observers please get your final product structure of your group and come up on stage We'll go one by one and you'll have 30 seconds You just kind of give us a rundown of what you saw some questions You might want to go about what was difficult about the process Was it difficult to get some of that information back and forth? And just general observations. We'll start on this end. Yeah, we'll start on this end. So Caleb Do we have a little bit Kayla? Here you can just Just general guys down You come mark. Well, hello everybody go ahead Hope everyone's having an amazing day so far First observation that I saw was there's a lot of inefficiency. No, there's a lot of one person seeing Something right and then there's a lot of downtime here with nothing's happening and our poor builder here is just sitting waiting to receive instruction And that's just wasted time There's a lot of manual work that's coming back and forth and then also from an observer's standpoint It's hard for me to see what all is going on So yeah, that was pretty interesting. But as you can see we have this lovely science project here not sure You did an amazing job It's just yeah, I just don't know. It's the correct job, but it's an amazing job. So kudos Thank you. All right. Yeah, that is quite complex compared to ours right here. Well, our team was awesome so the seer the seer was observing information that was passed on to the runners who also both deliberated and talked about Interpreting that information Then hopefully remembering it by the time they got down to the builder Who the builder took on that information and tried to extrapolate whatever it was the runners were talking about and Trying to put together a structure Similarly The inefficiencies it was like you got a set of directions and all three people would run at once instead of maybe like one person sitting behind But also similarly instead of like breaking it down into pieces. I think sometimes you try to do the entire thing And try to get the full idea of it instead of saying, okay Let's take this first half one person is in charge of that part and then kind of break it down And here's a look at what they developed it's 2d So this is our first comm failure So the approach that our seer took was to break down into the component pieces so numbers of dots number of Toothpicks in each color. So that worked almost well, but right from the get-go. It was wrong. So It was and I'm not sure if it was wrongly said or wrongly interpreted It was a bit like playing Chinese whispers or telephone and then the problem was One person could use their eyes one person could use their mouth one person could use their ears And so even though everybody had all the component pieces They were only allowed to use one function at a time and then there was no return communication allowed so every time there was a possibility or question it resulted in in People doing the best that they could with what they had and what was interesting was to watch the frustration Building up as everybody knew something was wrong, but nobody could figure out how to communicate Where that was so so that was a problem, right? Thanks, guys Mike All right This is rather large, so I'm just gonna leave it back here It's like a fish. Yeah, it's yeah, there we constructed a fish and Yeah, it's more or less the same of what everyone else has been saying just there's this odd Communication and everything the thing is everyone had different communication styles. And so these there was no Common language that everyone was speaking I should point out though since I am from the security department That I noticed I documented three bugs in the game I wanted to go ahead and report Runners were able to eavesdrop on other descriptions So and I was surprised more people didn't try to take advantage of that, but that was possible also runners were capable of giving false information or There's capable of false information being able so the runners are given the incorrect information if they tried to eavesdrop and then of course there was the a liberal interpretation of the rules and Security department really frowns upon that behavior. Is it an issue? Is it an issue? Is it in the handbook? Yeah, the eating of the parks was bad we you know All kinds of departments are now involved and you're all guilty, so It was fun though. Thank you So I was actually quite impressed with the team. I think that they got fairly close The thing that I observed I mean obviously it was a difficult process and it was inefficient But I felt like the seer was very detail oriented and try to break it down into simple parts But even that did not produce the results even more interesting is that The runners did come back and verify some things and still didn't quite get it So it's like no matter how detail oriented and how you try to break it down in small components It still didn't come out with the result and it was you know not Going to be successful. So it was it was definitely interesting process to watch All right, so we got a dream catcher This one So very similar to what a lot of folks were saying it started out so good The smallest iteration possible was just eight toothpicks perfect, right? Then the critical problem of it's two triangles and a square came out and that just went all over the place The other fun thing is I watched a micro management get reinvented where the runners Were watching the builder and they're like no no no goes here like no and they just started to do it for them So I thought I thought that was pretty funny. It's like there's micro management right there Yeah, we got a fun little spike on the end. It's dangerous. Thank you. All right. So at this point before these two go This is where I'm going to let you know a secret on the last two that while you guys were all doing this They were allowed the runners were allowed to ask their seers questions So as we actually look at their structures right now, you can see there's a lot different Results and what the others have so Jeff and Elizabeth they're going to talk about that Jeff if you can step forward too so that people can see what you produced. Yeah, so this is what we ended up with It works pretty well with the runners being able to ask questions of the seer I think echoing what everybody else said I found the Finding common language was really helpful Evan was describing it as triangles and squares and Antony translated that into okay open care closed care it and Or open bracket whatever Yeah, I think the only thing we missed is that there was a miscommunication where Evan thought that that was everything that he had communicated everything and so the you know Nobody really knew to kind of check back in and say okay. Here's what we have You know, here's what we've built. Let me describe it back to you, but otherwise I thought yeah communication made a huge difference So same observations at the beginning, you know is quite comical watching them trying to do this once they could ask questions They did a lot better. I thought that our seer did a great job of breaking it down into easy steps And both this year's once they were able to ask questions They both had different questions, you know He was still giving them very small steps like they still were really trying to clarify it But then watch them come back to the builder That's where even though I thought they both were on the same page the seers and they're trying to describe it to her and Somehow and like that that small amount of space. They were both sometimes thinking this different things So it's interesting to see that even though you both seem like you might have the same idea in your head Like obviously once you're communicating it you had a different picture in your head than what the other person had So yes, definitely having better communication if the builder could have asked questions. I think we've gone a lot faster I thought they did a fabulous job. We just missed a little triangle at the end Which our seer tried desperately to get out last minute like five seconds left and they're sprinting across But so I think they would have gotten it. Awesome. Thank you. So, you know with this Hold that actually don't know so with this game obviously it's just a fun game to play But driving down the point, you know, we are a lot of What our tools use for is collaboration and so it's driving that bi-directional collaboration When we look at the people who can't talk to the person that has the goal in mind Obviously you could see some of the results end up not being what that person was asking for and so we have collaboration That's part of Going back and forth and understanding what the better picture is in the end You have better results that are very close to what you were looking to get so the game is fun but it's also to just show kind of a nice little example of what it's like to have collaboration in different levels and Get the result that a team can do together instead of looking at that top down Let's just guess what he meant or she meant and go from there and then in the end You know, you don't you don't meet what was expected. So that's the game We're gonna go into our presentation more now and get loud, but thank you for playing. Hopefully it was fun Or If you want dots you get we have some you can eat right here. We have some not dirty ones on touch non-touch Sorry Right with that think JJ is gonna kick off with talking a little bit more specifically about how to use GitLab for non-technical and project management use Thank you, JJ. So here's the basic GitLab concepts and project management Okay, so this is probably a really bold statement But I feel that there's actually no such thing as a non-technical role in today's business environment Because everybody has a role to play in software development So like from the apps that you play on your phone to what you're doing within GitLab And actually what you do within an operating system all of that information is getting fed back to the people who developed that and That feedback loop is really important to make improvements in that so in my mind. There's actually no such thing as non-tech so From a very basic Perspective software operates a lot like a layer cake So you have to have a really strong foundation and then that foundation builds upon other things and each layer of frosting That's between each one of like in this example in this purple cake The frosting between those are like your web hooks or your apis or actually the integrations that are then making those two pieces of software talk to each other And so each task that's above the next one can get more complex because it's building off the foundation that you've already put into place So for GitLab we can actually have everything from project planning to execution all done within one platform And so if you take a look at the cake now This is actually how GitLab structured so at the very top level you can have a group and then underneath that group You can have epics and then underneath that you can have projects that have issues that then have templates And so all of those pieces together can actually stand alone or you can put them all together and it makes a really awesome Process in a workflow and you can actually have lots of teams working together to get something massive done But you've broken it down into little pieces And so this is actually how the marketing team has their System structured right now previously we had everything into one big bucket It was just called general and then we just would work from that We've shifted to allow everybody to have their own project So like the XTR marketing operations field ops corporate digital marketing and product marketing Those are all projects the ones with the little file folders. Those are actual groups because then underneath that they can put Projects or they can put more groups so they nested information. So there's more information built up underneath that and Then epics are built at this level and you can think of an epic as like an umbrella It just takes everything in all of these individual projects and rolls it up into one big thing And so then we've also gone through and we've templatized a lot of tasks that were repeated And so we know that Anybody in any of the teams can then pick up this project and know what has been done What hasn't been done what needs to get done and if there's a timeline associated to it And then who is responsible for doing what and so we've done a lot of that for eliminating the manual tasks that Happen on repeated projects like we've run campaigns and there's always a list upload or a field event There's always a list upload. So this is one of those things or if like we're always running a digital ad That's there's certain things that have to happen And so this is like the checklist and so you don't want to do that every time and have variances So you templatized that and So then we also created a unified view to track our progress So within marketing we actually our CMO has asked that we all use the exact same amount of labels And so we have status work in progress review and then scheduled And so this view actually gives him the ability to see what everybody within the company is working on from that very high level and where it is within project completion and so this is an issue board and Everybody within the company use or within marketing. I should say uses these labels and so Todd always has an ability to see what we're working on And then this is how marketing is chosen to observe epics and parent epics So you can have the relationship between an epic and a child epic and it's a one-to-one You can have multiple children to a parent and you can get further down But marketing has only chosen to do two different levels. So it's a parent and a child and then you have issues underneath it But you can only have one issue associated to one epic. You can't have issues associated to multiple epics Yes Jackie's actually gonna do that in just one second and then if you still have questions, we'll cover them at the end Yes, ma'am Yes, okay, so within GitLab. Thank you There is a change in terminology. So parent epics was what they used to be called. They're actually now called ancestor epics I don't know the reason behind that But that is what it is And so just from a project management standpoint You want to define what your ideal state is and then you want to create that framework So you have to have a really strong foundation before you can work from anything For each piece of the project you want to make sure that you have a dry, which is a DRI It's a direct responsible individual. They're the person who's responsible like our director of field ops He likes to call it one neck to choke So it's the one person responsible for that thing and that's the person you can follow up with And then like I said, you templatize their repetitive tasks and then you set SLAs So based on like the due date you work backwards and figure out how much each piece should be taking and then Create rules of engagement and definitely have like a feedback loop So like in our example and then in this game the people who could ask the questions and ask for clarification They got closer to this structure than the people who could only go one way So you want to make sure that you have that feedback loop And you can iterate the process as you go. So if something's not working change it So like I said Jackie's actually going to now jump into oh wait, sorry documentation It's always very important to document what you're doing in our marketing handbook section You actually can see the entire structure that we've done issues milestones templates Groups projects all of it and what all the different labels mean And so anybody new to the company can actually jump in and read this area and get a really good idea of what it is We're doing and how to interact with the issues and projects in our section So now I'm handing it over to Jackie and she's going to talk about the integrated campaign. Thank you JJ All right, so I'll just share kind of an example of how the marketing team has been using epics and issues and a good example Is to just commit campaign that we began in January of this year So it was our first integrated campaign and if you're not familiar with what that means It's basically landing a single message across all channels So using social media digital marketing all of our content our website and in doing so it was involving a lot of different team Members so we had field marketing content marketing digital marketing marketing operations business development and SDR organization there are a lot of people involved and Initially when we were kicking off I had a Google doc and I had okay here are all the different things I can think of that we need to do and then realize we could do this in GitLab so Doing so is our first kind of test into using epics to give Kind of the high-level information and then organize the group into a single unified vision for what this Campaign would become so this is our well ancestor now campaign Which is basically giving you a full level look at the campaign Personas messaging quick links to the recordings of any meetings that were taking place so that if somebody maybe was missing something They could go back and rewatch if they needed to and the goals of the campaign the messaging So here's another look. This is just two screenshots of that parent epic where? We also included key timelines So what needed to be done by what dates to hit a very very tight Timeline and deliver delivery date of February 18th So you can also see we I we documented who the team members that would be involved So what different team was responsible for what different part and from there? We got more specific so the parent or the child epics we included things like the events and webcasts and emails What were what was the sales enablement that needed to take place? what was the content that we needed for each key pillar and Positioning and messaging was the first thing that we took and took into consideration We also used the labels that said just commit and that just gave you the flexibility to use the issue list To say anything with the label just commit. Let's see where we stand what's still open what needs to be done and In this example, this was the strategy and design epic and in this We had lots of different tasks so you can think of the issues as the task that needs to get done Each issue has a directly responsible individual like JJ mentioned And it had a due date and these due dates were really important because there were a lot of Dependencies that were happening. We couldn't work on the content until we knew what the message was we couldn't work on Anything related to digital marketing until we had the designs approved so This just kept us organized and saying what do we need to get done by what dates and Keep us on the timeline that would help us hit that delivery date Here's another example It's the positioning and in messaging epic and this was the first thing that we were jumping into and again This was like a lot of the things that were dependencies for other groups to be able to complete their work and With that I'll turn it over to Ty and at the end we'll have questions. So if you have things related to that Jump on it. All right. Now. It's my turn to talk about how product manager marketing Uses get lab to do project management. So I'm in technical marketing. I know some product marketing people out here the way that JJ described as you have marketing and then you have marketing is that group and then there's several projects that are labeled either like marketing ops There's product marketing and then I always forget the rest of them Obviously focused on product marketing. So I click on that one all the time But you have that project and group structure now there is Examples like if you know, I'll talk a little bit connecting this on the technical side But you can create subgroups and all that stuff But the way we do it is that parent group or ancestor group and then the projects that are within that I'm gonna be more specific on talking about just how we use the board views You have the group project structure You have epics that reside within groups and then you have issues that are created at the project level Issues can roll up to the group. So if we have these different marketing groups That are specific projects We can go to the marketing group and all issues from all those different projects will roll up And then you could see in a board view there everything that's going on from all the different marketing groups now you can also have board views in Just the project. This is what we have in product marketing right now after this last session I learned something and that's probably that we should have our board views at the marketing group level that way when we're assigned something by marketing ops or by content that We can still have that visibility Into that issue as well instead of having to replicate Our own just to the track our stuff. So right here. It's just The moving it from the the lane to lane the as forget what it's The status is Status plan says work in progress and I think there's one more status one review which we don't use on our board, but Those are the mandated that was decided upon the Todd That that's what our marketing should use is if you have a review work in progress This gives him visibility at that parent group level if you want to look at the board and see everything That's in process. He could see all the issues that are correlated with that that label We labeled and everyone has what's the proper word you use earlier for labels that you want to create their additive labels Additive labels we have tech PMM because I want everything. That's tech PMM specific to come up on my board So I'm filtering on my board by tech PMM and that's showing everything. That's specific to our technical marketing team We use the we we could create boards based on a sine so this allows us to see who has What issue what they're working on? Maybe your manager just wants to see what the team is working on or you're Being a collaborative agile team and want to just see what everyone's doing or what you can work on together You could see the specific issue that that person's working on you can organize that by a signee inside of the board views Some of that's not often used right now And this is something that's even for our customers trying to get them to use more often is the burn down charts We categorized it by we as in product marketing. So this maybe should be more aligned but as Q1 if I 20 and Out of that milestone to our issues to take a step back and say what is a milestone? Milestones is somewhere where you can define a time increment So you can have a start and an end date for us. That was Q1. So in this particular case, it was four months and so in that milestone that we defined it was January 1 to one month in April 30th and All the issues that were done in that time are reflected on that burn down chart And you could see ours in the typical burn down chart because during the course of that Four months, you're gonna add more issues to it And then you're gonna work on those and then eventually you reach that point where you're complete and then you move on to Q2 FY 20 Where are we on time? Okay. We got time. So related as a customer. So my job is technical marketing So I've worked a lot with agile planning tools the way on the the engineer side and more of the dev side that GitLab is used for you could look at issues and project management as Even for us too, but you're gonna have those merge requests that are connected to The issues that are doing something with the repository You could do that for us as well if you're changing something in the handbook You create a merge request and you tie that to an issue But for a customer if they have their application, they're working on that They create an issue an issue is a problem and enhancement Maybe an addition to something that's the starting point where you're gonna move that in The lanes that you saw to you know work in progress or complete and then you have that merge request Which is tied to the issue. So I create an issue. I'm a developer. I see okay I need to work on this. I'm gonna create that merge request and then check out a branch from the master branch Get working on that and then have the ability to collaborate inside that merge request or inside that issue once we've defined our Once it's done and you know, it's past then Closing that merge request will close an issue and then there's a lot more to the process in terms of what we do with auto devops and stuff, but for a customer that's doing more engineering or even our own GitLab engineers you are doing You have that issue as a starting point and a merge request is that fix or that addition to make sure that issue is completed Aside from that going back from customers just to us I think We just need to move our board to Your board so I need to move it up to the group level so that I can just roll up all issues that are connected to us in there So we have actually more time this time for you to Thank you So just to kind of explain what we mean by the different levels of GitLab. I'm actually gonna jump just right into our GitLab instance So within GitLab like I said it with the layer cake example, there's lots of there's lots of layers So GitLab comm that's the highest level of all of GitLab and underneath that you'll have a lot of different groups And so you'll see things like the marketing group is not bizops group There's sales etc. And each one of those can then have their own projects underneath it You can build an epic an issue board at this level But then you can also jump down into just this marketing specific level and build issue boards and epics at that level as well The difference between the two levels is if you build the issue board at this top level It will roll up everything from every other project underneath it if you build it down at the marketing level It'll only pull things from within marketing and so you have to think about where your work lies and Where you should be building your issue boards and epics so as an example marketing ops We presently work across departments So we do a lot of with sales ops bizops sales in general and all of those are individual projects and Groups and so our issue board is actually built at this highest level because we need to pull in everything else So if we go over here to the left And we click on boards You'll see Let me get to the right board so this is our marketing operations board and If you look closely at all the issues that are underneath this You'll see which project they actually belong to so the little URL slugs tell you where it actually lives And so some of these are on the employment one which is a people ops board others are within our own project or sales force and Because we have additive labels We see it in these different columns So marketing ops has many additive labels because we have to track things across different projects that are outside of marketing But you'll also see the marketing ones in here, too So the status work in progress or review or things like that and so on this board We have our labels, but then we also have what Ty showed was by people So these are the people that are on marketing ops So there's Robert Nicole and myself and these are the issues that were assigned specifically to own and then if we keep Scrolling to the right you can see all our other columns that have different labels associated to them But because our board is built at this highest level We have everything if we took this same board and built it down at the marketing level We would lose everything that's in the employment project the sales project sales force, etc So we're not getting that global view So as you're building this for your own teams like think about are you working cross team? Or are you only working with your own team? So like Jackie she built one of her own issue boards down at the Digital marketing programs level so just within that one itty-bitty project and She had issues in like field marketing that weren't showing up on her board And so then she had to move everything to the higher level to the marketing level because then she could have both digital marketing and Field marketing show up on that board. So like as you think about it like it is like a cascading waterfall So this is the marketing group so everything in each one of these projects can show up on a board and Labels are about the about the same a label can only be applied to a Project or a group if you put a label a project label on an issue and you then want to do something at a Group level that Issue label may not show up So like you have to think about it that as well So like labels if you build them on the project level you can only use them on issues within that project so again like if field marketing had a label on it that's like field marketing and Jackie created something in digital marketing programs and wanted to put that field marketing label on the digital marketing issue She couldn't because that label was created only for that one project But if she if the label was at the marketing level then she could use it in both projects So you also have to think about that and so same thing for like marketing ops We have all of our labels built at the very highest level in the highest group possible because then we can use it across all The groups within GitLab And so that's kind of the layering structure it gets a little deep and complex so if that got too deep Please let me know That is about all we have to present today, but we are going to be taking questions So there are two mics here in the room So if you have questions if you could please go to one and we one of us will gladly answer for you Okay, so if you have a issue in a CS project you still cannot add that to To a marketing Project like you can't add your label or you can you just can't if your label is at the GitLab calm level Yeah, then yes, you could but if you built your issue board in field marketing You wouldn't then be seeing the CS thing your issue board would have to be up to roll everything underneath it Yeah, you could build So you could So if you have labels at the group level and you have those issues already in a specific board you could still create a board at the Group level and just use that Label that you've created To make it at the group level We'll talk about basically like a lesson learned for me I created all my labels at the marketing digital marketing programs like group because that's the group I'm in and then I had issues that were coming from like field marketing content marketing and I had to Redo everything so Basically think about where you're like where you would want to apply the label And if it's gonna be at other groups and make it at a level higher. You just had to redo labels though, right? Not yeah, but yeah, I was just like you had to read you. Yeah, well on boards But yes labels and boards for the only thing that had to be redone Yes, sir, what's the distinction between the dry and the assigned in terms of how you think about that? In reality, they should be the same The way that Well, every team does it differently the way we do it is that whoever is presently responsible for getting that work done is who's the assignee And the dry should match but like with a list upload I'm presently assigned for most of them, but if I'm no longer going to be doing it I will change the assignee to somebody else And so they should really match but they don't necessarily because if there's multiple steps within it You change the assignee to whoever is like on deck right now and then once they're done with their piece They change it to whoever is now on deck But there should be one person who's in charge of making sure all of that gets done an example from just commit because it was like I was learning who was in charge of white I wouldn't set the assignee or the due date until I had negotiated with the person like will you be able to get This done by this date. We need it for this other Dispendency and once they agreed that they were the correct person to be doing it and that they could do it by the date That's when we would assign that just as an example. Okay, and then when you're doing MRs, how do you know who to assign the MR to? The way marketing does it is you generally assign it to your direct manager or the operations person within your team Okay Yeah, so if you are assigning an MR to somebody that doesn't have merge rights You'll see a little red triangle next to their name On the MR and that just indicates that they don't actually have merge rights and can't handle that for you But if it's something that you're needing them to look at before it gets merged I would still assign it to them and then they can reassign it to somebody who has rights to merge it Who has rights to merge things Myself Business ops and a few people and people ops do and any of the infrastructure team does as well They're just like a little tidbit if you don't know that you can also if you get a comment to you And you get that in an email you can reply in your email and it'll show up in the issue And then there's integrations with slack and matter most so if you wanted to get notifications Anyone to build up or just it's not that hard to add those integrations But still you can get notifications via slack on comments Yes, francis Just curious how you guys using weights for issues I just kind of pick random numbers, but at the moment Most of marketing is not using weights The product marketing team or the technical marketing team might be I know the data team is using it And they're using it kind of like the Pythagorean where it gets bigger So it starts with one two then it goes to five then 13 like it goes all the way up to 13 So with weights, it's um not just with us, but even with uh customers who are approaching agile It's always not the it has to be a complete buy-in by everybody Everyone has to decide on the scale that they're using like the Fibonacci scale and they have to You know be able to weight the issues in that manner because like I tried to do it in product marketing But obviously we haven't I did it for my personal self. It's not like I talked to the rest of team. It's like hey This is what we've decided Wait There's not a get lab standard right now For weight Exactly, so Yeah, there's there's some team capacity stuff that hopefully eventually we add to Get lab deck and you can like predict out Per like sprints and everything so the the weight is More like if people are doing that true agile and stick it to it like you're saying That's a big association with that. You have to stick to it Yes, Jim with respect to your status labels the additive status labels Have you all collaborated with other groups because it seems like your status working process is what other groups are called doing and it feels like You know, we would want to have some sort of commonality so that we could grab labels in a consistent way Are you guys talking with any other groups at the moment? We're not so marketing as a whole has have chosen to the labels that we've chosen But we do each respectively like each of our teams have other additive labels So like marketing ops has some marketing programs has others field marketing has additional ones for like east public sector west So no, we haven't collaborated with other teams across get lab It is something that like i'm working on a project with francis on for sales ops as well And so we are trying to get some of that standardization, but until the whole company agrees It's not something that we'll be able to standardize Yes, ma'am. Okay quick question. So is there a way to Create an mr in a group which when it's merged close an issue in a different group Yes The question is can you create a mr in a group that doesn't that will close an issue in another group, right? Yes, you can so in every mr if you do a slash command and it's slash You do slash close and then you just put the link of whatever issue it is that you're wanting to close It'll close it wherever it happens to be Okay, you could also put the issue number two. Yep. Cool. Thank you So thank you because you just changed my life that you can do issues and boards at the get lab dot com level. That's awesome Um, I was quickly trying to find the answer to this But do you know if it'll go into private groups and repositories like legal tracker the compliance team has some stuff that Isn't visible to other parts of the organization. I'm wondering if you can still aggregate some of that information up You can't if it's a private thing that it won't be showing up. Cool. Thanks. Yeah Um, so you were showing it first right at the group level I'm part of the public sector team, right and then you have the marketing team underneath it So things that are happening at the marketing level that and then you know end up I guess Breaking down into the specific issues. They have their own labels But on the channel side, which mine is under public sector I'd love to be able to tie my label in there for like partner marketing Into what it is that's over at the marketing group level Is there a way to do that or no because it's it's two different groups and it is possible So if the label is built at a level higher than both of the groups, then you'd be able to put that label on Either group and have it show up Okay, does that answer your question? Yeah, so what would be higher than that if I'm looking at um, like You know the first place that you start off was Um, what I thought was groups Right, which is at the highest level for this level Uh, yes Yes, if you put your label at this level, then it'll work in your channel and then it'll also work in marketing Um, but then your issue board would have to be built at this level also to be able to pull in both of those issues From the two respective places Perfect. Yeah. Thank you If you need help, please reach out. We're more than happy to Um, are there any other questions Okay, um, there's a survey in your app. If you wouldn't mind giving us feedback that would be awesome Otherwise, thank you for coming and if you have any questions, please reach out to any of us on slack We're more than happy to help go through these. Um, we will also get you slide copies if you'd like that So, thank you. Thank you. Thanks everyone