Technical Debt in R&D Organizations: A Conversation with John F. Conway and Raminderpal Singh

Interactive Transcript

spk_0 Alright, what are we talking about today, Reminder Park?

spk_0 Hey John, yeah it's good to be back at the table right? A lot going on out there in the world.

spk_0 Thinking about, so if you take the topic of technical debt and it's a big topic,

spk_0 you know, these are massive topics and we spend many times talking about them. Sure, we'll come back to the bits and bobs.

spk_0 But, you know, if I'm running an org, an R&D org, I'm going to try to be as efficient as possible

spk_0 in how I spend my money, what I buy, the build versus buying all these different things.

spk_0 But actually most logs are quite inefficient and they start big and they have plans

spk_0 and they end up kind of losing a lot of money, time and money, both of the similar things.

spk_0 Although in a large company of course, time is a spent cost so they don't really count time often and they should.

spk_0 But you know, actual green dollars they do count. I think we should go through the stopping,

spk_0 go through the different bits and bobs and just learn from you and learn from the conversation.

spk_0 Why is that going on? What creates those habits and what can we do about it?

spk_0 Yeah, it's a fascinating thing that goes on in the industry.

spk_0 And there's definitely not one answer, one situation, it's pretty broad and diverse.

spk_0 I think some R&D organizations have unlimited money in a way, if you think about it.

spk_0 And then there's some R&D organizations that are either bootstrapped or are very tight with money.

spk_0 And they don't have the luxury to spend on technologies, advanced ways of working.

spk_0 They'll still pull back, they'll be back in a little more of the stone ages than their cousins or their peers in life sciences or other places

spk_0 that are highly invested in. But technical debt is very interesting.

spk_0 There's all different flavors of technical debt.

spk_0 Given what I just said, the companies that pull back might have technical debt in the ways of very old equipment and difficult ways of working.

spk_0 And they can't get away from that.

spk_0 And life sciences companies that are very well funded might have technical debt that is because they bought two of everything.

spk_0 And it's not being used or it's being used in not great ways.

spk_0 And again, it's an overhead and a problem in the organization.

spk_0 So there's all different types of flavors of technical debt.

spk_0 I think finding that balance, which is, you know, you have these conversations all the time.

spk_0 With the pendulum always seems to swing from one end to the other.

spk_0 And people can't find that middle ground.

spk_0 And so these are what I've observed as technical debt challenges.

spk_0 They get compounded though.

spk_0 When it comes to things like integration, like, okay, hey, we've got all these, we've got all of our shiny toys and we've got all these capabilities.

spk_0 And we want to now tie them together and make it seamless and this and that.

spk_0 And again, the technical debt comes into play when people do this in a very point to point way.

spk_0 Or they, you know, they boil the ocean and some of the things are trying to do.

spk_0 And they spend years perfecting a scientific software platform.

spk_0 And then.

spk_0 And then it's kind of it comes in equated and they're like, oh my gosh, we've got this mass.

spk_0 Yeah, but it's not me getting it.

spk_0 By the time they get there, they have this massively integrated spent millions of dollars.

spk_0 And they're like, the technology came out and it just blows away this old way of working now.

spk_0 And people are like, oh my god, we can't get rid of.

spk_0 We just spent millions of dollars on this. We're stuck with it.

spk_0 And so technical debt is very tricky.

spk_0 That's what I'm trying to say here. I'm not articulating it well, but.

spk_0 So you have to find out and you have to work very hard at minimizing your your involvement, your integration, your stickiness of some of these tools.

spk_0 So that when it comes time to replace them, it's it's not a multi million dollar problem and a multi year situation.

spk_0 Right. So that's the enterprise. That's the large organization and part of technical debt.

spk_0 Which by the way, is a classic software engineering principle modularity.

spk_0 If you have an architectural software, your modularity is one of the non functional requirements, NFRs, the column, one of the NFRs you have to worry about.

spk_0 Now, do people actually worry about it? It's only not enough.

spk_0 And that's what causes these problems.

spk_0 But I would say that the people who are building these systems are not software are not pure blood software engineers that kind of coming from science in software.

spk_0 And they don't get the long term traps, which I think you're pointing to, of taking, you know, software engineering principles into accounts.

spk_0 But again, this is this is a very important part. You can over engineer.

spk_0 From a software engineering perspective, something that maybe only has a shelf life for two or three years, right?

spk_0 So it's this balance and trickiness. And so, you know, when I lived in pharma, we used to get we are not a software company, John. Right.

spk_0 But I'll tell you, we wrote a boatload of software and they still do today. So there's this dichotomy or this, this, this.

spk_0 What's what am I trying to say? There's this personality conflict of what are we doing?

spk_0 And even things like bioinformatics, right? I mean, software programming. Where are you going with that? Absolutely.

spk_0 Thousands of lines of analysis code in notebooks. And what happens if a new analysis platform comes the next day? What are you going to do?

spk_0 If a new type of approach for a new type of analysis comes alive, how do you switch to that? That's a software engineering problem.

spk_0 Actually, this is a very important use case. And look, by the way, people, we haven't talked about any of this. This is not pre-planned. This is us just getting out and talking about things that we've experienced.

spk_0 So bioinformatics, if I had $100 for every time somebody got angry with me and said, John, I spent the last 15 years building this platform. It's mine. I own it.

spk_0 I run it. It's my team. It's this, it's that. You know, why would I, why would I go and buy this new software or do this to that? They get upset about it, right?

spk_0 Yeah. And on the contrary, I also run into organizations where they're head of bioinformatics left. And nobody knows what to do. What's with the with the environment.

spk_0 They can't understand it. They can't figure it out. They don't know what's what. And it's it's a disaster.

spk_0 It's because it's all it's all hokey code. It can be hokey code. Or again, it's not documented anywhere. So no. So the fifth home that was created is there's there's no one in charge. There's no nobody understands it.

spk_0 And to unwrap that to undo that not is a is a very large undertaking. And so, so these are these are real problems in the industry. They're multi million dollar problems for small organizations.

spk_0 They're tens of millions of dollars. The problems for large organizations. And it's, I don't know if it's totally preventable. So that's that's part of this conversation, right?

spk_0 But I think a lot of it is preventable. A lot of it. I think with principles, it's preventable. The question is, do people who have not come from that background where principles matter? I mean, I'm talking about, and I mean coming back to software engineering and I do agree with you are coming about not over engineering.

spk_0 But the principle software engineering have come from 100 years or 50 years of people having scars. I give you one example. When I graduated from my first, you know, undergraduate. This is in 91 years ago.

spk_0 Electrical engineer coming out of London in Piedel College. And one of the biggest hires was Arthur Anderson, IIT. And they they're claims of famous they'll ship you to Chicago for six weeks. And actually they're shipping you outside Chicago to a training base and you would learn IT because it was IT consulting. And the language they were teaching was cobalt.

spk_0 Now, you have to be pretty old and know the name cobalt. The cobalt was a business language, a programming language for business applications decades back. And what they had made was a very strong business consulting companies who had legacy cobalt code and couldn't maintain it.

spk_0 And this is decades back. And this is the same problem you're describing when you know direct sort of bi-formatics leads this legacy code thing that has been a lot of money trying to maintain that code.

spk_0 A lot of money, a lot of effort. And so this comes back to, you know, we get asked this three or four times a month.

spk_0 John, what's the best environment for us from a scientific informatics from a scientific IT R and DIT perspective.

spk_0 And for industrialized science in industry, it's a hybrid approach. It's that platform ecosystem. There's an article written in the Harvard review years ago where an organization a large pharma could buy a scientific software platform.

spk_0 But they have full configuration and God forbid, but if needed customization of that platform, they're not reliant on the software vendor to do it. They could if they want to, but they're not reliant.

spk_0 So what they get is a commercial off the shelf platform out of the box, but that they can take it and turn it into what they need it to be. And now they've got the commercial part of it. And then they have their part of it.

spk_0 And the more that you adopt, the more that you can see and configure and and use from an off commercial off the shelf perspective, the better off you're going to be it's going to cost less money and long run upgrades.

spk_0 And it's everything that you do in these days, it's becomes more seamless, not a mountain moving exercise every time you want to this software gets upgraded. And then when you get into a GXP environment stuff, that's a whole nother ball of wax, but so you know hybrid, right.

spk_0 There could be a case where the company is completely aligned with whatever that software provider is given and they just they don't need a hybrid system. They can go commercial off the shelf. It's configured and that's the end of it. Right.

spk_0 So all these assessments need to be done along the way to figure that out to reduce this these these unfortunate unneeded dependencies and technical debt and things like that.

spk_0 The problem is decision making in these organizations becomes very difficult. It becomes influenced. It becomes fragmented. I didn't get my way. So I'm going to go off and do my own thing because I don't like what they just they've selected.

spk_0 And we have to reflect that by saying well, there's an open source alternative. Let's try both. Yes. Oh, yeah. Yes. Open source. Oh, you know, again, an R&D organization, so many organizations says, oh, we're not spending that money on this. We're just going to go with this open source.

spk_0 Fantastic. Except when it comes to support and it becomes maintenance and all these other things and it becomes if not managed properly, which happens.

spk_0 I won't say all the time, but a lot of the time. Yeah. Then it becomes technical debt because somebody somebody leaves or it or it's just sitting there and people are like, what is this right. Why is this here? Who's using it?

spk_0 And there's no metrics. There's no understanding. And now it just added to that big garbage can of frozen debt. And now what do we do with it? I've come from organizations that have had 15 year lens because of all the murder and acquisitions they've done. They've had.

spk_0 I forget how many registration systems, maybe eight chemical registration systems, like you can't fathom this. You're like, oh, John, that's not true. Trust me. It's true.

spk_0 Well, limb systems. Again, because of how they evolved in their journey in the company, how they were disconnected. Maybe it was M&A, whatever it may be. But at some point, somebody's left hold in the bag.

spk_0 And they're like, oh, my God, what are how are we going to fix this? How are we going to do this? And you got to remember, end users are dug in to the where they're doing things. So now you're telling them, hey, we're going to be taking that away from you and replacing it with someone else.

spk_0 And now here's another lesson learned. I can't tell you how many times that replacing it with something else is less than what they currently had.

spk_0 It's like you drive a Mercedes around a nice Mercedes expensive Mercedes with all the bells and whistles. And one day somebody comes and says, we're replacing your car. We're giving you a you go.

spk_0 And that's how you're going to get back and forth to work. And let me tell you the experiences they in debt. Right.

spk_0 What's interesting about that is that the people proposing it, they think they've got a law's voice. But the perception of how it's received and how it's used is a you go experience.

spk_0 So exactly the engine that is on steroids, you know, like, for example, we were talking a lot about, you know, gen AI and AI.

spk_0 Yeah, it's up in the engine in the back office. But actually what the user is experience, experiencing is a you go.

spk_0 Exactly. And look, I'm going to use the word criminal, right. It's criminal. What has been done in some of these organizations that we are involved in and we work with over the years currently.

spk_0 And so, I think that's really that a IT organization comes in and says, hey, we're getting rid of this piece of software.

spk_0 And I won't go into the details why, but it's not for the right reasons all the time. And they're going to replace it with something different.

spk_0 And then they put constraints on because they can't really afford it. They're going to put constraints on how they're going to use that software.

spk_0 And trust me, nobody wants to use the software under those constraints. It's a waste of effort, a waste of time.

spk_0 It aligns the vendor, the new vendor coming in. They can't get done what they need to get done because they're under these constraints.

spk_0 And now the vendor and now the end user say, this software is a piece of junk. It's a piece of crap. We can't use it. We doesn't do this. It doesn't do that.

spk_0 And the vendor gets my line. And in fact, it's the IT organization that didn't do it right.

spk_0 Yeah. And so, a lot of that user experience, they don't, they didn't get a grip on the user experience that's required.

spk_0 Well, they go grip on at all.

spk_0 Not at all. They use their stories, your requirements, how they interact with the software, how they're going to do the value.

spk_0 What are they we trying to achieve? Like, it's not done. But what was done is how we're going to save the company money.

spk_0 And when in fact, they they lost money for the company, they potentially impacted discoveries and development.

spk_0 And they they completely screwed us all up. And now they have more technical debt.

spk_0 Because now the now the user community says this new piece of software is no good. When in fact, it could be perfectly suitable for what they're doing.

spk_0 Now they'll go through an exercise. They're going to go higher.

spk_0 A large consulting company, a generalist who's going to come in and tell them what they want to hear. Because they know they're going to have four or five years of consulting now around something that could have easily solved.

spk_0 And adding lots of bells and whistles to make it look like the previous version.

spk_0 Yeah, correct. Yeah.

spk_0 But now, but the problem is there's two problems. One is the implementation.

spk_0 So this is a journey you go on. This isn't just like we select a piece of software and we implement it. It's over.

spk_0 That's just the beginning, right? I talk about this until I'm blue in the face. But but and then and then there's problems.

spk_0 The implementation isn't done properly or they keep it as a paper on glass. Let's say it's in the LN. They keep it on a paper in glass for for too long.

spk_0 We're talking three to six months max in a large organization. And then you start implementing new templates and making it.

spk_0 They don't do that. And then they say, okay, we're going to get rid of it now.

spk_0 And but the problem is those end users never use the tool properly.

spk_0 So what makes you think they're going to use the new tool properly without proper change management.

spk_0 You know, configuration whole thing. We're talking a major effort. This is a $30 million program at a large farm at today.

spk_0 You pick one of the top four ELNs. You have, you know, tens 20 30 40 departments in this organization.

spk_0 You have a ton of work to do. You have to deploy it. You have to hypercare. You have to configuration. You know the whole.

spk_0 It ends up to be a total cost of ownership. 30 plus million dollars.

spk_0 I don't think anybody actually plans for total cost of ownership.

spk_0 If this is a great conversation, go ahead, keep going. And then I'm going to tell you what happens.

spk_0 Well, my experience in large companies, you know, back in the States was their eyes are always on green dollar spend.

spk_0 And they say they push the approval on the green dollar spend. And then the other sponsors, sure, but don't ask for headcount.

spk_0 Right. Work it in what you've got. So right.

spk_0 So you've got your current commitments. Now you've got this thing you have to deploy. And we're approving the green dollar spend on this.

spk_0 But don't ask for head extra headcount. Don't ask us to slow down your.

spk_0 So slow down your current milestones, you know, to delay things. And sometimes even worse, they won't approve the green dollar spend until you commit to productivity increases on the, you know, as is.

spk_0 So without this, it would have taken me two man years, person years, but with this I can do it in one person years so I can drop a headcount.

spk_0 So they even let you cut people down when they exactly.

spk_0 But there's this, there's this portfolio planning that goes on, right. And so.

spk_0 I guess I always have to be careful what I say, but I'll just say it. And I think sometimes people appreciate.

spk_0 Research is sometimes, depending on vantage point you're looking at.

spk_0 The, the group that's not getting the funding because think of this, as you get closer to market with a, with a pharmaceutical therapy, it starts costing a lot of money.

spk_0 But you got to get that to market. You can't, you don't want it to fail. There's a lot of failure more than anybody wants.

spk_0 But the more money you put out at the end, and if you can get it over the line, then the money starts to come back in the organization just like any other revenue and any other type of company.

spk_0 So development, clinical manufacturing, they're going to get a lot more money to, to make sure that that that return on investment happens sooner.

spk_0 And then, you know, we can take some of that money, give it back to research and stuff. But the problem is research isn't always going to get that funding.

spk_0 So what happens in the portfolio planning is somebody says, oh, we're going to give $12 million to research for a new LN, right.

spk_0 And they're thinking that's enough money. Okay. And then, and then it comes in that the vendor selection happens that comes in.

spk_0 And the price tag is 20 million. And they're like, oh, we don't have that money. Can we get it down? Can we get it? Can we do this? Can we do that?

spk_0 And so nobody wants to hear about total cost of ownership and that potential failure that's going to happen.

spk_0 So, so they're like, hey, we, we can't hear about that. Or we're not going to do this project. And we have to do this project because we're suffering.

spk_0 We're missing this. We don't have reproducible science. We don't have fair data. We do blah, blah, blah. We're not using the scientific method. All the things that electronic lab notebook is there to to do protect and produce that model quality data so that you can extract it out of there and run a better in silico first or model first approach to things.

spk_0 And so this is what happens. Nobody wants to hear about that total cost of ownership because it freaks a lot of people out and they never get to do the project when they really know how much it's going to cost them.

spk_0 It's the companies that embrace that TCO understand it and say, okay, this is really what it's going to take. We have to be honest with everybody internally here and and do this right.

spk_0 They're super successful, but I can tell you it's not the norm. Yeah, I would argue. No, I get that. I would argue that there's a there's more underpinning problem here, which is a new mentioned about, you know, model quality and in silico and the new measure about fair and things like that.

spk_0 I would argue that companies treat these as soft value points and that's the problem. They're not so so for example, let's say a company's burning. What's a burning platform? Right. There's a burning platform. We need to do ELN's better.

spk_0 Do we? I mean, yeah, sure, we're saying it in the board room. We're saying it at the C3. Do we really believe it? And I would treat it as a soft value statement, not hard value statement.

spk_0 And that's what causes these problems. I mean, it's a classic cost sense of issue. Cost sense. That's what your point is to go out and even cost center. The cost.

spk_0 We need to do things better, but when it comes to it, it's not the same as putting another sales guy out there or making sure there's an application engine. It's deployed to deploy customer deployment to support customer deployment.

spk_0 It's kind of like a soft improvement, which we'll get to sooner or later.

spk_0 I agree with you. I will tell you I think of it this way. This is for me a very easy to understand analogy and very powerful, in my opinion.

spk_0 You have a toxic dump in a stream way, 10 miles from here. It's going to pollute that whole stream. Right. This doesn't stop there. It's sit there. It's going to pollute everything downstream.

spk_0 And that's the same thing that happens in discovery and research. If you don't have things in order, remember, it's going from research to development.

spk_0 And when you throw junk over the wall or misinformation or missing information, now the development team has been poisoned.

spk_0 Now they have to go figure it out and make it all work. And the same thing happens. If you go from development into CMC and manufacturer clinical, you know, all of that.

spk_0 As you go down the stream, you're just poisoning the rest of the organization. You don't do it right up front. And that's really what ends up happening.

spk_0 Now that's that's the situation, but we're talking about decision making at the C-suite in the board here. And I, you know, reality check, you know, if you're in the C-suite, you've got constrained funds across the whole thing.

spk_0 Absolutely.

spk_0 And I get that.

spk_0 You're working, you're working which burning platform do I focus on today? And let's like you said very well earlier, you're going to focus on the market access, the production and the manufacturing, all sales and then all the way back upstream until you get to clinical trials.

spk_0 And then prior to that, you know, maybe a bit of animal stuff. And at some point, it's sort of importance, but not really the thing you want to worry about.

spk_0 Right. Right.

spk_0 I think there's another problem. And that is to you have IT and organizations. And then the business, the science, the R&D, they feel IT is not doing a good job.

spk_0 Look, I'm just going to, I'm just going to be very open about this. So what do they do? They start building their own internal IT, cold shadow, IT and some organizations.

spk_0 So in reality, if you look at some of the top farmers today, they have their corporate facing IT. And then they have a whole nother shadow IT in their organization, which means they're almost double the size of what they should be.

spk_0 If they work together, if there wasn't us in their mentality, they could work together and be one cohesive unit, they would be much more efficient and much more successful.

spk_0 And, but unfortunately, I think organizations have struggled on how to structure how IT, informatics works together in these organizations to make it work.

spk_0 And this leads to a ton of technical debt as well and problems. And so that's a whole nother Bolognax that that companies have to deal with on an ongoing basis.

spk_0 I think you'll spawn the, it reminds me again, corporate organization. There's a theory that every 18 to 24 months, a corporation goes from silos to integrated.

spk_0 So you go from, I want a big IT group, so I want the IT group kind of dispersed, you know, as friends of the within the other organizations. And they can't work it out and they flip, they flip a lot.

spk_0 So, yeah, seeing outside life, so I see a lot.

spk_0 I feel that it, why is this? Why does this happen? So again, you know, we're talking about complex things here. So to say it's one thing would be childish. I think this happens for some key reasons.

spk_0 One is ignorance. Okay. And not a not a not a maligning type of ignorance, but ignorance of, well, I just don't understand this. I, you know, I'm older now. I'm in a senior executive leadership position.

spk_0 I didn't have to deal with these things coming up through my career. And so I don't truly understand it. Right. So how am I going to, how am I going to manage it? How am I going to?

spk_0 To establish it or, or, or innovate in this space, if it's, if we don't get it, if I don't understand it. So I see a lot of this in the senior executive teams where they truly don't understand how to do this.

spk_0 And, and, and unfortunately, it's always a cost, it's always a cost center that is scrutinized, but it's always a cost center that sometimes it's just given money to try to make the problem go away.

spk_0 And I've done some analysis of different organizations and stuff and their, their efficiency levels and things like that. It's very difficult.

spk_0 But I do feel that there's this, this lack of understanding, but lack of knowing how to do this. You can't, and I've seen all different strategies too over the past 15 years.

spk_0 Oh, we're going to do twice as much with half the amount of money.

spk_0 Oh, okay. That's a recipe for disaster. It'll look good for the person coming in saying they're going to do this. And what they end up doing is they almost in a blinding way cut to the bone in the areas and almost destroy parts of the organization and lift another up. They'll get the accolades there.

spk_0 And then they move on before, before, before, before, before, I went there once or the next year of year.

spk_0 Exactly. And then the, the, the, the, the poor sap that inherits that next is like, oh my god, what did they do here? So there's that that goes on. There's this, this bit of, um, CIO chief information officer leaders that truly don't understand the data like the whole data side of things.

spk_0 They're wrapped up in high level things, concerning concerning things, the security aspects of things. Yeah.

spk_0 But by the way, security is changing so quickly that, you know, it is a very difficult job to have. It is all encompassing. And, you know, the last thing anyone wants is their name on the front page of a newspaper and a data leak leak that has to do with patient data or anything like that. So these are all massively stressful problems.

spk_0 But this, this technical debt can, can happen very quickly and, and build up to where it's constricting and basically it becomes unmanageable.

spk_0 I think you're onto something about, there was something kind of nuanced in what you were just saying about the sorts of leaders there are.

spk_0 And you described two types of leaders, not explicitly, but I read that once I believe there is somebody who's really good at corporate has wisdom understands the notion of, you know, how corporate, corporates need to, corporations need to deal with these problems.

spk_0 How you have to, you know, you have to, the vision of responsibilities, making sure you're not creating a burning fire for future. I've seen it and done it before.

spk_0 Whether it's in the industry, our industry or in another form, another industry, but they have that wisdom.

spk_0 The other one is people who understand the data, who understand the science. And there's very, very rare to find somebody's been both.

spk_0 So you walk into a room and you're dealing typically with one personality or another personality. Somebody's been who's come up from the organization who really gets it, but has never really seen these challenges before.

spk_0 As you said, yeah, what am I supposed to do here? Because they've come up through a vertical or something, you know, they've a director, senior director, VP, senior VP.

spk_0 Now they're a bigwig, but they've not really understood these classic organizational problems or somebody who's got a lot of experience with classical organization problems, but actually doesn't really understand the topic.

spk_0 Correct. Absolutely. And you know what? It's okay to, we used to say put bombs in seats, right? It's okay to understand what those capabilities are, those missing capabilities.

spk_0 And that's where you build out a team that fills in the gaps and puts that together. And you have somebody at the helm that truly gets that big picture and knows how those different players contribute to the overall picture.

spk_0 Right. And that's what makes it work, but it's I don't see it too often.

spk_0 It's hard because you know, if we, I know you're a big fan of six thinking hats and if we take that kind of view of life, you've got different characters that the person who's come bottom, so I was really a deep expert on whether it's data or science or whatever the area is a clinical trial, so example.

spk_0 They will have a push mentality on look, we need to do these things because they're the right things to do and we will champion the right things.

spk_0 The person who's coming in from an organization will have a constraints mentality. We need to work with planes, we need to innovate within constraints.

spk_0 And if you know, one is leading and one is part of the team, that tension is, it requires a certain, a certain relationship to happen.

spk_0 Otherwise, it doesn't persist. I mean, this thing just falls upon.

spk_0 Absolutely. And so what you see is IT organizations that can only service a portion of their client or customer base and action.

spk_0 And so what happens is, if you're one of the lucky ones that they're able to work with and help, that's great, but the other ones that are neglected, erode.

spk_0 And then they, and then now the cost to bring them back up to some sort of level playing field becomes unwieldy.

spk_0 And not only that, and we talk about this, and we've talked about this before from an economics perspective, the whole artificial economies that we deal with.

spk_0 One of the most powerful things in it, in my opinion, again, I'm not, I'm no expert when it comes to economics and stuff is consumer confidence, right.

spk_0 The same thing is true in a large global IT organization. If your client base has a very low IT confidence, no matter what you do, you know, you're throwing your hat in a room before you walk in there, you know, you're sending in food, you're making all types of promises because it's, it's a, it's a horrible interaction.

spk_0 And again, this contributes to the overall lackluster results that our IT organizations get because ultimately comes down to us and them, and that is not a very nice environment to work in.

spk_0 This is a good one. I've got actually a little history example of how I've seen this successfully tackled.

spk_0 When I joined IBM in 2001 in Vermont, one of the, I didn't take this, but one of the groups who gave me a job offer, I took another one, but was in a group called EDA, and this is EDA.

spk_0 It's designed and able electronic design, these are design tools. So this is semiconductor stuff designed to software software for people doing design work.

spk_0 It's, there's an analogy here. It's an IT group. And so the VP who ran that was a really smart guy. He had a problem. He just taken the job of running that EDA group. Think of it as an IT group.

spk_0 And he was every year for the four plan, going with, you know, his cup, penny, you know, trying to get pennies from the various customers, internal customers. Very similar, right?

spk_0 Getting these pennies, getting enough to budget to pay his people and making a whole Excel list of commitments out, you know, like his own given the cake, giving the cup of coffee, trying to get people to give that give that little bit.

spk_0 And he changed, he immediately changed that relationship. So in the four plan, he created a whole set of different set of discussions with these groups.

spk_0 And he said strategically, we're all going to get together and you go, all these internal customers together, these design groups can say, okay, what are we focusing on here for you guys?

spk_0 And he, through those conversations, he created real strategic partners with partnerships with these folks where they appreciated and they've, they actually influence what the key top five or 10 strategies are for that IT group.

spk_0 And they, they, they absolutely locked in on some multi-programs and very good leader. And I think there's a lot to learn from that.

spk_0 Yeah, no, that, that, that sounds great. And those are the types of things that have to be done. I mean, but it doesn't, it doesn't happen.

spk_0 And well in many organizations. And what I see sometimes is, for example, if you look at like the post, the US Postal Service versus, you know, UPS FedEx, other ways of doing it, they can outperform governmental approaches or your credit dogmatic approaches.

spk_0 And, and the same thing becomes true in an IT organization, a global, you know, our IT organization where that it becomes very bureaucratic, it becomes very constrained and, you know, consulting organization or a private organization could come in and kind of run circles around things.

spk_0 And so it's, it's a, it's a huge challenge. But again, when not done properly, it's just another example how technical deck can really build up because things are falling through the cracks, people aren't getting what they want, they start building their own things, they're not following any rules put in place.

spk_0 And that us and them divide becomes bigger and bigger. And in, and what, what instead should be happening is, if done properly, a global IT organization could embrace the shadow IT in their customer base and work with them to enhance it and make it part of the overall footprint and trust me, it works really well when that's done.

spk_0 But it's not done well today in many places. So, so we're going to continue with these technical debt issues, money's not going to be spent wisely. And unfortunately, some of these organizations aren't going to get what they're hoping to get.

spk_0 And the ones that suffer in the end are the end users are the scientists, the researchers, the clinicians, et cetera, because their quality of work life suffers because they can't do anything close to what they do in their private or personal lives with the technology they have.

spk_0 And so it becomes, it becomes again constraining and a poor quality of work life.

spk_0 Yeah, and it shows, I mean, if someone could turn up and say, listen, I can get chat GPT, do I chat GPT? So I script, which does better than what you were giving me at work. What are we doing here?

spk_0 Yeah.

spk_0 And the evolution of apps. So there's something called the API economy, this is term. And what happened was, I think a lot about 2000s, mid 2000s, there was up until then, everything was go talk to the IT team.

spk_0 And there's some of these APIs became live. And when you have an API, you don't actually need to talk to the IT team. You could create an app at the edge. If you go an app at the edge, you have all these folks creating their own apps at the edge and ignoring the IT team. So the IT team are now, you know, they're removed from the line of fire.

spk_0 But that relationship problem occurs, like you're saying, it was a partnership. They were just, they're just not to be ignored because if you're given the API, I don't need to talk to you.

spk_0 Yeah, yeah, and if you're given the API with guidelines and rules and stuff and said, it's just like any other variant type situation says, hey, here's the box we want you to work in.

spk_0 Okay, if you're going to come outside that box, just give us a call. Let's talk about it. Maybe we make the box bigger. Maybe we say, hey, we were going to come up with a better way to do this. Let's work together. Whatever it is, you almost need to.

spk_0 You need to provide those bumpers or those guidelines and and you know, instead of somebody coming in, you say, no, we can't do that. Sorry, no, no, no, no.

spk_0 And you know that as a as a scientist, as an automation engineer or whatever on the other side, you get very frustrated very quickly.

spk_0 You know, hey, the cloud, the cloud was put in place, super efficient way of doing things and all of a sudden, it puts this constraint over it says, well, yeah, you don't have to wait six months now for an Oracle server, you know, to get that.

spk_0 And then another two months to set it up and stuff, you can go right to the cloud within five minutes do what you need to do. Oh, but we're sorry we're going to have to do a security audit.

spk_0 Oh, it's going to secure. Yeah, and that's going to take three months, but we can't get to it right away because we're super busy. So it's probably going to be more like six months and we're like, what's the point here? Why do what what are we doing? Why we have an here? And this is another example of where you put the guidelines in place.

spk_0 You open up the usability and you put a box around you said go have at it, right? So it's just it's just super frustrating.

spk_0 When you're in a large organization and you know you could get this done in minutes, hours or days, and now it's taking weeks, months or years.

spk_0 And it's this is what boils people's blood, right? So you have to have a better environment of enablement and and this is what this is what doesn't happen.

spk_0 And you know, I won't say much more than that, but it's all doable. It's all achievable. It's just it's it's figuring out how to get out of everybody's way to do it.

spk_0 Yeah, and I think you you talk about dynamics between the different bodies. There has to be a kind of a shared responsibility and there's there's fundamentals to this to work, which don't normally play to, you know, when you've got turf when you people got people are turf grabbing.

spk_0 Yes, normal. You have to take your egos off when you come into the meeting room. Okay, so there's a lot. So you know, I think you might ask me earlier. If not, we do talk about this a lot, but we have we have ego problems.

spk_0 And science, right? We have ego problems. Unfortunately, and you know, there's all different types of personalities out there. We've all seen them.

spk_0 And you know, some people have to be the smartest person in the room and some, you know, are going to fight or don't understand actually what things cost and how to do them like to actually work with your hands.

spk_0 You know, many people don't have these experiences in their childhood, teenage years, even college years of actually doing something with your hands and producing something and making it happen.

spk_0 So they get into these now. They're in they're in their career and they're difficult to work with. They have no idea what they're talking about. They have no idea how it would even happen or how they would get this done.

spk_0 And but yet they're screaming the loudest and unfortunately, as we all know that adage the school, you will gets degrees. This happens more than not. And it's just a huge problem.

spk_0 And they're very good. They have a skill. They're very good at creating a simple message about what needs to be done. And yes, and all us intelligent people. We still love simple messages.

spk_0 Yeah, give me a simple message. I can latch on. I can go to the politics right give me a simple message of who's a vote for. And if I forget the complexities of everything.

spk_0 And simple messages have a way of punching through simple messages and simple success criteria, right? Like, you know, let's just achieve one thing here.

spk_0 Let's not boil the ocean. Let's not try to achieve 10 things. Let's do one. Do it really well. Figure it all out and now move on. Right. But you know, it's it's difficult to have conversations with folks around project management planning. How we're going to do it. How we're going to is, you know, it's complex.

spk_0 It's not simple. Even if it's one thing, it's not simple. It's complex. Exactly. There's nothing easy anymore. Nothing. So even with chat, GPC. So yes, exactly.

spk_0 John, I think it's great. I think it's great. I mean, we should, with your permission, we should come back to technical debt several times over the next few months.

spk_0 Well, I think it should be part of our conversation moving forward on how do we guard, you know, we talk about culture a lot. How do you guard the culture? But how do you, it's the same thing with technical debt, which is part of a cultural problem.

spk_0 You know, we're going to belabor this. But how do you get a handle on it? We're, I mean, the amount of money and and problems and angst and everything that can be prevented by just putting a little foreshadowing or forethought, not foreshadowing, forethought into technical debt could save an organization.

spk_0 You know, a lot of headaches, a lot of money and improve their efficiency dramatically. And remember, at the end of the day, these mistakes are compounded. They cost companies in today's world, billion dollar discoveries and opportunities. Right.

spk_0 It's just the fact. And so we're not, we're not messing around with the little things here. This is, this is people's lives, people's quality of life and companies, organizational spend and organizational, you know, quality of work life is very, very important.

spk_0 Yeah, because you have users and users have emotions and they're overwhelmed. And if you mess with them, they switch off.

spk_0 Yep, absolutely. Thanks, John. Hey, it's pretty cool. All right. We'll chat next and keep us going. All right. Take care. Thanks everybody. Thanks everybody.

Technical Debt in R&D Organizations: A Conversation with John F. Conway and Raminderpal Singh

Interactive Transcript

Topics Covered

Related Episodes

Out on a Limb | Nov 2nd | Hillhurst United Church

How Do You Respond to Jesus? John 5:16–47 :Daily Devotional, Daily Bible Study

Episode 240: Otto Aerospace CEO Paul Touw talks teardrop, laminar flow, and Phantom 3500

Burnout, Breakthroughs, and the Power of Getting Back Outdoors | Gun Talk Hunt

Share Episode