Navigating engineering-focused environments #FOSSBack

This panel discussion focuses on the integration of design within engineering environments, especially in open source contexts. The speakers, including UX designers and engineering managers from organizations like Canonical and GitHub, explore how the collaboration of design and engineering can enhance user experiences. They delve into misconceptions that both designers and engineers may have about each other's workflows and emphasize the importance of creating a shared understanding of user needs. Through personal anecdotes, they illustrate how fostering curiosity, empathy, and communication can help bridge the gap between design and engineering, ultimately leading to better products and more cohesive teams. The importance of including design feedback throughout the development process and ensuring that design considerations are viewed as integral rather than secondary is also highlighted.

Welcome to our panel discussion on navigating engineering focused environments. So, many of us here in this room and online already know that open source and open source processes are somewhat tailored to developers. There's a lot of fast feedback loops, you know, terminal tools, Git workflows. But, in order for open source and open source processes to really thrive, we also need to consider great user experiences. So, what

we're going to be trying to answer today is where does design fit into that picture. So, before we get started, do some quick introductions so we everyone knows who we are and our contacts is. So, I'm Miguel. I'm a UX designer at Canonical and I work on our web app software operators and some open design initiatives with universities. And before that, I was a university student that

I did some creative computing and then went into UX design. So, I've some context in both different fields of design and engineering. And yeah, I'm hosting this panel and thrilled to be here. So, what do we go down the line? Okay, hello. I'm David Adler. I work for Canonical for 3 to 4 years. Um I'm very thrilled to work on open source full time. Before I contributed

here and there where there was time. So, now I have much more of my time focused to it. Uh I'm an engineering manager and it's me. Cool. Um and I'm Gloria. I work at GitHub as a design director for the security and enterprise and platform teams. And I guess the story of my life is um dog fooding because I'm building GitHub with GitHub and before I was

designing Sketch with Sketch. That's that's my past role. And uh yeah, so I've been a bit everywhere within this workflow you were describing always very meta. Hi, I'm Errol. Uh some of you may know me as one of the core maintainers of open source design.net which has been going for more than 10 years now. Uh where it's a design community um where your designers often find their

first interaction with other designers that are doing things with open source as in contributions being the things. I work currently at the Open Home Foundation which may be more familiar as Home Assistant. I work on the departments that look after music assistant and the ESP home which is the ESP32 chips. So, everything to do with the ESP32. Um Home Assistant is a home home smart home automation

uh system that's open source. Uh I've been there for 3 months. Um some other things about my history, I've been doing design and open source since 2018. Mostly in the humanitarian and human rights open source software space and privacy and security. And the other things that I am doing at the moment, I'm a Penpot ambassador. Yay, Penpot. Um I'm on the advisory board for the Open Technology

Fund looking at Foss sustainability funding and I advise the ethical open source licensing for alternative licensing for ethical ethical um open source. Great. All right. So, let's get started and let's talk about culture clashes. So, we usually speak in different languages in design and engineering and we also sometimes can work at different paces. So, what do you think are the biggest misconceptions engineers have about designers and

vice versa about designers have misconceptions on engineers? And what do we start with you, David? What misunderstandings do you first see designers have about developer spaces and engineering teams? Um yeah, maybe give it a bit of a positive flow. So, what was my positive experience is when I started collaborating in Canonical, one of the UX designers took me on the side and she shared all the way

she works, explained very detailed her workflow and her like, okay, I do 30, 60, 90% checkpoints and at that point this when I um talk to engineers as well and in but iterations I need some space on my own to kind of iterate and and take distill my thoughts and I can't have uh collaboration all the time and I think that's something very individual and that's a

good talk to have with your designers to understand what works for them and I think it's also an individual uh thing. For other people it might be different. Um another aspect is users love empowering software. They love software that lets them do something and to build something like that or that's actually a good goal to have as an engineer also. You want to build something that others

people find useful. But how do you do that? But I think you have to start with user needs and as engineers we don't really we're not the people that are skilled to understand the user needs and actually UX designers or also other designers, visual designers are. So, there there is this potential for collaboration that really benefits um the software you build. So, that's one aspect of avoiding

misunderstandings is to teach engineers as designers the importance of user needs and user-centric design and user-centric development. Also, one aspect that I thought about, without design, they often think, oh, I will just add this feature and it will make my software great. But we all probably know these interfaces with thousands of gazillions of buttons in one screen and you don't find what you want to do. So,

adding features might be the wrong thing actually. So, that that that's where also um this approach can help you. And um yeah, especially in Canonical, it's a very engineering driven um uh organization and I think also many open source uh communities are very much engineering heavy. So, I think for designers it can be a bit of a challenge just to be outnumbered. So, they might have an

opinion and they might have something a bit challenging but they're the only one and they're talking to bigger group. um that can be a challenge and misunderstanding and yeah, as a lead for a software you have to be aware of that and kind of cater for that. And it's good you had a positive experience as well with design. So, good success story. And what about from the

design side? Is there anything that we get wrong about engineering workflows? Gloria, if you want to start. I'm a bit anti-engineering workflows. I think I believe in shared workflows. Um in fact, in at GitHub we work in EPD team. So, that's engineering, product and design that we all work like lockstep together. So, there is no such thing as a developer workflow and a design workflow. So, that

helps, right? Like understanding that we are building a product ultimately. So, it's not like about this feature or this thing. Like we are building something somebody will have to use. And they don't care how you are organized internally or how your workflows are. So, let's try to blend them and make them, you know, as indistinguishable as possible. Um but I guess one of like something that's interesting

that like it's a real real case, right? Things that happen daily when we work with engineering now that sometimes you we designers get frustrated at something that seems so easy, you know, in our eyes like, but how do you mean you cannot build this filter in this list? Like you have the information. And they're like, yeah, but the that data model doesn't allow us to do this,

this and that. And then we're like, oh, you know, you default to the these guys are lazy, you know, like they don't want to work. >> [laughter] >> Uh but uh I think like building this um understanding of what is like behind the curtain and how the things are architectured and how the data models are uh built and how things connect with each other and building this

empathy, you know, like blending and bending your uh skill set so that you can get a bit into uh engineering world and vice versa, right? Helps a lot. But also, another hot take, I think if this data model was built with designer uh sitting next to them, probably it was it would have been architectured differently. So, sometimes these decisions that sound like very, oh, this is a

metal, you know, like very uh back ender decision, I don't need the designer, right? And you know, these things happen. You might think like the architecture the right architecture is one but then user needs say otherwise. So, yeah, I guess yeah. I don't know if Everyone take notes. >> Um I have some other points but I really want to reinforce what you're saying with an example hopefully

that shows this. Uh when I worked as one of the only paid designers at one point at the Open Food Network a few years ago. At the Open Food Network is a like an open source system for sustainable food supply chains. So, it was a system for like food producers to sell their goods more like locally um but also like with a less of a big tech

focus. But um at one point there was um we had a very integrated flows like with design and development as well. Um I was really proud of a a moment where I was able to um add to the QA flow a design QA, the concept of design QA. Um and that worked really well and actually the QA person was like, oh, of course. Now I'll do this.

I'll I'll do design QA as well as engineering related QA. They just needed the single perch to to know that they were kind of like able to and allowed, right? Um but there was this one moment uh where they were looking at building a new like API back end point, right? And I was like, "Oh, cool. So, when's that meeting? When are you talking about this?" And

they're like, "Design API? What?" And um it's not that I could really like you you know, I don't have experience of like building APIs or even you know, calling them myself, but I'm curious to know what the implications are across the product. Cuz it's not just the API is the domain of the people building the API. It's important to know how that's going to be used by

a user. Is there another way to interface with it in some way? Um so yeah, I think it's really cool what you said, Gloria. Um but uh my what do we get wrong about engineering workflows that they're all the same? Um there's this assumption that everyone uses some form of like, I don't know, Agile workflow or whatever in certain circumstances and every single open source and proprietary

place that I've worked has a had a different way of doing however they want to do cycles or sprints or they don't do them at all. So, every engineering environment is unique, right? You have to learn it. You have to take the time to learn the the environment first and not assume that I think sometimes designers or other people might read like an Agile article or maybe

read the what Basecamp Shape Up book or something. And they think that that's how everything is done everywhere and you really need to get to know the environment. Um and the last point that I wrote on this is just that engineer the there's an assumption that engineers don't want to get involved in design processes and that's completely contrary to everything that I've known. They're just waiting for

the invitation essentially. They're waiting for the invitation but also the they also have to sometimes argue to their manager why they should be involved in the design processes. So, it's all a process of how can you help each other be involved with with each other's processes. That was kind of really shifts well to my next question about more of the reality of our day-to-day work and I

mean, I think we established that we want to be more connected and union like more of a sir what's it called like central force that works together. But how do we in teams where maybe design isn't seen as a a primary thing, how do we bring design feedback into those developer cycles in a way that we don't slow them down or lose design context in translation? And

Gloria, GitHub is well the hub for this. So, how have you seen teams successfully use GitHub as a design collaboration tool? Um yeah, like we talk food a lot as I was mentioning and everything happens in the platform. So, we might not be the best example cuz we are very very heavy users of our our own product, right? So, we might not be the ideal picture but

we do use a lot of um discussion features, issues and of course something that uh Errol is saying about QA and how to integrate design in the QA phase that sometimes it feels like design is or design QA feels more like a polish. Like it's like a separate PR always. Like it's like the the last mile thing. It's like, "Oh, create an issue with your feedback and

then, you know, we might or might not have time to get to it." And that's a thing that we should try to avoid by using the same workflow as the code goes, right? So, that if you have any feedback on a feature, use the same process. Like the same PR, the same issue. Try not to branch out because it's not a polish. It's not an improvement. It's

not something you want to add on top. It's not an extra thing. It's like the thing, right? So, it's like writing bad code and being like, "Oh, no, but yeah, write an issue and we will make it work later." It's like, "No, it doesn't work now. Fix it now, right?" >> [snorts] yeah, I think it all it sounds repetitive but it all boils down to walking together

the path and um not not having things happening um afterwards. Yeah, I would say for us it's issues, it's PRs and the other you mentioned sorry to go back to the question. You mentioned the keyword to me which is translation. No, you said [clears throat] how do we translate things? Uh something that I'm seeing lately is that this translation gets smaller and smaller as designers get closer

to the code and as designers start prototyping more and more using the real code. And basically sorry, Figma and then both but >> stop using more like design tools and start using more like deep so that the end Where where the engineer is where >> Yeah, like where the real thing goes in production, right? So, that this translation gets smaller and smaller and smaller. There's a point

where there is no translation. Like if you have a very well-designed design system and that the designer can quickly put together a layout and explain a flow through you know, like real code. Like there's no explanation to do. It's like this is how it works. So, yeah. Uh Errol, you've worked in various open source projects. Uh what practice have have you seen to be best suitable for

I guess making your ideas visible and actionable to engineers? Uh there's a few. The funny answer is you uh indoctrinate your developers into design knowledge and thinking like in a in a nice Obviously, you're friendly. You talk about the importance of design. I just um if you'll allow me to open my work Slack and say a comment from one of my developer teammates uh literally today um

because it kind of sums this up. He said to me, >> the name. Don't say the name. I won't but he'll know who he is uh from what he said. He said um let me find it. You You are So, this is one of the core developers of Music Assistant. So, maybe it narrows it down. You are re-wiring my brain. Haha. Um started watching some UX stuff

on YouTube as well as I look at designs in a completely different way now. And this is from one of my developers. And I've been working at Home Assistant on Music Assistant for like 3 months. And it just took going into all of those conversations with like an open mind and being like, "Well, this is why I care about the usability of this tool. We all want

to make this better for all the users that we we love this open source in a kind of a way. Open source is kind of one of those things where you can love it in a different way than working at a proprietary company, right? There's something slightly different about open source. And so, you can uh have a different relationship with open source than I personally have a

than I did the proprietary tools I was working on. So, we're all there from a perspective of we care about the user. Um but on a practical term, there are things there are certain ways that I've found that are really really useful. And really it boils down to designers being interested in documentation, whatever that means to themselves. Like So, um I I also have I also kind

of want to speak to this this comment of like uh there's something about like should designers align more with development flows or how developers are working in open source? Should we learn how to code? Should developers learn how to use design tools? Should we be using the processes that developers use? Um Is that doing something different to the design process? And I kind of think it all

comes down to how are we respecting and appreciating each other's ways of working? Like I through through my design I in in open source I was really interested in learning, "Okay, so why do you do the open source in this way? Why do you um have like critical comments and then nitpicks? What does that mean? And how could I use that in my design actually? Like how

could I use code review processes like in commenting, nitpicks? And how could I translate that into what I'm doing in design that makes sense for me but also helps me speak the language of developers as well? Um but a very pragmatic thing that I've been doing lately in my design files is I've been putting uh like version control of like when I edited this design, what I

did to this design and and the dates. Also for the contributors, the design contributors that are coming into the design file. I've also been uh having uh creating discussions for in our Discord Discord forum around the design so that the developers and the engineers and the open source community can um can give feedback in the area where they're comfortable, which is a Discord Discord forum, not the

commenting in a design file. Um so, I've just been kind of structuring my designs in a way that is good documentation essentially, I would say, more than anything. I I love what you said about like bringing the designs to where people are so that you get like the the real juice. And also the fact that just want to reinforce that. I love it but also document the

final decision somewhere that you can find it later because we do have a lot of Slack threads and like things happening everywhere and then it's like, "Oh, but when was this decision made, right?" Or who made the call. So, you always need like a decision log. I mean, in our case we use this this discussion post and we just they they blah decision was made blah blah

and this is the link to Slack and it's fine. But track those things somewhere. Yeah. And David, can you share any examples where maybe you've adopted your workflow or your team's workflow to include design and how did it turn out? Yes, sure. I mean, some of these things have been mentioned already like design QA, it's necessary before you merge any any PR. A designer that designs something,

they look at the end result or the proposed change and they say this is in line with what I intended. And this goes together with engineers understanding the intention of the design because sometimes there's deliberate white space or there's deliberate organization on a page and it's good to share this knowledge with engineers because it's also good for them for the future because maybe next month there's something

they build and they can recall and they can use that knowledge so they can also become a little bit of designer. And this notion of not needing translations, I'm not sure if I fully agree because from my experience engineers often find all the edge cases in a design so there there is a tiny gaps or tiny like oh, but what if this is null and what if

you're loading and this is here and this is not loaded and and these kind of >> you design next to an engineer. [laughter] Exactly. Because they're like Exactly. So, that's why you need like collaboration and that's why you need feedback loop. Can be a little bit annoying maybe sometimes I think for for designers and but but then you need a culture of sharing this kind of critique

in a way that is on eye level and not then oh, you did a mistake or something like that. Um so, yeah, be nice to each other. And again, there's this balance for check-ins versus giving free space to iterate. Some people they don't like to think and build their design in the fully open because they're all the time criticized and then it's like hard to basically there's

no freedom and always the fear of there will be another negative comment. So, yeah, that's that's a very personal thing. And one thing about because you asked about workflows, uh specifications, I mean, any change you do you should usually it's good practice to start with a specification and start the specification with user stories. Describe what you want to do. What is the goal? The user should be

empowered to do X or Y. And that helps to also think from the perspective of the user and I think that's a practice engineers can learn that that at least my experience I learned it from designers writing user stories first. It's to be fully honest, I don't always write the spec. I don't always write start with user stories, but it helped me take the perspective of the

user. So, in kind in this way you could say designers advocate for the user in the in the building process. And you don't have to do it all the time. It's a bit like I had this comparison in my mind about test driven development which I did for like 2 years and then I thought it's too tedious, but doing it for 2 years taught me to when

I interfaces like function interfaces, not human interfaces, uh to build them in a way that they're testable which is good. And then you automatically do that and you kind of don't unlearn it and that's the same here like once you start rigorously always writing user stories first and in the future even if you don't write the user stories, you still think oh, but what is the user

perspective? And I guess also well, as you guys said, adapting to the shared toolings key I I think asynchronous communication and and being able to documenting your decisions are very key in showcasing and work together in a better way as well. Asynchron- asynchronousness is the one of the powers superpowers of open source, right? Because open source is you could some could say superior to proprietary in many

ways because it's so much more inclusive of many more perspectives cuz it's by its nature um about how we collaborate across borders, across um different kinds of play It should be it's open, right? Is that's the whole point, so. But even if we have the right tools, we still need to convince people that the work matters. And I think as we established, design can sometimes be seen

as a secondary thing to pushing features or the road map in general. Something that connects a bit to the talk from Juan and and Lea earlier on accessibility. Uh something I recommend, I don't know if there's designers here, but something I recommend to get people excited about features is to put things in front of users. And if you have an inclusive design panel with people with different

needs, it it it is very impactful and really drives the vision home seeing how somebody uses the product. And I had seen developers be like, oh, like we really really need to fix this. Like this is awful. I feel embarrassed or whatever, right? And >> Yeah, we had a we had a when I worked at Ushahidi, um we had one research um we we did some in

in the field research for a tool a prototype tool we were building and developers came with us, obviously. Sat in in all the user testing, sat in in the um we did like a stress test of like how this app should function in like under um connectivity stress um because, you know, uh Kenya East Africa connectivity is is um tricky sometimes. Um and I remember one of

the lead engineers, she spent the day with us at user tests and then that evening, I wish she should have she should have slept probably, but she stayed up all night writing user story issues because she was so jazzed and so excited about what she had learned, but she was writing them from a perspective that I didn't know cuz an engineering perspective, right? So, yeah, joining having

those conversations is so important. >> this aha moment with the sign-up flow at GitHub. Uh I shared I think at the pen pot first because it was recent, but we had a visually impaired person going through it was something else. Like I I we prioritized that flow I think the morning after. That's also my experience with user testing. If you join them, that's heavily motivating because you

see you think you build the right thing and then they show you no, actually someone struggles with it and then you think very hard like I want to make it right. And I want to go back to sort of how do we frame design and how do we frame the impact of design so it resonates with engineers and maintainers. So, David, if you could share what you

mentioned, the user testing, but are there any other sort of design contributions that you found helpful in in being able to understand what the impact of having design is? Well, there there's the obvious uh big value of you get a finished Figma or pen pot design and you implement it and it works and I mean, that's uh right on the table. There's also, yeah, quick improvements of

copies. Sometimes you have labels and and like the text visible in a web application or desktop application. It's important to get it right, to make it discoverable and yeah, design definitely can help because they have a way to think like the user and also a user who doesn't know the tool and then what would they look for and what's the right copy so that they understand the

function is in this and not in that menu. Also like information hierarchy. Uh it's also part of design, I think. And yeah, just understanding the user problems and and teaching engineers to think in that way. And you guys mentioned about your uh having documented decision logs, but contributions that help you push your idea and to get that buy-in as well from Um one that I can think

of is so, normally we there's a lot of work it's hard to prioritize because maybe it's not like the shiniest work, which is trying to standardize things, uh find patterns, frameworks, things that like repeatable things that you can reuse across the platform from the UX perspective I mean, is crucial, right? And sometimes it's hard to get those things prioritized because they are seen as enhancements. But then

when you sit with engineering and you kind of you know, show show the cards or or like like look at each other's cards, you very quickly realize it benefits everyone working on these things because of scalability. You can build faster afterwards like if we fix it now, we we remove a lot of that. You can remove a ton of code that you don't have to maintain. So,

it's like there's this more like systems thinking perspective that I think both disciplines share for different reasons, right? But it's like this are a perspective that benefits I think everyone in the room. So, I think thinking of these things, you know, to try to get these people excited to prioritize those things or to get this buy-in air quotes because I mean, I I don't think we we

should be getting buy-in, but I I get what what you mean with that. Yeah, I think the the tricky thing here is that we wish that it wasn't the case that we needed to try and convince people that UX and usability and accessibility and everything that you could push to the kind of design side of things is also is important as whatever else you know, might be

regarded as important from an engineering perspective. Um, but I guess that is the case, right? Um, I kind of feel like this comes still down to a lot of communication. So and I I certainly have found um, it's often it often feels more difficult to get buy-in from community than say the people that I'm working more closely with on an open source project. So if you do

distinguish uh, so I it's quite unique for an open source project I think to have that that kind of staff element and that community element because we're not really we haven't really spoken much to the kind of open source projects that are all community contributions, that are all like have no kind of uh, staff resourcing or very um, ad-hoc. Uh, maybe like bounties based payments and things

like that. Um, but I think that it is about how much time you spend able to being able to communicate what you've done and why. and that sometimes just takes time. But I think Victoria um, spoke about the Prometheus internship earlier today. Um, and I think one of the things that I uh, really enjoyed in her talk was that she spoke about how important it was for

the observe the open source community before proposing hey, I want to change this design. I want to make this better. I want to I want to implement a design system or whatever. Not every open source software needs to have a design system. That's a hot take maybe. Um, some people will agree with me uh, disagree with me. And like yeah, it's it's it's about observing the space

of the open source and contributing authentically to to that space. Um, so those kinds of things communication is really the thing that it comes down to with with um, communicating for buy-in. Um, but I'm also a big fan uh, lately I've been doing hand sketching for product um, for my my product cycles. And I find that I come up with different ideas when I'm sketching by hand

than when I'm sketching in say like a design software. Um, and I think that that actually really helps things to feel emergent and dis- around discussion and not feel like it's kind of like, okay, we're pushing for prototype. We're pushing for this speed and things like that. It helps people I think sketches and wireframes, things like that help people to stay in an explorative mindset rather than

the kind of mindset where when I've shown high fidelity designs to some community contributors in open source, they resist it a lot more because they're like, oh, you made the decision already. It looks like it's already decided. So what can I even contribute here? And sometimes even worse things that have been said to me which I won't repeat. Um, because this is recorded. But um, yeah, I

think you have to be there's a there's a certain amount of empathy that really needs to kind of come into this interaction with with the people you're involved in. I'm a bit cautious with time, so I want to get quickly to some reflections and if you could give one piece of advice to this audience or maybe one thing that you wish you would have done differently when

bridging design and engineering, what would it be? Anyone can go. I can go. I think um, the biggest piece of advice to me is like staying curious and uh, trying to learn what the people around you are doing and how they're doing things. And something I think we should all be doing. I know it's rude doing it in real life. You should not do that in real

life. But going to other people's spaces and opening all the drawers and like cupboards and laying what you have here and what you have here and how you do this and how you do that. Don't do this in people's houses, please. But uh, I think discipline wise like it is so important to stay curious and understand. Um, and likewise uh, designers I think sometimes we are too

privy to our discipline and we might think like not everyone can design. Right? [snorts] Also like lower that idea and let people in uh, and yeah, like share what you know and uh, give back, I guess. Yeah, everyone starts somewhere, right? With design, with engineering. Um, designing for the ESP32 electronics experience is incredibly difficult because like a lot of it is hey, everyone should know a level

of electronics before this and it's like everyone starts with if they want to learn electronics, they got to learn the basics somewhere. They can't automatically know like what the best way to solder is and what a pin on a board is. Uh, some they've all got to learn. Um, but I think the one piece of advice that I would give if I can only pick one is

to go to each other's community spaces. So we're blessed in open source that we have community and it's actually like open source is as much building a software as it is in being community with each other. Like there was this wonderful thing that happened at chaos a chaos event um, at one point where everybody was in the room saying like why they contributed to chaos. It was

because they made friends at chaos. They loved building the chaos metrics platform and system and everything that chaos does, but really they made friends for life in open source and so have I. Um, and so being community with each other, designers and engineers come to design events, engineers please. And you know, designers go to go to an engineering related um, talks and conferences. Ask questions. Be curious.

Be curious. Yeah, I have a similar idea. Um, I wrote on that design and engineering can and should teach each other. Should be curious kind of the same point already made. Um, we have sometimes individuals who are skilled in both, but I think it's very very rare. I've seen like one or two individuals in my life that are good designers and good engineers. to build good software

you need both, so you need to collaborate, you need to understand each other and that's the only way to build high quality uh, and to build something yeah, that users in the end love and find empowering. Um, so yeah, collaboration on eye level, that's that's the key and as Gloria also mentioned, designers can learn the design components and then their designs can also be easier implemented. So

there's this level of um, sharing sharing knowledge and and that's yeah. very good food for thought and a lot of good lessons and advice. So thank you very much for your insights. I hope we have some time for questions from the audience. Okay, we have some time. Questions. >> [applause] >> Yeah, thank you for your talk. It triggered a lot of memories and experiences. PD as well,

no? Huh? I'm going to ask a simple one. How do you resolve conflicts? It's very >> simple. How how much time do we have? Conflicts between whom? Engineering and design specifically? Does Does anyone have I want I worked on this project once and this uh, we were work- it's the same prototype actually where we did some field testing. Um, and one of the engineers different time zone

to me, so made it really different time zone to me, so it made it hard to sync up um, to to chat. One at one point he had um, completely redone the application. Everything to do with the back end, everything to do with the front end overnight or something like this. And this has happened a few times to me where um, uh, engineer has kind of either

taken a design immediately done a PR um, on and iterated on my design without like a conversation. Um, and at that point I mitigate Well, it's not really conflict as such, but I I'm like, okay, there's there's an energy here which is enthusiastic to say the least. Let's slow down and have a conversation about it. But honestly, rarely I've had to really be harsh um, and put

down like a uh, this is a conflict. It's more about like are we spending enough time listening to each other and understanding each other's perspective? And how are we how we encouraging that? We ended up um, doing a lot of side-by-side design development that with that one engineer. I have to say that most conflict I have I had seen in my life tends to be misunderstandings and

uh, like flawed communications. So normally it's yeah. There's I always assume good intent from everyone. So it's like what you're saying like sitting and talking through things. Normally everything solves quickly. I'm afraid the time is over. There's probably more questions um, that you can address in the coffee break that's following now. Thanks again to the panel. Thank you. >> [applause and music] [music]