The Myth of 'Best Practice'

The full transcript

Kavya (Director of Product Marketing, LambdaTest) - Hi, everyone. Welcome to another exciting session of the LambdaTest XP Series. Through XP Series, we dive into a world of insights and innovation featuring renowned industry experts and business leaders in the testing and QA ecosystem. I'm your host, Kavya, Director of Product Marketing at LambdaTest, and it's a pleasure to have you with us today.

In today's webinar, we will unravel the myth of best practices in software development, exploring why a one-size-fits-all approach may not be as effective as commonly believed. To shed light on today's discussion, let me introduce you to our guest on the show, Richard O'Brien, Head of Product at BugHerd and Director at ReleaseNotes.

With over 20 years of experience in software development, Richard brings a wealth of knowledge and insights into the discussion on debunking the myth of best practices in our industry. His diverse background spanning engineering, design, UX consulting, and product management offers a unique perspective on today's topic.

In today's show, we'll explore common misconceptions surrounding best practices, the importance of embracing continuous learning, and the significance of adaptability and evolution in today's dynamic landscape.

Richard will also share his experiences and expertise, shedding light on why being open to learning and improvement is the ultimate best practice that matters in software development.

I'll now hand over the mic to Richard so that he can share a bit more about his journey, and then we'll delve into today's topic. So Richard, over to you, please.

Richard O'Brien (Head of Product, BugHerd) - Thanks, Kavya. Yeah, so I started out my career as a software engineer. I graduated in the early 2000s from Swinburne University here in Melbourne. And I joke that I spent the rest of my career trying to work out what I like doing.

So I have done software engineering and project management, front-end development, UX design, UX research, and now product manager here at BugHerd and ReleaseNotes.

BugHerd, just to give a bit of background on what we do, so we're a tool for agencies, QAs, and product teams to gather feedback from particularly non-technical users through our point-and-click feedback experience.

So you can pin feedback directly onto the product that you're working on or the website that you're working on and manage that feedback through to completion. So we've been around or BugHerd has been around since about 2012 and really sort of was the first in the space.

And so we're really excited by the challenge of making feedback effortless, getting the QA process and the client feedback process out of spreadsheets, and making it much simpler for everyone involved. So, that's sort of why we're here and why we do what we do.

But, yeah, I mean, in those 20 years, there's, I think why I like talking about this topic is because there's been such a lot of stuff that I've done over that time to realize that there's not always a best practice, but I think we’ll come back to that later. But anyway, that's it. That's a bit about me.

Kavya (Director of Product Marketing, LambdaTest) - Thank you so much, Richard. That's a very interesting career journey spanning, of course, decades. Now, let's jump into the first question of the day. What is the most common best practice myth you have encountered in your career? And how did you realize it was not a one-size-fits-all solution?

Richard O'Brien (Head of Product, BugHerd) - Yeah, I think, so I guess in the caveat, you know, best practice in this context, what I'm talking about is in what we do knowledge work, right? So, there are obviously best practices in other areas. Like, you know, I want there to be a best practice for how you fly a plane or like treat a particular medical ailment or things like that.

But I'm talking specifically about knowledge work. And I really don't think, uh, you know, sort of racking my brains, like what's the most common best practice myth? I don't think that is one. It's just the whole thing with best practice to me is that it's so contextual, right?

And I think how I came to think that really is just, I think, organically over the course of my career as I've moved from, you know, graduating straight out of university to working across different organizations and trying to start companies, doing the startup game, advising a VC, working in.

I think user research is a great way to realize that no matter how much you prepare, no matter how much you think you know, you're always gonna find something new that is sort of counter to what you think is.

Oh yeah, you know, we designed that UI and used all the best practice approaches, but you know, 7 out of 10 couldn't use it. So is it really a best practice what we did there? So, I think it's over the course of my career. I've just sort of developed that, uh, I guess a viewpoint, um, on, you know, what we're doing, uh, isn't, you know, there's never a cookie-cutter approach.

There are always ways that you can get influence and, so that, you know, change how you do things, but it isn't ever like a silver bullet.

Kavya (Director of Product Marketing, LambdaTest) - Awesome. Thank you so much, Richard, for sharing that viewpoint. What stood out for me is how adaptability is key when it comes to software development in that case. Depending upon the use case or the problem statement at hand, the best practice keeps on evolving. Is that what I think is the gist, at least what I took away from what you shared?

Richard O'Brien (Head of Product, BugHerd) - Yeah, absolutely.

Kavya (Director of Product Marketing, LambdaTest) - Awesome. Moving on to the next question. How do you balance the search for efficient methodologies with the understanding that no universal risk practice exists?

Richard O'Brien (Head of Product, BugHerd) - Yeah, I think it comes down to judgment, and like, I've heard it referred to as like training your gut, training your instincts. It's something we focus on from a customer point of view here at BugHerd.

You know, when we're doing our work, we want the whole team to have that influence from the customer, that understanding of what their problems are, and the problem space so that we can build the best possible solution. Anyone in the business can do that.

I think, you know, training that instinct or that gut feeling only comes from iteration. It only comes from having lots of conversations with the customers or, you know, if you don't, if you're not in a customer-facing job, it's, you know, looking at what you did and comparing it to, you know, what you set out to do, you know, did when you first started the project, what was your goal? Why were you doing it? What did you expect the results to be?

And then looking back at that, um, I think as knowledge workers, you know, the reason we get paid well in the, in the jobs that we do, um, is to create upside for our companies, right? And you only do that by, um, you know, pushing the standard, trying to do something in a better way.

I like Shreya Doshi, who was the first product manager at Stripe, who had a good I'll butcher this quote, but it was about playbooks, right? Everyone could just follow a playbook and it, you know, there's lots of great playbooks out there, but you know, if eventually the playbook becomes the standard, right? And everybody is following it.

So, how are you different? How do you create upside and outperform your competition, uh, if you're just following the standard? And I think that sort of hits on that best practices we tend to use as like a safety blanket for what we do, you know, we avoid putting ourselves out there at the risk of being wrong and trying something new. Uh, we fall back to our best practice.

So therefore, you know, I, it's, it's, it's safer. You know what I mean but you end up with like those mediocre results, mediocre returns. If it's a project process, you end up with mediocre efficiency in how you get work done, you know, it's about looking for, to answer your question and search for efficient methodologies is about always being open to new things, something different and looking back at how you did, didn’t work and don't just take the sort of best practices gospel.

Kavya (Director of Product Marketing, LambdaTest) - Interesting, thank you so much for sharing that. And that also makes me wonder, you know, as Head of Product - Is there any product playbook that you came across in the industry that you sort of looked at and feel that it had to be broken down and rebuilt and, of course, ended up implementing it in your career?

Richard O'Brien (Head of Product, BugHerd) - Oh, not broken down. Definitely, there are heaps of playbooks that I have been influenced by. Absolutely. And I take that as sort of inputs to how, like, it's not to say other people aren't doing it in great ways, and you have to learn anything, everything from the bottom up.

It's about taking what other people have learned and evolving that. There's a great podcast called the Knowledge Project that is just lots of different people who have different backgrounds and it's all about improvement, all about being better and different ways of approaching life.

And I think that's that, you know, in terms of influences in product management or in just my career in general, you know, intercoms have always been a source of inspiration in how they work. The 37signals Basecamp guys and what they do is absolutely, I mean, it's a direct influence because we are using ShapeUp or a form of ShapeUp.

Like I wouldn't say we're doing their version of ShapeUp, but I mean, that's the whole point, doing a bit that works for us. So the ShapeUp work that they've done is definitely an influence on how we work too. So it's taken the pieces of things that we see that are interesting and can think, oh yeah, that's adaptable to us. I mean, ShapeUp stood out to us because we have a similar type of product, and similar type of team, and a similar way of working.

So it sort of fitted quite well. But even with that, you know, it's implementing that process has taken time and, you know, getting people on board and all that sort of thing. It's not a, uh, it's not, it's never easy to implement change in that respect. Yeah.

Kavya (Director of Product Marketing, LambdaTest) - Great answer, thank you so much, Richard. And then definitely check out the platforms that you just mentioned. Would also suggest our users do the same. Moving on to the next question, what role does team dynamics play in determining the effectiveness of a practice?

Richard O'Brien (Head of Product, BugHerd) - Oh yeah, that, like, it's everything. It's everything. It always comes down to people, right? It's whether it's your team or whether it's your board, or whether it's your customers. Like being able to get anything done, whether it's implementing a process or developing a solution or whatever, it's always a team game, right?

So, it can't be top-down. I think the benefit we have at BugHerd is we've always been like a startup DNA to the company. So the founder and all the management and everyone who's really ever worked for the business are really come at problems from a lean way of thinking, you know, test and learn, don't over-invest in the solution without getting it out and seeing what customers think about it.

So over that sort of 12 years of doing that, I think that's always just been a core of our culture. But as I mentioned, shape up, even in that context, you know, still took us six to 12 months to get that implemented and running, right? Because it was about, you know, talking to the team, taking them through what it's about, why we're doing it, what the problem we think it is that it solves, and then finding our own way of doing it.

So, you know, starting off with one project and seeing how that worked. Did we deliver on what we were trying to do? Is it working for us? And, you know, it's got its own challenges, but, you know, our team, I think, is very engaged. We've got a great culture, and I think that makes it a little bit easier.

Yeah, I think on a, you know, on a like that shape up is really a process thing for us, but on a, on a management level, another thing that we've done recently has moved from monthly one-on-ones to weekly one-on-ones. And that was a bit of a shift as well. Really needed the team to buy into that, to understand the reason why.

And that's been really effective from a management point of view, making it just a more regular conversation, uh, which, you know, again, best practice would say you do monthly one-on-ones, and there are performance reviews and blah, blah, blah.

But we find that actually, you can avoid a bunch of that by having consistent regular conversations on a week-to-week basis because you know, you know, your teammate more, you're more in tune with if they're having a bad week or a great week or what's happening in their lives, you know, there's much more relationship that you've built up there. So, that's been useful too.

Kavya (Director of Product Marketing, LambdaTest) - Great advice, thank you so much for sharing that. And on the same line, can you also share an instance where being culture significantly influenced the outcome of a project?

Richard O'Brien (Head of Product, BugHerd) - Oh, good question. I think team culture significantly affects the outcome, I think would be, I mean, there's a bunch of projects that we've done that would be that case, but the biggest one, I would say, was our most recent UI redesign. And, you know, we've done a pretty significant update to the product.

Obviously, you know, having been around for 12 years or so, any big overhaul is a big change. And, you know, with that, we have a great customer base who really support us and give us lots of feedback and things like that. And so as we've rolled out this, this, uh, your redesign, there's been some performance things that we, that customers have called out to us and stuff like that. Um, and I think our team, the structure of our team, the way we, the way we think about the product,

You know, some teams might've taken that as a real negative hit and we've got to roll back and blah, blah, blah, blah. But in our case, you know, the team really, um, you know, moved forward with that. They set up some great metrics. They set up, got some real visibility on what was the root cause here and ended up with like a solution that is, you know, three, four times faster than the previous, uh, the solution was on, on sort of, um, responsiveness in the UI and speed of the general speed of the UI.

So that was a real win that came out of some really negative sort of feedback, to begin with. So that positivity that always, you know, test and learn sort of ethos, you know, get it out there, see what customers say and, you know, fix it quickly is sort of how we, we tend to move. And I think that yeah, without that culture, it could have been a very different outcome for UI readers.

Kavya (Director of Product Marketing, LambdaTest) - Awesome. Thank you so much for sharing that, Richard. Again, very insightful. Moving on to the next question, in what ways do you think the constant evolution of technology impacts the relevance of certain practices over time?

Richard O'Brien (Head of Product, BugHerd) - Um, yeah, it definitely does. Right. So if I think back to, uh, when I started my career in the early 2000s, um, you know, uh, software development was a waterfall process. Right. And the reason for that predominantly was, uh, you know, software was on the device, not on, uh, the cloud, uh, you know, source control was only just coming around.

So Git wasn't even invented until the mid-2000s. And so the process had to be, you know, getting a really strong set of requirements to find and then moving into development and then a really heavy test phase because, you know, it was getting put on a CD, or it was getting, you know, released to server instances and they couldn't really iterate like you can now.

So Agile wasn't possible, right? But then you fast forward, say, to the late 2000s and get there, we've got cloud is becoming available, APIs and integrations are more of a thing. And so Agile becomes a way that you can more effectively develop software, right? So if the best practice, say, had locked in as waterfall, then we'd still be doing it in that way. And we wouldn't have the efficiencies that we have today.

On a more consumer sort of level, I think when I look at how my kids use tech versus how I use tech, right? It's completely different too. So, if you think of it that way, there's a whole new set of best practices that are coming down the line that we haven't even seen yet, right? Because they're voice first, they're AI-enabled.

My kids live in the cloud and online, right? They don't even think about storage space on the device. It's like, what's that? Everything is just on demand. So, when you think about that, how could there not be changes in the patterns in which humans use devices? I think it has to be. I think also, from a testing point of view.

You know, it's something we're struggling with at the moment around test coverage, right? I think that's a perpetual conversation, especially in development where, you know, the best practice would say you need as much test coverage as possible, aim for 100% test coverage, that sort of thing.

But as a business of our size, you know, that can be a real drag on our efficiency and speed to market and we need to be able to evolve and move fast and improve the product. And if you look at that in isolation, like, okay, we don't have a huge amount of test coverage. That sort of can be seen as a negative.

But when you look at the volume of usage that we have in our product to the number of support requests that we get every day, you know, we're really quite reliable in that respect, right? So, the lens you take on it also matters in terms of what practices matter and how much they matter.

Kavya (Director of Product Marketing, LambdaTest) - Thank you so much. So essentially, staying agile and being open to innovation is something that is paramount to staying ahead when it comes to software development games.

It also makes me wonder, back in the 2000s, what, according to you, was a best practice that isn't considered or is obsolete as of today? I'm sure you, of course, mentioned a word mention about quite a bit of it.

Richard O'Brien (Head of Product, BugHerd) - I don't think I can remember that far. Yeah, I, well, I don't even know. Uh, that's too far back for me to remember. Um, I mean, I started out with Java, right? Learning Java and C++ and, uh, you know, I don't know why this has popped into my head, but Java doc was like a standard for commenting on your code. And I just remember how much of our, our uni, uh, courses were about learning Java doc.

I don't think I ever used Java doc ever after I left university. Right. I used, you can comment your code and things like that, but at the end of the day, like it was sold as this, oh, that's best practice. And that's how you build it. Build software. But then you go and get into the real world and you realize it's, it's different everywhere. Right. Um, that's just about getting the job done. I don't know if that's a bit of a random anecdote, but it's a bit hard to remember the early 2000s.

Kavya (Director of Product Marketing, LambdaTest) - Thanks for sharing that. Very interesting, of course. And it also makes me wonder if, I mean, there are, of course, many industries and sectors that are more vulnerable to the impact of outdated practices, right? And how essentially are they dealing with trying to mitigate the risk now that there is this transition happening?

Richard O'Brien (Head of Product, BugHerd) - Yeah, sorry, what's the question there?

Kavya (Director of Product Marketing, LambdaTest) - So I wanted to understand, if say, for instance, an organization or a sector for instance, that has been following some outdated practices, how essentially can they mitigate the risk and adapt to the newer age best practices out there?

Richard O'Brien (Head of Product, BugHerd) - Right. I think that's a general question about business as well. Right. If you're an industry that maybe isn't evolving, you're sort of open to being cannibalized in some other way. Right. I mean, the taxi industry and Uber, like, how much did we hate taking taxis? And then that sort of gave rise to Uber, and now they're in a really bad place. So, yeah, I don't have any, I don't know if I've got a good answer for that one. Um, yeah.

Kavya (Director of Product Marketing, LambdaTest) - Great, thank you. Moving on to the next question, Richard, in your transition from being a developer to UX consulting to becoming eventually a product manager, how has your perception of best practices changed over time?

Richard O'Brien (Head of Product, BugHerd) - Yeah, I think it's, um, uh, I think it's less so about moving through those different roles and more about growing as a practitioner, growing in my career, um, building up that experience and confidence and exposure to different things to be able to make your own decisions. It sort of is like coming back to that training, your own gut, um, building up that, that expertise muscle, if you will, you know, the thing that changes your perception.

It's thing that gives you the confidence to think, Oh, actually I might know a different way of approaching this. Um, I loved, so I follow, um, uh, John Cutler on LinkedIn, who is a like product evangelist for, or he was at amplitude. I don't know where he is now, but he was talking about it, I think he posted something about a team that he met with talking about comparing yourself to others.

And this team was wondering what the best companies do. And, you know, they described quite nervously their approach to discovery and prioritization and road mapping. And then he asked them what, you know, the company they think is doing it best, like whatever, whatever company they saw as the best in class.

And then he DM'd a friend because he had somebody who worked there and said, oh, this is what this team's doing. You know, what do you think of that? And the person who was at that other company that they saw as best in class was like, wow, I'd love it if we were doing it that way. You know, can I have a job there? You know what I mean?

So this team had like no confidence in themselves that they were doing it. You know, trying to do it as well as they could, but like they always thought someone else was doing it better. The grass is greener. You know, someone knows more than me. I think as knowledge workers, that imposter syndrome is the thing that you like, but I still struggle to outgrow it.

You know what I mean? It's always there like, Oh, someone else knows more than me. Someone is better. Someone's doing it better than we are. But often everyone's, I don't know. I see this in how we work with product teams and agencies. Uh, and so I regularly have customer conversations and everybody is like every single one is like, ah, you know, our process is probably a little bit different, but blah, blah, blah, blah.

And they describe the same process that everyone else has. Same problems that everyone else has, you know, those sorts of things. So we all think we're doing it wrong and a bit unique, but at the end of the day, you know, it's, we're all just getting by. We're all just trying to do our best, right?

Kavya (Director of Product Marketing, LambdaTest) - Thank you so much. That was a very interesting point of constricted because, you know, what I've sort of learned is each tool sort of brings in its own unique challenges and perception, which keeps on giving you more learning on a daily basis.

So whatever you shared, that's absolute gold for our audience, I'm sure. Moving on to the next question, could you discuss a time when feedback or insights from a client or a stakeholder prompted a significant change in your approach to a project? You did mention the changes that you brought to the UX, of course. But yes.

Richard O'Brien (Head of Product, BugHerd) - Yeah, I mean, one that comes to mind at the moment, we're doing some research on how we can make Bokert even simpler for our customers, clients, or stakeholders, right? So the core users of Bokert are product teams and or digital agencies who build websites for others, and the people who contribute feedback into bulk herd are usually stakeholders or the agency's client or things like that.

So we're doing some initiatives at the moment to how do we make that as simple as possible as effortless as possible and I was kind of lots of conversations over the last couple of weeks. So this is a bit fresh in my mind, but Something that stood out was someone was talking about how You know their client was a marketing manager at a fortune 500 company, right?

And so you know, very senior, lots of experience working in marketing and advertising for a long time. Um, but this project that they were working on was the first ever website redesign project they'd done. Right. So for the client, it's like, it's a new process.

They've never been through this. It's not a lot of the things that we take for granted as being like, Oh, that's just fairly standard. Yeah. This is the standard process. This is how you get feedback on a website. This is how you communicate with development teams. This is all brand new to that client.

And so while they're probably a similar age to me, have lots of professional experience, know what they're doing, very capable. It's a shift in the lens that they're having to think and look at what they're doing. So, the thing that triggered me in how we think about our client or guest experience in BugHerd is really shifting from a B2B interaction to more of a consumer-style interaction.

So, you know, if you think about the tools that they're using, Microsoft Office, you know, they're on Instagram, they use LinkedIn, they're maybe not as exposed to Jira or the other sort of Figma tools that we use in the website design and product design process.

So how do we change our UI, adapt our UI to be more in line with what they're used to in Microsoft Office, what they're used to in Google Docs, or the social platforms that they're using to make it really instantly understandable to them without any knowledge of the process of creating a website or designing a website?

So that's been an interesting insight out of this recent research. I think that's just one example of, like every time that we go and talk to customers, we learn stuff like that and adapt.

Kavya (Director of Product Marketing, LambdaTest) - Awesome. Thank you so much once again for sharing that. Of course, client and stakeholder feedback is something that we at LambdaTest also value so much because it definitely helps us incorporate their perspective into our product and effectively redefine our strategies, objectives, and so on.

Moving on to the last question that we have today, how do you handle resistance within your team or organization when introducing a new practice or changing an existing one?

Richard O'Brien (Head of Product, BugHerd) - Yeah, I think, um, you know, the culture we've got makes it a lot easier than it might be in some other places. So that's a good start, but I think the key, uh, to any change is about, um, engaging with folks early. So, um, you're not doing it's like, you've got to make it clear that you're not doing this just for the sake of change or just to frustrate them more. Um, you need to really be clear about focusing on what problem you're solving with this change.

So you can't just make change for the sake of change because that's just going to slow everyone down and make things less efficient for a time because change does take time. It's hard to implement anything, really, even in a small team. So focusing on that problem, bringing those people along with you on that journey.

So, you know, iterating, not just going, jumping from A to B, but taking the steps in between to, uh, like I talked about with shape up, we know, implement one project, see how that works, see what the benefits are, the downsides are, um, you know, iterating that, that process to fit the team and the business. Um, so not being like a dictator and saying, this is what we're doing, but being open, genuinely open to the feedback of the team and adapting to that feedback.

So you can't just plow ahead and not listen to the feedback. I mean, BugHerd is a feedback tool. We're a business about feedback. So yeah, it's important that you know that feedback is everything to us. So really engaging the team, taking their feedback on board and using that to adapt process, because that then builds ownership within the team of that process, ownership of how things are done here. That will make them advocates for that.

You know what I mean? So the more you engage, the more you bring people in, involve them and respond to their feedback, the more, the more you sort of build that. Um, everyone feels a little piece of ownership of the new process. Um, I think also it's important, and we've got this is having a culture where change is natural and it's really, um, failure is okay. Uh, it is a big help in this.

So if you are in an organization where there isn't a lot of opportunity for change, there's not a lot of appetite for change, it's probably going to be pretty hard for you to make any change. And so, in that case, you can iterate on your own process and maybe that of your direct team. But it is very heavily dependent on the organization that you're in and their appetite for change, too.

Kavya (Director of Product Marketing, LambdaTest) - Absolutely. I think the great insights again, Richard, you know, collaboration as well as involving all the teaming members at every step in the process definitely seems to be one of the best practices that teams, and software teams across can implement. So that, you know, with that, we come to the end of today's session.

As we wrap up the session, I would like to thank you, Richard, for joining us today and sharing your valuable insights. To all our viewers, thank you for joining us in this episode of the XP Series. Stay tuned for more enlightening discussions. Richard, thank you once again for joining us. It has been a pleasure hosting you.

Richard O'Brien (Head of Product, BugHerd) - Thank you very much. Happy to be here. Thanks, Kavya.

Kavya (Director of Product Marketing, LambdaTest) - Thank you, and everyone, stay tuned for more sessions and subscribe to the Subscribe to LambdaTest YouTube Channel for more XP series. Thanks once again for more XP episodes. Thank you once again.