 Okay, I got a we better get going because we got 45 minutes. I am Chris Edwards. I'm a senior manager development manager at IHS I Am not here to sell anything. I'm not a consultant. I'm an agile practitioner I come to these conferences because I like talking to people. I like learning from people so After this talk, I encourage people to come up to me I want to understand more about what people's experiences are if you can take anything away from this How does this work in your context? So? disclaimer, this is not a talk on architecture I'm here today to talk about leadership What I'm really going to talk about is how this architect role fits into an agile organization So there's a lot of questions, you know, if you think you look at the agile manifesto It doesn't really talk a lot about this architect role talks about team self-organization. We want to empower teams We want to give them control That seems a little bit contradictory with this concept of this this Architectural architect sitting on his ivory tower making decisions generating large documents Encouraging large backs batch sizes So is there really a place for this architect role in agile organization? so I'm not here to talk about what I think your organization should do what I'm really talking about today is is our experience my experience in this role Hoping that some of the things that we tried you can take back and give a try on your own So you just I want to set the stage a little bit of our context We're relatively small group within our organization. I chess itself is 8,000 people But our part of the organization that was working on this product is about five teams It's a pretty good mix each team sort of had their own mix of their development their their process within their team We are a thick client desktop application It's a engineering platform for petroleum engineers written in C++ The code base is fairly old the product itself was fairly new But it's built on a code base. That's you know 30 some of the code in there was written 30 years ago and We recently adopted agile so this the story is a few years old now, but when but when it started we had just started doing an agile transformation and The main the main story revolves around a major project that we had which was to take our thick client and convert it to a distributed database platform multi-user platform So we started we started our journey With these this new agile transformation We really wanted to be pure to our agile principles. We we were we wanted to empower teams to self organize We wanted to give them control So our first approach to architecture was totally hands-off We we formed feature teams we gave them projects and we gave them full autonomy We believe these agile manifesto says that we should leaders should really step out of the way and give the teams the space to get the job done and We actually saw some some good results with this We had some projects that were they were pretty Well-defined they were in our they're in our skill set So, you know, maybe it was an enhancement to an additional feature or a new feature that was you know another engineering feature or but What we found was on this new project This new multi-user project required skills that we didn't have an organization We never had anyone that had worked in distributed systems. I didn't know no one in our organization had ever had to deal with things like database concurrency and The same approach of just handing this project the teams doesn't really work people people were actually getting frustrated The project was was having trouble getting off the ground and people were getting frustrated. They were actually screaming at us for help the agile manifesto This was a piece of the manifesto. I think we kind of ignored so build projects around motivated individuals Give them the environment and support they need and trust them to get the job done. So These people were not motivated. They were frustrated. They were the people actually dreaded working on this project And we were not giving them the support they needed so This was his first realization we had about this architect role is that this concept of empowerment We want to we want to just take our hands off the wheel and give teams the space There's a little bit more to it than that. We need to provide them with tools. We need to provide them with skills training And we need to figure out a way to do this without sacrificing our agile values Maybe maybe this really is a time we said for having someone taking a higher level view and Finding a way finding a path forward But how do we do this? without this person becoming a commanding control design authority Okay, so So I was actually tasked with doing this the reason for that was I had been on the project along I'd worked on this product a long time I had a pretty in-depth knowledge of the code base and I'd been involved with some of the lead-up of the project So I had a lot of the context so it kind of made sense that I'd be given this this task and I really needed to answer. How do I do this? I wanted to avoid this? I wanted to avoid me Doing a huge amount of upfront architecture work And then throwing this, you know large design document to the team and I also wanted to avoid becoming the the Boss the guy who specifies standards that everyone must follow What we really need realized is that rather than a you know military commander what we needed was someone who could scout ahead Someone who could look look down the backlog look for you know challenges that are coming down the pipe do some investigation And then feed a stream of information to the team someone who's a servant to the team someone who's not an authority figure So we arrived at this concept of the architecture scout and the scout and this idea is that that the team still own their designs the scout is there to provide information they are a service Now I did some large I'd say not large design, but I did do some documentation. This wasn't totally just a a Prototyping or information gathering thing. I did do some you know, I figured out. What are the layers of the system? I fed the team some design documents, you know, here's the responsibilities these layers But primarily the way I communicated information the team was through prototypes and examples The teams use these prototypes as templates to work from so whereas before they're struggling They they have no idea where to get going, but now they've got something to look at they can use these examples as templates for their next work and The teams really hit the ground running with this. We saw velocity improve almost immediately Morale was improving people were excited to work on the project. We were getting things done. This was really really great for a time so Here's the five teams and here's little me architect guy figuring all this out And this is a little bit of a representation of the communication structures that we had I Was feeding information to the teams? And if people had problems, they'd feed them through me. I would come up with some solutions I would help them out the teams themselves weren't really communicating Occasionally Teams would have to consume each other's work. We're building this system So we've got modules and they need to come consume the modules each other's a built But maybe one team has a different idea of how things should be designed than another and what we started seeing was Conflicts forming between the teams. So here's an example, you know One team consumes another team's work and he says oh, this is really poorly designed. It's got like a thousand classes here It's it's complex. I don't like this. It's hard to understand and the other team says well If I have just one giant class, that's not going to be maintainable. I Think there's elements to truth to both of these statements But the problem was they were looking to me to define some standard. Well, you're the architect Can you just tell us what the system you tell us how to design it and we'll design it? We don't we don't like this conflict Really what they're saying is work harder do more do more and What I started getting to the point was I needed to be really in a thousand places at once I I need to be looking at everyone's work I needed to be kind of running around and and and seeing you know, what are you doing? Oh, that's not consistent with what these eyes are doing and I need to to fix this problem and I remember at one point. I actually Realized that I was terrified of taking a vacation because if I left for any period of time Well, they're all these mistakes are gonna get made and and and I can't do that because because then I'm gonna have to fix them And we're gonna have to do all this rework and Yeah, this was not fun so What we really got into a situation was that I I'd become a single point of failure on the project. I'd become a bottleneck for decision-making and Not only that it relied on my skills and decisions To be really really good because if I was wrong, it's gonna be really costly So the other kind of question is what if I am wrong and if I was wrong, how would I even know and In fact, what we found out a few months into the project that there was a pretty major problem with our architectural approach is it was there was a part of the architecture was extremely unmaintainable and We realized that if we were to continue this approach in the long term It would be completely unsustainable and we had to do a ton of rework and and take a new direction And I had some conversations with some people about this and I was kind of like well like what do you think about this? And they're like, oh, yeah, yeah, this this doesn't make any sense Well, wait, how long have you known that I? Kind of suspected this a while ago Why didn't you bring it up? Well, you're the architect. I just assumed you knew something. I didn't I thought you had a really good reason for doing it This way. Oh Okay well What was happening was When I was doing the design when I'm doing the architecture, there was all sorts of assumptions that are being built in The teams weren't aware of these assumptions. They did and what I wasn't saying was the detailed work I wasn't in the weeds Realizing that all these assumptions I built in were being completely invalidated in the day-to-day work Because they weren't aware of the assumptions. They had no way of communicating to me or knowing that this was the thing that they I should question There was a study done recently. I think there's a TED talk on this that they found that Medical teams they did a study of a whole bunch of medical teams And they were trying to find out what was the key elements in the high-performing medical teams the teams that were really successful And there was a weird element to them that the teams that were the highest success were the ones that made the most mistakes That didn't quite seem right so they dug deeper and what they really found was it wasn't the teams that made a lot of mistakes It's the ones that brought up a lot of mistakes the ones that Communicated to their team because they understood what was going on and they didn't feel Uncomfortable telling the team these things, but I'd create an environment Where the architecture couldn't be questioned the architect couldn't be questioned and the team didn't understand the context of the work They were doing So what we really had here was a people problem This isn't a technical problem. This this is a leadership challenge and I I this was when I really started coming to this realization that The architect role is more than just a technical role that there's a real fundamental human people component to this and So I'm a I'm a software developer I'm My trade is to tell computers how to work solve technical problems. I Was finding technical solutions to what I thought were technical problems really what we have is a people problem. I Love this xkcd comic guys Engineer as well, and he's trying to solve the equation for love using math This is probably how I would do it too my normal approach is useless here so My view up until now on leadership was fairly one-dimensional I kind of thought that you either you know, you have the the drill sergeant who tells people exactly what to do Or we have our our agile Empowerment where leaders take their hands off the wheel and just let the teams self-organize and decide And but neither of these was working So I had this problem. How do I serve teams without just telling them what to do? I need to I need to help them build this architecture of the system, but when I just give answers People will just follow it whether they make sense or not Fortunately, I had a lot of leaders in my organization few could coach me they provided me a lot of resources I got a lot of support here one of the one of the resources that Was pretty pretty powerful pretty impactful on me was just looked by David Marquet turn the ship around so Marquet was a submarine commander and In 1999 he took command of a ship submarine called the Santa Fe And he had he had six months to get this ship ready for deployment The problem he had though was that he'd been given this assignment at the last minute He'd actually been preparing to take command of a completely different submarine one that had different technical specifications different standards and There's no way that he was going to be able to get that ship ready If it relied on his ability to give the right orders at the right time Because he just wasn't going to be able to understand the technical specifications of that ship fast enough so David understand understood that in organizations. We often funnel Information to those who are the decision-makers those in the authority positions Whether it's the you know the VP or the architect or the manager or the product manager or whoever we Funnel information to them so that they can make really good decisions You'll see you'll see leaders do this They'll go into meetings and they'll just sit there and they'll ask lots of caught lots of questions And then they'll make the decision meeting over so How instead rather than moving information to the authority How about we distribute the authority to those with the information because then we can make fast decisions? We can we can respond quickly to new information and those who have the information are going to make better decisions So I like this quote leadership is not what you achieve in the moment leadership is what others achieve the moment you leave so If you're terrified to go on vacation because you think everything's going to fall apart Then I think that that maybe you're not meeting this and and this was definitely the case for me So the other thing David realized was that if you want to take your hands off the wheel You want to give up control and give authority you need you need a little bit more because if we're in a situation Where if I take my hands off the wheel and everything falls apart Well, then empowerment is not going to give us a good result. We need something more so he identified these two pillars and In order in order to divest control we need to develop the technical competence and those doing the work And we need to create organizational clarity. So do people know? Do they have skills in good software design? Do they know TDD the day-to-day? Knowledge do they have knowledge of enterprise architecture of distributed systems of of database concurrency? They need to have all this knowledge And the other thing they need is to have the understanding of all the assumptions that are going into the architectural decisions They understand why we took this approach so that they can know when to question it And when to try something different Once you have those two things in place, then you can really hand over control here team So David he marked had he made a he made a pledge to never give another order Instead of giving orders. He replaced it with intent So he would communicate what the what his intent was and then rather than for permission to things They would communicate to him what they intend to do and this is pretty powerful And and actually I give you guys all a task next time you're thinking of asking your boss For permission to do something instead instead say I'm gonna intend to do this and here's why here's what here's what went into my decision and a lot of times When managers or leaders see people do that what they actually see is man This is someone who's really taking ownership of their work and this isn't this is actually something we don't encourage enough I think so Marquette's Marquette's book kind of opened up a new a new dimension to how I think about things So this is great. This is from Spotify. A lot of you have probably seen this I Kind of had this this one-dimensional view down here We either you know have 100% control or we have 100% autonomy. We knew that didn't work. So Marquette's Concept of organizational clarity is very similar to this concept of alignment What we really want to do is figure out how to get people up here Excellent technical skills. I'm aligned on what the system is and I have the autonomy to figure out how to deliver it so how do I do that and so It took a new approach to this architect we viewed me more rather than more as the scout now I'm more of a coaching role. I'm going to help Build that help develop the skills and understanding and the people who are doing the work so that they can make the decisions We want to divest the decision-making So one of the things we did we formed this daily design meeting We realized we needed to do some catch-up because the teams didn't have this knowledge So we invested 30 minutes every day where a technical lead from everyone Form each team would meet and we would talk about challenges that the teams are having and we'd work through them together As a team we would discuss how it how would you solve this problem? And what came up was all sorts of realizations that we were totally not in the same page and then Once once we came to a conclusion. We wanted to avoid that this team became the new New authority so the technical lead would bring there the one the technical lead that brought the challenge from their team They would bring it back to their team and they would repeat the exercise We wanted to reinforce that the teams themselves are the ones that own their decisions Okay, this was a this is this is a good suggestion from Marques book resist the urge to provide solutions So a big part of my job was usually I'd be sitting in my office somebody come by they have a problem. They have a question and I'm a problem solver. That's that's that's that's who I am that's kind of core to my nature So I want to solve problems. I mean you bring me a problem. I'm gonna give you an answer But every time I do that I'm communicating To the person across from me that I own the architecture. I'm the decision maker. I'm the decider So resist the urge to provide solutions, but we have to replace that with something So what I started doing was if someone came to me with a problem I'd I'd sit there and I'd I talked to them I'd I'd partner with them to solve the problem might understand, you know, what would what what solutions? Have you already considered? Why would you choose this one over that one? I might I might ask some questions about some things They hadn't thought of but what I really want them to do is I want them to walk away from that meeting owning the decision that they made Okay, and what's in what was really interesting about this is after after a while of doing this People would would already know that I was gonna ask these questions. They'd approach me in my office and They'd already have things prepared to say, okay. Here's a problem. I'm having Here's some things I've thought of You know, I really like this idea Because of these reasons I think this was one of the better ones and this is what I intend to do about it Not they're not asking me permission. They're telling me what they intend to do and We got to a point where I could just basically say yeah, that sounds great So in these meetings in any discussions in the meetings, I'd ask a lot of questions the questions I ask communicate values Which of these solutions is going to be the easiest to accommodate change in the future What are the impacts on on performance on reliability? What do I want you to think about? When you're when you're designing the system and the questions. I'm asking are communicated them What I think you should think about when you're building the system Okay so the last last kind of part about this is Going from a position of Building a system. I personally invested a lot in the development of this product And now I'm having to really really take my fingers out of the weeds and and let people make decisions that Maybe you're not always the best realizing that that mistakes are going to be made and letting go letting go of control was very hard for me, but I Know that I've been in meetings where I've done this facilitator thing and I've been asking the leading questions But I've really gotten the back of my mind like this is the answer. I want everyone in this room to come to Everyone in that room knows that I'm trying to get them to that answer. That's not really the same thing as letting go of control So, okay. One thing I want to say is that this design meeting didn't come without any problems We did get some jealousy from those kind of attend this kind of Became the new like expert authority meeting man. These are the smart guys. I want to be in that meeting Why can't I be in that meeting? And not only that we still had some conflict between teams We were divesting control to the teams themselves and the teams were taking ownership of their decisions But the teams themselves weren't always agreeing and you could see some conflicts And the last one is we were still having this problem that this design group was still kind of seen as a design authority So that was a challenge that was hard to overcome So the main thing I want to talk about now is the the conflict A lot of you are probably familiar with Conway's law Organizations which design systems are constrained to produce designs which are copies of the communication structure of the organization so If this is our communication structure and really now it's it's not me it's five people in the middle here Then can we really be surprised that we can we're gonna build a system that's that's you know Got modules being built that are all built very inconsistently or not and not communicating well with each other So how do we solve this problem? So One of the things we did and I would actually say that this was a this was a side effect This was not the intent that we were going for We we developed these sort of design steps. This was a framework to have discussions within our design meeting and The reason we created this is because a lot of our design meetings were turning into arguments People would you know get really attached to an idea they would have I'm sure everyone's been in a meeting where Someone's like arguing tooth and nail for the idea they came up with they're very attached to it I get pulled into this really easily What we tried to do was develop an algorithm I mean we're we're programmers we like to develop algorithms So we've created an algorithm to solve this problem This was a framework for having these meetings to pull us out of this this positional argument So so at the start of every you know someone would bring a problem. We'd make sure everyone understands What is the problem? We're trying to solve this is gonna keep us focused Because we go down rabbit holes Then we go in a solution mode idea mode Where everyone? Everyone is allowed to throw ideas onto the table. We'd actually put them on the whiteboard Everyone's ideas are on the whiteboard. They're all equal and there's actually something interesting about us about us all standing back Separated from ideas now. We're physically separated from the idea. I came up with and all the ideas are equal and The last thing is we we did objective Analysis of each of them. Why is this one a good idea? Why is this one a bad idea and Okay, so something I give you a try if somebody's if somebody's arguing with you and they're really arguing for a point ask them Well, what's a what what is one thing about that you don't like? Everyone had to talk about everything that's good about other people's ideas and everything is bad about their ideas and What this does is it pulls people into interest-based thinking we're thinking about what are we what are the outcomes? We're trying to accomplish rather than what what what is the idea? I want to win So this is something I actually realized recently is that we basically reproduced Edward de Bono's six Thinking hats minus the feelings one Which I actually think maybe could have helped So Edward de Bono's thinking at his objectives. Let's define the problem. Let's go into fat. Let's let's identify facts ideas Positive and negative outcomes and then arrive at a conclusion and agree together So what this does is it pulls people into parallel thinking and we we're all in the same mode and it's a conflict resolution framework so What's interesting is what we what we developed as a way to stop fighting in that meeting Actually turned into a way to help the teams themselves Get along better because what started happening was people the technical leads would go back to their teams They use the same framework And people started realizing that when we talk in this way We're not fighting anymore and everyone feels better And if we and I've actually been in meetings where we're me and another guy We'd be we'd be fighting and then and then someone would say Why are we not doing that thing again? This doesn't feel right and we kind of all tend to migrate back to this this way of discussing What's interesting is now this Framework of having conflict resolution was embedded within all of the teams and all of the teams had this common understanding That if we're going to disagree this is how we're going to resolve it One of the biggest reasons that people avoid conflict is because they don't know how the other person's going to react when I bring something up But if I know exactly how they're going to react if I know exactly the conversation We're going to have and I have a history of positive outcomes of having the conflict then The framework for having this this this common framework for resolving these became a Avenue to have better communication passed between the team. This was not something I expected to happen This was a surprise and I was very pleased about it Okay, this is kind of a I'm going faster than I thought Last point disagreement is a mechanism for organizational clarity. So Conflict is not just something we have to resolve but what we realized is when we disagree when we have deep Disagreement, that's actually when we we are the most Misaligned and these are opportunities for us to to get better and deeper understanding of the assumptions and reasons behind the architecture So I'll give you an example We had a problem one of the team members one of the teams brought to our design meeting and We realized there was really two options we could We could put some business logic in the domain layer or we put it in the database And we had this discussion the meeting and everyone's pretty well aligned within that group that business logic belongs in the domain layer That's the most cohesive for the system So we came we came to that agreement but the side technically brought it back to his team and the team repeated the exercise We want the team to own their decision great They came to the complete opposite conclusion And what we realized we wanted to deeper we wanted to understand what was going on here That there were there were members of that team that had a very strong database background And they felt very strongly that you know database integrity is the most important thing We should we should optimize that against everything else so My initial impulse reaction Well, we should just get them in line that you know the design teams decided we should we should enforce the standard the Architecture says business logic goes in the domain layer. You should put the business logic in the domain layer But if I if I look at this situation through my sort of new lens my new leadership lens my new way of thinking I'm realizing that really what we're missing is is one of our pillars There's this this lack of organizational clarity around what we should be thinking about it in our architecture So what we did the way we resolved this was we actually brought the members of that team to our design meeting We actually spent the next week in the meetings having pretty intense discussions about About all the things that led up to where the architecture is that we looked at all the things The reasons we made the decisions. We really wanted to make sure that we weren't missing something Maybe they were right. Maybe database. Maybe the database was the right way to put it What we came to the conclusion of everyone realized that that yes This was an important thing, but when weighed against the other factors, there was other things in our project that were more important So we did end up reinforcing our architectural approach But we what came out of it was multiple people who had a deeper understanding of the why behind it and We had much deeper commitment within our group and across teams in the approach we were taking Okay, so the end. Hey, we're all big happy family, right? So something interesting happened and I love surprises because They teach me something We've gotten to this point All the teams are gonna go along. We've got these great communication paths forming between the teams then there's little old me Am I even needed anymore Which it's a little scary Because does that mean I don't have a job anymore Actually, it turned out to be a really good thing So I'll get to that in a second, but we we realized that yeah my my role wasn't really needed We come to the point where we were having our daily design meetings and people were already Coming to conclusions. They were solving things in their team if they realized as they needed another team To solve it. They'd just you know, they'd pull the people in they'd have these design discussions They come to our daily meetings and really it just became a reporting mechanism. Hey, hey architect guy Here's the things we decided. What do you think and I just kind of became a yep looks good looks good looks good Well, you don't really need to pay someone to do that. So we migrated to this approach of Full full divestment of the architecture that of the control the architecture the teams themselves own the designs So okay, so what happened to me I actually You put yourself out of a job and opportunities open up So I'm actually in a leadership role now in a different group and part of the organization So this has been a really good this whole thing was a growing experience for me I learned a lot about leadership, which has now opened up new opportunities. So put yourself out of a job. It's a good thing Okay, so just kind of a review we started out here this idea that we need full autonomy, but we didn't really have this alignment or The skills I migrated to this low autonomy thing. I'm just gonna give you the answers What we tried now is is okay. We still have the architecture. This is still the approach But let's start building the skills and understanding of the team and eventually we migrated into our happy place Where the the design and ownership the ownership of design is shared amongst all the teams one thing I learned from this whole thing your approach has to evolve the The architecture scout role I believe served a purpose when we did it The architecture coach served another purpose eventually we realized we didn't need this role at all That doesn't mean that we would just jump straight to doing the architecture coach if we did this again Maybe maybe we have to resurrect these roles again in the future Maybe there's some new role that we hadn't even thought of that we're gonna need again But we needed to continuously inspect and adapt what we were doing and try different things So some learnings for me the empowerment more than just taking your hands off the wheel and letting go You need to give people support Lead through intent. Don't just don't just give answers build understanding Explain the why what why are we doing this? What is the architectural intent? Resist those urge to provide solutions Partner with people help them take ownership of the decisions they're making and help them come to those conclusions Create a framework for disagreement and the framework itself can help to navigate conflict But if it's common across the organization it can actually create this emergent behavior of better relationships across all the teams and the last one When when conflict happens when there's major disagreements celebrate that because you're about to you're about to delve deeper and get a deeper Understanding across your organization. It's a really good thing So I have what 10 minutes left for questions. Thank you everyone for listening Um There any questions? Do we have a do you have a like a hand mic? Go the architect should we know in the solution discussion or He needs to review a leader. I mean that better to know in the solution discussion Or it should be one's a solution let the team figure out the solution and let give you later I'm what is that better? I'm sorry I mean the solution I mean team will discuss among them and come up with a solution or We should I mean architect should we know all in that team discussion or he should be sit outside and review those Okay, so yes, I think the question is is should the architecture architect be involved in that team discussion? I said absolutely because that that is the opportunity that I had to to teach to build understanding To ask leading questions to communicate the values through the questions. I'm asking That is the key point that I did a lot the most of my work in building that Thanks Any of the architectural decision which you wanted you you you showed that okay You had to convince people for almost a week for going for some decision but During the phase of like no spending this week itself is like, you know, too long for them to digest that decision So how do we enforce them to like, you know that to any decision? You've forced decision Once we arrived at this it didn't Be a people People don't want to be misaligned. They don't want to be on a different page This is what I saw is that is that actually once you had the the way of Resolving these disagreements people naturally wanted to do that They the reason they avoided in the past is because conflict is uncomfortable conflict bad. I disagree I disagree with you. That's fine. I'll just do my thing because that's the easiest thing to do Once you create the framework so that they can resolve that I Never encountered a person who didn't want to do that who just like that. I had to tell them what to do it just sort of Got better That's been my experience Second question Being the architect lead You have to like not take care of like now how each team is progressing from their Thought process about what is the problem they are solving? So how do you keep that in line with what you are thinking from whatever product you are trying to build as architect? I had to lean heavily on the Technical leads and I wouldn't believe these were the people that had the strongest understanding The strongest technical skills. I can't be everywhere at once and and this is what you're saying Is it's really really hard to keep track of all these things? That's just not something one person can do I believe so the way we got there was was Step one was really developing the competencies of this smaller group of people so that they could go back and Then the teams themselves can sort of self self-regulate. I think I've got time for a couple more questions We talk about the system architects here, but there is a chain on business architect enterprise architect So how can build that connection? So it is team level I have Build architect team, right, but I don't know how the way business architect is thinking right how we can build those connections So here, I'll let you hold the mic. I don't need a mic. I've got one Um, I don't have a lot of experience outside of this context I haven't I haven't worked in like the enterprise architecture scale So I don't want to I don't want to give you an answer I don't under I don't really know but I believe that the principles of building skills and and and getting alignment explaining why Pushing that down as far down in the organization as you can I recognize that there's Times where not everyone can be involved in a decision you get to a point where that you that just is not feasible to do But I think the principle of divesting control as far down the organizational structure I I've seen this on With user stories as well Right, it's it's that here's that here's the requirements. I'll just implement them whether they make sense or not a Product manager a product owner who's communicating the intent behind the user story is going to have a much better long-term Outcome because the team can understand why they're making a lot of little decisions every day So I think that this concept Scales to a lot of different situations, but I don't have that exact experience. So Sure you first and then okay, we'll do a couple more So you you talked about that you have a design meeting. So my point there is You get away from your architect position and you created five more. So that now you already talked about that every team I think oh why that person is there why not I then How so I don't know whether you guys have solved that problem or is there any idea? How do I solve that problem? I don't know to create again these other people also go through the same way you went through So Marquette talked about this in a book because he said He wants to create a ship where every person on that ship thinks like the captain. I Would I would like a team where every single member of the team is thinking like the architect and that's a long-term goal It takes a lot of investment in people and people development and in skills development But that is the ultimate goal is to really have everyone having that solid understanding Did I ask your question? That The the problem you try to solve that not not single person dependency now another person getting to the same same So at least at least then we had one person You moved one step further, but yeah So the other thing I was developing was the leadership skills of those individuals so that they could repeat that task Yeah, that makes sense. Yeah, I'll agree Why don't we do one more okay? Simple question as you discussed you have a conflict regarding when we need to implement in on database level or module ever, right? Suppose you have decided that now you have decided that it will be implemented on module level So after that do we need to create some guidelines some document guidelines so that in the future? Also, we not know to need not to discuss same thing again. Yeah, we had some very light documentation about that No one read it Just didn't happen and I don't know if that's just because people don't like reading documentation Or the second one is just that the knowledge was so dispersed throughout the team that it wasn't needed That if you had a conversation with someone they'd be like oh remember remember that that's not where we put stuff Okay, yeah, you're right and it became like a self-sustaining Knowledge base that the team itself A lot of times I think we produce architecture because we're worried that if that person disappears that knowledge is gonna disappear Well, if everyone's got the knowledge and I know that I know that's not really like that's an extreme case There's gonna be so there's still gonna be some silos of knowledge, but let's let's avoid single points of failure Basically, it's happens with within our team I'm we discussed and we decided to go with this one and after that we don't have any Guideline over it. So after that we have discussed same thing again And we have decided like that again will do need to do this thing So in the future also some other developer comes in and then again we have a discussion like that So we need to have some guidelines, right so that we can refer it and Yeah, yeah, and I don't have a problem with that like that doesn't I think having some light documentation about you know the general like how did we arrive here and like a historical document, but I've never seen that done. Well if you if you if you see a way that that could be done But they always get lost like the people forget it exists. It doesn't get updated when new decisions are made Okay, thank you If I'm gonna stick around afterwards if people want to talk But I want to be respectful of people's lunchtime because lunch is starting now So I'll just be up at the front if people want to Talk about this more. I want to I'm curious to hear more about other people's experiences I want to learn if you think this would apply to you if you think it wouldn't that would be very beneficial to me So thank you everyone