Agile Transformation in Hardware: Quantum Detectors' Journey with Scrum

Lindsay Velecina: 0:03

Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.

Leslie Morse: 0:20

Hello listeners. My name is Leslie Morrison delighted to be a guest host here today on the scrum.org community podcast. I am joined by Matt from quantum detectors, and you're gonna get to learn a little bit more about him and all of the amazing things that he is doing related to Agile and Scrum and hardware and software all pulled together. So I think it's gonna be a really great conversation. Hey, Matt, how are you today?

Matt Callahan: 0:49

Okay, thank you yourself.

Leslie Morse: 0:50

I am. Well, thank you so much for joining us on this podcast episode, I'm excited to talk about quantum detectors and the work that you all do. Not only is it fascinating from just an industry perspective, but it's also the story of Scrum and agility related to hardware, which is something we don't get to talk about as much as I think we'd like to as agile lists. So thank you for being with us. I really appreciate it.

Matt Callahan: 1:18

Yes, great. Thank you for having me.

Leslie Morse: 1:20

Yeah, the I just want people to go ahead and start off by learning a little more about you. So tell us some about your professional background, specifically how he found Scrum.

Matt Callahan: 1:32

Yeah, sure. So I started my career as an apprentice. So I've kind of worked from the bottom if you like, my training is in electronics. So that's kind of what I studied in and what my initial roles were all about. So hardware related. As my career developed, I started getting involved with the wider part of the product. So that would be both mechanics, and software and firmware, things like this. And then eventually leading to now where I'm at Quantum detectors, looking after the whole product. My journey with Scrum and Agile might be typical of most people in hardware. It was a big buzzword, you know, in a lot of companies, and a lot of people saying these things. And at this time, you know, it's been used in software for quite quite a bit. And it was reasonably well understood. But in hardware companies, this buzzword led to some bad practices. So in previous companies, we've had managers trying to implement agile, it was just called Agile, not Scrum. And it was normally just oh, well, we have daily stand ups, and that's agile, or we have Sprint's and that's agile. And so that was my initial experiences of Scrum. And so when I went to quantum detectors, I was responsible for a larger portion of the product. And I was with a fresh team, and a fresh company. Were a spin out company. So we're still reasonably young. And it was a great opportunity to try things. And we've got a revenue sort of experimental mindset, quantum detectors. So when I joined, I was like, hey, you know, this Agile Scrum thing that's quite good, can I give it a go? And I managed to convince management to give us a trial and experiment. So we trialed it for three months on one product. And then at the end of those three months, we had great results. So I just kept expanding and extending the tests until now the whole r&d Department is working in scrum in an agile fashion.

Leslie Morse: 3:41

That's, that's really cool. And the thing that fascinates me the most, Matt, about that narrative is that it sounds like your first exposure to scrum was kind of very superficial and mechanical, not what we talk about is scrum.org, related to professional Scrum. So what did you What about your own personal experience, even led you to want to go at it again, once you were at Quantum detectors,

Matt Callahan: 4:09

because I see things not working. And I It frustrates me. So when you're working with new products, things that haven't been made before, it's there's often a lot of innovation and creativity that has to go into it. And especially with highly technical products, as well, there's another complexity of you know, introducing risk and uncertainty. And traditional project management is just really hard work with those things because we never know what we don't know. And agile was supposed to be the thing that can deal with complex environments and complex products. And so it was always in the back of my mind or something we should be doing. And whilst I had that, that sort of bad initial exposure, if you like, I thought, Well, I'm sure we could be doing this better and This, this chance to experiment and try and adapt as we go along was great. And we've kind of had to learn as we go, because there's not much information out there in applying this to hardware, which has a lot of unique challenges with it.

Leslie Morse: 5:13

Yeah, for sure. And so we'll we'll dig into that story, because I think I'm just very impressed that you had the persistence to like try, because there's so many people that have kind of gotten a bad taste in their mouth that it's, it's hard to turn the ship around. So you're like, I this is this is supposed to work, I believe it can work. So let's really dig into the details of that and start with just like you more about quantum detectors, like talk to us about the business, we know it's biotech, we know there's that vendor of hardware and software, but what's really your your core business and why you exist?

Matt Callahan: 5:49

Yeah, so So quantum detectors, essentially wants to be the fuel for scientific discovery, we make detectors, which you can think of as high speed cameras, for special applications. We want to sort of make cutting edge technology more accessible to scientists, and therefore, fuel the scientific discovery and you know, find new materials find cures for things. So all of our products are geared towards that, that science. We've got a range of products, mostly split into two categories. One is X ray, and another is electron microscopy. For those that don't know what electron microscopy is, if you think of a really powerful microscope, it's essentially that rather than using light to look at things really small, we use electrons. So we fire electrons, and it goes through material. And it means that you can image things about 1000 to 10,000 times smaller than the width of a human hair. So you can really see the structure of these materials. And this is what the scientists are using to develop new materials and learn and study more about what the existing sort of materials that we have today.

Leslie Morse: 7:06

What is the target about the ability to change the world, getting more of that technology into scientists hands. That is the epitome of the scrum.org mission statement, right? Helping people in teams solve complex problems, scientists are out there solving complex problems. And now you're solving the complex problems of the tools those people need in order to succeed. This is complexity upon complexity, upon complexity. So no wonder you are looking for something outside of kind of that traditional delivery management sort of approach. Earlier, you said you were kind of leading or over product there tell us a little bit more about like your exact role and what you're accountable for.

Matt Callahan: 7:52

So I'm employed as the lead detector engineer, quantum detectors, we have a range of products on sale at the moment and in development not yet released. One of the things with hardware is that we tend to have more products on the go at the same time. So there's a bit of extra complexity and management there. I look after most of the research and development team, the research and development team, the people that I come up with these great innovative ideas and help develop the products and release them to market. We also have various other teams that support us and support the business. And everyone's really intelligent, we've got a great bunch of really bright individuals. And because of that, we've managed to sort of overcome really difficult obstacles and create really simple products from complex needs.

Leslie Morse: 8:51

That's there's so many things that I'm curious about, just related to the nature of how your product development lifecycle works in terms of customer discovery, around what their their needs are in the iterative process of even coming up with a viable solution, you might want to turn into a product. That is not the purpose of today's podcast, though today's podcast is really the application of great scrum in this hardware environment. I do think we should talk to you about that other stuff in the future though. The The earlier you talked about like we wanted I wanted to go back and revisit Scrum and Agile ways of working because like stuff wasn't working. And things were harder than they needed to be. What was it that was hard or what was it that wasn't working? That led you to proposing scrum as a different way of working?

Matt Callahan: 9:53

I guess the simplest form is that we were always wrong. We're still wrong but You know, we would formulate a plan for developing a small piece of the product. And then inevitably, halfway through the development, we would find some issue or some issue would happen to us. And it would involve, you know, tearing up the whole plan starting again, that that could happen multiple times in a project. And this leads to the product, being late and over budget, and not necessarily meeting what the customer needs are. And it's, it sort of builds upon itself. So it takes you to take a step back to find out what's happening, if you're in in the detail, it's too easy just to be consumed by perfectionism, or consumed by getting accurate plans. And so agile really helped us or scrum really helped us to step back and take a look at the product rather than the project, if you like, and look at the customer needs and how we can maximize the value for them rather than for us. Yeah, the

Leslie Morse: 11:07

they sound like the same sort of classic challenges, lots of other organizations face as well. And the thing that I heard coming through the most from you was really a shift left in learn earlier. And uncovering those big rocks earlier in order to avoid waste and increase quality, which are right, right classic sort of things. But I love that you kind of lead with the learning first, because so many other people would lead with the will we want to get faster, time to market for customers having products in their hands or efficiency and more kind of classic business sort of things. But the fact that you are coming at it from a learning perspective, just tells me that your culture was probably already primed for this alternate way of working more so than maybe others. Would you agree with that assumption I'm making?

Matt Callahan: 12:08

Yeah, so half of our company's full of scientists. And if you think of the scientific method, it's already much well, you know, hypothesis, method, experiment conclusion. So half the company are already primed, if you like to sort of work in an experimental way. The other thing is that we've got a great bunch of people working for us. And they've all kind of got this growth mindset, which is really critical, I found for new ways of working and in complex environments. So when I suggested the idea, you know, there wasn't really any pushback, if you like, other than establishing the boundaries of the experiment, everyone was on board and gave it their, their full attention and their full effort, which is great, because as you said, other companies might look towards command and control, and first, and waits audit to sort of go in with this.

Leslie Morse: 13:06

Yeah. Now were there concrete sort of business measures or value indicators that you were looking towards? That these things need to improve? Through our use of Scrum? Were you able to be empirical in the use of Scrum.

Matt Callahan: 13:22

So we tried to be empirical where possible, but it's always really challenging to do that, because some of the numbers, some of the metrics are based on feelings, so they become slightly less empirical, you might have a number. But if it's just someone's opinion, then then I won't say what's the point, but it's a lot harder to keep track of, but we definitely had targets. So you know, we need to become quicker at delivering things, and quicker at delivering to the customer. And when I say deliver quick to the customer, what we really mean is deliver some value to the customer sooner. So we might not deliver the whole product to the customer, we might find some users that are really keen to try out the latest tech, and there'll be happy to put up with quirks and they'll be happy to try, you know, little experiments with us rather than receiving the whole thing. So yeah, we definitely looked at delivering value sooner. And we've hopefully delivered on that as we've gone through. Yeah,

Leslie Morse: 14:24

when it's there, I'm resisting an urge to talk more about how you found the boundaries of getting started with Scrum. And that sort of, let's do an experiment to see if this works for us sort of thing because you said something, I think really important there is the cut getting value some value even if not the entire product into the customers hands early, and really taking advantage of your customers that are the first movers around new technology. And this is where you I haven't had the luxury of really directly engaging in scrum in hardware sort of situation. So my brain starts To her, I'm like, Well, given the fact that you're giving people like X ray technology and advanced microscope technology, but given that you're dealing with the hardware of these kinds of products, how are you breaking down into those incremental chunks of value with hardware involved?

Matt Callahan: 15:19

This is probably the biggest challenge that we faced in, in the hardware world, because with software, it's typically readily modular. And there's typically low cost associated with delivering software. If we took sort of hours, it labor out of the equation, software is typically low cost, and can be delivered in small chunks. Hardware, is, by virtue of the fact it's physical, a lot more expensive to make and deliver. It's also highly integrated. So whilst we attempt to modularize, a lot of the things and that's a real key thing for us is that if you can separate functions and make it modular, then it becomes a bit more independent. And you could perhaps deliver that, that module independently or even if it's not got much value on his own, at least means that you can develop quicker because you can work on other modules in parallel, or you can stop and start modules and develop them at your own pace. But when it comes to the customer, we've had to look at alternatives to the full product in terms of gathering feedback and delivering some value. So we might develop a simulator that simulates the operation of our camera, and then deliver that software to them and say, Well, look, our camera could do this sort of thing. What do you think of the user interface? Or we might make a very low performance version of the hardware and go, Hey, look, this is the new technology, it doesn't have all the performance that you need. But it's got this new feature x y Zed that we think is really good. Can you give it a try? And and so that's how we've managed to deliver some value early. And we really have to sort of say thank you to the early adopters to take this on. Because they're taking a big risk in time, and sometimes money as well to try these new things. But the benefit for them is that they're the leading the technology, they're at the cutting edge. So they might be able to say, find that scientific discovery first. So that's the motivation we find for them. Yeah.

Leslie Morse: 17:42

And so it really it's, it's scrum in that iterative product discovery almost like is this even the product we want to take to market more so than the get the product in market and incrementally improve it? Once it's existing? And I'm contrasting that on purpose. Because I think so many of us are like, how do we get some version of the product out there to everybody and then tweak and tweak and tweak and tweak and tweak and tweak and tweak. And that doesn't sound like that's possible in quite the same way. It's like, here's an early version of what this product might be like, iterating through that, and then that becomes the thing that you do more of the full release around. Am I getting that? Right?

Matt Callahan: 18:27

Yeah. So yeah, there's, as you said, it was about the product discovery, and then, and then also the delivery. So you're right, we've kind of covered the product discovery side. And in terms of delivery, we can or we have released products, and then we do iterate and re release things. But we have to be very careful, because because there's a lot of costs associated with it, especially with the equipment that we sell, is that if you release an early version, if you sell an early version to someone, and then you know, six months later, their friends get the newer version. They're like, hey, you know, I paid all this money. And why is my friend get a better version? Yeah. So we kind of have to really plan our releases carefully. We do iterate after release. And I think you'll find if you look closely, most other hardware companies do this. If you look at cars, there's normally like a facelift version or there's little, you know, reliability tweaks that nobody knows about. So companies do do this, but it's not as obvious. But you're right, we have to be careful about our release management and our release planning because we don't want to upset customers that have you know, are out of pocket because they're the early ones. So we might deal with that by having a friendly arrangement of upgrading people or some other methods. It's really depends on product product. Yeah,

Leslie Morse: 19:55

the you subtly touched on something else that I was curious about, which was In this use your use of the word modular. And you're talking about kind of the overall low cost of software in the grand scheme of things. And it's easy to do that if your software is architected with, like, you know, actual good architecture principles that allow you to do things in modular ways. Is there an approach that you're considering for that in the actual hardware aspect of it as well, and I'm coming at this from a very layman's terms, it's like, yeah, the core of the X ray stays the same. But there is this component that they could like, take out and replace with the newer one in order to more iteratively, enhance and upgrade the technology of those core products, because that's an entirely different product architecture strategy from a hardware perspective as well. Yeah,

Matt Callahan: 20:53

so we do try to modularize things where possible, but there's always this balance, because if you're going for, you know, 100% performance, then if you modularize a product, then you are accepting that some performance features aren't as good as they can be. And the trade off there is that whilst it might not be as good as it can be, you're saving a lot of time in F bit and development time, because it's got a standard known interface, you know, it can be done in parallel, it can be upgraded later, all these sorts of things. So we have to be careful where we make those splits. Because if we make the split or the module in the wrong area, then you get stuck in a situation where you need this, this, you know, extra 1% performance, and you can't get it without integrating it with the wider thing. The other thing with physical and hardware products is that some things will just be incompatible. So we do modularize, where possible, and we tried to make logical split, but there's, there's not like 50 modules, there's, there's a handful of them. Because of that reason, that

Leslie Morse: 22:12

completely makes sense. And so this is just an example of one of those things you'll have to think about as seeking to get value in the customers hands early. What were some of those other kind of gnarly challenges that you had to navigate, as you were seeking to use Scrum with these teams for the first time.

Matt Callahan: 22:34

So I guess another common misconception that everybody has is that you have to release something every sprint, and in hardware that, you know, no exception. But the if really the challenge is getting over the mindset that everybody has is that you have to release something or not even release something you have to have, you know, some working version of your of your product every sprint and whilst we endeavour to do that as much as possible. With hardware, that's just not going to happen. If you've got a small team, which we are, then you've got a finite resource. So every sprint we produce value, but some sprints might be, you know, a design iteration as a bit closer to being a complete product. Some sprints might be the full working thing that we could share with a customer. But it's really that mindset of how can we break down these tasks small enough that we can work on them? And how can we break them down such that we get the most value out of each sprint?

Leslie Morse: 23:38

Yeah, having that increment that you can get feedback on that is potentially valuable. right for the customer. The same? What do you What does sprint planning look like in terms of choosing those sprint goals? In order, because I'm sure that your ability to do that well has changed over time. So what does that piece of the journey then?

Matt Callahan: 24:04

Yeah, so sprint goals are an interesting one. I guess we've got a controversial opinion about those. Because we have hardware, what we found with sprint goals was that they were becoming really difficult to formulate. Whilst we could easily come up with a sprint goals. A lot of the ones would be Oh, complete x y Zed by the end of the sprint. Right? And that's not really a good sprint goal. And the challenges that we have is because you've got people from different domains and we're a cross functional team, but you know, one person in the team has, let's say electronics experience another person has software experience, another person has mechanical and whilst everyone has a good appreciation of the skills involve that and the craft that other people have, I can't say to the software engineer right now you go and design this mechanical enclosure and I can't say to the mechanical engineer Can you just design this new circuit for XYZ, so because we've got all those domains in the same sprint, it becomes really challenging to have a cohesive sprint goal. So we've now moved to the towards product goals. So we have a product goal, that is a slightly longer term. And we can all focus on that and work towards that. We also use sprint goals if possible. But that that's fewer and farther between the more we sort of go on this journey. So

Leslie Morse: 25:32

I imagine that looks a little more like what is the most important thing we can do this sprint that gets us closer to our product goal. And that's kind of what that conversation shapes up as. And so is it potentially maybe that everybody's working on a, again, this would not be a traditional professional scrum sort of angelic, multiple increments that you're getting feedback on, because some of them might be more software based, and others might be more like designing some portion of the hardware component? Yeah,

Matt Callahan: 26:06

so we get feedback, every sprint, but the feedback might be just internally, so we might, you know, review the increment internally. When it's more usable, then it goes to the customer, because then they can they can get some value out of that. Yeah, whilst it's not traditional, you're right, we do sort of increment towards the product goal. So I guess some of our product goals are slightly shorter term than other companies. But that's the way that we've had to deal with things. Otherwise, it falls into chaos, because it's just a collection of tasks that become the sprint goal. And that's not no

Leslie Morse: 26:45

value. No, it's not, it's not. So you started. All of this learning initially happened through like the boundaries of one sort of experiment, that experiment well, and well enough that you have scaled scrum to larger portion of the organization. So like, how much of the work that you're doing now is rooted in Scrum.

Matt Callahan: 27:07

So at the moment, the whole of the r&d department is using Scrum. Or I won't say our version of Scrum, we're using Scrum for hardware this week. And, and that that's born out of that initial first experiments. So that's really good. What we're now looking to do is slowly bringing other parts of the company or if it's not appropriate, we, you know, how do we interface with other parts of the business, because we're primarily delivering physical products in some areas of the business that might not be appropriate for them to work in the scrum framework. It might be more efficient for them to work in in other ways. So for those departments is how do we interface with them better? And for other departments? It's, you know, how can we bring you in sooner to our process so that we can, you know, work together better? And

Leslie Morse: 28:03

through this journey? Are you learning faster than you were before? Because that was one of your key objectives?

Matt Callahan: 28:09

Definitely, definitely, we've learned a lot, you know, since we started, and I think it's easy to forget, you know, how far you've come? When you're just looking at Sprint to sprint, you know, you see incremental improvements. But when you stop to think about actually, you know, two years ago, we were in this position, and now we're here, it's a big change.

Leslie Morse: 28:29

What are some of those things that you're really celebrating? When you look back? Over that time period? One

Matt Callahan: 28:35

of the things we now find is that we're looking at smaller and smaller problems. So you know, you might get a moan from someone about this thing's broken, how can we do this thing better? And, and that becomes a bit all encompassing, because that's the biggest problem that we have. But when you look back, do you think actually these problems are minor compared to what we're having? So one of the things that that I'm really proud of is, is that we're now looking at smaller and smaller problems, and that we're having better quality conversations far more frequently. In the past, and particularly with older management frameworks, those conversations wouldn't be happening happening often enough. And that leads to sort of issues that we touched on earlier.

Leslie Morse: 29:27

And your customers notice the earlier value delivery.

Matt Callahan: 29:31

I hope so. So, we always have the customers that we work with always really excited, we always get positive feedback with our products, and I think they enjoy feeling part of the process a little bit. Because they will be the first people to have this new product or this new feature. You know, they're always really keen to try it and share it amongst their peers. So we always get good feedback from them.

Leslie Morse: 29:59

Yeah. So you've talked about wanting to integrate other areas of the business in the in those interfaces and new and different ways. What else is sort of on the horizon? And what does the future of Scrum look like at Quantum detectors?

Matt Callahan: 30:13

So one thing that we're still figuring out is production. So we have a production team, a production department. And one of the interesting questions I'm battling with internally in my own mind is, is how agile do we want to be in some areas like production. So in previous places, some of the products that I worked on, we would sell hundreds of 1000s of those products every year, and we had multiple products. So that for that those types of mass produced products, they need a strong process, and you know, quite tight controls to ensure consistency and quality. If you introduce agile into things like that, it becomes a bit of an overhead. However, if the company or if the product benefits or values from incremental delivery, then perhaps you want more agile methodologies in your production environment. So I guess we're still figuring out how much we want in there and what works best. I think the main thing is that we will continually learn and develop you know, I think that's the most important thing over Scrum and Agile in itself, is that just make sure that we keep improving, if we can make lives a little bit better every time then then that's good enough.

Leslie Morse: 31:37

Yeah. Yeah. And I mean, that's such a, that's a good higher calling, like, we just want to make things better. And if that commitment to continuous improvement is there, that's the real driving force that you need to try things differently. Every single time. Yeah, yeah. What recommendations would you give people that are struggling with even how to get started thinking about Scrum related to hardware.

Matt Callahan: 32:06

So I went on a long struggle to find information and to find people that, that have done this, because when you do some research on this, there's not many people that that have done this. or, more accurately, I think what's happening is quite a few people have done this, they're just not talking about it is either becoming some trade secret, or perhaps, you know, they've, they've got some secret sauce that nobody else is aware of. But I really struggled to find a good examples of what what scrum looks like with hardware, because the typical things that you'll find are misinformed. And that leads to bad habits. So I would really encourage people to reach out and find companies and people that have already been on this experience and to go speak to them. Because there are a lot of companies that do use Scrum, or other agile practices with hardware, and you will get the best value from speaking to those people.

Leslie Morse: 33:10

I've even heard that there's going to be a Scrum or agile and hardware conference in Europe in later 2024. So like, people keep their eyes open for that, that might be a good place to go and learn from each other around all of this, because I imagine it's hard to find your tribe, right? When you go look for software related or you go look for scrum related resources and content so much is software related. That tribe is huge. And this is this tribe is a little bit more niche. So are there in that regard? Are there specific, like resources and tools that have been super useful for you, that you want to recommend to others?

Matt Callahan: 33:54

Yeah, so I guess, I have been on scrum.org training, and I have found it valuable. But But honestly, I would recommend to take on some proper scrum training initially. And go in with a clear mindset, you know, forget what product you're making, just accept what what you're being told. And then just try and be open with it and try and try and read deeper into the, you know, the values and, and the why behind Scrum. Because if you're focusing on the mechanics, it's not going going to work. You know, when we talk about delivering an increment, if you read it on face value, you might just go well, I have to deliver a physical product every sprint and again, that's not you know, possible, but reading into it, you think are actually customers value this other thing or internally revalue, this, this part of the design being done. And so it's taking some time to really delve into the why behind Scrum, why it was developed and why setting

Leslie Morse: 34:58

basically events But events really are there. Yeah, yes.

Matt Callahan: 35:03

Yeah, exactly. Yeah, why the events are there. Because once you understand that, it becomes much easier to apply it to your situation for your hardware, your physical product. And, like everybody, it's, it's going to be slightly unique. You know, your company has a unique product, hopefully, and a unique setup that might be slightly different to how other hardware companies work and have. So it's, it's making sure that you can tweak a scrum to your needs, but still keeping the same values and ethos behind it. Yeah,

Leslie Morse: 35:41

that's great. All right. So Matt, as we wrap up, I've got kind of two sides of the coin around sort of the same question. One of the best ways to learn is by to get stuff fabulously wrong. So when you think back over this journey with quantum detectors and getting started with Scrum, what is one thing that just did not go? Well, that you're like, Man, I wish I could go get a redo on this one. And this is what I learned from that experience.

Matt Callahan: 36:11

I think the sooner that you can have the correct view of Scrum, the better because if you've got an incorrect perception of things, then you might not ever even start the journey. And, and so I would really sort of, you know, try and do that sooner. In terms of things we've got wrong, we've got plenty of things wrong. You know, we've had lots of products that have had big faults in them that, you know, there's big ups moments, if you like. So I think the some of the things that we've had wrong, you know, getting the sprint length, right, and making sure the right people are involved, you know, we might have developed this great thing at the end of the sprint, and then Oh, actually, we didn't tell anyone about it. So it's a bit wasteful, like, the customer didn't know it was there, you know, or the stakeholders weren't weren't informed of what was going on. So it was a, you know, wasted effort if you like. So we definitely have that type of experience. And in the early days, yeah,

Leslie Morse: 37:17

Scrum, Scrum, for the sake of your own gratification, versus scrum to really drive to learning and empiricism that it's there to serve. Yes.

Matt Callahan: 37:31

Yeah, exactly. empiricism is a key, a key word for us. Because, because things are expensive in hardware, you know, people don't want to make things that often. So one things that we found really valuable was to with empiricism in mind is that if you don't know which design choice to make more, can we make a prototype? Can we physically make something and validate it one way or the other? Or can we simulate something to prove it? Right or wrong?

Leslie Morse: 38:02

Yeah. That getting further down the truth curve? Yeah, as quickly as you can, it sounds like, Alright, so the other side of the coin is, like, what you talked a little bit about being proud of things that you've been able to accomplish, but I want like, they looking back on the whole thing, like, what are some of your big celebrations.

Matt Callahan: 38:28

So I think I'm really proud of our team and our department, because without them, you know, the experiment wouldn't have happened at the beginning, we wouldn't have continued working in this way. And, you know, who knows what would have what position we'll be in and what would have happened, but I'm really proud of our team getting on board and to, you know, take a bit of ownership in terms of driving the improvements and, and, and enjoying the process as well. You know, we tried to have fun with it, where possible and celebrate the mistakes and things like this, the thing I'm most proud of is, is my team and and quantum detectors to sort of support this and to get this going. Because without that we wouldn't even be sat here today.

Leslie Morse: 39:10

Yeah, absolutely. And without that you without those people, you wouldn't have products to give to your customers either. Right? All of this, your companies are artificial constructs. Right? We really are groups of people doing amazing things with each other. And it sounds like you've got a great group around you. So congratulations.

Matt Callahan: 39:31

Thank you. Thank you to my team,

Leslie Morse: 39:33

that I really have enjoyed getting to know you and a little more about quantum detectors today. Thank you so much for joining us.

Matt Callahan: 39:41

No problem. Thank you for having me. It's been a pleasure. Yeah. And

Leslie Morse: 39:44

listeners. We hope you have gotten some amazing things to take away from this discussion as well. Thanks for tuning in.