[Open Discussion] Do we need software architects?

hello and welcome and good day good evening good night good morning wherever you are and welcome to this new virtual dvd today we have an open discussion about do we need software architects so uh for the people joining us on zoo um [Music] after i we did the introduction it will just be an open discussion right and there's no rules at the start maybe we'll need to introduce some later on just so you know for the people on zoom when you open up your camera and you speak people can see you on the live stream so hello people on the live stream as well um nice uh introduction here so i'm going to share my screen what we did today if i can see the share screen there we go so let's join let me show you the mural here we go so everyone should be able to see the mirror board and everyone could enter the mirror board as well um we'll show that as well on the youtube chat so everyone on youtube you can also ask questions and enter the discussion people on zoom can also just use the chat so what we did was ask people asynchronously before this meeting is do software architecture have a bad name and why what expectation do we have well you can read yourself right and thank you everyone for putting in the asynchronous input and there's a few things um that we saw happening here which is uh really nice and i look at these as polarities right so for instance right there's this uh one posted that says um something about um create big documents and expect reading them through without walkthrough right so on and on when we there's too much documentation that by powerpoint they call it i guess but on the other hand we are thankful that they care and help to write good documentation so there you can see there's a tight balance here and and there's more of these polarities um that goes into teaching the teams we're enabling the teams and not being command and control but on the other hand they we're thankful that they enforce regular sync points you see so there's also this tight balance between yeah we expect them to lead and facilitate which is partly commanding but they can also take it too far so i think that's the discussion today and we're gonna open it up and see if people have some thoughts or ideas by watching this uh board we can add stickies to it and and actually the goal here is to see it from both sides right we asked developers from yet architects to do this and so when you speak in zoom um as me well i'm an architect i have a background in software developer i still do software development but most of my time i do software architects so i consider myself to be in the role of an architect who does code yes but more on that side another mostly on development so please when you start and and want to add stuff just say where do you uh fit in right so um with me today from uh the virtual dvd meetup is christina hello christina and uh well i think that is enough for the introduction today i'm trying to find this zoom buttons where i can also see stuff but i i don't see ah there it is and i think that's it so let's start who wants to start joining great intro kenny one organizing question can you mute this blinking bringing every time if somebody enters ah sure thank you so uh i'm really happy that we got to this day because i had different starts on it on this on twitter the first one just have a discussion and the first measurement was a lot of architects wanted to discuss no developer wanted to discuss this open and this was scary because if we are not able to discuss with each other then we won't come together we want to learn and want appreciate each other i am a software developer by the way doing architecture since a very long time because architecture is in the software and the software is from ones and zeros but doesn't live in in in nothing so there is architecture in every decision with what we are making we decide about the architecture respecting it or making it or breaking it so in the second attempt was to create this mirror board and again start on twitter and it worked very well i hope much better as the first one um and that's it about me so what uh christina question to you what sticky was uh well really getting at you on this board what what really standed out and uh i had a few uh i found a few rents like oh we had a huge rent on on we tried the site saying that only these problems appears only in dysfunctional companies seeing each other as the find or the enemy and um yeah i couldn't name one exactly um i'm really happy that we have a lot of posts on all sides i do have something to share maybe on the back of what christina said about the dysfunctional companies that i think is is good to differentiate yeah good and bad architects and by that i don't mean the person but i mean the the people who have the job title uh but in some dysfunctional companies the people who make the decisions about architecture they might not have any more they might be out of touch with technology but they are still the people who make the decisions about what technology needs to be used and how that technology is going to be used yeah so what's your background augusto so yeah yeah i'm i'm a hands-on architect so maybe maybe like like you say i've been doing architecture for maybe 13 years now um and i think that that's a that's a big problem because that that gives um software architects a bad name because then that becomes the the ivory tower architect that makes decisions uh people need to follow and they don't understand why they don't communicate properly why those decisions are and i think one of the most important things is that the feedback loop is broken so they don't accept any any feedback from the development teams and they are not open to hear uh what are the troubles that they experience with that technology um and i think just because i don't want to take more time i think developer experience is also something that the architect needs to to think about so it's not only about user experience and the and the cast internal customers of the company but it's also developer experience and if that's bad then yeah it's as bad as any other problem that we can have thanks totally agreed yeah so i see some agree anyone who sees it differently or wants to add something here no so i just wanted to ask how uh so august to you just described yourself as hands-on architect which i so i am a developer and i wanted to know how how how do i take that hands-on architect as a role as in how what is it hands-on about um so i would say that yeah it's it's someone who uh when there is a problem so i was i yeah let me give maybe a couple of examples one is that when there is a uh yeah a new solution needs to be developed uh it actually does go and tries the technology so experiences it tries to see what is the development workflow um what are the difficulties with it um and then obviously tries to to improve that kind of maybe to digest it a bit for the development team but at the same time it shouldn't be too it shouldn't be too much um and i would say that the other aspect is when a team is is experiencing a problem that they go and sit with the team and they go with the team and they yeah that person pairs with the team uh to figure out yeah what is the yeah what is the issue and i think it wasn't one of the posted notes sorry i cannot read them properly now uh but it's about sharing the knowledge i think that's a a good architect and this also kind of applies to all the levels of architecture they are good communicators and they they help teams and individuals to to yeah to grow up in their in their in their craft so what would be the reason so i i think i i i come from a perspective where there's always good intentions and being an architect myself that's also my inten intention but what would be reasons why this isn't happening in most organizations do you have an idea i do hope sorry i'll talk a bit more but it's going back to the dysfunctional companies uh i think at least for what i've seen and i've been extremely lucky because i've seen this only one in two places sorry um at least when people they yeah they want to to keep on on yeah being the the person with power in the company and and obviously i don't think they do that out of malice but it's just they want to assert where they are um and yeah unfortunately that brings them to a point where again they're out of touch of technology they want to be in that position and and the way to that is to assert their power and not to accept um feedback from [Music] people around which you say and and this is the peter principle right you're being not sure if you know what the peter principle is but if you have hierarchical companies the only way up is to become the next role in the company pd principle says at some point you're being promoted in the least oh i forgot the english at least dangerous position oh the least uh that you're the worst yeah you're overqualified you get you're the where you end up is where you're slightly under qualified good a good project manager isn't a good manager of project managers but what i usually see is people get the role of architects and and and then exactly what you're saying i think also is then they're getting out of touch with the code but there needs to be a feedback loop of of being part of the the the change right they need people architects or everyone needs to be part of that that decision they made but usually they because of the roles in that company they become promoted and then they only do decision making works is that what you're going through but there's never the feedback looped back where they say well now i go back to developer because that's usually not possible because they're already promoted to an architect and then it's sort of like a demotion right they're getting demoted into developer about netflix i think it's summarized quite nice is that the cat no yeah but this reminded me of what a gusto saying right this isn't the cat it's actually a cto holding on to an outdated opinion about a technology is architects are usually in a higher role position but they should actually be on the same level and there should be a loop there welcome to the session so this is why we are here this is why this session uh exists there is no such thing like higher because no but that's usually how it's perceived yeah sure sure i think christopher wanted to say something yeah yeah because uh because i'm the cat and so you don't look like that i am a cto um um but i think the way augustus said he's a hands-on architect i'm a hands-on cto so i actually also dive in and code with developers and i and i see a ton of benefit there um but something that strikes me about the conversation is that um we're talking uh very much certainly about the real like experience of um uh what is often the case um in companies with architecturals that you know they're seen as promotions that they're seen as decision makers that they're seen as kind of out of touch and i think like one of the key ways um to um to like get around a lot of these problems is really to think differently about what the role of an architect is right and um i make it very clear for example i have a team of architects and i make it very clear to them that they are not decision makers um they're influencers they are advisors but they're not decision makers and that already changes a lot um and so i think a lot of it is about kind of setting expectations about what what does it even mean to be an architect and um some of what um i think we we get into a bit with the higher and lower thing is that i think architects should primarily be focusing on the higher level of abstractions of what's going on in the system and the developers are at their lower level and obviously there are clearly interactions between these two and they cause difficulties one way or the other and that's why it's really important for the architects as you say to get in and feel the pain of the developers um and to also share the knowledge of the developers so the developers can understand that connection between what they're doing in that higher level of abstraction um so anyway i do think that it is possible to combat these harmful interactions but a lot of it has to do with expectation setting about what it means to be an architect so christopher can i ask you a question on that right usually i see a lot of people so you're saying i'm telling my architects to be facilitators they're not taking the decision so did they have a lot of problems uh making or letting the teams make the decision did you see that happening um i would say um yes in the sense that um i've my experience is that good developers also tend to have strong opinions and it is difficult for any person with a very strong opinion to let somebody else make a decision that doesn't uh correspond to their opinion so yes there are challenges there um um for sure uh but but i think that um again as long as that is like clearly set as an expectation so they can work toward yeah thanks yeah and what i usually see is also the other friction then right so um having collaborative decision takes a bit longer and sometimes an architect would be put on a pressure of moving forward and then you have this friction between decision taking longer by the team because well you need to align the team right and you need to find all the knowledge but still the architecture is pressured into making the decision so then they turn what i usually see turn to command and control right okay then i'll do it and at least we can move on right so yeah you have to have a patient cat yeah although we so we we this is on youtube and it's gonna be recorded we've played with this at the client where sema is and where i've just left um because the you're exactly right right if you kind of if you move from one particular making the decision to potentially everyone making a decision you then you open yourself up to to paralysis right while everyone agrees on the decision so we went a step further instead of taking a step back so we implemented a a mechanism whereby anyone can make any decision as long as they speak to everyone who's impacted and everyone who has expertise so then that gives the architects a means to collab you know share conversations share thoughts point people other people all this kind of stuff and instead of making an architect responsible for the for the outcome we used adrs to document them and then whichever team made the decision we're holding to it right um and it's very interesting to see you know previously you could get people making ad hoc decisions suddenly when they've they're given the power but also the responsibility it's um you get some crazy decisions to begin with but then people very rapidly learn so we got quite good at making shorter term decisions for littler things or or bigger things sorry so we could revisit them and stuff but that was amazing that then architecture became a task as opposed to a specific job title yeah so that was yeah we're doing exactly the same now where the change management is like if you want something to change create an adr propose it i'm the architect call me and i'll facilitate it but i'm not making the so that works what were the pros and cons there did you have any cons to that because that's a whole different way right because we do it's not enough yeah steve can talk about this because we so there's a blog post coming from from the client when he gets uh when he publishes it about and he's it's called the roller coaster of autonomy but sema can talk about this a little bit right so don't name the clients okay thank you andrew yeah but as christopher said uh it is so we i'm a developer and we can be very strong we are very opinionated people and architecture really is about collaborating with different teams so we were actually five six teams and for me the difficulty was to uh so the rules that andrew set out were that you have to let everybody make their own decision and the difficulty was not able to actually say that you know what you're doing is wrong that's not how you should go ahead with right so you have to hear them you have to listen to them you can try to convince them but that's it right that's that's where it ends and then they create the area and that was a very interesting thing so it doesn't go in a loop forever so a team has an autonomy to decide and go ahead with the decision they make unless they are convinced by other people but that was also a difficult bit for me personally to say okay to let it go yeah so i i think there's another connection here which is um uh interestingly enough it's about devops culture really right which is the um you you have if you're going to be um given the ability to make those decisions you also have to live with the consequences right and so um you you have to be in a position to feel and experience what happens as a consequence of those decisions and that really is very much a devops culture yeah 100 and this is what what is sorry this is what i wanted to say what is missing the skin in the game yeah with a feedback loop with the ability ability to to enable and to empower people and step back and accept errors it's just like raising a child so you have to let go but with the skill in the game on both sides or on all sides the game becomes more leveled and it's not higher and deeper because every every person working in a company has to do his job or her job the best the cto it's cannot do anything because without the developers and and the other way around so the game is the most important part and the feedback group i can understand and on the other hand do people want to take the accountability because stage one stage one of the roller coaster accountability is no one believes that you've just told them they are completely empowered so nothing happens stage two is they all believe and they then you get chaos because everyone's making decisions 15 every minute and then stage three is when it calms down and it gets back to be normal on the other hand i like not being accountable and just being told what to do that's also a guilty pleasure i can say right someone just makes the decision for me and i just do it what's wrong with that yeah and that's at least 60 percent of people see me right and what and what would be wrong with that right so yeah it depends on the company culture do you want this do do you want to build a car to have a company where you decide everything you cannot have you are the one person bus factor 100 and you are the most important one and you have all the power all the accountability do you want this then hire these people and if you don't then let them go yeah just tell the rules and say okay this is so it's also on to the person itself to let go right we're all autonomous persons so but yeah that's that's i argue with avraham did and abraham said well i can abram poopko he said right i can believe in a capitalist model where they're shareholders it's their money so it's their decision take it or go on one hand i can argue for that i won't i don't want to work in that kind of culture just so you know but yeah i i can argue for that as well so i think a lot of this came out of that type of culture i can imagine i think it actually promotes collaboration more uh i have also start i i do not know and i may be wrong but it is architecture right so no decision is really the right decision it's not that this is the right way you can go this way far that way you are just choosing um the pros and cons right so you will face one thing altogether and when you are actually talking about it together it may not be the decision that you want to go ahead with but it's it's not too big a deal because you're just saying that okay i'm saying this it's not too big a deal sometimes it may be but but sometimes or most of the times it's just not too big a deal and we can actually decide and when you're lots of people are thinking together it's also you so you may actually propose something but then you find out from other people but so it actually uh has more thought processes right so you actually think about it more so that's useful so you may even change your mind yeah yeah so here's a nice uh comment from anton from the chat right so and and i like this perception as well perspective as well this is similar for board members as well sometimes where architects as well right i've witnessed this myself with architects while being a developer right there's an architect they are there for one year set a strategy leave another architect comes in different strategy and this is a lot of teams are constrained by tech choices made previously it's not so common that teams have true autonomy also because engineers will not stay long enough to feel consequences of the decision so how yeah how would we deal with that right so yeah and i i i recently saw a right meme for that right let me find it but yeah right writes unmaintainable code leaves company yeah the feedback looping is again not existent i mean you have to be able to give feedback to writing that code should be stopped at the first review or second so it's nothing which must go on forever and the same regarding opinion and mindset and losing touch with with technology is not about not only about technology but decisions like uh changing technology from let's change everything from react to view do you think about the consequences do you think about uh are there enough people to hire it's not only technology it's it's much bigger it's a strategical question and discussing these decisions and putting them in document them um can lead to a situation that everybody can leave but this is the idea they're a situation somebody can come and can leave without letting everything burn down after that so burn up or burn this belongs to the culture and to this developer experience yeah i i agree with i agree with that sort of at um at the at the level of the small that is like it is true that any person should be able to come and go and things should be able to continue to run smoothly but if you have a culture of high churn high turnover and nobody stays for long this is a bad sign and so um so you know what anton is saying about the fact that not many developers stick around long enough to experience the consequences of their decision that is definitely a bad sign and it's a real indication of needing to build the right kind of culture and i think very often that kind of culture includes um making sure that people are a empowered be given the opportunity to make mistakes and learn from their mistakes without having you know having terrible consequences and and then building a culture of of really um like collaborating together to toward a purpose right and um i think that goes a long way toward um building the types of relationships that will be positive instead of confrontational like when we see in some of the problems with this hi guys let me maybe clarify what they meant by that statement so because from my experience i've seen that people sometimes they they see some new technology and they they're very excited they're very keen to use it and and and they just use it like i seen people replacing i don't know sql with mongodb and then implementing relational model and mongodb or using some open source library and so on and i want i want to comment chris on this thing that you meant you mentioned that it's bad sign but i think if you look at the industry average time that engineer spends in one company something like two or three years and i think it's okay to expect that an engineer will leave your company in two or three years because this is industry average and and that's that's why i think people who for example you use amazon cloud and then suddenly someone says let's i want to use google because they have cool thing called whatever full bar and then in three years he leaves and you need to deal with google so this is what i meant but would you accept such a sentence as an argument it's not an argument google is cool because i mean i mean what i'm trying to say that there are some very passionate people and they are like you know experienced and you hire new senior engineer yeah bring some new technologies and he brings his experience and then three years he leads and if you don't have someone who is supervising that like someone like city or or like i work in sweden right now and it's it's very uncommon to have architects we don't have architects at least in like small and medium companies but we have tech leads for example and tech lead is someone who's supposed to kind of supervise what people are doing so they don't just choose random cool open source library because he read about it yesterday and some cool blog post yeah so um that reminds me right about teams that have no hierarchy or flat organization the problem usually there is also power dynamics like ranking if you not make explicit the decision-making process then this can be a problem but i think this also has to do with it with recruitment right if i recruit someone i wouldn't look at technical capabilities but more on how what for you is the most important important values value and for me i hear a lot of well not a lot i hear some senior developers call themselves seniors and say that they don't need any coaching or mentoring so for me that well by default doesn't make you a senior anymore and i usually some there's something wrong with the recruitment process there so my friend juan is uh interim cto and well he's he's now experiment with including people in the recruitment process right so the team itself needs to be responsible also for getting these new people in so they can experience and if they would find this during the recruitment process well you're my new tech lead or even well in my company i get to be in the participation of a new manager right then hopefully and we all make mistakes then we can well get these things out hopefully this is this is it belongs to the part skin in the game i mean why should somebody at hr care about my team colleague more than hired and checked it is my i want to work with her every day and i want to make a great team and i don't i know how teams what the team is lacking so of course short development or other teams should be involved the other thing about skin in the game and it's like very post accelerate but the kind of thing that anton talks about is easier the kind of mindset is easier if you're not shipping you know you're just building a big product and then a year and a half you're going to release if you've got a release you know if you might release in three days time or maybe later today or maybe you know in a month but most people are that then changes the dynamic right and you can you you can flush out people quite quickly who who talk a good game but yeah that's that's kind of where i went as well is is you know two two years that should be plenty of time to feel the consequences of the decisions that you make right um and uh so i also noticed that um augusto posted in the chat that average turnover is more like just above one year right and i would say like two to three years i could i can live with two to three years potentially if if it's really just above one year and your company is at that kind of average i do think that's a bad sign even if it is the industry typical or average that that doesn't make it a good thing right and not something that i want to live with right i i don't want that i want something much better on the on the hiring thing like it's not a very i was surprised when i read it but um i've met some people from netflix and everyone in the bay area they all move apart you know moving once a year in the bay area is kind of standard right the people i know at netflix have been there for ages which is a big deal but in the bay area that's a really big deal and then if you read some of the books by their old uh head of people or whatever chief people officer um how they treat people and talent and make people autonomous and kind of look after them when they want to stay and pay them to leave if it does if it kind of doesn't work out for them that's really interesting they make it easy to hire the right people they make it easy to make you feel you're being paid and recognized for what you do because they ship right but then if the if the phase of the company changes from like i don't know startup running really fast just get it out the door to slightly more boring but you know building chaos monkey and stuff then they they let you go right so and that's really interesting and so people i know been there for a long time this is developer experience it works very well in in a very quickly growing stacked up like netflix because you can give shares to people they will get more and more value over time you can afford paying insane salaries but for us i i assume most of the people here on this forum we are from europe and in europe it's more uncommon to have these crazy growing startups and big stock piles and and you know three hundred thousand dollar salaries and so it's i don't think it's fair to compare us and netflix or even bay area i think but it's interesting because lots of them are famous netflix engineers and could leave to go to another company there i know a lot of them have been you know other companies have tried to entice up you know they all do talks and stuff it's interesting that they stay so then maybe they've got good stock options right but um you know they could have gone to uber or to to facebook and stuff and they haven't which is quite interesting because i think at some point the salary in the recom you know i think i think fundamentally at some point being paid a certain amount stops making a difference and being able to ship your code and see people use it makes an equal amount of difference there's several people saying this and i think there's a lot of research at some point there's a turnover that salary doesn't yeah it's obviously quite you know what i mean it's obviously not not a little amount of money but at some point you know shipping code i've worked in too many companies where we didn't ship code and it's just you know you don't you don't feel any value from what you've done right so exactly would would be anton would this be you said before uh that you would see some supervisors and tech leads should supervise is this something which is important for you or wouldn't be something more important to be able to ship and see how the customers are happy or not or catching some bugs before they are released or reward rewards like this wouldn't be something more important than the money i mean many things are important and different things are important for different people right because i'm i'm experienced developer i have like 15 years of experience i've worked in number of companies i'm tech lead right now i'm shipping code to production like which every day i'm making decisions i participate in decision making and i understand what you mean but i was i was just trying to say that still there are some companies i've seen in the past that for example someone you know this past fact some smart engineers comes to the company and builds some solution using some cool technology and then suddenly this guy leaves the company and no one knows about the technology and this is surprisingly this is so common in in or maybe i'm so unlucky i don't know no it is common you're right anton you see it quite a lot right so let's we've been talking about the good and the bad aspects of a software architect so maybe let's dive into one of these things so i hear for instance christopher you said the the the the let's call this the watch what is a good caring i cannot write characteristics of an architect right and what is a bad one so i put already some posters here and now i move them yeah should we go into that so what are bad okay then i switch them is that something we want to dive in let's make that more visible right so uh let's dive in i hear christopher said right architects are not making decisions uh and i hear sima you're setting letting go of the ownership something like that right they're they're able to letting go of the decision so facilitate collaboration collaboration et cetera no just collaboration just have multiple teams talk about it architecture okay so we have developer experiences essential architecture influences i have another one here so i see this similar usually to a manager and a developer or a manager and and people in the team i hear one a colleague of mine in his friend of mine in his end of the year talk he says okay why do you why do i need to stay at this company so he totally turned it around right and that's how i see this relationship maybe as well and usually we're not doing it does that make sense what i'm saying so they're there to serve the teams instead of the other way around serendipitou is called yeah let's put it the servant christopher uh so servant leadership so what are some dark patterns here feedback loop is broken have so a question here this also resolves to managers and maybe someone can tell a story on that should should the team be able to give feedback on the architects on their performance end of the year if there is not in the year but every second week or something so part of that that thing so not being uh the developer is not in the feed back move on hr performance this is what i usually find weird with managers as well that they get their performance review and nobody asks the team right nobody asks the teams okay how did your manager actually do this here for you and they're not asking and they're like okay that's for me it's already a side i don't want to work at that company but yeah but you already take it forgiven that architects and developers are two different persons i heard many times about like powerpoint architect there is some phrase at least that i heard many times and that probably is anti-pattern which means the architect who is not writing any code and i think you discussed it as well sorry i was a little bit late i did not join from the very beginning we discussed it a little bit i am fully i'm totally sure that under the uh quite size of a company i wouldn't have two different roles of course from once huge companies or more than 100 teams or something it is very hard to handle but the normal middle sized company and small companies i don't wouldn't see a different role then you have a lot of problems you don't have a lot of problems after that you don't have the silo thinking you don't have this hierarchy or one person leaves and everything it's uh and it's a it's a big issue that's one person you have teams taking over responsibility teams having the skin in the game teams taking decisions and teams collaborating because they have to is it is it about the size of the company or is it about the characteristics of the system or systems i probably should clarify what i meant it probably applies only to small and medium companies because this is where i mostly work because in huge companies of course you can have many layers of architects you can have chief architect you can have system architect solution architect and some of them they never touch code probably you can sorry guys for jumping in between but i think rather than discussing about you know and going back to the subject that we have we need software probably we can learn from each other in what context we need because christopher mentioned interesting thing that he is having a software architect group so i'm more keen to know why you came up with this t this year because just to give you a background about me i have good in almost all the situations that you are talking about where we have architect group working as in every tower i literally used to hate them then i moved to a company where we were all making decision on our own then i've seen the dark side of that also right and now i'm in a company where we are thinking about having an architectural group right so i i'm more keen to know that um what has led christopher you to make a decision such a decision and what are even the things that your architecture groups actually your responsibilities that they are having now and how they are helping your you know development teams on day-to-day basis well um so some of this actually goes back to a couple of topics that have been touched on a little in the conversation um one of them has to do with um anton's comment about what we inherit when we come to a company right so i came i came to a company um that had a culture of very top-down decision-making where there was a chief architect who was the only deployer who was the the gatekeeper who reviewed all the code and so forth and i really wanted to change the culture to be much more autonomous and drive the decision-making into the teams but as we say um that's not something that changes overnight it's not like you just go to the teams and say okay you give me you make all the decisions now and they go yay um this this takes um some time to develop and um so it was important for the teams to to be able to look to somebody um for guidance um and someone who could help them to develop that um understanding of the bigger picture um the understanding of you know why certain decisions have been made and what might be the pros and cons and so forth um and over time we've developed that into i think quite an effective small group of influencer architects and it's working out quite well for us and we're seeing now that the teams are developing that expertise now what my architects tend to do is that they tend to then go and explore other areas that a developer who is responsible for delivering features may not have time to go explore and then come and present them to the team so ddd is a great example of this where my architects can go and help them to educate the teams and say let's work through some of these things together let's talk about what is a bounded context let's look at your specific thing that you are trying to build right now and let's talk through it together and let's talk through the pros and cons so um this is i think working out quite nicely for us but it's certainly not um an architect who has to like approve or or uh make all of the decisions for the development teams make sense then and just a follow-up question on the same thing so how how does it like work in your you know day-to-day stuff and let's say a team is supposed to implement a new feature or something like that and how do you make sure that there is a architecture or architect involvement is required for this particular piece how do how does the collaboration happens between the architect group and the teams so we've done it in a few ways sometimes we do it by um having the architect kind of embed with the team and build with them um sometimes we do it by having the team like have a series of uh design meetings where the architects come and the team presents their design and then we talk through the pros and cons those are those are i would say the two primary ways that we do that and then we periodically also have like cross-team um information sharing sessions where the teams can bring topics and we can find commonalities and maybe say hey maybe this is something that next week or next month we should like talk about okay and does that become like a blocker for or a bus factory kind of a you know thing like oh we cannot because we have to make a decision on it you're dependent on them now we cannot move forward and it becomes a hindrance for the team velocity um so i would say in our case this mostly depends on the comfort level of the team itself in making decisions like we we do not tell the team that they cannot move ahead without having the architectural input we encourage them to do so and some mostly it's the team who says if we think we probably want to get another opinion on this oh okay so it's more of a full based approach in that yeah yeah yeah okay sounds good right because if if you can see it people pulling and sharing information as opposed to being told too that's when you know that's working yeah sounds good so another one here uh from fred right in building there would never be something like a construction our day in building there would never be something like a construction architect you have an architects and engineering disciplines why is this not so variety question before i react yeah go ahead simon so i i do think that there is architect architecture in the small and architecture in the big and i know small and bigger if it's and i think christopher also touched on this where he says does it depend on the scale of the software that you're building i think if it is a small application it can really be the developers of a team that can decide how we want to go with this architecting that application as soon as that application has to fit in within other subsystems and it has to co-exist with other subsystems and if those are huge number like 50 some services now you have to figure out some cross cutting concerns that will affect all the systems and that is where i think you need a different role at least yeah so answer to this for me is that i in id it may be small so may not be needed i think there is another another thing that um this is a metaphor that yeah as someone mentioned is taking from from buildings um but as a metaphor maybe is not the best one uh because in buildings you have developers the developers are going and putting the bricks one on top of each other that in our case is just a tool that we use like gradle if you're in java make if you're doing c uh so those uh those metaphors yeah they need to be taken with it with a bucket of salt i wouldn't say a pinch of salt and because yeah they they don't reflect properly um can i say something so i i posted this and if you construct a a big building then you have electrical engineers you have construction engineers you have people who are yeah doing all kinds of engineering jobs and the architect has a special role is is basically guarding the overall concepts and ids so and but an architect is probably not someone who can do calculations on a concrete construction or let's say the and i see so i don't think you should compare software engineers with brick layers no it's it's about a decision process indeed uh doing the construction uh like like manufacturing uh that should be automated yeah it's it's it's it's about overall uh decision at decisions at different levels and uh and yeah uh you have decisions in silver and you have decision in let's say system of systems or the overall concept of of of a a system and so i think an architectural is is is most of all about communication so if there are different people involved uh understanding what what each of the people involved is doing and does it align with with yeah with the original concept or so it's guarding guarding that everybody works towards a common goal and and i think the architect is the the yeah the the keeper of of that goal and and uh and so it's it's and it can be a role of course it can be in a small company with a small team it can be a senior engineer that takes that role of course it's it's not but say a function and and it certainly is is not hierarchical uh per se as well so i i i would say if if if the architect and has has a specific goal in mind and and he sees a conflict i i think he should have to uh the last word if if there is a conflict in a team or a uh but just also for from a practical uh side to to let's say at some point enforce a progress yeah so you're saying if they see a conflict in the team uh they should i'm not sure what you said frank i uh so if if if there are if there is a discussion which which uh maybe the an architect thinks uh will will uh deviate from the yeah from the goal so there was discussion about using that that new and fancy technology that was invented two days ago and uh we which which everybody yeah software engineers uh yeah sort of tend to to to like which can be reconflicting with with establishing an outcome and and and maybe with the context you're working in so indeed yeah you can start using it but after a year is there still somebody around who understands it and then uh or no whatever reason so there can can be contextual reasons for um yeah not to not to want that and yeah then somebody needs to to make the decision to okay no no let's not do this because yeah it will be fine now for the coming sprints but in a year from time it will uh gives us a heart act yeah there is a very good term for it local optimization should not contradict with global optimization so yeah and i also see the aso talking about scale yeah if if you talking about a building and and and you have of uh often also architects at let's say a city level or uh i don't know what's the proper word for that uh or or city planner city planner yeah exactly and so yeah so i think an architect can also be uh yeah making sure that the context where a team is living in is understanding that context and and and not having every engineer a developer have to be aware uh what's happening around it that's indeed so an engineer should not have the time for that you should focus on on the job at hand and and so that could be also a role of an architect is is uh yeah making sure that that that that the the context of of the team is understood and and also aligned with the the goals of the company that's cognitive load actually that's a super important point right because if i'm in a smaller team with maybe a smaller scope but i know it in more detail and then maybe i'm an architect with a broader view but less detail because at some point human beings reach their cognitive load limit right yeah and making sure that all of everyone doing all of the roles can co-exist in an environment where they know enough to do their job that's hard so one thing you said that bought my mind and what threat what what for me is most interesting and what i usually don't see happening quite well is i believe architects should also be and managers as well able to manage conflicts on a deeper level than the rationale so also on an emotional level so if there's no decision being able to make or the decision is in a different way than you expected then what what hasn't been said that has to be said so usually there's this patterns of cycling through decisions right we come back and decision making again and again and this is usually that there's something on a deeper level that hasn't been discussed yet it's usually the emotional level for me in i.t as a whole and i also came from that side and i'm trying to work myself on this part a lot better now is how can we communicate also on a more emotional level so for instance there was a decision made in one of the companies i was and just because that decision was made doesn't mean people cannot talk about that it's a right there was a decision being made that that makes sure we have for the next three months we're we're not being a full team because we need to migrate certain bits of the architecture as a team and so that means we're not cross-functional and and that's that's not fun we know it's the correct goal but on an emotional level that doesn't it doesn't feel right and that needs to be there as well and usually we are forgetting about yes there is a decision being made but that also means that there's also an emotional level of pain that needs to be expressed and usually i think managing that conflict is is something a architects needs to be able to do rational and emotions not sure if what other people think of that or see it differently this is the part of your servant leader it's not only servant but it's also a leader so it at the final point if nobody can decide they should take the decision because this is why they are there this is why they have all the experience and uh not to say oh no you are autonomous now i don't take any decisions this is uh just preparing my finger pointing time so no it's not a server either it's they of course they should teach and coach and help but take decisions even if they are hard or bit with big consequences but that's it a life it's not um kindergarten so i think it's a tough one because right uh sometimes the team cannot make the decision i had i gave autonomy once to a team and then they didn't want to take the decision because it was too big for them to make the decision right they felt insecure about the decision sure because you cannot give autonomy you can allow to be taken out and yeah but it's not throwing over the fence it won't work this way because there is other more sentences about maturity um and in situations and pressure and we didn't talk about management and stakeholders and whatever other complex complex cities here so it's a nice in a nice or in a normal world for me everybody should discuss with each other and discuss about the consequences and i take decisions every day but they always ask my team and they can say hey i don't get it but i don't need to get it i trust you but i am in the loop it takes me 10 minutes to give them the loop and they are in the loop and can learn and maybe take over if i'm holidays this is what motivates me to be able to go to leds and know that the team is not stopped and blocked trust is the key word as well right this is the thing sometimes they'll just trust you because they know they know that you're doing all the right things and stuff and or that they could tell you to stop christina if they didn't agree right but they're maybe happier because they can go off and write code and they they know you're feeling all these things but if they don't know that they could tell you to stop because they think you've gone rogue then that's bad right so then inspect i even i ask to argue with me or to challenge it because i need this challenge nobody knows everything most of us doesn't so need this challenging and need to be heard not only to be listened to anton's dead right but like where can seaver and i are contractually obliged to workers to mention that pairing and mobbing is very good but it is super good for this stuff right because then everyone's you see everyone's skills everyone gets eyes on the same thing it's a more open forum around about something concrete like code or a problem as opposed to just a general team dynamic yeah so uh what i'm just connecting dots here but what christopher said a while back about having a pull based model i don't know if it would work for your situation kenny but if if the teams have perceived autonomy and if they are stuck and not not able to make a decision then they can pull on the architects do you think that's a model that potentially can work yeah well i i usually i usually first uh make the collaboration on the on on the decision part and if i see them struggle i will i will just tell that and i try to relate so i try to late i can i can imagine this so do you want what do you need and here are some options we can postpone it can we postpone this that's usually my first question like can we do some experiments to make you more yeah and that's the thing experiment experiment can we postpone the decision is this a decision is reversible i i know i'm not sure who it was but someone said um oh i forgot the name ron jeremy i think while pairing right if you see the other person making a decision that you know in the long run it's going to be painful but it is a decision that's easily reservable i'll just let them do it and experiment and feel the pain reversibility of decisions is a big deal yeah don't think about it enough no and i in you got to join rude milan's workshop right she has this awesome handbook i would call it for architects where where it says right almost almost all decisions are able to be postponed and you can create smaller decisions from them and make experiments so there was this decision between two and i said can you use it at the same time and they say yes well in two weeks we'll just use them together for this user story we take a bit more pain now and we'll see in two weeks ago and okay fine so we don't needed the decision now and i didn't come up with that before i didn't even know but during that conversation myself i came up with that and at the right time i took at least a decision that we could move forward with while not making the decision right and this is what fred said to move forward yeah to move forward yeah exactly what fred said yeah yeah that's the the the like we we spike out loads of our decisions loads of our decisions get spiked first so so someone actually goes and does it they don't just read a website and you know download and write hello world because we look you discover loads of stuff or we do that but then we build it because if you know otherwise you're like well we did everything it said on the um on the market but it didn't do the seven other things we needed to do which we only discovered when we tried to build it yeah it's always this this life of a developer read the small cups please sorry guys it seems to me that architects are almost like superhumans the way we are making them ought to be i mean i'm a developer but it does seem that there's a lot of a lot of communication and emotional intelligence that we expect from the architects and why not i think it's a projection right i think architect should be a role and i'm into role theory and deep democracy and a role is everything right from being a mother being a father being a leader being yes exactly gem cultures every time kenny says and role theory is everyone has it but usually if we make the function architect then we also project it all on an architect yeah and that's like the system trap right shifting the burden to the intervener and there's where the trap is and i think andrew you said it before is that you want to be able to make them make the decision but if there's already the way you come into a company oh we just hired the architect i'm like oh big trap projection going on there so the first thing you need to do is try to spread that role of being an architect towards the team so that everyone can carry that part it's always a bad smell when they hire an architect and he comes in and feels he and it is a he right it's almost inevitably he and they'll feel the need to make seven big decisions really early on to justify their value whereas i'll spend as much time as possible ignoring all possibilities to make decisions and learning about previous decisions because that tells you what you need to know right so yeah sorry you say we we get to the post-it uh uh white middleweight fan but this is a big problem like i genuinely i actively have to people think i'm going to tell them what to do and even when i haven't told them what to do people still sometimes act like i've told them what to do and it's really terrifying like the thing that keeps me awake at night more than anything is people think i'm cleverer than i am because i'm not and that i know what i'm talking about but i don't and so you know but if i so i actively from day one i'm trying to learn from people raise people up like the the reason i keep branching jam cultures is is and not just being you know if you step out the way the two other middle-aged white men in the team will step up typically right and they'll start filling in the role the space you've made so you don't just need to clear the space you need to clear the space and then hold the space for all of the people in the team maybe the junior dev right that just joined who didn't like uh who's done like a you know they've been on a 16-week you know kind of uh javascript hot house thing right but they're you know so they're very new but they've they're baked into tdd and pairing like they can't conceive of writing code without it i want to know what they think right i want to know what the person who's written you know ancient you know cobol and doesn't you know doesn't talk about anything anymore i want to know what they think all of those different people i want to know what the po the ux person thinks that's what you want to do because that's how you get the good conversations and the right decisions and then this this sentence doesn't it's not valid anymore about the problem are not architects who are middle-aged citizen white men but who are not talking who are keeping gatekeeping the gatekeeping is a much much bigger problem than so i don't know i am i never wear i'm a white man uh i'm white woman it's enough but but i i don't know if if if we can put everything on this card i think you're right gatekeeping is the big thing right because people why are they gatekeeping because they're like i've just been promoted this feels like a terribly large responsibility so i should make it look like i'm worth the pay rise because you typically in the uk you get a pay rise and you become an architect and then you're here because suddenly like you said with the peter principle you might have been a good developer i sometimes i sidestep being a good developer and went straight to being an architect so but it's terrible and then you come out the cover isn't terrified but doing it because they think that they're supposed to do it and then you come to information hiding and the other dysfunctional stuff and same what kenny said if you are starting as the new architect is coming you cannot resolve this problem anymore because you have a new title you surely have a different pay so you can do everything what you want you put yourself in a different position this is why i never ever never in my life had a fighter modern software engineer because i'm still a coding architect and this is what you get you cannot not hire the architect but not on the paper and never in front of a team i don't know if it's the right way to go i don't know it my way it's surely not so good paid way to go but it makes me much happier because i don't have this burden to to prove that i've heard the title or something yeah because it should be yeah the the success of the team should be well your success and architect should be the success the team because if it isn't delivered yeah then everybody is has failed and this is what accelerate is either we win together or we fail together and then you don't have place for hierarchies and being mostly more important or less important yeah this is skin in the game yeah fine is good yeah here's another one from einar which is the other way because i like that that polarity here right which uh on the other hand we want to cast the architect as a dysfunctional clueless ivory tower that's projection right when you're in a conflict you turn to stereotypical behavior like oh every time if i hear the word ivory tower there's already conflict going on there and it and and it allows developers to adopt a victim role if only they would listen to me but my hands are tied and all these stupid decisions are being made above my pay grade it frees you from the actual actually having to enter the discussion and negotiation that is required to make your ideas count in a software organization yeah so for me there's always two ways to deal with this one you leave the company or two you fight for the right yeah you as you turn into the victim i think yeah i just saying this this is pretty easy for me to say but not everyone is able to leave their job so just so you know i i i'm aware of that as well but there's also lots of so other things i've seen because i took the architect i didn't take the architect i ended up on the architect route but there's the kind of thought works we have and that's some silicon valley companies right we have principal engineers so you're still hands on you're not supposed to have a leader you might have a leadership role but it's leading by example and and the expectation we at thoughts have of those people is they'll still be hands-on they'll still be you know shipping stories or doing things but that they will pick the right story or the right way to implement it which will have a kind of you know 10x effect so not a 10x developer that's terrible you know what i mean like a they'll pick the right thing that will have a real impact like make it easy you know get us to production or you know you know something really important not at an architectural level but to the enemy level i think lots of developers who are like einar describes they don't know how to do that loads of people i see they kind of you know we're a consultant so we come in and ask people questions and stuff they express this frustration but they don't they haven't they haven't gone on a journey to figure out what the one or two things they can do is and one of the things that we come in and do is is go okay this if you change this thing and this thing lots of stuff will suddenly you know the negative reinforcement loop will become the positive reinforcement loop and all that kind of stuff right but it's hard to spot those things sometimes especially if you're institutionalized right you're just stuck in the system you know it you've tried some stuff it all failed so anyone uh has a different view or opinion so in the last few minutes there's a couple of people talking including myself anyone has a different opinion like like einar i like i like these uh different opinions so anyone who wants to react on i that probably not have a different opinion but i have a question that i'm really curious about what i observed in in sweden in smaller to medium companies there are no architects but there are tech leads so what would be the difference between a tech lead and an architect in your opinion or maybe in your experience what you observed what they are doing who is uh thinking and working on the architecture the technique yeah of course in context in context of architecture and technical decisions what they are what they are what uh what in your context in your experience who is taking the decisions regarding the architecture the team right this is the right way so we are talking here about teams and some kind of decision making when team has autonomy team has responsibility like in ddd community it's quite common to be talking about microservices ownership right so so what would be the reason that they project the role tech lead on someone instead of just developer so what would be the trade-offs there i i have my assumptions here but what what what do other people think so why would we make it explicit that someone is tech lead in instead of just i'm a developer in this team i see i see an architect as the bridge between the the problem space and the solutions space a tech lead sounds to me more solution space only yeah so i assume that there's is someone in a role maybe not explicitly but yeah so who makes that you know the decision about transferring decisions from from the problem space to the the solution space is that attack lead or is that an implicit architectural can we make a one more step in this conversation and i would like to mention another thing this is popular in toronto event design community which is cross-functional teams and i've been working in cross-functional teams in number of companies and i really like it i've also been working in a functional teams like back end only for example and in a cross-functional team a tech lead is a part of the team right so it's uh someone who is in the team working together so the question architect do you see different or not because when you mentioned that tech lead is kind of has nothing to do with problem it's only solutions i would disagree because functional team works on a problem and a solution for a problem so how does it work for an architect i think it depends on the size of the organization so if you are talking like anton you were mentioning before about small organization so i don't know if you have 50 people probably the tech leads or you know if you have a principal engineer they do those those things but if you go to a bigger organization maybe those those roles are more clearly defined so i think it's good in the in this discussion i think it's good to put the context of the size of the organization yeah i agree i but how about some exceptions that we have in industry like companies like google i never heard about architect and google how they exist yeah so also a bit bit on team topology let's look at that book that's getting some traction a lot there are four types of teams so i i haven't discussed this with them actually but where would an architect fit in in in the team topologies because they're not explicitly there right in the book no and you could say you could say and i argued for that that it can be the enabling team but an enabling team has an end date yeah architects team don't have an end date so so they they also talk uh this is for the front-end part i know so let's say you have a shared design system you have a sort of virtual team that manages that so this is an approach i usually took as well so let's say you have five teams and then each of the teams has a representative in in the sort of architectural meeting every so weeks right so then you have people in the team that are expert as architecture doesn't mean someone else from the team doesn't do it be careful with that trap but and these can really rotate as well right it's the same with i think they're going into these some reliability engineering teams right sometimes you have a team sometimes it's a virtual one inside the teams so yeah someone call it reliability because they're they're they look at the reliability of the service don't they as opposed to that yeah or the individual i really i think it depends and it can change over time right sometimes you just maybe need for a couple of times that team or not i think it really depends on context i'm not sure i i could see both models work actually so where i just where i was very recently we we had of that meeting but we invited everyone so it was once a week and it was like the most attended architecture meeting i've ever seen in my life and we invited product we invited ux we invited the security person so they could kind of sit there and and send a distress flare whenever someone sounded like they were going to do something stupid um and there was no unified technical direction beyond we're building a event eventually an event-driven multi-tenant sas that's kind of the direction they were headed off in um and so that worked and that we were taking cross-team decisions but within people from teams the one problem that my pair who is the client ostensibly the client's chief architect but they didn't you know he and i avoided doing any chief architecture the one question was what happens when the cto comes to me and asks me what the architecture is and it was it had evolved in a unified direction but we couldn't guarantee it so we did and we didn't have a document which we'd passed down to the teams which they were implementing or implementing or not but you know we could pretend to the cto we were implementing it so that was absent so we spent quite a lot of time managing up to make them understand get see what chris says about this chris is the receiving end of this this mindset but you know we spent more time we set the teams going they've got the hang of the autonomy we then spent more time managing up to go right we understand this is how we will push your you know desires down this is how we'll represent an enterprise architecture view et cetera et cetera so we'll meet your needs but we will do it in a different way we won't write a big document we won't you know we'll sense strategy and individually from teams and bring it up to up the chain supposed to push it down stuff i'll shut up and see what chris says now this is a disaster never do this it'll go wrong yeah i also see this as a uh so the question i ask you anton about the um the labeling of tech lead what i usually see is this balance right between ownership and not ownership so if there's no ownership we try to label people with the ownership but the dark side of labeling people with that ownership is the projection again so if you go too far on that part well now you have command and control labeled people right because it's giving to it's given to them by the way because of the projection usually so that's a tight balance so if you if you take that away then people questions okay who is who's responsible for the decisions they say okay we have a tech lead this is a tech lead label the tech lead okay now the tech lead is that then it's like oh and now i turn the other way so that's not really a good way the only thing is to manage that polarity it's like breathing in breathing out right it's like i'm breathing in oh okay i'm getting too much oxygen inside and i need to let go or letting go once you breathe out oh i need new oxygen so it's the same with with the labeling of that that certain role and i call it the role architecture of the ownership of it because the danger of not labeling is okay who owns it the danger of labeling it is okay someone owns it and can take power over it and i think that's the tight balance that an organization needs to deal with is how do i balance that polarity between these two and it's a managing situation right so i think anar asked these questions right uh how do these evolve what forces affects the evolution i think same with team topology entering the game right saying teams aren't static it's a dynamic thing and we need to treat them as something dynamic and we need to have a feedback loop that constantly uh senses the the the system in order to to maybe slightly nudge it in the correct way or change it in the correct way small changes but yeah that's complex hopefully i make sense in that explanation i think just something to share that um what you just described i think happens in a lot of in lots of parts of our organization where someone who is perceived as having certain status uh is supposed to to deal with something um and i read it recently um yeah on on a book about yeah about leadership um that i can't recall the name now sorry and but yeah about the cto um kind of asking um yeah the other c-level executives about their um their opinion on a strategy um and then i think the same the same uh situation can happen where maybe the other executives say oh well yeah this looks great because they don't want to confront the ceo um but i think yeah then the the person who is in in yeah the person who is in power they need to go and ask to their team whomever that is to say this is what i believe is the the way we should go please critique it because here i'm not happy with it and just to invite people to criticize whatever we yeah we have come up with i'm not sure if it makes sense yeah i i do i've been in that situation where there was i mean someone from the business comes in oh we have this this and this and this should uh should happen and so on and then the whole group like looking at me and today i noticed that i stopped talking i said well no i keep i kept on talking and i said like i have no clue how we're going to solve that do you have any id people please that's awkward to silence or not uh that's the most awkward silence so i said no i'm not taking the decision anymore please stop asking me stop looking at me i can help i can challenge it but i'm not going to say how it should be done and that meant that the fact that i had the role of making decision on an architectural level on design level on system level and that was really annoying so i made sure i didn't need it to do it again yeah yeah and that's uh that's hard yeah that's hard yeah i can i can give probably another example like as a tech leader is some architects i think had the same issues like when someone from sea level comes to you and says we need to build a feature x we just sign some partnership for example how much time will it take do you need to answer right have you have you ever been in such a situation all the time the best trick it to answer is not to answer a number it's always to answer arrange or to say this is complex so this is not complex so this we need to take into account we have no clue how that third party works so we'll have a ramp up time just to understand how it works we need some experiments but before we can have some rough idea of how it works and then i remind those people about the cone of uncertainty you know at the beginning of a project you can make a projection this is going to take so many times but the error is four times minus fifth time so i might be taking four more times or uh half of uh one fourth of the time that's the kind of uncertainty at the beginning of a project and if they don't believe you you take the book and you show them this is science this is what this is statistics not science this is statistics but statistic is science there's no way around it so i'm saying so much but this is how uncertain it is it's that's another thing to put in the pros of architects actually is to because again joe developer like i've seen execs not to to to throw arrows at christopher but um some execs know they can just by their presence they can go and scare a developer into putting something at the top of a backlog right and and having an architect to run interference on that and to kind of be able to speak their language and to give the stuff that eve was talking about and kind of explain it like that but also then to kind of go oh do we have the priorities changed has is this the change in direction all that kind of stuff that's another thing that you can't expect every to be to have that i didn't used to have those skills and i'm only just learning them now so so there's uh to to go on that road what you were saying as well eve don has this nice assumption mapping where she goes into that statistic it's in the visual collaboration book that you can download from limpup and she has this exactly what you said the assumptions and and mathematics inside there that that proves right well so just read it it's really nice but i think this is the moment where it becomes unfair i saw some job advertising thing for expectation from an architect to give estimations for projects and i just thought are you insane how can you hire me to make to give you a number about the work done by totally different people what kind of wizard i didn't talk about without by my first and single thought was how can you so stupid to rely on this uh how how accurate can this number be and what is this number anyway so how accurate can a third person person talk about what the team does we never this is what most non-technical people don't don't understand the thing we never repeat ourselves to be a developer it's the most creative work ever because the situations are always different you never repeat the same feature twice you are a monkey and it's already automated so the situation hour is different the code has evolved the team has evolved or changed so you cannot estimate things like this one important person leaves so why do it at all why not working towards a goal and making small steps and i think about what i'm ready to invest in so i invest two weeks in this project i look how it works and then i decide instead of asking are you done in six months and two weeks yeah i agree with the concept i don't agree because for me estimation is just that it's an estimation so it's just a rough has to i i if i go to a casino i can estimate that i come back with money or not right but that it's just that it's it's it's predicting the future but what they usually want is uh is giving deadline and that's a total different concept so estimating or just bluntly being misused by people uh and and that's what i usually tell the teams now right estimation is for you as a team if you want to use them to improve your work if anyone outside the team ever negotiates you about estimation come to me and i'll go to them i wasn't about the numbers it is not about the estimation about this permission does this exactly uh and it's the same it's the same mistake yeah exactly i wanted to tell you you to answer your question can you ask me like why someone is labeling people as a tech lead because i think business is just works this way for them it's easier to label someone an architect or a tech lead and then they can ask these estimations only from one person instead of waiting for endless meetings endless discussions that take time and you know because i've seen several times in in my experience they ask you estimation they don't tell you why they ask it and three months later you find out you have a deadline and then the deadline because you told them that it will take that amount of time but they never tell you about that it's like adam smith um you know in the old days one man person would make you know a pit or a nail or something right so they'd you know they'd forge the iron and they'd make the things and they'd hammer it out and shape it out and then capitalism comes along and splits out all the different job roles so they can scale up and go faster but we we're still living with that right we're like we need to have a dev lead and we need to have a lead and we need to have an architect and can i just be the one person wearing different hats or can the whole team have those hats and we swap them around but that's not how the mental models work currently of most people in organizations right but there's something there's another there's another bit here about um um how remuneration works in companies and how how structure kind of influences that as well in that you know i think a lot a lot of need for that structure comes from the fact that you get massive number of you know junior seniors and so on and then you promote out all your experienced people to exactly to those to those leads to attend meetings to management positions to non-technical positions so i think a lot of a lot of companies have a problem like that because you you can't split those roles across the team because team doesn't have the [Music] skill and you don't have that skill because you promoted your experience people out because you thought because the company felt like paying them as a programmer you know whatever the amount you need to pay for a person with 10 15 20 years of experience was just too much so we can't pay that much the programmer we have to promote them to director of engineering that's very true actually it's like yeah you start with the team with no capacity and then you have a you need to have an architect and the loop kind of just goes on and on and on yeah and then you lose autonomy so you have to teach people autonomy and i think a lot of things kind of keep keeping a reinforcing cycle yeah yeah yeah just to stay up with the job market right we can't pay pay developers more but if we promote all of our developers to senior developers yeah i think this will change i think we we are already in the middle of a crisis where everything every company realized somehow that they need computers and they could use some automated stuff and they lose their market share because the world is digital and this idea about code monkeys won't work out for for long it will work out for the next couple of years but at some point companies realize that they need the brain of the people and not the fingers the type of the same thing christopher christopher you said something that rings a bell with me right we were talking about or you said this is where you benefit a ton from someone with power and influence who can protect against abusive estimation people can say a lot about project manager but one of my best projects i was in was with a project manager who used his power to protect me as a developer and that was just the most amazing time as a developer i had because the person went to me and said what do you need i said well this is what i need okay i'll make the translation to the ceo and just let him shoot and he did and we managed on time we managed before time that we even expected but we never he was just the the correct gatekeeper right the spiderman a lot of power becomes gives you a lot of responsibility so yeah so there's always a good side there sometimes when you have sometimes you need a person with power uh to protect but there's that superpower and the other one so if you get both then you're you know you're going to be winning the other one is not wanting to not hear about bad news so the the best project managers who are called mel and either work was mel andean and charlie three best ever they were amazing at that thing you've just described and the other one was they didn't they wanted to hear about bad news as soon as possible so therefore if it is gonna go you can tell them today they'll make you you know make sure you don't just you know put the raise the flag by accident they're going to make sure that you've done it right but then they'll work you know they'll understand that they'll work with you and et cetera because if they're not like that then you'll not tell them the bad news and it'll just you know get worse mars but those are superpowers and this is uh this again coming from deep democracy they say you first need to own your rank right so i am that architect i am in this position they i'm in the system but then i get to share and play with that rank it's what eve said right they're projecting on to me these decisions but i'm gonna share it with the team yeah yeah that's turned the ship around right that's the book about the guy who's who the american admiral or whatever he was who ran that that um nuclear submarine he pretty much wasn't running it but he was ostensibly in control sorry christopher yeah yeah i was just gonna say like that goes both ways right it um especially for someone who is in that sort of middle position um it's not just about sharing the the role and expertise of the team it's also about educating in the other direction so when you read books like phoenix project for example this is exactly what happens right is that you have someone with the right level of influence who can educate upwards as well and i think that's really really valuable we've heard a lot about dysfunctional sea level and i think having somebody who can have a positive influence in that direction is super valuable yeah like someone said earlier actually maybe designer it comes down to mental models if if their mental model understands the estimates are plus or minus or that software you know is better in thin slices and all that kind of stuff then you're going to win and the people who can identify current mental models and change mental models that's the big thing then people get they're like oh you're not understand you know i keep explaining things but you're hearing something different because how you think of software development is is different from me so let's address that first which is why 4k metrics is good right four key methods numbers and then we're like but to get this better we're going to do things that seem strange but blah blah blah that's a game changer from me and i think i think it was sim put it in alt right the architect elevator making that change not doing that but also managing above and give them possibilities so we're closing the deadline of today or deadline estimations trying to get christina so uh no but i want to have two things for the people who are still here or listening is let's first talk about a developer perspective so who just one thing what can you do differently tomorrow as a developer to battle if you're dealing with this ivory tower type of architect what's the first step that you could do here it's not about the ivory tower generally with your colleagues with your team leads with it it doesn't have to be an ivory tower so how to let's say you're in that system let's say you are dealing with an ivory tower architect what what would be one thing that you can start doing tomorrow differently i cannot answer this like it has to be somebody else because i won't be in it won't happen so i heard uh i heard it somewhere here i think it was einar take ownership of the problem yourself as a developer i think yeah right it's easy to sit back and play the victim role but i think if you start owning it and start taking responsibility i think that's that's something you could do but yeah i haven't been in that position for a while yet but that's what i did back then now the other way around so if you're an architect you feel you're being projected into the ivory tower so someone says hey i've reached our architect to you what what's something you could do start doing tomorrow i've heard a lot of these already but what's the most pivotal thing you can start doing tomorrow david's was good ask questions so so i sound like a lean idiot but they should if i was the architect or if i was if i was the developer i would ask the architect or the senior person to come and pair with me for a day and if i was the senior person i would go and pair with that person for a day or watch them mob and sit and shut up as well just listen there's a thing in lean called go to the gemba which is so i sound like a lean idiot but basically and i think in the toyota book which is also behind me there's a circle on some of the toyota floors and where it's like senior execs going to stand and they just watch and you can learn tons because i guarantee in almost all circumstances because people don't try and do you know become an ivory tower person on purpose they'll just have a very different idea of what happens from what's actually happening and i think if they go and listen and watch i have and the best of two of the three people i just mentioned on my project manager awesomeness hit list two of them would just sit there for for two or three weeks and just listen because you can hear you can hear development working or not working although it's different now we're on mural oh no we're on um where's christina i replaced the mirror with that one posted this is it anyway it's in german uh on my monitor here uh explain star instead of x expect so instead of uh expect something and be angry if it doesn't happen just explain what is in your mind it is so my motto uh put on the monitor to not forget and do not have too much expectation too high cognitive load uh projected on anybody else so for me it's just like listening and yeah i think with itself between different for me it's either if you're a coder or an architect or a human being always take responsibility first start from there and if someone calls you ivory tower architects which i've probably been called or someone said it let's take ownership on that at least someone is thinking it so it must be true in a way you mean challenging and making it tearing down the story right why why do you believe i'm and then accepting that it is what they perceive you to be listening okay time to wrap up thank you everyone for your input and thanks everyone who wasn't here but gave input anyway to miro board to youtube through zoom and uh in two weeks i think we have another meetup again again with ben continuing our worldly mapping collaboration so it will be up this week and see if we can get another collaborate collaborative modeling session going on there so hope to see you there and thanks everyone for your input and we're going to close the live stream and well we're gonna do what every meetup usually do is the after talk

Channel: Virtual Domain-Driven Design

Views: 318

Rating: 5 out of 5

Keywords:

Id: nGdlw7bbaaY

Length: 106min 43sec (6403 seconds)

Published: Tue Jun 01 2021