 Hi, I'm Brendan Connivoy not Jen Krieger. Jen couldn't be here So I'll be presenting both parts of today's play and what we're talking about today is basically the four-year journey that was Required to produce rel 8 so how we're at monetized rel 8 design processing culture and for our marketing folks well It was short for red hat enterprise Linux so What are we talking about? We're talking about this problem. We had there was this one technical objective Separating the operating system from the applications We inside rail had two processed nightmares to kind of sort out And it took four years of work to get to the point that we could actually launch a new rail release with those processed nightmares in Hand and it involved about 1200 people overall inside the red hat organization. So a full 10% of the company So let's let's go back in time Back to March of 2015. This is when rel 8 began and It was it was great. We had a schedule 8 alpha was going to be based on fedora 24 due July of 2016 8 beta based on fedora 25 do in February and GA do in August of 2017 That did not happen August 2017 was two years ago. Well was launched more recently So this other thing happened at the same time. We started the rel 8 project We also started the rel.next project which was inspired by fedora.next actually and rel.next was Inspired by just the notion that if we divided the operating system from the applications We could do some things we wanted to do that would be good for the product Good for the distribution good for the business and For us we were trying to solve that too fast too slow problem that Matthew talked about where some things you want to deliver faster Some things you want to deliver slower didn't seem tractable to please everybody all of the time But for our customers what they wanted was a really stable operating system but also Really rapid moving applications like you want your oh you don't boot your distribution just to boot you like boot it Because you're going to run something and so whatever you're going to run You want your operating system to be rock solid But you also want your applications to have the features that you want and generally that means getting upstream Into the distribution as rapidly as possible and as safely as possible so basically we make upstream safe for consumption and On top of all that we wanted to be able to add features without changing the user experience So all the time people are like I want everything the way it is only with this one thing And when you put all of those one things together you get into this problem where you've changed everything for everybody so We kind of had this contradiction of how do we serve everybody the thing that they want and yet not change anything for Anybody that they don't want it So with this Problem in mind we actually stopped the rally project. We just put it dead in its tracks It was such a hard stop that there was a swear jar like we were meeting it Conference ahead or ahead of dev conf in Czech Republic in 2016 and we actually had a swear jar if you said really you had to pay basically Crown so anyway, it was It was significant. We decided let's really solve this problem. What's really put our energy into it and What we what we found was that we didn't actually know how to proceed. We didn't have the skills We didn't have the tools. We didn't have the mindset. So what did we have? Well, we had Linux distributions and they're over a quarter of a century old now, right? Like like even Red Hat Enterprise Linux is is pretty new in the grand scheme of things Red Hat Linux came before that Slackware came before that SLS came before that they're old and and they're kind of set in their ways And then the distribution is just a composition of different components So Red Enterprise Linux 8 is is about 3,000 components overall and each one of them has their their own Like every community has its own norms for development And and of course because we're not the owner of those 3,000 communities We're just participants. We we are at best stewards of those communities And so we can't just go in and make radical change. We actually have to go and work with all 3,000 different points of interest and do something that's compatible with all those communities so well, of course is pretty successful and We have We have most of the stewards of that success But what we needed were actually new development teams when we looked at the the problems that we wanted to solve in The enterprise Linux business. It was we needed to make new code Whereas all these communities have existing code existing Somebody created this thing and it is great and we're using it and we're working with them with it We actually needed to make some net new things and that was not actually a skill that we were staffed for and What we had were mature Linux distributions Fedora is great and it was great And even CentOS has has a great place for us But what we needed was to actually change the fundamentals of all three of them like splitting OS from the applications is What does that even mean right like one of the foundations of how things work right now? Is that anything can depend on anything and this this is pretty fundamental and And of course we just have a legacy we have people are used to using this They're used to the way things are but we actually need to to change the way things are and not interfere So what do you do when you when all of these come together? Well, you know, we said this calls for agile and It sounds like a good idea, but it's also a little messy So we did the usual thing that most companies do when they think let's let's do agile We tried out scrum like that is that is the thing that makes sense to the most people because they're like Oh, there's there's a schedule and there's feedback and yeah, it's good And that actually worked really well. We created some great scrum teams We had some great projects and we had great success and we also made the typical wonders like we just did textbook stuff We had experts in we had like highly proficient agile coaches and whatnot. We still made all the same mistakes. So We're gonna talk a little bit about what those were So first what were the good things? So we had scrum teams and those teams actually did produce good work. They they made new stuff the the The foundation modularity came from that our in-place upgrade infrastructure Product called I think it's well project-wise in Fedora. It's called composer It's like red hat image tool as a product So those came out of the scrum teams we created and they made net new stuff directed by product management And that was a thing we hadn't done before we built a muscle that was that we didn't have or it was atrophied And we did that with cross-functional teamwork. This was This was also kind of a novel thing for us because we have a lot of developers We we staff extensively for engineering and less so for most other roles and so that that imbalance means that we end up with a lot of a Lot of self-directed engineers making choices without product managers or customer support or anything else kind of tempering design decisions and and we did some distribution experimentation just along the way of Making rel 8 we we wondered okay. Well, what is it that that we want to have be the operating system? What is it that is the the applications? Is it just the kernel versus user space? Is it? System D is it what goes into a base container image? And we we did a lot of different things the fastest supercomputers in the world right now We're running a variation of rel 7 this was internally codenamed Pegas that has a more modern kernel and that that worked very well For that use case, but it turned out. It wasn't really good general solution so so even though we got a lot of great success not everything went well and I Just want to cover two things that didn't work Well, the first was that we didn't accept failure fast enough and this is one of those Things where if you're if you're on the team you see failure and you're like I don't want to accept failure I want to like I want to push through and make it work and all failure accepting failure means is observing that something isn't working and then making a change and in those cases where we looked at what are the problems that we have what are we going to do about it and we We really dug into it. We made Significant change and because of that significant change those those things Rapidly got much better and when we took a long time to actually have that that honest introspection Things dragged on and it was it was very painful for many members of the team So that was one thing, but there's this other thing I mentioned earlier that we generally staff for development over other roles so in most in most development Houses in the industry you have a pretty standard set of Developers to quality engineers to product managers and whatnot. It looks something like this like usually have five date developers have everyone product manager and In in our case because of our long history We actually have I think we started out with 130 to one product managers and now it's down to like 75 or something it it was it was Really out of balance and that meant that doing things like scrum actually Didn't work or they didn't scale very well So what we learned was that you can't just take scrum and and apply it and have everything work great Because when we did that we topped out at about 50 people We actually ran out of scrum masters we ran out of product managers And we ran out of queues like we just we ran out of everybody, but engineers Of course, we wanted to create more teams, but we couldn't because we didn't have the people to do that with and Further we needed to go from not we didn't mean 50 people We need to get 1200 people to be adopting these process changes to have these capabilities They didn't have before including remote staff So a lot of best practices actually are designed for everybody's in the same building in the same room at very least in the same time zone Here we are we inside red hat have staffed basically every time zone on earth Literally and the practices that are necessary to make that work are very different than what you would do if you had everybody in the same room So we did manage to scale this though And the way we did that was by formalizing a thing called autonomous subsystem teams Which is something that we didn't invent It's actually something that the rel 7 team invented while we were doing our our scrum work Because everybody faces the same problems One of the cool things about agile is like science you kind of rediscover the principles as you go along And so the teams that were delivering productized rel at that point in time We're having the same scaling issues and basically all they did was they took all of the roles that are Necessary to to move technology from like an idea to delivering it to a customer into one group So product management engineering quality engineering documentation support like that end-to-end team We just set one up for every single one of the technology areas where rel is and They came together for l7 when they were going to plan the next minor release update like 7 7 came out last week And if there was a change in the networking stack the networking subsystem team decided to do that and they decided it on their own so all we did was take that concept and Apply some of the agile principles to it So no change on who was in a subsystem team, but we kind of scaled out what they're supposed to do so they went from just planning to actually Executing together and that is that is really fundamental. You can't just show up some of the time You have to be there all of the time or at least at the right times in order to deliver Understanding to one another because basically You need to be a team not just a group of people that do things sometimes related to one another So we created all these subsystem teams We made them in charge of themselves and then we added optional agile facilitators for when they needed it And by doing this we were able to scale up a little bit So that was the first two years of this four-year journey. So where were we it's March of 2017? Let's do a checkpoint So technology goals were instantiated upstream. We had modularity. We had other projects that were well in hand we were exploring Cadence and and other aspects of splitting the operating system from the applications and We had roughly managed staffing ratios. It's still not great It's better to just go with industry norms, but it was working out. Okay, and so we decided to restart rail 8 in March of 2017 and What what actually happened? So it alpha was delivered on July of 2018 That was based on Fedora 27 8 beta was delivered in November That was based on Fedora 28 and GA in May about two months ago actually and that was actually based on 8 beta so once we get to the beta we stop inheriting from Fedora, which is a topic of Talk next or tomorrow actually so We did that but how did we do that like what were the actual steps? Like what were the things that we did because like just creating some system teams is not the end result It's like what did we learn and how did we apply it to all 1200 people? So the first thing was creating empathy between roles So as I mentioned, we mostly are engineers inside the rail division like eight times out of ten you're an engineer if you work on rail and That often means that you don't know what somebody else does you don't understand their role and You don't know how what you do affects them or how what they're doing is supposed to affect you And so this was a pretty deep change for us Likewise row uses a waterfall schedule. This is we didn't do scrum And in fact if you try doing scrum across 1200 people All in the same sprint cycle There are definite scaling issues and so we had a waterfall versus agile problem to tackle And then we also just had these outdated tools So our two process problems were basically waterfall and planning because the ability to plan Fundamentally is about being able to see what the big picture is and Break it down into actionable pieces and then take action and we didn't really have good tooling for that So what was the foundation for our change? Like how did we? How did we kind of apply some of these insights that we gained? And this is this is the hardest thing of anything and it's just it's just getting started because it is so Easy to do what you have done That just starting is the hardest part sometimes So what's let's think about this when you need to change the process for 1200 people? What do you do? What do you choose? What is what is the way to start and further? What if they've been doing it for 20 years? What if they like their entire lifetime their entire career? They've done things one way and you want them to do it another way well Oh and just side note the the rail development process is based on the red hat Linux development process Which was created in 1998. That's when the first bugzilla was filed The Agile manifesto wasn't even a gleam in somebody's eyes until three years after that. So it's a really deeply entrenched Production process kind of based more in in like physical manufacturer of goods than then Rapid software development practices. So where did we start? We started with a tool Which is the exact opposite of anything you're ever supposed to do like tooling is not the right thing Like a tool is a means to an end and there's only one reason why we started with a tool and that's because we didn't have a Tool to do the thing that we needed to do in order to create empathy to plan together to do any sort of Capacity work and that tool was JIRA actually so That's how we started we started with a tool but just having a tool doesn't mean you know how to use it So we invested in organizational abilities and and what does that mean? First thing is how versus what so a lot of the time When you see a problem here an engineer first thing you think is oh, I know how to solve that Let's do this let's do that and When You're trying to execute at scale what you actually need are some people to be in charge of the what needs to be done And some people in charge of the how you do that and the way it normally breaks down is that Product management your support organization people that are deeply aligned to up tune or upstream or Tuned into where things are going really need to focus on the what and then the people that are Really fantastic at handling code and and implementing things and whatnot are really good at the how So how versus what and the other piece is just ownership versus leadership. There are so many So many people that want to be owners, but in open source most people don't own anything We are we are working together. We are just trying to get things done And there are things that we want to do and leadership you can sometimes get people to do the same things You want to do? Ownership is kind of like a proprietary notion, right and and that kind of leads to the last thing Which is the difference between consensus and consent when you have 1200 people How do you get everybody to agree on it? You generally don't what you do is you find the things that everybody can live with and If you get there you have gone far because 1200 people are definitely going to give you their opinions that is That is that is fedora that is that is how we develop we have opinions But if some of them are just because we came up with one and some of them are because we are the Expert and it deeply affects us and we we are informed those are the ones that we want to have Consensus from and consent from from those it can live with choices So those are the organizational abilities and then when we actually put it into practice we kind of started out with with If you all use bugzilla If you look at bugzilla under the hood, it's just a it's a database with with a little web interface on top It is it's pretty primitive as far as tools go But it is like grains of sand and and the metaphor here is that it's like playing checkers Playing with bugzilla is like playing with checkers And when you actually want to plan when you want to actually talk about and design the beach resort You need something more sophisticated. It's more like playing a game of chess and so starting with a tool developing the abilities to To actually listen to the right people or be the right person to be listened to and then the tool to actually have the conversation in That's how we got started So when we did that when we had those things in place then we could actually Realistically talk about things that we could do inside of rel and this is where this is where things got Kind of interesting and more into how does fedora and rel relate to one another because one of the things that we figured out was That if you want to give customers the feature that they want Without forcing everybody to adopt that feature themselves You actually have to make it opt-in like we all the preference of opt-in versus opt-out spam, right? Well, we all it turns out that everybody actually wants opt-in versus opt-out features So if you can do that and we did it a lot in part due to the fedora change log process We scan hundreds of those and read them and made Decisions about whether we were going to keep them Reverse them document them do training for them. It was really helpful and in many cases We just documented in a few cases. We changed things to be opt-in and other cases. We just did a whole hog Reversion so probably the biggest example I can think of is DNF when we looked at how wildly different the DNF experience was between Yum and and DNF We started a two and a half year project just to get DNF behavior to look more like yum behavior because that would have been You know kind of like the system D of rel 8 we didn't want to have no one of those cases where we did great technology but also got Negative publicity for that great technology just because it was incompatible The other piece was that when the teams were actually doing their work. They got on their process. So Inside the traditional well all schedule there. There is basically this this huge Waterfall like Niagara Falls kind of set of milestones and what we did was say, okay within These windows you can do whatever you want as long as your output is The the thing that is needed. So however you want to develop if you want to do scrum if you want to do Kanban You want to do just like your own process You can do whatever you like as long as it happens between these boundaries and that's even though that doesn't mean we got rid of A waterfall schedule it meant that we changed the relationship between what the teams were doing and how we talked about the schedule and Then finally because we were adopting new tools A lot of the time our tools shape our thinking so our tool shape our processes our processes tied it to our tools When we introduced a new tool there was a natural inclination to say okay Let's just copy everything over and it was really important to create space between the old and the new So while we have some bridges between the old new tools We're trying to actually create a better way of working in new tools so that teams can Can like more readily adopt modern software development methods. They don't have to but they can So how are we doing like we we made all these changes we this seems kind of fluffy but Just as a reminder of these where the focuses for change Empathy waterfall versus agile rolling out the tools. So How do we do an empathy between roles? We we got some things done and some things we're still working on so now All roles are represented on subsystem teams and for the first time in Rills 15 year life The team is not who your manager is the team is what your technology area is and whether you're an engineer or quality engineer You know any other kind of technology specific role that is your team your manager is kind of irrelevant to the matter and We made them a little more real with quarterly planning. So one of the things I didn't mention I probably should have is that Within old rail schedules, we would talk about Well, seven is its own program and six its own program and eight is its own program and all the schedules are separate And it's really structured as though the people are different in every one of them And the technology is different every one of them. The truth is it's all the same people with almost without exception It's almost all the same technology the difference between the bash and rail seven and the bash in rail eight is not a lot like It's it's just a few patches and they're great patches but when when you treat multiple Releases as though it were a separate set of individuals You actually create a situation where people are very likely to over commit and over committing is is the path to burn out It's a path to frustration. It's a path to bad work really so Quarterly planning is a thing that we've implemented or kind of the process of implementing where we review all of our releases Like all of our work at one time and decide just what we're going to do over a short period of time that is the thing that most teams are doing now and We also implemented facilitation norms for those teams that did need to have an agile practitioner We standardize on agile practices that are based on best practices So they don't have to use them But if they want if they want to go agile they have ways to do it, but there's still some things that we're working on so the The ratio of product managers to developers is still Too high, but the number of people writing documentation is not enough things like that It's something that we're still working on but we have like the path We have we have quantified what the problem is and if you can see what is needed see where you are Then it's very easy to chart a course to getting there much more so than just like this nebulous feeling of some things were wrong and Also, we're just working on getting better reports out of the tools that we've adopted because we have like these high-level Planning tools, and we we are executing on the low levels and we're tying them together and actually getting a good visualization for How am I doing on creating that that? Resort at the beach is it's tricky. It turns out. It's more tricky than just talking about the state of every grain of sand So the second part waterfall versus agile, how are we doing? So we updated the program cycle considerably one of the things that was announced when rail came out was that instead of this Thing where we're reluctant to talk about when will the next rail release be? Does anybody ever wonder when the next rail release is going to be? Yeah, yeah, it's it's been shrouded in mystery Honestly, that is that is true because what we what we did early on was we would set the schedule based on what the needs were and Those needs came from our customers from our hardware partners And we would mix all of those things down and we'd come up with the exact optimal schedule of everything went right Nothing ever went right and in crisis And as the number of customers has increased, it's a good problem to have there's a number of partners have increased It's a problem to have it's gotten harder and harder to do that when rail 8 was launched We also announced that we would just be making a release every six months. So Approximately six months, you know, it's it's notional 8 1 beta is already out. So we're on track for that, but that is That was kind of like groundbreaking. So for for us we can actually say we know when rail 8 6 will be out or 8 10 will be out and and anybody can line up on that and Then we just reimagined waterfall by by the role people are fulfilling not by the outcome So within any boundary we provide the the thing that needs to be done should happen But it doesn't have to happen on this date or that date It's just you know, you have the spectrum that you can work in and we're still working on that schedule like getting to a six-month schedule because has come at a cost of cutting some things down and leaving some things large and actually when you go from a 9 to 12 month schedule to a six month schedule It's still really easy to over commit. So we're still working on, you know, what does it look like? What does it optimally look like to to plan? build test and deliver Really every six months Right now. We're airing on the side of stability because that's what customers primarily looking for and we're still rolling out quarterly planning and We're still working on consistently meeting deadlines like we're we're doing pretty good on this like things are coming out on time Or within one day, but that's because of a lot of high contact management not because everybody's used to it yet So we're making progress and then updating out moded tools. What does that actually mean? So For us it means that we're using a combination of bugzilla and Jira So bugzilla is like a big community interface. It is it is where developers do their work It is it is fundamental. It's foundational and the way that we've adopted Jira is that there are just some BZ's that are in bugzilla Where we set a little flag in the BZ and it gets mirrored to Jira and Jira We have like our high-level plans and we can drop those BZ's into epics And so we have this wider data container to hold work in so if there's like 20 different development items across Like three subsystem teams we can have three epics that go into one feature that that are all in Bugzilla, so if you're an engineer you work in bugzilla You don't have to do anything because your workflow didn't change at all. It's changing people's workflows is unpopular but if you are one of the team leads you did planning you connected everything up and You can then see the high-level effect one thing that we we knew was really important was to not have to replicate data Like if there are two sources of truth one of them is always going to be wrong And that's the one somebody's gonna rely on so It's so important to To have there only be one source of data and have that source of data be something that people actually want to update So that there it's not like a burden to go in and get things be current It actually has to be part of their workflow for them to be happy and So changing bugzilla was was a non-starter and of course also When we went with Jira what we discovered was some organizational issues that we were completely unaware of so I mentioned that that Balance between development and other roles being out of whack But what actually happens is that the way bugzilla is set up is also developer centric like the the most people that do Work have a workflow that works really well for them So everybody that isn't that Their workflow their work their output is kind of hidden somewhere else like you will never see in the BZ The documentation that's going to be updated you won't see the test plan You won't see any of this stuff. It doesn't even have a place for that to go So how do you know that documentation is important? How do you know there's a plan for testing? How do you know that you need to hire more people because that thing doesn't exist actually in Jira? We actually treat all of those different things as as on parody within the same epic. We have Bugzilla's for engineering activities. We have test plan test case development verification documentation doing demos They they're all there side-by-side and by raising the profile thought-and-out non-development work We're actually creating visibility so that development knows. Oh, I I need to actually be done on time because all these other people Can't even start until I'm done. So We've gotten that far, but we're still making use of this. We're still kind of feeling out What is the best way to use? Epics should we use subtasks like you get all these features and you kind of go crazy you it's like, oh, let's do all the things and Making good use of tools means kind of standardizing on practices that actually work well for people You only learn that through iteration. So we're iterating and of course process automation like actually having to update things in in Jira isn't a great experience if If it could just automatically update when BZ is update like your epic status, that would be super because right now We have two two sources of truth if all of the all of the bugzillas are being updated regularly But there's some data type above it like an epic that says I'm just waiting to be done and and all the BZs under it Are done that epic should say I'm also done and without automation and that only happens by human updating it Which means it's no longer accurate which means we've kind of missed that that whole point of a single source of truth So we're working on that automation So with all of that in mind, where did where did we end up with it? so I Would say right now the the rel organization has reluctantly gotten into a mindset of continuous improvement It is no longer the case that teams are like, ah, we've launched rel. It's back to normal. No change We'll just be our our stodgy cantankerous selves dissatisfied with the way things are but living with it It's it's actually the case that there are changes that are going to be happening Every single release and we're trying to roll them out responsibly and respectfully But there's an expectation now that there didn't used to be there's an there's this notion that you can actually Introduce change for the better instead of just complaining about it, which was the the state for quite some time We also have a much much greater state of empathy between roles, especially between development and QE like Like it is they are they are our brothers and sisters in engineering now the fact that there's engineering in both of us both of our job titles is is no longer lost on us and In those two things We are when we're working in fedora when we're working upstream We are really heavily focused. It's not perfect yet, but we were heavily focused on delivering changes that are opt-in that that wet people use them, but not have to use them that what customers or end users all Choose the things that they turn on and continue to get the value out of Fedora out of rail now sent to us that is right for them So they don't have to kind of Take a long time to adopt new releases, which is really where this all came from was Changing versions. It's hard Well, seven was based on fedora 19 and rail eight was based on fedora 28 Can you imagine just like doing a yum update from fedora 19 to 28 like that would It would fail first of all And your system wouldn't boot and yeah if you And and even then just there's there's so much so much change and so much of it was an optional Like building those options in were it was a fundamental and so between continuous improvement And and like respecting roles and and like developing technology for for people to actually use We're gonna say it where we don't have to plan a 24 month schedule out and and like design technology for yesterday's problems that that no longer are relevant for today's solutions and You put those all together and you can actually make your changes just in time you can You can iterate you can build for the current moment and that's really the biggest change for eight was that Shorten schedule paying attention to customers designing for opt-in means that you deliver the right things at the right time any questions Is that it's hard to make expectations about engineering Have you looked at like partitioning how the Engineering effort and planning stuff goes into like instead of doing it at six month intervals Partitioning it like into one or two month intervals and see how that if that Better for for that kind of thing. Oh, yeah, we are we are working on micromanaging that schedule so We launch a new release every six months But the total cycle time like the from start to finish is like nine and a half months right now Which is way too long and we're trying to shorten that but there there is a period of planning Which is principally why it's longer than six months, and then there's a development window a testing window And then a final testing window so within that development window Apart from just shortening it. We've actually set it up so that you have to do your features first and Then your bugs I mean you can do bugs But you're incentivized to get your features done early and the reason we do that is that features are generally more invasive But they also require new novel tests to be created they require new documentation to be written So if we get the things that require more people done early we can parallelize like all of this Like my summary for this is we just didn't like make minus j on rel like just setting up setting up the make files to run in parallel is kind of the foundation of it and and absolutely part of that is by shortening windows and by Making the things happen early that are better to happen early Yes, not there yet right now the Jira server is behind a firewall work is being done to make that not true Yeah, yeah, I want to I want to expose Jira I want I want community to be able to engage with us where we are What Yeah, I'm familiar with some of Jira's more interesting features because at my workplace Yeah, every tool has a place Yeah, Laura I would say the fundamental reason why all this change is necessary is that nobody knows why all this change is necessary like literally everybody is complaining about everything all of the time and Change if you're not paying attention, you don't know why things are happening But fundamentally everything that is happening is to address some problem. It's like a legit problem. So Like if if developers are unhappy about something and We take some action to fix it Will they be happy that we fix the something or will it be unhappy that there is a change the answer is yes What we generally try to do is Talk about the why extensively the fact is a lot of people don't notice the why everyone's overwhelmed by like sheer volume And so we'll don't notice the why until they've actually run into the what and then there's like a retroactive Why is this happening to me and then you explain it and they're like, oh that makes sense Why didn't I know that like because you didn't go to this thing or read that thing or hear this thing like over communication In with 1200 people is actually not possible. You cannot say Something enough times and enough forums to actually get more than like a 50% hit rate Then answer your question or did I just like filibuster? Oh, yeah, actually, that's a great question. Yeah, so I'm gonna repeat that so the question is is The result of all this the developers can see more of the result of their work in the why the answer is absolutely So here's the thing when you're just working on BZ's if you're just working on a task You don't really know where it came from you just know that it showed up and and for some reason you're working on it And you might want to know why am I working on this thing? What what does this connect to and the whole point of having planning tools is that you can connect your work to? like a broader objective to a greater goal and Our theory is that if you have like transparency and the reason why you're doing something you can make better decisions possibly without even asking somebody so if if you take the trouble to to like Look at the working go. Hey, what does this connect to and then read the thing it connects to you can go all the way back to a Market problem you can see what other things are being worked on and how they're supposed to work together like these things are meant to Allow greater transparency to increase understanding to actually give people like the the holistic view not just this little micro bit of implementation Uh-huh So I would totally defer that question to Jen, but I think she'd say about two-thirds When we get to a hundred percent all sorts of things happen. It's gonna be great All right other questions. Thank you for coming