Quality Bits

Perceived Quality & Trade-offs between Product and Engineering with Alaa Sarhan

• Lina Zubyte • Season 1 • Episode 3

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 40:13

In this episode of Quality Bits, Lina talks to Alaa Sarhan, the CTO at wundertax.
Alaa is not only a great engineer, but also someone who is passionate and caring when it comes to product. You'll hear about the idea of perceived quality, as well as how to balance off product and engineering when creating high-quality products.

Find Alaa on:
- Twitter: https://twitter.com/AlaaSarhan_WTX
- LinkedIn: https://www.linkedin.com/in/alaas/

Alaa's reading recommendations:

Further reading recommendations for some mentioned concepts:

Links to books are to Amazon and as an Amazon Associate I earn from qualifying purchases

Follow Quality Bits host Lina Zubyte on:
- Twitter: https://twitter.com/buggylina
- LinkedIn: https://de.linkedin.com/in/linazubyte
- Website: https://qualitybits.tech/

Thank you for listening! Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.

Lina Zubyte (00:09):
Hi everyone. Welcome to Quality Bits, a podcast about building high-quality products and teams. I'm your host, Lina Zubyte. 

In today's episode, I'm talking to Alaa Sarhan who is an amazing person to talk about trade offs between engineering and product. He's a CTO, so he works very closely with engineering and you should be an amazing developer. Still is, and he has a big passion for product. So in today's episode we're talking about the idea of quality, the balances, the tradeoffs that we make between product and engineering, as well as about the building harmonious teams. Have fun listening to this episode. Hello, a welcome to Quality Bits.

Alaa Sarhan (01:13):
Hi Lina. How's it going?

Lina Zubyte (01:15):
It's going well. How's it going with you?

Alaa Sarhan (01:17):
It's going great. Thank you. Excited to our conversation today.

Lina Zubyte (01:22):
Same. So could you please tell a little bit about yourself?

Alaa Sarhan (01:26):
Hey, yeah, absolutely. So yeah, my name is Alaa. I grew up in Damascus, Syria and I graduated there from Damas University whole, the degree in information technology, kind of software engineering or information system engineering. I moved to Berlin in 2015 and I live here since professionally. You might actually say that I am a software engineer by trade, but I feel like I'm more of a product developer at heart. I love or big passion of mine is I dunno if you call that a passion, but <laugh> a big drive for me to actually build meaningful products and by meaningful I mean having a positive impact trying to solve real problems for people that they face on regular basis. I spend a lot of my time whether at work or even sometimes my private time or free time as people might call it into thinking about this stuff and working on it.

(02:39):
Another topic that is interesting to me that I also have been spending some time on is building or rather growing strong product teams. And this is of course recently have been combined for me in my current job as a a CTO at Wunder Tax here in Berlin. We are based in Berlin and in the role of CTO of a small company in terms of headcount, we're about 25 people. The role is going to be about these two things that I really love. So building products digital product. In this case our product is actually helps people to file their tax returns in Germany. And of course at such a size I am directly involved into making sure that our team is a productive team, a strong team that is harmonic and that they have good dynamics and they have everything they need in terms of skills and tools and environment to be the best they can to deliver the the best work they can do.

(03:55):
And yeah, I love really this job mainly for that reason, but it's also that we are really, really building a really meaningful product. In this case one of the most meaningful products I've actually ever worked on in terms of its impact and the services it offers. Apart from these two things, I have some quite a curious person. So in general I have no long term fixed hobbies but I enjoy quite a lot of music playing and then listening to music and composing even sometimes or attempting to and enjoy doing some sports and the company of others are really enjoying time with friends and enjoy being in any kind of social activities. And another big part of my life and energy and emotion and stress and love and everything that goes into that is parenting or co-parenting. My four years old daughter with her mother and yeah, that's pretty much myself I guess in a nutshell.

Lina Zubyte (05:08):
So let's start with the basic question and the base of this podcast and the definition of quality. So with your vast experience, what is quality for you?

Alaa Sarhan (05:22):
That's a very good question and it's hard to reason about because at the bottom of it, what I think we usually make a mistake of is we think about quality as if it is its own thing separate from everything else and we just need to think about it and do it, integrate it into our process of building a product for example, as if it is an external add-on component. You should just fit it in and find the right way to hook it into the process. What I believe is the better way to think about it, what I feel like is also more natural, maybe not the most intuitive, but it is definitely the most, I would say organic way to think about quality. The way, if you don't think about the word quality it is there and how is it there? It's there in everything you do at the end of the day it is a part of the mindset. It cannot be just an external process you do or external task or even I often conflict in or conflicted before and in the past with the idea of having a QA in, I know sometimes it has its own benefits in some level or depending on how complicated your technology and your product, how it's built. But in general it's never a limited thing to a person or a separate task.

Lina Zubyte (06:49):
I'm happy that you separate the concept of quality from QA tasks or roles because even if they're related it's not actually the same. So in this case I wonder how would you define quality?

Alaa Sarhan (07:05):
The way I think about it in general is what matters is the other way around. What usually happens when we take that mistake and think about quality inside out. I think you should think about quality the other way around from a user perspective, from our market perspective because at the end of the day that's what matters. So I usually say what matters is the perceived quality by our end user or by the market or by your community. If you're working a non-profit project, depending what your target audience is, then the question becomes or another question, the way of thinking about it becomes a lot different from the usual habits or processes we build. In many cases,

Lina Zubyte (07:47):
I really like the term an idea of perceived quality. If you had to slice it down on what it's built from, usually what would it be.

Alaa Sarhan (07:56):
When you start thinking about that way you realize that well for our target audience or for let's say user to for simplicity for our user end user receiving or using our product or service, their perceived quality is going to depend on factors such as their trust in our brand maybe or maybe in the product itself. It's going to depend on how much value do they really derive from that product and something we don't usually refer to in business language, but I like to use that term sometimes. I mean in business we always think from internally about customer lifetime value, but I think from the customer perspective that is what I would maybe call product lifetime value because for your users to start using your product and stick to it the stickiness of your product, it depends on many factors, but one of them that we've sometimes don't think about or maybe we never really termed or leveled something is what I call product lifetime value.

(09:00):
So how does your customer perceive the value of them investing and sticking with your product on the long term, not just the immediate value they derive from one news today and tomorrow. Not only the instances in which, but also how do they perceive how much value it's adding to their life, how much is it simplifying their life by solving problems? If they would imagine that product didn't exist, that those problems would be an annoying to them or they would still exist for how much effort. I mean it's a kind of balance of cost benefit analysis a little bit that's going subconsciously in every user's head. I think when they are choosing the product,

Lina Zubyte (09:43):
We often hear about putting users first and I like the concept of the perceived quality, but how would you approach the idea of quality within engineering, meaning that your engineering works quality is good,

Alaa Sarhan (10:00):
So I would want to look at quality from that end first I think, and then we start driving into our internal processes of building a product or how we internally look at the quality of our work starts to look slightly different. Like a typical mistake we do when we don't look from that end is we start optimizing for quality that doesn't matter and I know this is hard to say or hard to hear for some people, but sometimes especially engineering, if I take an example there, since I'm mostly an engineering and see they're mostly you see a lot of engineers argue and want to, when they hear the term quality, I mean you tell 'em like we wanna deliver quality products. Many immediately think of yeah, my code should be top-notch quality and the best code I've ever written and it should be like a hundred percent test coverage, always architectured in a way that I know it's going to be maintainable for the future. It's going to be something I can extend in the future very easily for some hypothetical scenarios that I just come up with in my head. That's a big mistake I think we do very often in engineering when we don't think about quality from the user perspective.

Lina Zubyte (11:20):
There was this quote by Russell AOV and he said better to build the right thing wrong than the wrong thing, right? Correct. Yeah. And this top notch engineering does go to this way that we will sometimes, which is not really necessary. So how do you balance this out? I know that you're very much into product as well, but you're also a shift technology officer, so you do work with engineering a lot, so what would you recommend here to balance the trade-offs in delivery between the quality of engineering and product

Alaa Sarhan (11:59):
In the essence or big picture? It's not that complicated. I think it's simple. The only thing you need to do is switch that mindset to look from the other end and then once you do that you realize that well first and foremost you want to deliver to the customers and the users to their expectations and to maintain their trust and confidence in using your product. That's your priority. This means you want to, when you are delivering something new or you are changing your product, quality means in that kind of first stage or first let's say step of delivering that value, quality should mean that you put only enough effort to first deliver that value or that new feature or that new product even. You need to put enough effort so that when it's out there your customers will derive value from it or big chunk of your customers.

(13:00):
Sometimes you want to not necessarily target the whole entire audience, but you choose the subset of it for the beginning, so you want to make sure they del derive value from it and they don't have a terrible experience. Something we worry sometimes way too much about is that, oh, there should be zero bugs is never a realistic thing to begin with. We know that, I mean it's maybe good to aim for, but in the first stage you wanna deliver value as soon as possible and in a way, as you said in the quote, better deliver the right thing wrong. So if you deliver something that your users perceive as like, yeah, this is a good solution that I'm deriving value from, oh, but wait a second, there is a little issue here and there, but it's fine. I see that that is working, it's going in the direction that I wanted to go and maybe those issues are not necessarily blocker for value delivery but just not very nice to be there.

(13:58):
So those you can patch up, you can improve in the second step so it becomes more of a two steps process. I think the first step is you wanna deliver decent solution. I would say that works delivers value and addresses the target also you mean to address solves the problem you mean to solve. You need to understand those kind of things first so that you are a bit intentional unconscious about what you are trying to deliver so that also when you get feedback, you understand it better when you know are you're succeeding or failing, you can better know why. If you're just blindly putting out things out there, then it's much harder to do that. Now the second step is, okay, now we've proven that this works, we've proven that our customers or users derive value from this and they find it useful. What is there that is just making the user experience less ideal or less smooth or creating a little bit of friction here and there or confusion to some of users this step should happen afterwards and soon so we should not forget about going back and fixing that.

(15:05):
But then it also still needs to rely so much on user validation and customer feedback that you are come that's coming in. It is important as you internally as the team building that product, whether in engineering or in any other function, to look at it from your own perspective and eyes and think, I would like to deliver a better product there, but it is not enough. You need to get the user and customer feedback. Now to get to the engineering level, which is the most interesting <laugh> controversial level where we struggle with this understanding it, I think there needs to be somewhat a connection between when we and engineering think about, oh there is those terms, we say our coach should be maintainable and should be scalable. These are the big two that's good, but it's very theoretical and it could be very limited to engineering thinking and very kind of non grounded,

Lina Zubyte (16:06):
Not specific at all. Right. Maintainable, what do you mean about it? I just recently saw a talk by Rebecca Parsons about building evolutionary architecture and she said that yeah, usually we have these goals which are like maintainable, what does it even mean? Yeah, does it matter for your product or doesn't matter? Let's talk about value and specific actionable things and they suggest a fitness functions for evolution of your architecture.

Alaa Sarhan (16:35):
Yeah, yeah. For me this is the software architecture, I don't know if you wanna call it movement or phenomena sometimes it just went too far. Also in isolating what software architecture is outside of the context of at the end of the day we're talking about products built to solve problems in the market. So your value function or the function that tells you if you're doing well or not is pretty much determined by how your customers perceive your product and how they use it.

Lina Zubyte (17:08):
Absolutely, yeah. And I guess also the success differs, right? Based on a different company and different product. And I wonder how do you decide what success is for your product based on maybe product maturity or what you want? Do you have any experience and examples there?

Alaa Sarhan (17:29):
Well, as you said, in general sense, you wanna build a pros trust and confidence in your product or maybe your brand and you wanna make sure your customers understand the value proposition and what they've derived from that product. Now this differs quite a lot depending on what stage and what type of business model you have and who your target kind of segment is. For example, if you are let's say pre problem solution fits and targeting let's say businesses, you are targeting SMBs with some solution. I had the opportunity to work on something like that a couple years ago where we were building a contract negotiation solution and in that product for example, or in that stage the way we were entering the market, let's say we were just directly in contact with some businesses and we had a very close relationship to them and we were building the problem solution fit together with them.

(18:32):
We just went to them and we started talking to them to understand their problems and how they usually function and what the process looks like on their end. And we started putting the bits and pieces of how it could work in a software solution that solves some of the annoying problems they had in terms of filling up the process and making it a little more digital and much easier to access and collaborate on success. There was basically direct feedback from those initial customers and our success for that stage would be determined by finding really the right problem solution fit and then how do we know we found it, we can only know it by directly talking to these customers. It was direct qualitative feedback from these customers and see it working and seeing them paying for it because when your customer pays for a product, this is their vote, this is their mechanism of telling you, yes, this works, this is valuable for me, this saves me quite a lot.

(19:37):
That's the first validation you are getting there. Now from there and then in the next stage we would've needed to go into product market fit. How can we scale this? How can we build the whole process around how do we acquire more users? How do we present that value proposition in our usps? What are actually our usps? Do we have other segments that can benefit from the same exact product? Can our market expand basically? And your success there starts to shift a little bit towards it's still the same you are in that case, for example, if we're building more of a SaaS business model, then the feedback we will get about our success is going to start to become a little bit more quantitative in terms of how is it growing in terms of maybe conversion rate, if it is going to be less of a sales process, like more se self-service, if it's sales, then sales will determine a little bit the success in terms of how many customers we're getting on that product and how many of them are satisfied with direct maybe customer feedback and so on.

(20:42):
So that's one way of determining success. If you are targeting, I would say B2B and Star still in the early stage if you are in a different stage. Another example I worked on at Wikimedia Dotson is the wiki based project. There was a problem solution fit there is like wiki based software was built to solve a specific problem and it was relatively good solution compared to all the other available solutions out there with its collaboration feature or built in collaboration kind of functionality. And we knew that it was a good fit and a good solution for that problem because we had enough validation from interested institutions who wanted to use the software because they found it very, very useful and solves problems for them. And they did install it and they started kind of using it, but it was very, very high cost on their end because that product was never or that software, I would say in this case it wasn't a product yet, it was never put in any business model, in any functioning business model to be offered to a market or to a segment.

(21:47):
So the challenge there was like how do we find product market fit in terms of offering, how is it going to be offered when using what business model we're using, what pricing and figuring that out and success there is going to be slightly different. We wanna define, we do we need to understand those interested users in this potential product what does it solve for them in terms of costs especially so that we can determine the right pricing or at least the right initial pricing and then we can offer something and see if they basically purchase this for that price and how is it going to work for them in terms of maintainability or maintenance costs and so on. Are we going to offer it as so as a software as a service and success there? Yeah, would be I guess going again in this direction of how many users express their satisfaction with your product with their purchasing power, but also with their retention, do they stay with it? I mean the another part of success in general, after you have reached maturity, which I can get into with our current product vendor tax, once you have some maturity level of your product, then success is also slightly different and becomes more on the continuous delivery level and maybe features and conversion rates and so on. A lot more quantitative than qualitative in the other two examples.

Lina Zubyte (23:17):
So you've mentioned a lot about getting user feedback. How do companies gain user trust?

Alaa Sarhan (23:26):
I'm going to take Aax as an example here because it's a little bit of a product that is first kind of in the maturity level, although we are trying to discover new avenues for growth there but it's kind of in the maturity level for the last few years. And Winx as a product I think gained a lot of trust and confidence of its current customer base. And how does that happen? This happens when you do three things. Well, first of all, as we discussed before, you need to understand your target users priorities, expectations and their emotional experience while using your product. You need to understand those so that you fulfill them. You might not fulfill all of them all at once in the beginning, but you need to continuously keep delivering on them. So what do they mean? Inver tax context for example. It's a product that allows you to file taxes or tax returns in Germany to different target groups.

(24:29):
We have the English tool also for expats. What we have a little more tailored other tools for different tax situations as we call it. Our users priorities and expectations from such a solution are quite unique for this kind of problem. We did a research back then in 2017, our C P O back then did an extensive research to understand specifically that and using this priority for such a product is first of all they need to be confident while using that product, really confident about what they are doing because any moment of hesitation or confusion or not feeling confident about what data they are entering and is it in the correct place or not it creates a lot of friction and it causes lots of drops of users like, okay, I'm not confident here, I dunno what I'm doing anymore so I'm going to stop it.

(25:20):
The reason confidence came up at the first priority for is that it's a sensitive topic. You're talking about money, you're talking about your taxes, which usually people have already built in fear that they do something wrong there because there is always this myth that if you get in trouble with your tax office, it's going to be or could be a huge problem. So confidence was the first thing. The second thing was speed and the easiness, if it is going to be so much effort, it's going to take me two days to complete my tax return with this tool, then it's already huge investment with my time. Maybe it's not worth it. Maybe paying a tax advisor to do it for me is then cheaper for me and surprisingly the third one was how much estimated return we give them, which was very intuitive I would say.

(26:04):
If you ask someone what's your intuition about what would be the highest priority for users when you're using your tool like ProTax tool or any tax software many people would say, yeah, you should give them the right estimation of return because the more return, higher return you estimate for them and you actually make it happen the more likely they will use your product. And that's turned now not to be true. So discovering those priorities and of your users and emotional experience as I usually refer to it, you need to understand what emotions your users are going through when they're using this tool and what kind of fears they have and confu confusions that they might end up having that just make them either afraid or not very feeling very confident that I wanna commit to this is super important. And once you address those to in a decent level, again, you cannot necessarily fulfill all these at once from the beginning.

(27:04):
The idea is to get to a decent level where you get some users to use it and you see how they interact with it, how much they behave, how much they convert, and how do you do they behave. You need to do a lot of user testing, I would say in this cases to see for yourself how your users are actually interacting and where they are confused. But there's also the quantitative, in our case, we have big volume of traffic so we can do a lot of AB testing as well in this case, and you need to continue to deliver on this. I guess this is the second important thing you need to do to continue and maintain that trust you have built and confidence in your brand and your product especially for retention and returning users. If they come back next year and they see the little issues or the little friction they experienced last year for example, or last time they used the product, but in our case it's a yearly usage if they're still there.

(27:56):
This with time is going to build a feeling that, oh, we are not anymore improving our product and they slowly start also losing trust. And if another player comes into the market and doesn't have those sets of fraction and just offering almost the same value, then we are increasing the likelihood of a switch of a user because we are decreasing the stickiness I guess by not continuously boosting their confidence and trust into company as well and the team behind that's behind this product and that they, they care, they see those issues and they fix them continuously.

Lina Zubyte (28:35):
That sounds wonderful and I feel like it's a good segue for us to also head into teams because there's users, so they do have trust, but what about the teams having trust in what they're building and with each other, building herons teams, there was a part that you mentioned about testing and having a QA as a specific role that maybe it's a little bit questionable sometimes me as a qa I would agree because I feel like the way a lot of companies do QA is siloing, <affirmative> not really helpful for the teams and the understanding of QA becomes, oh, QA is basically equal testing. It's not just that. So testing is an activity and as Aristo says, right, quality is not an act, it's a habit, which you want to have these quality habits right in teams. So how do you make sure that you have those quality habits and the teams you work in and what are those quality habits for you in your idea? How do you make sure that developers do have a good understanding of testing in the teams as well and have this confidence net as well, right, as users that the team also have some kind of confidence about what they're building?

Alaa Sarhan (29:57):
That's a great question and you're definitely bringing us to one of my favorite topics in general. My belief is strong products are only built by strong teams and the team is actually the starting point. If you have a good team, what is a good team? That's something like very, very debatable and very big topic. But if you have a strong team that is really working well together, there are maybe three things that for me as signals that define a good team or a great team apart from the very easy one that is like, oh, they have the skillset set to build the product. Yeah, well of course this is the most obvious and it's not really a signal because without it, it's not going to work. But the signals of a strong team I would say there is what I call mindset proximity. It's important to have DI diversity and it doesn't contradict mindset proximity at all.

(30:50):
It's really important to have diversity in thought and experiences and backgrounds because it just feeds into the creativity and coming up with original solutions or maybe thinking out of the box. But at the same time there is some level of proximity that needs to exist there. Sometimes a very, very conflicting set set of mindset or ways of thinking about things would also not work if you have it in the team. So there should be some shared level of similar mindsets. So we all think, I don't know, <laugh>, the typical maybe buzzwordy kind of thing. Are we all thinking lean, agile kind of way, mindset, maybe that makes it maybe clear. I mean, so there should be that kind of level of mindset, proximity shared mindset about what matters and how we should interact and how do we build products together. But then the second signal, you need to see a very good shared sense and understanding of the goals and the mission of that team.

(31:57):
If the goals or the mission of that team is just different in each person's hat, each person has their interpretation, that's not going to work. You're not going to be aligned, you're not going to be high performing or even performing to begin with in an effective way. So much time will be wasted on a lot of overhead communication to fix those misalignment or misunderstandings of what exactly we are after here and what is our mission and how do we think about it. It's connected to the mindset, proximity of course a little bit, but this is more specific to what are we trying to achieve right now? This should be very well understood by everyone in a similar fashion. It can be differs so much between people or groups or teams if you have separate teams. And I think a third one usually which is a good signal of a good, great team is they care about each other on a personal level.

(32:49):
They support each other, they know each other because we are people, we're complex. So for me to be very, very performing with you in a team, I need sometimes on these micro level decision making or on daily basis, I need to understand, oh, maybe Lena today is not having a great day and I can sense that or I can see that so maybe I can support by covering up or being proactive about saying, you know what? I can also help you here. Or maybe let's pair together on this task because I feel like maybe you need that. So this helps a lot also in building a good strong team that can support each other and then you can even boost up performance that way. All of these are difficult to design and difficult to externally impose on a team that doesn't work. They need to build from within.

Lina Zubyte (33:43):
So you mentioned that we should build it from within the teams but what about the job of team leads or leadership in the company? What could they do to help

Alaa Sarhan (33:57):
Your job as, let's imagine if I would be hiring a team, my job is just to make sure that the selection process that we go through in building that team together makes sure that these people find each other and assess those kind of signals. Do they think alike to some degree, but are they also diverse enough to be creative and think out of the box and challenge each other? Do they all already have a shared understanding of what we are trying to do here? Do they bring something to the table in terms of challenging even the current assumptions of goals, but on some good ground, not just for the sake of challenging, but on a good ground of maybe deeper understanding where these initial goals came from. Now we wanted to go into quality part. So when you have a team that has a strong team that cares about what value they deliver and their product to their customers, then the quality is going to be part of what they do on daily basis.

(34:58):
As an engineer, when I'm writing code for a new feature, I'm going already to be putting the right amount of thinking through, okay, what kind of edge cases matter here? They need to cover and test. Well maybe cover with automated tests because I don't know if I will be able to test them all manually or I don't know if other people will be able to think of them or remember to think of them. So as an engineer you can see sometimes some of those edge cases, but at the same time you don't wanna waste time on every edge case you can think of. So you need to have some judgment on what edge cases matter, for example. And what is the critical path that you wanna also test well and cover for you as an engineer to do this well. You need to understand very well what context you're in and what product you're building.

(35:50):
You cannot be in isolation and here this is what sometimes goes wrong when we put a QA person as an isolated task on our isolated person who just does this. I mean, you're removing this responsibility completely from everyone else because you are saying, oh, there you go. There is the QA person who is responsible for making sure they translate the business requirement to quality constraints and what we should be testing. And they will also test it later. So they will tell us if something went wrong or not, we will not care, or we will not really worry too

Lina Zubyte (36:23):
Much about. Yeah, I guess it's so also common and makes people lazy. Then if you have someone else doing a task then you know get used to it, then it's really hard to switch from that. And as a QA, I often would be the bridge between different departments, right? But I guess the mission, I really like one of my past colleagues who was a QA used to say, our job is to make ourselves obsolete. So as a QA, I should come to a team and think, okay, how do I enable the developers to also reach for the context to also get involved with the product and then also to automate the testing and do manual testing as well. How do I enable them to do it? Which I think is such a different view of the QA at all. And to make yourself obsolete, who does it mentally even, that's a difficult one to grasp. But I do find that if our goal is this way, it's easy to understand that some teams would not have a QA because that's fairly temporarily role until the people are enabled. The sad part is not that many people are enabled unfortunately right now in the business, but we definitely can reach the state. So to wrap up this conversation and come full circle, what is the advice that you would give for people to building high quality products and teams?

Alaa Sarhan (37:57):
I would say engage with your product and with your business in any function you are in, need to understand the context you're working in. So this is more of a advice every individual in a team. Be proactive. Do you have the shared understanding like others about what your goals are and what your context is? It's the same thing to, I would say, team leads or maybe even managers. The most important thing is to enable everyone to be able to engage and be able to give their feedback, be able to give their opinion, share their opinion, be able to do what they think they should be doing to deliver a quality product. So creating that environment is also crucial and it's the responsibility of the leads or manager, depending how it's structured in that company to allow everyone to challenge and deliver quality product with all the intelligence they have, all the creativity they have, whether it's on an individual contribution or a group contributor contribution when they collaborate together and something. So the summary of all this is think about quality as being, it's a mindset as you said in the beginning, it's a habit, it's a mindset shared among the team. It's not an act, it's not a task done by one person delivering quality product on that function. It's not a function. It's the mindset shared in the team.

Lina Zubyte (39:18):
Thank you so much, ALA, it was lovely talking to you.

Alaa Sarhan (39:23):
It was pleasure talking to you too. Thank you so much.

Lina Zubyte (39:27):
That's it for today's episode. Thank you so much for listening. Check out the episode notes. As usual for the guest contact details, I'd love to hear your feedback as well. So leave your podcast three things or just send me a message on what you learned and what you liked or didn't. And until the next episode, keep on striving to build those high quality products and teams.


Head Shot

Lina Zubyte

Host