Thomas England @ Origin: IoT, AI-Native Engineering, Velocity Trap

Thomas England is the CTO of Origin Smart Controls — a company building software for IoT device management in commercial buildings. Origin came out of the mechanical and electrical engineering world, not the software world. That's the whole point: mechanical engineers and software engineers build the platform together, so it solves the problem the way a building engineer understands it, not the way a developer assumes it. Their clients include the NHS and a major UK broadcaster.

In this episode, Thomas breaks down why velocity is the most dangerous thing AI gave engineering teams, and why point-solution SaaS companies should be watching their pricing very closely.

Topics covered:

• Why most IoT dashboard platforms fail — they give you a toolbox, not a solution
• The engineering triangle: quality, accuracy, velocity — and why AI breaks the balance
• Why you can't blame Claude or Codex when your production breaks
• Two types of AI resistance in engineering teams and how to handle each
• Why point-solution SaaS is in trouble — and what Atlassian should be worried about

If you're an engineering leader figuring out AI adoption, or a founder building in an old-school industry — this episode is for you.

👉 Follow George:

• LinkedIn: https://www.linkedin.com/in/georgehelgesen/
• YouTube: https://www.youtube.com/@georgehelgesen

👉 Follow Thomas:

• LinkedIn: https://www.linkedin.com/in/thomas-england-09334280/
• Origin Smart Controls: https://originsmartcontrols.com/

Transcript

SPEAKER_00 0:00

You're watching Backstage Tech, a podcast for software founders, investors, and product leaders. We're back, it's episode number six, and today we're joined by Thomas England, CTO of Origin Smart Controls. Thomas, welcome to Backstage Tech. Thank you for having me, George. Thank you so much for joining. I know it was a long trip for you to make it from London to San Francisco. You see this beautiful golden gauge. Golden Gate Bridge. I have a hard time pronouncing it for some reason. I was told we need to add some humor to the podcast because we always talk about serious things like AI, technology, software products. That was the first attempt of a joke.

SPEAKER_01 0:43

Well, um, unfortunately, there's not a there's not a claude skill yet, I think, for uh uh interview introductions at least.

SPEAKER_00 0:50

Yeah, I think the the biggest mistake for me was to generate this joke using Claude. I'm not gonna do this next time. Thomas, why don't you take a few minutes to to introduce yourself? Sure.

SPEAKER_01 1:01

So um I am CT of a company called Origin Smart Controls, um, as you kind of introduced me as. Um what we do is basically a software platform for the management of IoT devices, specifically in regards to things like, well, managing a commercial office space, managing a uh commercial manufacturing space, kind of anything from air handling units to CO2 levels to security in terms of somebody's left the window open, et cetera, and kind of everything in between that. We not only do the software platform side of that, so the visualization of all of that data, um, but also we help you design your um installation, your solution, and we can also install that as well. So it's kind of a bit of a uh holistic service at that point in regards to everything around uh solving that sort of problem. In terms of my background, so I've been in the tech industry since uh 2014. Um, so that is now 12 and a bit years. Worked for Origin for now coming up to two years, and then before that, um I worked for a different company for pretty much my entire uh previous career and kind of uh came from well, not not being a software developer at all, um, to then kind of learning my trade, to then moving through the ranks, to then being technical director there.

SPEAKER_00 2:14

It was actually one of my questions because when I was checking your LinkedIn, I noticed that the first role at MPro5, which was your previous company where you worked for a long time, was office administrator. How did how did it happen?

SPEAKER_01 2:30

Yeah, so it's a it's an interesting story. As I said previously, my um my background is not really in software engineering originally in terms of my education. So when I went to university, I did a degree in biology and then I did a master's degree in immunology, uh, which is study of the immune system. That master's degree pretty much proves me beyond any doubt that the original career that I was looking at, which was kind of research science, PhD, was absolutely nothing that I wanted to be involved with whatsoever. The hours are terrible, uh, the pay's terrible. Uh, it's one of the most political jobs you'll you wouldn't expect it, but it's one of the most politically charged jobs you can possibly do in terms of like competition for funding, lab politics. I was completely out of that. But that did leave me then with a situation whereby I didn't know really what I wanted to do as a job, as a career. After settling myself with uh several tens of thousands worth of uh university fees, I was then uh looking for a job and kind of a bit of a bit of a purpose as well, to be honest, at that stage. That's when I just was looking for pretty much any job at that stage. And uh something came up at Crimson Tide Emperor 5. Uh so I applied for that. It was a temp office administrator role to start off with. And I applied for that. I got an interview, uh I got some curious questions as to why somebody with a master's degree was applying for a temp office admin job, but sort of explained the whole story, and it's like, yeah, fine, good. And so I got hired on there and then spent basically three months as well, a month as a temp, then they brought me on full-time for two months. And then I was one of my many, many, many responsibilities is an office admin, and and it's a it's a position that I have uh now a tremendous amount of respect for just because of the amount of random crap that you have to deal with. You are generally speaking the messenger boy for the entire office at that point, is I was having to update the corporate site, the WordPress site, uh, for some announcement that we'd made previously. And uh the the chairman who had very strong ideas about the way that colour should be represented in terms of the corporate brand, wanted some changes. So I was at that point, I dived into WordPress, and somebody several years previously had created this WordPress site and they didn't work there anymore, and nobody knew how it worked. And so various people had an attempt at hacking it at various points in terms of making it look a bit more how people wanted it. So I was sat there with the horrendous WordPress editor, not knowing anything about software development whatsoever, with a whole bunch of minified JavaScripts that was in front of me that I didn't even know what that meant at that particular point in time. And uh the chairman happened to walk past my desk at that point behind me, obviously coming to ask how the thing that the very specific thing he'd asked for was going on, and said, Oh, I can see you're in the middle of things, don't worry about it. And he said, Oh, what are you doing there? I said, Oh, well, I'm I'm trying to find the classes that I think control the colour, because I was starting to understand a little bit about CSS at that point. Do the colour changes that you wanted? And he's like, Oh, interesting, interesting. And apparently, he told me afterwards that was the point that you then talked to the technical director, the then technical director, to say, I do think this guy might be slightly wasted as office admin. We have a we have a software position that's open, an entry-level junior software position that's open. Why don't we try Thomas? So that was my start into was was a complete fluke. Uh the chairman walking behind behind me when I had a whole bunch of code open that I had no idea what it was doing or how it was doing. But from that point on, yeah, it was just uh being thrown in at the deep end and then uh it's a bit of a sinkle swim, but fortunately I floated. So uh um yeah, carried on, improved my skills and understanding more and more, and then more of a leadership position after that, and then eventually being promoted to succeed the previous technical director who'd then been promoted to CEO as the new technical director. Yeah, it was uh from from the bottom to the not quite the top of the company, but it was quite a journey.

SPEAKER_00 6:05

What a story. I thought you would say the chairman comes to you and says, uh, what are you doing? You're saying, Oh, somebody somebody asked me to change to change the color. I have no idea why and why exactly this terrible color. And the chairman would say, Actually, I requested this.

SPEAKER_01 6:23

I mean, the person in in question never made a secret about when it when he wanted something doing, so that would never have worked with him. But um, yeah, but no, it's um uh yeah, it's it's funny how these things work out.

SPEAKER_00 6:35

Yeah, and he also reminded me about uh my personal story because I also started I started as content management, I worked with with marketing, and it was also a WordPress website. And I remember the first days when I just opened the editor. I was shocked by what I saw. Not nothing I could understand at that moment. HTML tags, CSS. Well, I had no idea what I was doing. I still have no idea how it works, to be honest. But let's talk about today. You're leading technology at Origin Smart Controls, the company that provides monitoring control and automated solutions. So, could you tell me about the main problem you're solving at Origin?

SPEAKER_01 7:15

People have building management systems, people have the hardware for a lot of these sorts of uh monitoring solutions in place already. You know, at least for large commercial buildings, you you kind of have to, you you have to have something that controls, you know, when AC turns on or off or or um enables you to record uh how much electricity your tenants are using, for example. So they have the ability to monitor these systems, but they don't have the ability to visualize them all in one place. The systems that are often in place with these sorts of installations are pretty old. And if they do have a way of putting the system, putting the data off the system into something else, it's generally speaking highly partitioned. So you will have your air conditioning data in one place, you'll have your electricity data in a completely different place, they don't talk to each other, you have no ability of understanding the relationship between those two things. Never mind automating any kind of control or monitoring or alerting about tenant A or B has suddenly increased their electricity usage by 10 times over the last month. There's something that's wrong with faulty wiring. Um, they've plugged something in that they probably shouldn't have plugged in, and they've started a Bitcoin farm or you know, various other things at that point which which you'd have no visibility on because you're effectively you have all the data, but none of the ways of accessing that data easily or uh interpreting that data in a way that's actually useful. Never mind then, as I said, the next step of then automating solutions to problems as they come up. I think the other side of things as well is there are other software platforms that will allow you to do those sorts of things. Uh, of course, it's it's a relatively crowded market, I would say. But what they generally speaking are is dashboard uh platforms. So they will allow you to graph or chart data. They're not generally speaking very good at the automation side, but at least you can see the data in one place. But what they don't have is any kind of understanding of the industry and kind of um the problem that they're solving. They're just giving you a toolbox and then basically saying, here's the toolbox, work it out yourself. With our platform, that's quite a lot different to that. We have our background as a company is in building management systems, is in mechanical engine engineering, uh, mechanical and electrical engineering. And so with the way that we've built our platform, is very much with those solutions and those problems in mind, and to provide you basically a good out-of-the-box experience. And more than that, it is software as a service or software with a service. So it's not as if you're just throwing a login and then told to get on with it. That we have a team and we have experts in-house that understand these systems, understand the sorts of problems that you might uh come into and can help you use the system, set the system up, maintain the system. Um, so uh quite a long way, quite a long form answer to that question. But um that that's the kind of differentiator of rather than just being kind of a toolbox that you have to set up yourself, it's much more of a service, and we we we come with the right solutions to start off with for those those class of problems.

SPEAKER_00 10:16

Does it look like a combination of hardware experts and software experts working together as a team serving the client who who wants to install the sensors, connect them to the software system and see everything in one place, and also maybe to to operate uh some devices?

SPEAKER_01 10:33

Yeah, absolutely. I mean, I think with the way that the the the company where the company came from, it came from not being a software company, it came from being a BMS company, it came from being um mechanical and electrical engineering company doing those installations and where it then entered the software space and and employed myself and some others to help them build that offering, is that they didn't find anything on the market that really solved the problem. It it solved a software engineer's understanding of the problem, but that isn't the same thing as what a mechanical and electrical engineer would say, these are the important things. Um, and a lot of the other people who come up with solutions, generally speaking, are very what I would what I call software development brained. Of um, they look at problems in a very specific way and they come up with, generally speaking, consistent solutions which appeal to a software developer, but not necessarily a useful to an end customer.

SPEAKER_00 11:27

And I believe we spoke about it on this podcast many times with the guests that joined me on Backstage Tech, that a great product offering starts with deep understanding of the industry. Here in this particular instance, we're talking about the hardware, we're talking about the sensors, and then building a solution that specifically solves the problem that is well known and well understood by hardware engineers.

SPEAKER_01 11:51

Yeah, I mean, I think what it's very tempting to fall into is building for your understanding of a problem. You can get, I suppose, lucky just by dumb luck of coming up with the right solution. But generally speaking, to build great products, you, as you said, you need to have a deep understanding of the problem that you're actually trying to solve. I think, especially with in the the modern age, in terms of how accessible building products has become, things like cloud code or or open AI, the barrier to entry is much lower. So you really have to come up with the right solution. It's not just about coming up with a solution. It needs to be the right solution.

SPEAKER_00 12:25

Can you tell me about the clients that are working with Origin these days?

SPEAKER_01 12:28

Yeah, so uh some of them uh we need to be a little bit careful about because they're not everybody is happy about being named. Um, but what I can say is we have uh a major broadcaster in the UK that's working with us, um, the NHS, several major commercial tenants as well, or tenant management companies that are working with us. I have to be a little bit, as I said, um furtive in terms of naming them, um, because sometimes people can get a bit upset about that sort of thing. But yeah, uh so those are sort of uh um a selection of commercial space management, I guess, would be the core of that.

SPEAKER_00 13:02

Thomas, you mentioned NHS, the national health system in in the UK. I wonder what would be the process for for origin to start working with with such a client.

SPEAKER_01 13:12

Sure. So I think you have two routes to do that. You can work directly with the central kind of national body of the NHS, NHS UK, or you can also work with um the more distributed uh organizations, so the individual trusts that are sort of the regional trusts around the UK that control NHS offerings in that particular part of the world. So the we've kind of taken the approach of working with the individual trusts, and generally speaking, to start off with at least they tend to be an individual sales pitch to a certain extent. I think a lot of um certainly the UK, right? A lot of the mechanical and electrical um engineering industry and the BMS industry is there's a lot of money in it, but there's it's quite small in terms of the number of people that are in it. So you can spread by word of mouth quite effectively. There's also specific publications um that are targeted at um NHS estate managers uh and people in charge of estates generally in the NHS, as well as specific networking organizations as well. Um, so you at least the way that I've seen success previously and work with many NHS trusts over the years is you kind of take a bit of a hybrid approach of generally speaking, you find somebody who has a problem, you solve it well, you work well with them, um, and they will generally speak be quite willing to then promote you internally. All of the estate managers talk to each other, and all of the people in charge of estates talk to each other, and you can spread by word of mouth quite quickly at that point. Um, I mean, in terms of the the shape of our solution is also quite useful for the NHS because it reduces the number of external contractors that they need to hire in, because we can kind of do everything for you at that point. Um, it we are also pretty flexible in terms of the way that we can structure the fight the financial part of it as well and the commercials. Um, generally speaking, with the way that the NHS functions, they have annual budgets. They don't really like operational expenditure, they prefer capital expenditure because the budget this year doesn't necessarily predict the budget next year. Um that's not enormously unusual, but it's particularly acute in the NHS in terms of the way that they work. So what you can get then at that stage is uh some people will only want payment up front, some people only want monthly payment, whereas you know, we're pretty flexible of what you actually might find is that people will pay for all three years of a contract initially, because that's what they have budget for that year. They can then go through, prove the return on investment, and then they can get it to get it added to budget in in two and a half, three years' time at that point, with either an uplift or an expansion of the services. I think the other compelling part for Origin in the NHS is because it's a platform that effectively runs itself with a service attached, it means that they need to understand how to use the platform, but they themselves don't need to manage the platform. Generally speaking, whilst there's quite a lot of budget for these sorts of things, they don't have a lot of staffing that is admin staff, basically. Um, so anything that is more self-run, self-serve, is or sorry, is more self-run rather than being self-serve, is generally speaking popular at that point because they haven't got to worry about that or commit resources to that.

SPEAKER_00 16:26

I wonder what role do you play personally when someone like NHS starts uh working with origin, and let's say they may have uh specific requirements for maybe some workflows. Maybe they want to control some sensors remotely, maybe they want to show the data in some specific manner, or they just have a new sensor which you never connected to the platform. How what so I think it's two questions combined in one. Uh, how do you deal with this? And what is what role do you play personally?

SPEAKER_01 16:55

Sure. I mean, I I think again, one of the ways that Origin distinguishes itself from the rest of the market is you know, a lot of people will say we support the sensors that we support. Some of them will actually go so far as they will only support sensors from specific manufacturers. Um, our approach has always been whilst we have manufacturers that we know and love, uh and that we um will try and push up those products because we trust them, fundamentally we are happy to hook up pretty much any sensor as long as you know we think it's not terrible to the platform. And the platform is designed to be sensor agnostic and manufacture agnostic. So from that perspective, we're pretty flexible and we're pretty capable in terms of what we can do. And again, that would be one of our selling points, as I said. I think the most effective roadmap that you product roadmap that you can have is one that is very heavily influenced by customers. And I think it's an important part of my role, maybe making it back into one question, important part of my role as uh technical director or or CTO, only the product side of it, to be able to talk to those customers and understand the core of what they the core of the problem. Customers will often come with asking for a solution with a problem formulated in such a way that they kind of have already come up with a solution. Right. Sometimes it's the right solution, and sometimes it isn't, and sometimes it's a solution that will work for this iteration of the problem, but not the next one. And I think that's where my role often comes in to try and kind of analyze that as a problem, analyze the solution potentially, and try and make it as generic a solution as possible whilst still actually solving the problem. That not only benefits Origin and us from that perspective, because we go, okay, cool, it's a new feature that doesn't just solve this specific issue, but actually might we can design it in such a way that it solves a myriad of similar issues as well. But also it's better for the customer too, because again, they will probably benefit from that. Um, in terms of, I mean, give you an example, we had one um NHS customer who the way that we were demonstrating uh pipe temperatures, and so it's incredibly zell and dry. Um, but that the reason why it's important for the NHS is that in the UK um there are some pretty uh stringent rules around um something called a Legionnaire's disease. So it's a bacterial disease that basically the bacteria can uh proliferate in pipes or in air conditioning that are not flushed or cleaned and are sat at a specific temperature. So it's a it can be a big problem in um hospitals in particular with cold water taps, whereby if nobody runs that tap, then Legionnaires uh bacteria, legionella bacteria can can um grow to the point where it might become a danger to health. And obviously in a hospital where you have people who are already sick or might be immunocompromised, et cetera, that can cause a big problem. There are specific regulations within the NHS around controlling that, and so you can get fined or, you know, worse at that point. So it's it's a real point of focus. But we had one customer who wants to be able to see, didn't actually want to use our very specifically developed feature to alert around uh Legionella risk, but wanted just more of a general one-page view of all of their tap temperatures across all of their floors of the of one particular building or all of their buildings. And he came up with a very specific solution, uh, which was basically a widget just to do that. And I was like, we can take this as feedback. We're probably not going to implement a widget which is here is tap temperatures over an eight-floor building. That's probably not that's probably not a thing that we're going to implement. But we had a bit of a think about it. Instead, what we did was we developed a feature which could take basically could pivot data over any other piece of data and any other piece of metadata in our system. So in this particular instance, it was filtered by a building with floors on one side and types of uh sensors on the top. But in theory, we also made the available um data around what room it's in, what building it's in, what's the site, um, also things around has it been tagged with anything in particular. So you can start then building a really complex visualization that is very specifically uh useful to a problem. The code that we wrote is very generically applicable and very multifunctional from that perspective. And then at that point, it that's arguably eight or nine features in one at that stage rather than just one point solution.

SPEAKER_00 21:15

So it sounds like it all boils down to building a solution that is one, sustainable and two, universal, which which gives you higher ROI in the log run, right?

SPEAKER_01 21:26

Exactly, exactly, yeah. And and and you still need to make sure you actually solve the problem, but that solution, you know, don't try and limit yourself to just solving one problem with it.

SPEAKER_00 21:34

Let's talk about AI in engineering, and I think even being more specific about AI in engineering management. And with this large paradigm shift in the industry, has it changed the way how you judge the process and the deliverables of software projects?

SPEAKER_01 21:50

There are many different opinions. I think my my feeling is it it hasn't really. I think the way that you judge an engineering team or a Engineering department. I don't think I came up with it, but the way I've I've always thought about it is uh you've got three different categories that you judge an engineering team by and sort of uh three points of a triangle if you like. And um, you want to try and have balance across those three points. And if you try and move more in one direction, generally speaking, pulls away from the other two, or at least it's it's hard to try and excel at all three of those things simultaneously. Um, so the first one of those would be in terms of quality. Um, so that can be code quality, it could be architectural quality, it can be basically the technical excellence of your solution. So that might be uh a beautifully um decomposed microservices for a platform, it might be uh a very elegantly designed uh multiple layers of uh failover for a highly redundant system, that sort of approach, as well as being sort of a beautifully written code line by line. The danger of overfocusing on that, however, is you then move away from how useful that is. So if you have something that is beautifully decomposed into a whole bunch of microservices that is, you know, to a software developer, a thing of beauty, or something that is got seven layers of redundancy and it doesn't need either of those things, that's where you're kind of moving away from then the second category, which would be sort of accuracy or precision of the team and what they're what they're producing. So that's that's about solving the problem as it is. So that could be that the feature actually solves the problem, could be according to the specification, or it could be that you're failing to be accurate or precise because the specification is wrong and nobody has worked that out at some point previously. And if you're overfocusing on things like architectural design, but then you're not able in a way that is irrelevant to the actual end solution, then you're just wasting time and wasting energy at that point. And generally speaking, moving slower as well, which kind of then relates to the third point of the triangle, which is then velocity, which is probably the easiest to understand in that that's just how quickly you're able to develop and ship code. Those three things are, if you like, naturally have tension between the three of them. You can do all three of those things simultaneously to a greater or lesser extent, but generally speaking, if you start focusing on one, you pull away from the others. And what I think we've seen very clearly from well, I think I think that nobody will argue with is that what AI assist encoding and LLMs in general have be enabled us to do is dramatically increase the velocity. We're able to deliver much more quickly, we're able to deploy much more quickly. I think the danger that I've seen is that you start pulling away from either the quality side of things or the accuracy and the precision side of things. I think every engineering team will find that they will have a different version of that playing out because you'll have different characters in the team that will be more or less focused on quality, that will be more or less product focused and therefore be doing better at the accuracy and precision side of things. But I think what you do need to be very careful of is is as a somebody who's in charge of those teams or in charge of multiple teams, having a very clear focus on yes, we're moving faster, but to what end? You can move infinitely quickly, but if you're going in the wrong direction, that's not a useful, that's not a useful thing that you changed at that stage. So going back to your original question, sorry, that was quite a long uh preamble to it. It's not changing the principles, but what it has changed is a lot of the tools and a lot of the pressures which a team is under in terms of um you know those those three parameters at that stage.

SPEAKER_00 25:26

So, from your perspective as an engineering leader, when this trade-off happens between the three peaks of the triangle, how does this trade-off affect how you deal with customers, users of the product, or stakeholders? Let's say if you build a product as a service company, it can affect it in multiple ways.

SPEAKER_01 25:44

And I think it depends on you know what is your intention behind that change. The danger that you can fall into is uh, as I think probably everybody will be seeing from their stats. I you know, I've seen from from from stats that uh not necessarily of my team, but but of stats that I've seen, the more the faster you go, the more mistakes that you make. That's it. That's I'd say that's generally true. That's not a thing specifically about AI, but given that how much AI has juiced how quickly you can go, I think there's probably also something about AI as well, and just in terms of the obviously uh hallucinations being one thing, but just the offloading too much of the thinking to um the LLM and you know the quality of code reviews going down by that point. Or um, if you're going more of an agentic route in terms of code review, possibly at that point, just the AI not understanding all of the particularities or the um context um of a particular product decision. You then have potentially quite a tricky situation whereby you might be losing a nine or two in terms of uptime. There might be more bugs coming into the software platform, which for software as a service, I think there's long been uh uh an expectation that there will be bugs. What I think you can't get away with is that's not an explanation that you can give to a customer as to why their system's not working the way that they need to. I think customers are willing to be um understanding to a point, but you can get yourself into a very difficult situation if you try and move too fast, whereby you'll have to necessarily start looking for excuses at that point if there are more than whatever the imperceptible line of acceptable is um at that point to customers. And if you then start saying, Oh, we're really sorry about that, uh, you know, due to AI, et cetera, um, which you've seen, I think I don't think I think there'd be there haven't been that many companies that have straightforwardly said that, although I think some of them have said that when there's been a really horrible mistake, generally speaking, with marketing and things like that. There's certainly the strong implication that things are moving much faster, therefore we're breaking them, as as the classic tenant goes. You might then be um creating an unintentional uh market force that products that move slower but more consistently are seen as higher quality at that stage, and that you start getting a stigma that gets attached to um AI-assisted development. And I don't think that's what anyone in the software industry wants to have happen because we see this as an incredible tool that can make us go faster. So, but I think it's a tool that you need to be responsible with. When you get into a situation whereby there are more problems in production, you need to be able to explain that in some way, shape, or form. And I think the bigger thing for customers is you want to be able to demonstrate that you have solved a root cause issue that means that it won't happen again. And you need to make sure that you're improving the systems in place around code review and around deployment review to make sure that it doesn't happen and still be able to move more quickly at that stage.

SPEAKER_00 28:53

And you certainly cannot blame Claude or Codex for these mistakes, because it will make no sense to the customers.

SPEAKER_01 29:00

And I think if I can interject, as well as it would make no sense to the customer, it would suggest that you are not doing exactly what I just said around you're not correctly code reviewing, you're not, you don't have the correct processes and regulation in place inside of your own business. And I think if you find yourself wanting to blame uh Claude or Codex for bugs or outages, that probably should be an inflection point for you to then think about actually do we have the right processes in place? Do we have the right um safeguards in place um for AI? It's moving so quickly in terms of not just your own teams using it, but also new features, new capabilities coming out that it can be difficult to keep track of that and to work out what are what's the safe way of using these things as opposed to riskier ways of using them.

SPEAKER_00 29:47

Exactly. It's it's all about having the right processes for the engineers using AI. But can we speak about the opposite a little bit? But there's such a thing as resistance among the engineers who are not ready or they they hesitate or just don't want to use AI in engineering. Have you heard anything about this?

SPEAKER_01 30:05

Yeah, no, absolutely. I think the engineers that I've I've worked with and and uh you know people I've asked this question of, I think generally the the sentiment is engineers aren't afraid of trying it. And I think it's where a lot of the resistance, the reluctance comes is if they don't have a good understanding of how to use it to start off with and they get a bad result or they get a uh a result that doesn't conform to what they're expecting, they can kind of uh pigeonhole that at that stage of saying, oh, it produces low-quality solutions, etc. etc. Because there are skills that are specific to optimal use of particularly things like um agentic AI and things like that. Um I think I guess the problem is is that those skills are also changing and moving forward as well. Um, but I know certainly with some of my own team, they've had mediocre probably initial experiences using LLMs. They felt, I mean, it especially will be more of a problem if you've kind of got more of a uh senior developer who have a bit more opinionated about the uh solutions they will come up with, especially if their velocity increases and quite as attractive to them. But generally speaking, there's a learning curve to using this, and so you it's more of a thing of then gently encouraging them to maybe give it another go with a bit more of a specific parameter, maybe giving them some guidance about how to use it. I think that's again a useful thing for somebody in engineering manager to be able to guide, is understand how people who use AI well use it, and then try and cross-pollinate those ideas across the rest of your team. You still want room for creativity and people trying things because otherwise it will become very static. And as I've just said, the skill set is moving very quickly. Um, but if you try, don't force it down people's throat, but ask them to try things and give them specific steps to attempt. I think you can really reduce a lot of that resistance. I think there's probably a second kind as well, and I think we've seen this more in longer standing developers, kind of more of the old guard. I think there probably is an element of they have a set of skills that they've developed over a long period of time that they're very happy with. This sits outside of that skill set, is different, and I suspect to a large extent they probably don't see the reason for using it. I think if you can try and encourage those people with a much more evidence-based approach, that will probably work better. I think also those people, generally speaking, tend to be in charge of legacy parts of a code base as well.

SPEAKER_00 32:27

Oh, yeah.

SPEAKER_01 32:28

They have been there a long time, therefore they have more of the context, they might have even written it to start off with. So therefore, they are the guardian of that kind of legacy, uh, less less green field code. And actually, AI, generally speaking, doesn't handle that as well. So, again, there's probably a bit of a negative feedback loop that they're experiencing in regards to they're in charge of legacy code, it's less good at legacy code, therefore, more of the old guard are a bit more resistant and reluctant to get more to get more engaged with that. As ever with these things, it will depend on the particular particular characters that you have in your engineering team and how they interact with each other as well.

SPEAKER_00 33:02

Yeah, I absolutely agree. And the point that you just shared regarding the legacy project. Let's say a good friend of mine, or I would even say one of my best friends, he's a software engineer. And the other day I had a call with him and I asked him, How are you guys using AI in your team? And he said, Oh, listen, it's been an old code base, and the way it's written, there's no way we can use AI like we can use in the Greenfield projects, for instance. So yeah, I absolutely agree. It's all based on, of course, it's based on personality, on the character, but also on the experience, maybe some unsuccessful experiences, which leads to this sort of level of trust or or the opposite.

SPEAKER_01 33:44

Yeah, and I I think that's where, as an engineering manager at any level, you need to be looking to try and formalize people's professional relationship with AI and try and give them guidelines that they should work through. And that won't just help them to adopt it, but it'll also hopefully help your quality, it'll help your accuracy as well, um, and help to reduce, uh, should we say, more of the temptation of uh asking Claude and then just shipping it straight away at that point if you've got some level of control over the uh control over the output.

SPEAKER_00 34:16

Thomas, you mentioned velocity multiple times. And with the velocity we can get with AI assistant engineering and what what teams can achieve with it, we can actually replicate products over a weekend or within weeks, and the number of features we can build is just it it's become just crazy. Um, how do you think SAS companies are going to defend themselves?

SPEAKER_01 34:42

I think this is a really interesting point. Um, and there's been a lot of talk about the you know, the SAS pocalypse, etc. I think people are maybe with a lack, I would say, in the market at the moment, of purely vibe-coded or completely novel competitors, these larger companies, I think people are realizing it's maybe a little bit more complicated than just I will claude code my solution and put it on the market and then I'll become a millionaire overnight. However, I think inside of companies in terms of internal tooling, I think that's a there's a different story there whereby I think people considering, you know, especially for point solutions. Um, if you know there is I've got a I've bought a tool and it costs two pounds a user per month, can I actually replace that with something that I can I can code myself on a weekend with with Claude? Maybe. Um I think those sorts of point solutions, I would say in trouble. Um I think you need to be pretty compelling in terms of uh, well, generally speaking, the way that they've managed to get traction in the first place is you know, their UX is really good, they're quite cheap, um, or possibly have a good free tier that they're, you know, you can then convert to paying customers, or the problem that they're solving is is awkward to solve. I think, especially for that latter category, those those sorts of point solutions can be in a bit of trouble because with Claude you can solve a complicated problem a lot more easily, or or solve you are not solving the tedious problem, you're asking something else to solve the tedious problem, right? But then you don't have to pay for it ongoing. So I think those sorts of platforms are software point solutions. So I think there's actually a big opportunity within companies to try and look at those sorts of tools, that that sort of tooling that they're paying for at the moment and potentially replacing that um with something that they've built internally that they then own the code of. I think as ever, it just needs to come to a trade-off in terms of great, building the product is really cheap. Maintaining the product, on the other hand, is arguably just as expensive as it always was at that stage. Or at least it requires as much human intervention, you know, around have you covered all the edge cases? You know, are there bugs? Are there um, you know, what's the hosting situation? How um how does it fare from a security point of view? These sorts of considerations, which I don't think uh Codex, Claude, any of the LLMs has not magically solved conceptually. It's just made it easier to come up with a solution. I think what's more interesting is for the larger, if you like, non-point solutions, the the big SaaS companies, you know, things like Atlassian with, you know, their kind of JIRA confluence um suite of features. I think what I see happening in the industry is a big reconciliation between previously companies like Atlassian really held the whip hand um in regards to dealing with their customers because they're like, well, you need a way of managing your software development process. I think there's not that many people that will say I love Jira, but it does solve a problem for companies. And it's at the moment, it's a safe bet for companies to say, right, we can have our Argel process or, you know, whichever variation of software development cycle management you want, and we have software that will help us manage that. Now you look at the sort of money that you have to spend on Jira and Confluence and the way that their commercial model works, and you go, actually, we are spending an extraordinary amount of money on Jira and Confluence. Maybe we can vibe code something that actually is more of a specific um fit for our requirements that we then own the code of. And you know what, we're spending so much money on Atlassian, maybe it is worth then the maintenance or ongoing development costs. I think what you're gonna see is that at some point those sorts of SaaS companies are gonna realize that and they're gonna have to aggressively review their commercialization models to try and compete and be still be a better bet than your vibe coded internal tooling. I can't see how the existing Atlassian model, and sorry, I've picked on Atlassian here because it's it's it's it's the from my own personal experience using Jira for nearly a decade, it's it's the was always the pain point when it came to budgets of great, we want to add this new capability to Jira that doesn't think that doesn't exist there automatically. We have to pay for that plugin for every single user in the system. I just don't see it's an incredible money-making um engine for for Atlassian, but I can't see how that survives vibe coding uh software development tools because you're you're you're killing your own market competitivity at that point. Um there's is a new class of challenger basically that that SaaS companies are gonna have to realign to be able to compete with.

SPEAKER_00 39:18

Yeah, I think a very strong point is that building a product can be really cheap, but the maintenance costs can be still as expensive as it as it used to be. There's one thing I'd like to add is that building a product, and I'd love to hear your perspective on this, but building a product doesn't automatically mean building a business.

SPEAKER_01 39:37

No, absolutely. I I think you can have, and I think we will see that more when it when more um vibe coding applications get traction. I think people will come up with maybe a great point solution or a great, great software suite that you need a whole range of other skills to actually be able to push it out there. Never mind be able to scale it subsequently. So it's not only especially if you lean heavily on the service side of things as well. The software is, you know, I wouldn't say it's it's not the important thing because obviously it's quite important in software as a service, but the way that your customer feels and thinks about using the product often has a big impact in terms of retention, in terms of um expansion as well. Um so not just retaining the customers you have, but also getting new users. And if you don't get the service element of that right, and if you're not able to talk to new customers via marketing, then you can have the best uh product platform in the in the universe, and it really doesn't matter at all.

SPEAKER_00 40:31

Right. And then whenever your customer has a problem, just figuring out the UX because sometimes it happens. Who are they going to have a call with? Who's going to explain?

SPEAKER_01 40:41

I'm talking about the customer service, the absolutely, and I think that also then feeds back into the low barrier for entry for creating new software. If if you have a great platform and a great idea, there's very little reason now why a capable customer can't effectively take your idea and build their own better suited alternative internally at that stage. And yes, they still then have the issues about well, how do they maintain the support for that? But if you're not supplying the support already, then effectively that's a problem that they already need to solve, even if they pay you money for the privilege of having that problem. I do very much see that um, whilst that's always been an issue in terms of the quality of service and around making sure that if you're charging a monthly subscription, you need to be providing value with that. You need to be able to demonstrate return on investment for those customers. It's even more of a problem now with um the advent of vibe coded solutions, or even not necessarily good vibe-coded solutions, but the customer thinking that they can replace your product. That can still result in lost revenue at that point, and the customer may still not come back, um uh uh uh even if uh their solution turns out to be not a good one.

SPEAKER_00 41:52

But I think I can also flip this into the positive side, getting back to the beginning of our conversation today when you said that uh origin is an expert in hardware uh sensors and understands the problem very well, and that you just didn't have the right solution in place, so you decided just to build your own. Not not a vibe coding solution, but a professional, professional engineering product. But imagine someone who already has, let's say, expertise in healthcare or in finance and knows the problem very well and has a strong reputation with these new tools, and let's say it's always easy to start with a with a point solution just to solve one problem and then scale from there. I think the speed, how you can just demonstrate it that this problem exists, we understand it, we came up with the idea how to solve it. Here is the proof. I think this this is just incredible.

SPEAKER_01 42:48

Yeah, no, absolutely. I mean, I think in terms of the way that you can get to a proof of concept um is uh transformational for the industry in terms of the number of different shots you can take, basically, and and things that you can try before putting serious money behind uh an engineering team. I think I would say though, there is a gap, at least currently, from being able to get from an idea to a proof of concept or uh an MVP to something that is then production ready. I still think that where we are at the moment is you still need engineers to be able to allow you to do that. You might need fewer engineers than you used to, but you still need somebody who understands what, you know, if we go back to that triangle, you might be able to, as a non-technical founder, you might be able to have a really good understanding about that precision or accuracy in terms of we are solving the problem or not solving the problem. You might, well, you might then also be able to do the velocity as well in terms of lipoded solutions, but what you're not necessarily going to be addressing at that point is that third point of the triangle, which is then the quality. That will intrinsically then affect your velocity over time. I think uh just anecdotally, you've seen that a lot with kind of completely non technical um founders who have tried to completely Vibe code, that you get to an MVP very effectively, and then you start trying to move things into production, you start having issues at that point with all of the kind of vibe coding platforms that are out there. That's where you start needing to have somebody who's a bit more of an expert from an engineering quality point of view and has an understanding of those fundamentals. What I would say though is if you empower them with AI, then obviously you can speed them up quite significantly. We're at a point now with um AI whereby this is probably as good as we're ever going to get it from a cost perspective. OpenAI and Anthropic are pretty heavily subsidizing uh how we use AI at the moment. That's not going to last forever. I mean, I think if you look at some of the financials that have come out recently leaked from OpenAI, you know, they're making money on tokens, but their margin's not amazing. Um, so the speculation is that they're running at about 40% gross profit margin, which is making money on tokens. So, you know, that's that's a lot of people have said that they're not making money on tokens, so that's positive. But if you look at that from a gross profit margin perspective, a traditional SaaS company you'd be looking at 60, 70, 80%. So there's a lot of um financial assumptions that are built into their funding at the moment that suggest they're probably going to want to be able to make more money off those tokens. We've seen there's been some pretty crunchy landings for a lot of companies when they've moved from a subscription-based approach with, depending on how you do it, sometimes functionally infinite tokens to a token usage perspective and people getting some pretty large bills as a result of that. So I think from an engineering management perspective as well, you need to be, you can't just give your engineers a free-for-all, even if you're not paying for tokens yet. You do need to be able to kind of monitor and understand what that token usage cost is going to be so you can plan ahead in terms of budgeting and also in terms of making sure that the money that you will be spending per token is being spent on the right thing. You know, there's not developers that are solving problems that they care about or imaginary problems, that you're actually spending that money on things which are impactful to the product and the business as well, and making sure that you can analyze that return on investment.

SPEAKER_00 46:08

Yeah, which reminds me of Uber who spend their annual budget just in four months.

SPEAKER_01 46:12

Absolutely, absolutely. I mean, I I I was speaking to a couple of ex-colleagues as well, and they've said that one in particular gave an example whereby he was having a conversation with his CTO, and he works for kind of a not technically a tech company, uh, but something which a lot of what they supply is is kind of software focused and what their token usage was for a month. And I still think that he's probably off by a factor of 10, and he misquoted this to me, but he did say that he was comparing with his CTO, and they'd both used 36 billion tokens in a month off a 400 pound subscription. And like if you look at the token costs, even in an optimistic, that is, you're talking about 10,000 pounds of tokens on a 400 pound subscription, they're gonna have to limit that at some point. So I think uh that's not to say that the the world is gonna fall in at that stage, but you'd need to plan accordingly uh about making sure that you know, were all of those 36 billion tokens uh actually utilized on something that's probably core product? No, because at the point where they were being used, it was a 400 pound subscription. So again, it's just around having that kind of oversight and being able to monitor and incentivize good token usage as opposed to wasteful token usage at that stage.

SPEAKER_00 47:24

If you can give just one piece of advice for engineering managers in this era of transformation and software development, what would it be?

SPEAKER_01 47:32

I would say don't be afraid of taking the money on the table that's that's there at the moment. But you need to be aware that we have not yet reached the end point of how AI is going to affect engineering. So you need to be being very careful about how you plan going forward. Um, the way that it is now won't be the way that it is in a month's time, probably never mind six months' time, never mind a year's time. So having a good understanding of how your engineers are using AI and what what inputs they're putting in and what outputs they're getting from that is really important to understand what your return on investment is from that, and from the cost of uh running AI tooling.

SPEAKER_00 48:06

I think it's a great point. Thomas, thank you so much for joining me today on Backstage Tech and thank you for for this deep conversation. Pleasure to be here, George.

SPEAKER_01 48:15

Thank you for inviting me.