Do you think of money when you talk about quality? Is money vs. quality the same as speed vs. quality? How can we leverage the knowledge about money matters when talking about product quality?
This episode's guest Valentin Ranshakov, a QA expert at SAP Signavio, shares many interesting ideas about money and quality trade-offs, including when it does not make sense to concentrate on money.
Find Valentin on:
Mentions and resources:
If you liked this episode, you may as well enjoy this past episode of Quality Bits:
Perceived Quality & Trade-offs between Product and Engineering with Alaa Sarhan https://www.buzzsprout.com/2037134/11347563
Follow Quality Bits host Lina Zubyte on:
Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.
If you like this podcast and would like to support its making, feel free to buy me a coffee: https://www.buymeacoffee.com/linazubyte
Thank you for listening! ✨
Do you think of money when you talk about quality? Is money vs. quality the same as speed vs. quality? How can we leverage the knowledge about money matters when talking about product quality?
This episode's guest Valentin Ranshakov, a QA expert at SAP Signavio, shares many interesting ideas about money and quality trade-offs, including when it does not make sense to concentrate on money.
Find Valentin on:
Mentions and resources:
If you liked this episode, you may as well enjoy this past episode of Quality Bits:
Perceived Quality & Trade-offs between Product and Engineering with Alaa Sarhan https://www.buzzsprout.com/2037134/11347563
Follow Quality Bits host Lina Zubyte on:
Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.
If you like this podcast and would like to support its making, feel free to buy me a coffee: https://www.buymeacoffee.com/linazubyte
Thank you for listening! ✨
Lina Zubyte (00:05):
Hello, welcome to Quality Bits, a podcast about building high quality products and teams. I'm your host Lina Zubyte. Speed versus quality, money versus quality, money and speed: all these trade-offs are so interesting to discuss and know more about. So in today's episode I'm talking to Valentin Ranshakov about the money value of quality. Without further ado, enjoy this conversation.
(00:51):
Hello, welcome to Quality Bits.
Valentin Ranshakov (00:54):
Hello. I'm happy to be here with you.
Lina Zubyte (00:56):
Great. So could you shortly introduce yourself?
Valentin Ranshakov (01:00):
Yes, of course. My name is Valentin, I'm QA expert at SAP Signavio. I have joined company last month. Before that I have been working as a QA engineer, expert, staff engineer on multiple startups in Berlin and remotely. Before we start the session, I have a disclaimer: everything I share with you is my personal opinion. It's not company statement. And yeah, I have been living in Berlin for the last five years now and enjoying the city.
Lina Zubyte (01:26):
Yeah, we actually met because of a little QA community that we formed in Berlin and once we spoke about a very interesting topic, which is money and quality and how we should talk more about money. So in this episode we'll try to talk about that a little bit more. Let's start with a little bit of an umbrella question. What is quality to you?
Valentin Ranshakov (01:51):
I would say that in a nutshell, quality is a sense. It's a sense that everything is going right right now and it's going to be all right. We have a trust in quality, we trust in products or the system we're building. If we're talking about specifically software quality, I would say that we have to deliver pleasant experience to our customers, pleasant experience to our users in the first place. What it could be, it depends on domain.
Lina Zubyte (02:15):
It's a sense, I like that. And sort of it is a sense, right? If we think of anything in our lives, when do we say it's quality? It's when we feel it's quality with whatever features it has. There is this quote saying that "Quality is value to some person who matters", right? So what do you think value is in most of the cases?
Valentin Ranshakov (02:42):
I would say when we're talking about software development, for me I would bring quality under five adjectives. It's fast, available, accessible, fulfill customer expectations and secure. These five generic ones would cover most of the cases.
Lina Zubyte (02:57):
When we think about quality, there very often is a trade-off quality versus speed as if they should be traded off against each other. In "Accelerate" they say slow down in order to speed up and I really believe in it. I do not believe that better quality is somehow slower. Thinking about value though and speed, would you say that speed somehow refers to money? Because the more I was thinking about it, I'm like what do we mean with speed? It's just that we want to deliver likely more, which means in the end the monetary value.
Valentin Ranshakov (03:38):
I would say that we could distinguish two different conversations: quality and speed, and speed and money. Because I think that it's not connected directly but still could reach each other. I think let's first start with quality and speed. For me, I don't like estimation in terms of how quick you're going to deliver something in days, in weeks in sprints because I see that different teams could deliver software differently. Some engineers have better experience, some teams have better pipelines and they could deliver the same software faster because they could for example test it in a way. That's why every single time someone talked to me about tradeoffs, I'm asking why you're thinking about that. Why are you thinking about tradeoffs even when you have not started delivering something? Because even in your team, inside your team, one engineer could deliver software in two days.
(04:33):
Let's assume. Another engineer could deliver it in a week but will it be better software quality or not? We don't know and that's why I think that to think about trade offs not always translates for better quality. It's always safe to say I need more time because it's hugely in average works this way. But when you're going to plan something to deliver and you have your product owner or someone who actually needs this software right now it's very complex. Of course what's the resolution, right? What else we can do? We could estimate in complexity. Complexity is more stable quantity. For example, we could in our software, fix a minor issue on a screen, some not pixel perfect element. Sometimes we have to deliver new API endpoint and I assume that delivering new endpoint would be way more complex rather than fixing a minor cosmetic issue, for example.
(05:31):
So that's why I think that in our case as QA engineers or some developers would have to establish system that can educate engineers, help them to deliver high quality software. For example, trying to write tests before you write code or adopt best practices because as soon as you adopt best practices, next time you will deliver it faster. So we invest more time in people and in technology I assume that if you have a pipeline, any type of pipeline, Jenkins, GitHub actions, it will be beneficial for a team to deliver faster because they have something that builds automatically in parallel. Specifically on testing examples, if you have 500 tests and you cannot parallelize it, you definitely will deliver software way slower. Additionally to that, if we're talking about speed, we shouldn't forget about team size. As soon as you grow a team they will deliver software slower and that's a fact because more people bring more communication and most of the time what you're doing in working as a team, you're trying to decide what to build and how to build. The rest is simple. Delivery right now with the modern tools and systems is way simpler than it was 10 years ago. Now we still cannot figure out how effectively communicate what and how we're going to build and it splits between right product managers, product owners and engineers. That's why speed is kind of ambiguous system and often we'll try to play safe and tells that we need more time, but usually we need more education or models. What's your take on this point?
Lina Zubyte (07:15):
It's interesting that you also say that more people will make the process slower because I feel like there's a different kind of perception often, but it makes sense, right? The less communication you have, the faster that you're just going to do things. And we can remember the stories of some, I dunno, startup teams that first there were three people and they would fix bugs at night and now it's a growing organization and it's scaled much and maybe we would expect to deliver more usually with that, but it's not always the case, which is really interesting. So I really appreciated this point actually because often it's the opposite. They think that people in general tend to say that more testing will make process slower. It's not just testing. It's so much more, right? So as you say, there's communication, there's deciding what you want to do, how you want to do it. The more people there is, the process becomes more complex. So for me, speed versus quality, I believe that once we have certain practices and habits as you said as well, then we are moving much faster and those practices also help us prevent a lot of issues as well, which is interesting yet this thing, the speed and money conversation that's interesting. What did you mean about that? That it's speed versus money.
Valentin Ranshakov (08:43):
This conversation will be connected only to my startup experience because I think that specifically on startups high-pace environment, it's very important. If you would talk to product managers or business development people you'll recognize that every single feature you build actually brings money on top. We as engineers usually have a curtain, we don't understand what's happening on the business side. As soon as you start to listen to people who is actually bringing our work to the market, who is negotiating deals specifically on B2B sector, every single feature costs money not for building but also earning money for us and every single time engineers develop something, they're building actually a real estate and the new real estates bring more customers, bring more money and obviously more features you have specifically on the start more customers you could attract because if you have one basic feature, you have small audience, right? As soon as you add more features, for example from another customer they requested, they will sign a contract for a future for example, it happens all the time on B2B sector that you promise something to deliver, people commit to a contract because you promise them and transfer money for it sometimes in advance, sometimes as soon as contract starts.
(10:03):
Sometimes when you start delivering features but it's still always as much you deliver, the more money you can bring because you make your audience bigger or you upsell your customers. It's always the case when you're talking to support engineers and they have from time to time KPIs that they have to upsell people, upsell customers. How it happens usually: you have a set of features, you are selling it for 10, let's assume 10 dollars. As soon as you have twice more features, you're offering these features to existing customers and unlock features on the go and bringing more features faster helps customer success engineers upsell faster in a more efficient way. That's why delivering more features usually lets us to make wider audience or upsell current customers. On the same time, as soon as you have so many features and absorb the wall market, it stops and adding more features, adds more complexity on development and brings more defects, brings more complexity, brings more incidents on top.
(11:06):
So sometimes you have to deprecate existing features too and also you could understand deprecation of features leads us also to complexity and it's also work. You have to understand how to feature flag for example or how to make sure that it's not breaking any other feature or you don't have dependency between it. So that's why I think that money is a good topic, not only talking about speed on how quick we deliver things or how often, but also how quality affects money. Because money is a topic everybody can commit to, everybody could understand it easily on any levels. Engineers, developers, QAs, business development, product owners, designers, they don't need to have quality assurance background to participate. That's why this topic could be unlocked on quality perspective, too, and when I'm talking about that I'm talking more about how we can directly affect it and I see it from two perspective in my mind. First perspective is from churn: how many customers cancel their plans because they found our software with all the bugs. Usually if you're trying to cancel a subscription or trying to cancel a contract, they ask you what's the reason behind and then you have an option.
(12:20):
One of the latest one it would be you have too many defects or our software is too slow, you another software that don't have such defects or works faster, it is one way that's directly gives you an idea that this customer don't want to pay us again because they see our software not high quality. And the second one is about new customers. When you deliver features that affected audience or market value, it brings more customers that could use our features. So that's why I see that we could directly see how much money we lost about quality, but it's only only direct value. We shouldn't forget that QA engineers also present on a delivery pipeline. They're also participating on introducing new features and deprecating old ones. So it's only a portion but it's direct what you can see, what you can feel.
Lina Zubyte (13:17):
I think it also depends on the product because in some cases there may not be any subscription but this is a very good example that what is driving money. Often I would also use money as some kind of argument on why we should do a certain initiative, especially performance. I feel like performance is a topic that we could measure. Even if you open Lighthouse tools right now in dev tools and you run some kind of analysis, usually they have little facts and they said that Walmart increased their revenue by 1% just like making their requests a little bit faster.
Valentin Ranshakov (13:58):
Exactly.
Lina Zubyte (13:59):
However, we don't talk about this as much. So very often QAs get somehow siloed, developers develop a feature and we're not as thinking or relating to how the work we're doing connects to money we're bringing to the company. Some companies have done that so I've heard of some north stars which could say okay, this feature increased for example our important metric by this which means that we increase our revenue like that, which is very nice, it's very celebratory so we can celebrate as a company the work we did, but how can we even encourage it a little bit more? Can people being just members of the team somehow make an impact here and change this mindset?
Valentin Ranshakov (14:47):
I would say that we have to play by example first and bring people together more. So don't build walls between departments that's developing features and selling it from the start. And secondly, I would say the feedback loop we got from the customers also should be provided to engineers in a way. Usually in my case it comes always from customer support. They usually have a round table, biweekly or weekly with engineering present representative and share with us outcomes: who signed, who broke the deal, what opportunities they see right now on the table, what defects could affect more for example and bring topic about priority. Of course we cannot convert every single second of how work the money - it's useless because usually what you would like to see, you like to see a plan, a trajectory on how we can build. And I would like to present an example about airport and walking distance.
(15:47):
Do you know the example about that? That it's better to build an airport for a couple of years and then fly to another country rather than walk this path because you are building airport, it's investment and you have to spend money and time and you cannot even predict how you're going to build it because usually it's delayed all of the time and afterwards you can fly often very fast but if you walk the same distance it's very predictable. You know the road, you have your milestones but as soon as you deliver that there is no other options than it's end of the goal basically, right? It's end of the road even if it was planned and you deliver every single day, but on the same time you cannot repeat the same thing again and be as efficient as planes. This example give us more perspective on tech debt investment for example, we have to negotiate this idea that we have to bring more maintainable software on the table. That later on will pay off and everybody has to understand it in a way not from development side only but also from business side. So bring people together, explain what challenges we see ahead of us exchange our expertise and experience is very positive and brings a lot to the table.
Lina Zubyte (17:08):
Scalable and maintainable is actually and repeatable is what I learned from the story. So you could walk all the many kilometers that are involved there but you couldn't do it multiple times. So same way with any development practices. If we have some that we can repeat and be more efficient there instead of doing it for a very long time, maybe we should automate it as we say, usually I really like the collaboration with support that you mentioned it. I feel like in most of companies I worked in, it was there or I was the support as well when there was a startup. And I would need to check what people wrote in, I found it extremely valuable. It also gave me such a perspective that I didn't have before because sometimes we may think oh we need everything perfect or we cannot release it. Getting a perspective from customers you start to realize what actually matters for them and that our understanding of, I dunno, this one pixel off or something like that, it's not that important. It can be very humbling sometimes because you think you know better and you represent the customer but you don't at all. And this link, the support I think is really essential. How would you recommend to use this understanding of maybe metrics like money increase or understanding the churn and new customers and so on in the daily work? How could we have better conversations especially as QA or developers when we have those metrics and understand them?
Valentin Ranshakov (18:50):
I would say if we're talking specifically about money, it's very sensitive topic. Not every single company would like to expose earnings or expose current number of customers or expose even who customers are. And it's very difficult to set up a channel for this information. So we need to find a way what works for a specific company as a channel could be round table with customer support, could be all hands when we have separate section about our customer satisfaction. Everything is beneficial but also we shouldn't forget about feedback channel. How our engineers reflect on it and encourage people to bring questions on the table, encourage them to be present and on meetings because usually right now specifically on remote environment. To be honest, not everyone pays attention and it's very important to catch an eye, get involved and have a look back to see how people actually adopt the idea or adopt this information and how they utilize it at work.
(19:51):
I would say that it's a learning curve for sure. If you do it once, do it twice, it'll not work. It has to be a routine in a way, a healthy routine that helps engineers to understand more, helps developers helps QAs or other parties to understand more bit more about business because specifically in the startup it's very important to build a strong team, a strong sense of the team that we're working together to achieve something. So that's why I think that it's a question for founders mainly I would say to see what kind of channel is appropriate to utilize and next bring people together who could be involved in the channel. And in my case, in my previous experience, it was not a problem for us to speak about our targets. Are we hitting our targets specifically for this quarter or not? And it was mainly top down because engineers were not involved in a sale or in supporting customers directly.
(20:45):
So we always get information, specifically in my, I would say last three positions, we always got information about current status, what's happening right now. And it was not always the good news, sometimes it was bad news but it brings people up to speed to understand what's happening right now. I think it's very beneficial to have transparent channel, but how to start this channel I think has to be aligned with company mission and company values. How open you're happy to be, how open you would like to share with your employees or even with outside the world. I know that some companies practice open dashboard when you can open and see how much actually they earn on their subscriptions or on a customer level it's very transparent and very encouraging to see that your supporting for example business that happy to talk about numbers but not every single company.
(21:36):
Sometimes it's very confidential and obviously which would like to keep data about customers safe, right, safe and secure. Nobody has to get access to it and when I'm talking about B2B world, sometimes even deals you have the same customers, the same volume but they pay a different price because you build relationship, right? Because you value relationship and you would like to keep it quiet. If you have a customer who joined you in the early stage and were happy to use your baggy code, your software just to get something out of it. You treat differently rather than after Series C, you get the same volume of customers and treat different way because now they late up options. So all these tradeoffs you have to understand what's your business is about and I would say that it's founder's job but of course engineers if you are able or would love to talk about it, bring it to the table, ask about how transparent are we, how comfortable our company to share internal or external our data in a way: number of customers, percentage of churn, revenue, who knows? I think it's always very healthy conversation when you are talking about data, about data points about money in a way and build this trustworthy relationship because I think it's even if you don't want to share anything, it's already starting conversation building a relationship around the company.
Lina Zubyte (23:04):
Yeah, when I think about this topic, money. Money can sound very dirty term somehow for me like very naked term in a sense. You say, oh what's money here? But there's so many data elements as you say that are connected to this. It depends on the company. What is connected with your company, what are the metrics that you're looking at? Maybe the starting point could be just asking what is success for us? What are we aiming to achieve? What metrics should be follow? I really like using data to make any kind of decision. So maybe we could start just saying, hey, we would like to increase our registered user's count, right? This is not exactly this as giving exact money amount. I would ask this question actually of anyone who was creating the initiative or feature. It could be a product person very often. I've seen companies where they include this so they would say what is the expectation of this initiative or feature, right?
(24:07):
So we're hoping that we will increase this and this and this by that, that will result likely in revenue because this naked pure money metrics as well could be very cold somehow offputting because you may not understand the link between your work and that the revenue overall for example, it's not very clear to see, okay, what did I do there to increase that? So we could also start with small steps and maybe even if your company is not doing it, a first step could be just to ask what are we measuring here? How will we know that this was successful? Another part is like how will we know if it fails? That's a nice question but that's more about testing.
Valentin Ranshakov (24:45):
I have to add additionally that earning more money on a commerce business, not always the right because for example for e-commerce you can extract huge revenue in short period of time but lose everyone. It could be a case. That's why you have to think about balance between success metric. Do you want to get people engaged more with your product so they could stay more and lifetime value could be more? Or you would like to accidentally for example increase your revenue for the next months because you need to cashflow. It's always a trade off. It's always to see where the balance is and I saw a lot of examples from my previous experience that we had a heated conversation about how are we going to release this feature because we need more money or we would like to get more engaged people and sometimes we were ending up to understand that right now it's not the right time to release this feature because we get 2% more revenue but experience of our software could be worse and it's not paying off in the future.
(25:49):
We are here not building one day companies, right? Hopefully. We're building here for future or for sustainable future at least and we would like to see our product we build last long. And revenue is sufficient to get lights at home but on the same time you need to find a balance where it is, how much you want to push it forward, how much you would like to see revenue right now. It's similar for, I would say, people development, too, because if, a career development, are you happy to jump on a hype train, earn a little bit more money right now or you would like to build long relationship with the company and grow eventually if you want to grow. So it's always a trade off. It's like an essential of life, I think.
Lina Zubyte (26:38):
I really like how you added the dimension on both speed and money. Speed that we could build very fast but not what we want. Same way we could earn more money but also likely in the long term it's not the vision we're going towards and this makes us somehow also think that it's not as simple as, well it's not just going fast, it's also having a direction. It's the money the same. Sometimes you may say no to certain initiatives. I've heard of an example about retail selling website that you could for example just push the ones that are really highly priced then your revenue will go up, but is your product actually the way it was designed to be? Is it the same ethical product if you have no affordable housing just because you're pushing for the revenue? So it's quite a nice example. Have you had any examples in your career where you learned a money lesson that you didn't think about it but then once it was released you're like, oh yeah, we should have spoken about it.
Valentin Ranshakov (27:45):
I think that it came when I just started my career on a customer B2C company when management were happy to share numbers with us. When they actually put a slide on a weekly basis about lifetime value when they learn it from first time and explain us why we have to allow people to use our software longer and I'm talking about subscription service, talking about entertainment service and in our case we need people spend more time in the app to build a habit so they could build a habit more and it lasts long. Of course acquisition of the customers costs six months of revenue. The customers, in our case it was and we have to make sure that our stays at least six months with us so we could earn on the seventh month. Additionally to that, unfortunately we haven't brought on the table cost of development because it was an investment startup and we could burn money on development but we have to be very precise on marketing and on lifetime of our customers. And it puts me on the position, I was a QA engineer on the company, that I have to think not only about how people for example create an account but also don't forget about restoring passwords because if you could not restore your password, you could not use your account right now or what happens, usually you're trying to restore your password and website fails to send your email or send you a pin code and you forget about it.
(29:23):
You'll remember about it next time you pay the money again and it's not a pleasant experience to understand the moment that someone charge you monthly basis and you haven't used the app, what you're going to do, you'll write to customer success and cancel your subscription and it happens all the time. It's not something unusual. I sometimes forget my passwords too, even if I use password manager sometimes I'm messed up with my password manager and I couldn't log in next time I'll remember about my subscription when someone charging because I pushing my attention on my bank account, I know how much money I have on my bank account usually and who charged me today. That's why I think that I learned for the first time about this connection between quality and lifetime value and money from customer entertainment subscription service and it was very beneficial for me to see this depth and think not only about features that helps us onboard customers, demo accounts, first couple of, I dunno weeks they're using us but also how to keep them with us.
(30:31):
What else we can bring on the table to make sure that they're not bored with us? What other features we could implement to all the people inside, for example, so they could see connection not only with us but also with other people. That's what actually happened with us. We introduced some features that all customers interact with each other and I think that's also bringing the perspective how important it's for us. But so it's important not only beginning on the journey but after you got acquired in terms of customers, when you have got acquired, when you used a little bit and what happens next is the question, how good you're, how high quality software you build so people will like to stay and don't compare you with any other applications. It's also beneficial to see this kind of depth. I think that when we're building features, we're always thinking about happy path in the first place.
(31:23):
We remember about negative case test cases, but what happened if customer would like to use our application twice or three times or if they're using our application for five years. I'm still actually using this application for last eight years. I see the difference that if you would like to add more content behind your account, it's getting heavier and I see that performance is not so good because we haven't tested and of course I'll not cancel my subscription because I got so high value inside my account, but still experience is not the same. And I feel the difference if you log in for the first time and create new account, everything is fast, all works. But in a year, in two years, in three years, what is going to happen with your account? I'm not sure they have tested.
Lina Zubyte (32:12):
Your example about passwords and not being able to reset or say I forgot my password on one hand could drive the revenue up. But that is very in a sense unethical and this is where I could see we could speak up as well as anyone in the team if we are aware of it and say, Hey actually this in the short term is going to raise this, but in the long term it's going to drop it and it's a very nice dimension again to add to the conversations we're having. I remember one example where there was a website where you couldn't really cancel your subscription easily and on one hand there was a product person that said maybe it's fine, they shouldn't cancel and it's money. But for me it was such a bad taste in my mouth I was like this is not going well. You're going to continue with this kind of mindset and to just trap users to pay you.
Valentin Ranshakov (33:09):
I would say that people who are even in Germany could relate: how difficult cancel something if you have a subscription for a year. For listeners outside of Germany, you have to be very precise and write a letter, sometimes even physical letter in right time, usually it's like three months before you cancel your contract because they have a date after which they will extend your contract for another 12 months and you have to pay because it's contract. In your example when it's ethical or unethical to block people or prevent people from canceling, I have an example with my experience right now I'm subscribed to two patient services with a subscription model when you pay monthly and use your credits, but they charge you monthly and you kind of in the club and when you try to cancel a subscription, they have four or even six screens to prevent you, have you seen our new sale?
(34:08):
Are you sure you would like to do it today? We can extend your lifetime, I dunno, for a couple of weeks. As soon as you pass everything they'll have a cancel button, but you have to read carefully which button you click because one button is always let's continue, another button I'm going to cancel. It's standard practice. On the other hand, I'm happy to see that they're putting effort to be transparent about it because usually on the first day of the month they will send you a message, Hey, we're happy with us just to make sure that's clear and transparent. We'll charge you in five days being transparency a little bit and I appreciate it. But of course it's always a trick that you'll delete this email and forget about it, but at least they make it transparent that we're going to charge you. If you don't want to use us, please go to a website and click six buttons and we'll not charge. Have you had such experience?
Lina Zubyte (35:05):
Yeah, and I actually abuse it so I'm not the best sample of data there because I was using this one subscription service. I first had a free trial month because a friend gave a link to me. That's another thing. And then I had the reminder so I have a reminder for myself to cancel trials. I went to cancel it and while I was canceling they said, would you like a second month free? And I say, yes please. Then again, I have a reminder again I go to cancel and then they're, are you sure we will give you instead of 12 euros, you will pay eight for a year. I was like, huh, okay. And I took it. Yeah, they got me eventually, but usually I don't pay off as a customer I think because I do track it down, right? I'm like where do I pay what I pay? And so on.
Valentin Ranshakov (35:57):
On the other hand, I think that there is always software or application that are not about money. We always should not forget that money shouldn't be our main priority all the time. Of course we're working or living in capitalist world and we'll have to bring value, earn money to get beautiful life to experience something. But on the other hand, you shouldn't put all the effort you have to a money topic because sometimes you could burn out just racing this race.
Lina Zubyte (36:28):
And as you say, right, you could go to different directions. We could choose something that raises the money bar, but actually it doesn't raise the overall quality. And here I think there's this quote, testers don't win popularity contests. I feel that we could actually challenge that. So if we have conversations about value, about the fact that not only we will gain new customers and they will bring us revenue, but also we may lose existing ones, which will make the revenue go down where we can somehow say with data, this is an important part, with data from customer support, customer success, gathering feedback and somehow advocating for quality. QA could become a very powerful member and talk to as well sometimes speak some sense to finance people who may just drive initiatives just because it's pure money without realizing the side effects that they may have on all other features, all overall quality of the product. And that's not only QA of course it's the whole development team, but I think as QAs - question askers, we can very often challenge it as well.
Valentin Ranshakov (37:42):
I think that it is essential for quality assurance engineers to be someone who bring risk assessment to the table and also don't focus only on delivering but also thinking about different perspective, how it affects product development code, et cetera. And it's very important to not forget that we're here not as monkey testers, we're here to actually bring some value for our team, for our company. And it could be, in my case, I think that we have to run risk assessment tool and share our outcomes and train of course about that, train the skill and share outcomes with the team.
Lina Zubyte (38:22):
Really like the risk assessment, bringing it to the table, how would you bring it to the table if for example, you're reporting a bug, what would you add?
Valentin Ranshakov (38:33):
I think that reporting a bug, it's a conversation about your team first and majority of your team and channel you're using that you're reporting with. Usually it's reporting, bug reporting system, right? It could be different one, but they have multiple fields behind. I think from my perspective, we have to make sure that reporting bug is clear for our team to fix it. It's end of the goal. If your team is happy with one sentence and they understand what is happening, go for it. Write one sentence, forget about it, it'll be fixed. If you working on remote environment, when you cannot go to a person and show what's happening when you're inside your screen, please record the video because it's very convenient for people who's going to fix that. For engineers who are going to fix that to see it on a screen, what's actually happening would love to see also when you touch something, if you're talking about mobile applications. Specifically for me, I would like to add data that helps engineers assess defect, not when it was created but repeatedly.
(39:41):
For example, if one user has a defect and you reported that: developers usually cannot reproduce it or sometimes, and the reason why, because our software evolved, it changed. User could have slow internet connection or something like that. Some variables that adds depths on the artifacts and additionally that time pass, as I mentioned, software evolves and it would not be reproducible anymore. That's why for me, every single time I create a defect, I would like to have logs not as entry, but a filter to see how often it happens when it happens. So every time, or even if you'll open the same defect one year later, you can click link and see the filter for loss with specifically highlighted entries. That bug still is happening and you have to invest what is happening. Of course, ideal world, I would like to make sure that we close defects automatically if it's not happening anymore, but it's like next level.
(40:49):
You have to build communication between your log system, your reporting system, with how you notify people who created defects and customers. That defect is not here anymore or you have to spend a little bit more time. But in my case, ideal scenario, to have a log that always populates and up to date all the time, that's it basically. I think that the rest is the decoration. For example, you always would like to add priority to a defect, so you keep your team focused, but it's not an essential to get fixed the issue. You can fix issues without priority and it always happens right when incident comes, you don't have time to set a priority, you just fix it.
Lina Zubyte (41:29):
I recently wrote an article about how to get your bug fixed because sometimes I would see people really saying, oh, I report so many bugs and they never get fixed. And I'm like, look at your bug reports because sure, for some teams one-liner is enough and they will just fix it. But for other teams you need to talk about risk, you need to quantify it. So as you said, if you have a log message and you know that in also maybe another dimension to add would be in a crucial scenario, this bug reappears and it happens all the time for every user, for a hundred percent of users, that's extreme impact. That adds the priority, that improves your conversation, how you're talking to stakeholders about what bugs should be fixed because you're like, actually this is affecting everyone and that is of a crucial functionality. So adding impact and quantifying bugs I think was life changer for me because then I stopped being the person that people avoid and developers say, oh no, here she is.
(42:36):
She'll point out something. And I became a person where people are curious to learn more. I had meetings with CEO where we take a look at the dashboards and we take a look at what's going on and we talk risk, we talk customers, we talk quality. So this is about using some kind of data and helping out people to prioritize it, but in other cases you may not necessarily need it, right? So it's not always the case, but that can help a lot. I think in overall this conversation, we had to drive better conversations if we understand what is important for the company, right? And it could be money related, but it has lots of dimensions where we also can speak up and give our opinion. So to wrap up this conversation, what is the one piece of advice you would give for building high quality products and teams?
Valentin Ranshakov (43:33):
I think that I truly believe to a common language when we speak about quality. If everyone in the team understand quality the same way, it's way more easier to build high quality software.
Lina Zubyte (43:46):
Nice. Thank you so much.
Valentin Ranshakov (43:48):
Thank you so much for this conversation. It was pleasant to talk to you.
Lina Zubyte (43:52):
That's it for today's episode. I really wanted to sneak in a little song for you, money, money, money. If you're here and you heard that, wow, let me know what you thought. Not of my singing of the episode, but you can also tell me what you thought of my singing. I really appreciate feedback and until the next time, do not forget to continue caring about and building those high quality products and teams. See you next time.