Transcript
Andrew Harmel-Law: This is the panel for the track which is, the shape of the future of architecture practice in 2025 and beyond. The whole idea of the track was we know that architecture is super important. It's probably more important now than it's ever been, and you could see that in all the talks. My argument for the track, and I think again hopefully everybody's seen that, how we do architecture is coming into conflict with all of the other important things, which is what I've tried to curate with the people that we've got speaking. I was hoping all of the talks would spark people's enthusiasm and spark people's curiosity. The idea of this one is to continue the conversation. The idea is to take architecture out of the echo chamber, because in the past, architects would talk to each other, would be rude about everyone else, and then we would crash into mistakes which we would make over and over again.
Cat Morris: I'm Cat Morris. I'm product manager at Syntasso, which is a company that builds Kratix, which is a platform framework. I was previously at Thoughtworks as a product manager and platform product manager for four or five years. I did a talk with the lovely Diana on the friction fix.
Diana Montalion: Diana Montalion. I am a software engineer, systems architect. I wrote the O'Reilly book, "Learning Systems Thinking", and gave a talk with the lovely Cat who taught me not to hate product anymore out loud.
Shana Dacres-Lawrence: I am Shana Dacres-Lawrence. I'm a senior principal architect. I'm currently working at Accenture, previously I was working with Andrew at Capgemini, and previous before that at BT. I did a talk with Cat. My talk was around security and architecture, to betray one is to betray both, looking at the intersection between security and architecture. My background is in security, so I've come from a secure development background and gone into architecture, but really still remaining within cybersecurity and developing solution with the same security context in mind, both for public and private sector.
Vanessa Formicola: I'm Vanessa Formicola. I'm a principal engineer at Flo Health. I've done equally developmental architecture work. I've been a consultant for many years. I've also been in management roles, like engineering management. Spent quite a few years at Thoughtworks and Microsoft, various things. I've talked about holistic engineering and how we should factor in non-technical factors in our technical decisions.
Elena Stojmilova: I'm Elena. I'm technical lead from Open GI, that is a company that we have firstly started to adopt and practice the advice process and the decentralized decision-making process, and we have shared the experience there. I'm here to share the technical perspective from that story.
Peter Hunter: I'm Peter Hunter. I was tech architect on the program that Elena just mentioned. I'm now head of R&D, grand title, team of one, so not that grand. Again, we were just talking about the practice of architecture and decentralizing that decision-making.
Effective Communication of Architectural Concerns
Andrew Harmel-Law: All of your talks touched on systems that extend beyond just the code, how do you effectively communicate the full scope of architectural concerns to stakeholders who may have traditionally viewed architecture as just purely technical?
Diana Montalion: I literally have just started writing a book about this, so I literally have a book as an answer to this. What I will say in the short form is designing knowledge flow and understanding the principles of knowledge management, which is a whole field of study, those are so handy to integrate into our own work. Those principles I found instrumental to architecture. The other one would be, once I create an artifact that gives me insight and understanding, I create versions of that artifact that speak to the audience in their language, and I keep those things interlinked. The idea that I can only geek speak to the world has been beaten out of me by people who I need to speak to.
Vanessa Formicola: I find that depending on the specific set of skills of the stakeholder, you might want to think about what they get out, that specific problem space. Unfortunately, there's different levels of maturity and there's also a different level of approach to collaboration. There are different ways to engage a different individual, and these are purely people problems. You need to understand what they need and what they want to be able to translate what they might find interesting in what you need from them. At different levels this would look like something different. Sometimes you can't do it proactively in the sense of what they would like for the future. Sometimes you need to bring up examples of things that went badly and damaged their department, their people, because they didn't listen to something that could have helped them. At the end of the day, by showing the intersection between what you need and what they need tends to work at different levels, broad generalization.
Peter Hunter: It is in the language. It's how you remove the geek speak, I think. I personally am very visual, so I bring everything back to sketches. Excalidraw was my friend. I like to try and visualize a lot of what we're doing and why we're doing it. I think where geek speak can get in the way, visualizing what you're trying to achieve is really important and it's a really good aid for those that aren't necessarily going to understand what you're trying to achieve and what you're talking about.
Andrew Harmel-Law: Elena as well, a good example of this is sometimes if something is complicated, because I think people asked you about this, you showed the context map which is complicated, but that's because it was a complicated problem.
Elena Stojmilova: As a technical aid, probably I don't have like sharing my debt experience in sharing with different stakeholders, most of them are technical. I think that also ADRs are supporting that because in there you have all of your decisions, the consequences, the benefit from it, and they can be shared with the product and they can get understanding for the architecture decision.
Also, as Peter mentioned, I'm always trying to write some diagrams and they are not that architecturally, but simple diagrams in order to share like, this is how the system will look, and trying to map somehow the network link and how the communication will look like. Yes, context map, it helps, because we have context map that is in line with the business flow and whenever you're doing a change somewhere and you know that that will break some other parts of the system you can just show the context map. There is a visualization of the contract between the different bounded contexts and you can show like, if it may change here that will be broke and that we needed to get some conversation or some work to be done by different teams. That also helps.
Peter Hunter: Just on the context map, we had an issue recently where we saw product teams were getting frustrated with the speed that we were getting through the backlog, and actually the context map was used to demonstrate why that was, because the priority items to them were located in certain areas of the context map. There was only a certain amount of throughput that we could get through. That's a really good visual aid how we managed to explain it and the light bulbs came on and everyone was like, we understand now.
Shana Dacres-Lawrence: I would add mostly from maybe a security context is around putting the fear of the impact of the design or the architecture you're putting together. You might not want to label it as fear, you might want to call it the risk that you're carrying or the risk of what the solution that you're putting together would help to mitigate and what that will mean to the business and how it will help to deliver their wider objectives if they're looking to achieve a certain business goal. If they're looking to retain customers, having certain measures in place or certain architectures in place may mean that you're not actually retaining customers in this way, you're actually losing customers.
If you articulate it in a way, and articulate your concerns in a way that highlights their core concerns or their core objectives, we want a secure solution, but if you do this, it's not secure, which then will mean that your data is leaked, your data is lost. Then that really drives home why you need to put in certain measures in place, why you're looking at it from certain perspectives. It will help them to develop the perspectives that you have on to how you're looking at the solution or why you've chosen certain methods.
Cat Morris: I have two things, and a side point on Shana's point is if you can put a cost to it, like a number against it, like if something goes wrong it will cost us this much, the likelihood is 20%, therefore the cost of the risk is x, then you're much more likely to get buy-in and agreement and you can do that. Like, is it worth my engineering team actually spending time on that?
The first point that I had, which is the product one, and that is if you can align everything all the way up to business goals and then cascade that hierarchy down to what you want to do, there will be some level that someone that you are speaking to cares about, and it is in language that they understand. I think I bring it up in the talk of like how do you write your thing, the thing you're trying to do, the thing you're trying to explain or persuade in a language that agrees all the way through that hierarchy of goals across an organization. The second point is, your leaders are probably more technical than you think now. Over the last 10 years that I've been in technology the people who are higher up the tree are often from an engineering function or an engineering adjacent function, so probably can be a little bit more technical with them than you think, rather than just sitting in a corner and saying, they'll never get it because they don't know code. They might have written the system originally in the first place.
Diana Montalion: Mention AI.
Shana Dacres-Lawrence: Just the word, nothing more.
Andrew Harmel-Law: The other thing I'll say, and I didn't engineer this, but to Cat's point, as Peter and Elena pointed out, one of the key things that drove lots of what Peter and I did was, as you pointed out in the slides, you start with the business principles and the business goals and then cascaded that down. For me anyway, that's super important.
Shana Dacres-Lawrence: What I've also seen, touching back on the fear, is, when others try to reinforce their point, especially when it comes to the impact of certain security risk, looking at what others have done, and especially when it's gone badly in the public domain, the fear of having to stand up in front of Congress and explain why you had put in this solution, which then meant that your data was leaked. Then meant that you paid a ransom, is a really good sell to underpin your motivations behind wanting to put particular solutions in place, because it really helps to drive it home, and then they'll have a pause moment, have a think about it, and try to look at it again.
Diana Montalion: Unless they're Facebook.
Questions and Answers
Participant 1: What was the impact of this spreading the decision process across multiple teams, like, making this decision-making more decentralized? What was the impact on the actual duration of taking decisions? Because maybe it's acceptable in some cases, that depends really on the pace of the project, and also on the level of those decisions, what is acceptable on a very high level to take a year, will probably not be acceptable on the project level. How did you define the level on which teams should be taking the decisions? Because, yes, when you decide that there is an ownership given to the team, then I think that's fine that the team would take the decisions within this area. What about cross-team decisions? Who would take it? Ultimately, who is held responsible for those decisions, because when it's spread no one's responsible?
Peter Hunter: Time-wise, we set up our teams to be flow-aligned. We wanted them to run independently. We were measuring ourselves on the DORA metrics. We're deploying to production multiple times a day. We were set up. We did not want our architectural decisions to slow us down. We agreed that the decision records would have effectively a seven-day warranty period. People would propose them. They would have seven days for anyone to comment on them and give feedback. If there wasn't anything that materially changed that decision, then it would be adopted and the teams would continue. We artificially created this seven-day gap, which allowed people to give feedback. For the tech leads and the engineers that were savvy, they were getting the feedback earlier. We talked about the first one. You didn't get the feedback as early as perhaps you should have. Then I think as the team started to realize, they were going to get feedback sooner so that they came with a well-defined decision.
Participant 1: I imagine that this could work when you have very well-defined structure and responsibilities of the teams. Because I think that we all came across the situations where some people, regardless of their actual position, have more impact than others. Actually, what can happen is that even though you went through all of this process, someone can say at the last step after that was accepted, that won't work or I disagree. You need to have means to enforce that that was a decision, that you made it regardless.
Peter Hunter: I mean the decision, once it's adopted, it's adopted. If someone comes along afterwards and they didn't read the decision record, they didn't join AAF, then that's their lookout. They can have the opinion, but again, it's too late. They should then think about themselves, maybe attend AAF, maybe read the ADRs that are coming through. It's about behavior change, and it is a big behavior change. It doesn't happen for free. You can't just put principles in, ADRs in, and AAF and hope that it all works. It takes a lot of work to guide the teams, to remind the teams. At the beginning, we may have seen a few decisions that were taken without an ADR. Then we would gently remind the teams, you didn't take an ADR to AAF. Can you just document it and then take it through? It's a big behavioral shift.
Elena Stojmilova: I just wanted to share for what you mentioned for the between teams, like how you're making sure that they are communicating.
Participant 1: How do you define the level of decisions on which each team should be taking the decisions. Because first you define the ownership, and then the team is allowed to take decisions within its area of ownership. Then on a higher level, if you decentralize this architectural decision-making process, who is held responsible for that? Do you grant yourself maybe a veto right in this case? If you see that the impact, ok, you didn't think of the consequences, but ultimately like who is responsible if what is being taken will break something.
Elena Stojmilova: We don't have like a level to which the teams can make decisions. Teams can make any decision, but you have the architectural principles and they are creating the overall architecture vision where we wanted to go, like preferred Azure, be cost-sensitive and everything. When you're making a decision, you need to consider there's those architectural decisions, and be sure that your decision is aligned with those architectural principles. That will create our vision and all the teams will be aligned to that vision. They will not choose something strongly different from that. On another side, teams are working independently. We as technical leads we're also working together. We are sharing experience, and also, we have principles and architects that are supporting us. It's not just like we are working quite in isolation. We also are working on the same product and sharing the experience and the knowledge.
Participant 1: Before you even open this process, you need to start with principles and vision.
Elena Stojmilova: Yes.
Participant 2: I think when you look into architecture, or if you want to become an architect, your technical skills are usually not the most important part of the equation. What kinds of skills do you think are the most important to be a good architect?
Diana Montalion: The biggest thing for me is impact. That if I'm making decisions in the context of code, there's a relatively small context of decision and impact around me. Now, if I want to have impact on the system as a whole, I have to be able to make a recommendation that is going to get me the money and the time and the things that I need. Learning to be able to create a recommendation that also includes the reasons that we came to this conclusion, but also why this has direct impact on the primary business domain, what due diligence have we done to understand product's point of view, to understand the potential risks. For me, it's applying the same type of informal logic we use when we're making technical decisions and using language to construct that logic into a form of argumentation that helps other people to understand what we are eventually going to do in the code. It's a pretty rare skill. If you cultivate it, for me, it's been the most valuable. Then I can go away and build the things that are hard to build, and mostly people leave me alone.
Shana Dacres-Lawrence: I would add because I feel as though I fell into architecture. I was working with Andrew and I was more in an engineering lead role. I don't know if they said they wanted an architect, but they wanted somebody who was able to understand the technical and be able to detail what was going on in the system. Being able to have the understanding of the technical is really fantastic. I would also encourage you to develop your ability to accept feedback, because as an architect, you get so many different perspectives and so many different viewpoints from the teams and stakeholders that you're interacting with. It might not be the perspective that you initially had in mind.
Going into different governance forum, going into different review boards, you get feedback from so many different range of individuals where it may be contradicting or going against some of the principles that you may hold real close to you and you want to hold on to it. Sometimes you have to really want to just let go of it because decisions are sometimes made outside of your control. Also, being able to debate and argue your point and also present your point and understand the traits of what you're making in regards to it. Because it is very much, like you said, a knowledge role, but you are very much in a people engagement, influencing role as well. You have to engage with so many different types of people. Being able to understand perspectives and being open to feedback and change is really critical for an architect.
Vanessa Formicola: Although I totally agree with what I've just heard from both Diana and Shana, I'd like to point out something very often. I agree that those are the fundamental skills that differentiate you for that role. What I find is that often then people neglect all the skills that brought them to that point, which are their technical skills. Although I totally agree that that's not the key skill, it's your foundation skill. It's what you bring to the table that other senior leaders at the table that come from a different discipline don't have. You have to be careful not to lose that skill. It's a very difficult job because you have to be on all sides at all time.
The skill that you are bringing in that other disciplines don't have is the technical part. If you lose complete touch from what's going on at the lower level, and with this, I don't mean you need to code with every team at every point in time, but if you lose touch, you won't be able to add that delta that your product correspondent person will not be able to have that experience. Remember not to completely dismiss that part because otherwise you lose your key differentiator.
Diana Montalion: In a way, I'd say that's even harder now for me because it changes so fast and I work across multiple stacks and multiple languages. I actually have to work harder on my tech skills now than I did when I was engineering in a single monolith.
Participant 3: We've been talking today about how architectural practice is changing and being reshaped, do you think that also then reshapes career paths into and within architecture?
Vanessa Formicola: I have the very unpopular opinion that you shouldn't split the managerial roles and the architectural and the developer role. I'm a firm believer that either people should be able to flip around the various roles or find this perfect slice of shared responsibilities at the right level. Although this is a very difficult problem, I find that if you have a perspective from management, if you have a perspective from architecture, from development, in time you bring to the table the good things of every discipline and you're able to approach the problem with more empathy from all angles. Does it make our job more difficult? Yes, but that's why we have humans do it instead of machines. It's very difficult. It raises the bar. I don't think it means that we should have all the skill set at all time, we can also get help from our counterparts. If we carry on this strategy where we are just developers, just architects, just managers, we'll end up not having that visibility on the full system and the problems that we're having.
Diana Montalion: Systems leadership is multidisciplinary in a world that wants you to climb one ladder and then that's your ladder and you cannot get off your ladder. An architect role from my experience is you get off the ladder and you are going to do what a circumstance needs you to do, and that my titles have been different over the course of my career because circumstances are different. Also, it doesn't matter. I think that the ability to integrate, to the point of management, you can't have direct control over one piece because then you're not integrating. The question of whether you have, for example, the power to tell people, go do this. I think that's a really tricky question because it is so much a facilitation and an integration in a synthesis role that I think that it challenges what power is, it challenges what control is. I think we have to reshape what a career ladder even looks like for knowledge workers.
Cat Morris: I'm going to shout out Shana here, actually, because when we were at Devoxx last year and they had a bunch of different types of architects on stickers, and there was like security architect, technical architect, business architect, all of these different roles. I've been told that I was a business architect at one point in my career, and I was like, what are you talking about? Please don't fudge me with that. There are so many different hats you can wear in so many directions in. I was a developer for two years and was pants at it, like do not let me near your codebase, I will explode it, it's not good. There's still a path into architecture in some flavor for people who should not be allowed to touch a keyboard. There's lots of different types of architecture if that's where you want to go in directions, you should lean into whichever feels interesting. It's not a career ladder, it's more like a fan, like there's so many different places you could go to.
Shana Dacres-Lawrence: I would totally agree. The path into architecture, I think if you looked at it about 10 years ago, it would be very linear coming from software engineering, and there would be one typical view of an architect and you'd be a technical software architect. As Cat has said, that has changed so much over the last couple of years. The path into architecture is very squiggly. You can come from any route into architecture and it doesn't have to be a specific discipline. There's a lot of organizations that are building lots of early paths into architecture, rather than just coming from a purely engineering background, so supporting. I've even recently come across a product architect, and service architects.
Architecture, I think, is more of the discipline of facilitating and bringing the full holistic picture together, which really helps. I think that's why I had the picture on my slides of where I was holding up a lot of the titles that I've had over the years. I've played infrastructure. I've played security. I'm currently doing a data migration. Am I a data architect? No, I wouldn't really class myself. One of the good things that they showed on one of the talks was about having the comb, and being able to go into the depth and bring yourself back out. I think architecture allows you to do that because you have the foundations, and you'll be able to know how to apply the same principles across a range of different domains, and go into the depth, come back out, and be able to be successful within those roles.
Participant 3: Actually, that's a perfect segue for my question, which is about mobile engineering in general. I will give you a context observation and the question. The context is, we have 2 billion mobile devices out there in the world, which is a lot. The observation is that on the tech side, backend web engineering has evolved a lot. We have micro-frontend, microservices, all of that. Basically, they become like ice cubes on the ocean. In the mobile side, we still have big monorepos, big applications with very hard architectures to work with. Observation from the people's side is that usually architects in companies, they are so much focused on web backend, and they will keep mobile, let's keep it to engineers, and that's it. If we have a problem, let's just fix it for this feature for product, and then move on. How can we help or remove that little bit of hidden ceiling between architecture from different backgrounds to this, I would say, a little bit hidden elephant in the room or in the tech stacks?
Diana Montalion: The last year and a half has been an initiative that is cross-platform. We're designing for web and for mobile. We decided to use Flutter for the original prototype so that we could keep the codebase relatively similar. I come more from the website, like not nearly. It was really straightforward to design a cross-functional platform until I had to try and distribute it to Apple. Then I was never going to make an app ever again. I think that people have confused the distribution workflow with the building of the platform that can feed and the data. The data isn't any different in our case. I think that what happened originally is every organization, so you'd have a web app. Wait, we need it to be responsive.
Then they'd build either a mobile version or they do a responsive theme. Then we need an app. They'd hire a completely different team because they didn't overlap. Now you have legacy systems where the mobile piece has been siloed for so long that it's really hard to integrate. If you start now, you can keep them relatively integrated. Then like sending notifications from three or four different systems. I think part of the problem is legacy. It's hard to recover from where we've come from. Then also the distribution workflows and the communication workflows are so different that I think that's where it starts to differentiate a mobile team with specialty skills. I would hate to see the architecture itself, the fundamental architecture, be so siloed that we keep making the same problem. I think that the tech is still blocking us from the integration I'd like to see.
Vanessa Formicola: A couple of tips of things I've tried in projects that had Android, iOS, very legacy backend and multiple things in the middle of all this. Again, this is not a silver bullet, but it helped a little bit. I pick the people that will be part of the conversation when we design the new features. I never allowed mobile engineers to be alone designing while backend engineers were in a different room. By designing the people who are in the room, you design the conversations that they will have to the limit of what's your existing problem, like Diana was saying. Sometimes you find one monolithic application and you work with what you have. Even in those circumstances, when you build something new or you refactor something new to evolve it, if you have the conversations together, you'll find solutions together. It'll get you closer.
Another thing that I found useful was to design how we would have liked it to be, so that we could find a solution that was close enough to how we would like it to be if it was possible. A third thing, and this is very difficult to implement, would be to actually have fully cross-functional developers. I've not been able to have a team where that was 100%, but if anyone has one, I'm here. Because I think it's dysfunctional that we need to have conversations with different tech stacks within the same team.
Another aspect to consider that really helped me in the same project was the introduction of Backend for Frontends, which doesn't solve the problem fully. If you are able to build your Backend for Frontend in a language that, for example, in our case, ideal would have been Kotlin, because all our Android developers could do that, you could have more developers that could crisscross and help align that. In every conversation, I would try and make sure that the mobile approach was very consistent between the two platforms, and as consistent as possible with the backend in the limit of the circumstances. Introducing Backend for Frontends to help me put a layer between all the legacy of the past and try and realign what logic shouldn't have been in the mobiles, what logic shouldn't have been in the backend, and try and build a space where we could start actually aligning this. The ideal scenario would have been fully cross-functional developers.
Cat Morris: Building on what Vanessa said there, an antipattern that I see a lot and I fought against quite strongly was separate product managers for each of those distribution channels. You have your iOS product manager and your Android product manager, your web product manager, your backend product manager, and that's when I start flipping tables, because you're never going to get a consistent user experience. They might be different users. Usually, you want to align your product managers somewhat to some user base so they understand them, but the persona is the same. The person using your Android app and your iOS app is likely to have the same persona, they need the same thing if you're building a product that has a shared vision. Keeping that forces that consistency, because it's through one channel that you're getting the need and the goals for that product.
Diana Montalion: The same with design. If they're designing, design for the ecosystem, not for the one piece of software.
Cat Morris: It's much easier to find a cross-functional designer who can do iOS and Android with those skill sets than it is an engineer, because the differences are less in the UI than the code.
Participant 4: Whenever you're picking a system to use in architecture, there's never a perfect system. You're always making some tradeoff. I wonder how you balance that with, say, something you're looking back on a project a few years later and starting to feel pain points with that project. How do you identify if the pain points you're feeling were just those tradeoffs that are necessary with any project versus architectural, I don't want to say mistakes, but things you could have solved in the architectural progress? Because I find for me, I want to look at my projects and grow, but it's hard to balance like, which of these things were, any project would have some problems, versus, we really could have addressed these.
Peter Hunter: You're always going to reflect on decisions and there's going to be some positive decisions and there's going to be some negative decisions. Then you're going to have to make another decision, as to whether you spend any time on it. I think you've always got to look at the value that's going to come out of spending the time on it. We've got quite a sprawling architecture. There's a lot of decisions that I can see that have been made in our architecture that we have to let go, they have to flow past us. Then you keep them in the back of your mind for when you're next in that area or a team is next in that area and you can guide them to those decisions. You can then get them to revisit them and look at the decisions they made, maybe look at changing, re-architecting that part of the system.
Don't live in the past. At the end of the day, you cannot change the past. You can change the code, but that's changing the future. There are always going to be bad decisions. Elena changed one of my decisions. I think the times are changing. There's a new dynamic, there's new forces at work on the solution, the platform, whether it's from outside of the business, whether it's world events, or whether it's actually just someone's created a new service and the dynamic is different. I would definitely not beat yourself up, but learn from it and then play it forward. I wouldn't look to the past.
Andrew Harmel-Law: Elena, you mentioned in your talk about you made the first decision and then one of the big things you learned was to make smaller decisions. Do you want to just expand on that a little?
Elena Stojmilova: It will really help to try to make smaller decisions, as small as possible, and write them, and create an idea for them, ask for feedback, and that will lead you to not rethink in detail a lot. Because my first decision was big, and probably there were a couple of maybe a lot of other decisions that needed to be made. If you made a smaller one, you will get feedback faster, and you will be more flexible, and you will get better.
Diana Montalion: Keeping in mind, as complexity increases, we blame. One of the things that we're looking for is what to blame in myself, especially in my skills. I would argue, those are not different things. When you made that decision, you made it based on the time and context you were in, things have changed. You're going to look back and say that decision did not lead where I wanted it to go, always and forever. That's actually part of architecture, that's inherently part of architecture, the learning, the growth mind as context. Then sometimes the world changes around you, and often the tech does not give us what we need. The tech is behind our architecture. I want this, but the tech's not there yet to do it. I would put them all in the same bucket, and the goal is, make the best decisions you can, learn from them, as things change, do something else.
Vanessa Formicola: Generally, I'd rather make a mistake trying to fix things than endure the consequences of being too scared to make the change.
Andrew Harmel-Law: There's a Don Reinertsen quote, "Fast and wrong is better than slow and correct".
Cat Morris: How do I not dive into the detail too much based on, I've got these architectural goals, how do I make sure they happen? Trust but verify is something that we do. Trust the teams. You've written it up, trust they'll read it, before it goes to prod, verify that it's happened. That's TDD but for architecture.
Diana Montalion: If I'm being handed requirements, you've skipped architecture. I can't architect after I get handed a list of requirements, that's requirements-driven engineering. That is a change in when a conversation happens about architecture.
Peter Hunter: Read Andrew's book. Empower the teams and that will stop you from getting pulled into the detail.
Andrew Harmel-Law: People are smart, but help them be smarter and help them build the trust and stuff.
Participant 5: I wanted to know when thinking about these and facilitating these multidisciplinary conversations, what happens when these conversations produce compromise more than innovation? Do you start excluding certain voices? If you do exclude it, how do you manage the social repercussion of excluding those voices in the long term, given that you're working in an organization where once you open up the doors to getting everyone's input, everyone wants to have input. Then once people are excluded from that input, it rubs them a certain way. What do you do in that case?
Diana Montalion: I call this the car boat. One team wants a car and they get the budget and another team wants a boat and they get the budget. The engineers are asked to build a car boat, which everybody hates because nobody wanted a car boat. For me, this is not an organization that can't make capabilities decisions, like Cat teaches about capabilities decision about what matters most in the system in order for it to achieve its mission. They have to be able to do that to not get a car boat.
Peter Hunter: I was just going to say also like the principle side of things, shaping it up front. Specifying those or having a workshop to define those as a shared group will hopefully get that alignment. You up front it, you step into that, so that all the teams are aligned with a common goal and principles that will guide their decision-making. You tend to get less friction then.
Cat Morris: Read the book, "Never Split the Difference", compromise is a fallacy. Most of the time there is a goal that you can both achieve and get what you want at the end of it. It's not the case of either/or, or both of you have to give up something.
Andrew Harmel-Law: There's an approach called deep democracy, which I don't talk about in my book. There's a book called "Collaborative Software Design". They talk all about deep democracy.
See more presentations with transcripts
