Exploring the Future of Remote Work, AI, and VR in the Development Industry

Let's go. So you know what I just realized? This is a first face-to-face podcast for me. So, you know, you're taking me like my podcast virginity.

Well, I hope that this is perhaps something small that will lead to a big development, you know, in terms of podcasting and that you will be able to get some, some big names on board as well into your podcast. So hopefully— Thanks for that. That'll be in 2024 sometime, hopefully.

All right, so give us an elevator pitch. Who is Martin?

Sure, so my full name is Martinas Kvaksas in Lithuanian, but on LinkedIn you'll find me as Martinas Kvaksas because of the funny Lithuanian letter Š. But in a nutshell, I solve web problems. I'm good at problem solving. So if you have a web project that needs some improvement, needs speeding up or needs expansion, scaling, I think I could— I would be quite good at solving any of those problems.

Is there a common problem you face as a, you know, as a full stack, right?

At the moment, I am a full stack. But in my heart I'm a backend developer.

So if someone gives you a project, you're leaning towards the backend?

Yes, yeah, that's, that's where I find joy, working on the backend, whereas working on the frontend, um, I find it a little bit less rewarding for some reason.

Is it technology-based? So why?

I think it's because frontend is a little bit more visual and you need more attention to detail in terms how things look and how they are arranged. And I don't think I have an eye for that. But what I do like is transferring information from one point to another point, you know, transforming that information, doing something with it, you know, and then you can also talk about making API calls, integrating things. And I just enjoy that kind of stuff where you exchange data between things and make sure it works and make sure that it stays uptime and it is efficient, it doesn't use too much memory.

Okay, so do you have a common problem which comes up? So if you think about, you know, your career, you had a lot of different positions which either are backend or full stack, I presume. Is there a common theme you face as a problem or a challenge to solve?

Sure. I think the most common probably would be where a project starts out small and you create your database schemas for that project, which is still a small project and it works perfectly fine for that time being. And then a few years later, the project keeps growing and growing and growing. And eventually that your design of the database hits a bottleneck. For example, you know, you didn't establish foreign keys somewhere, or there's some indexes missing. But because back then, for example, you had a few thousand rows, it was super fast. But now you have a million rows and it's all of a sudden it's very slow. And why is that? Oh, because there's an index missing. So that is probably the most common theme that I've encountered.

Legacy systems, effectively, the scale is either organic or, you know, maybe funding induced, but you suddenly see your system going from 100 to 1,000 to hundreds of thousands, and all the poor decisions, architectural decisions, comes out. I actually have a story to share which is literally that with IdeaDrop. It was built in India, startup, no surprise, got built in India.

It was outsourced.

Outsourced, exactly. So I got billed and it got brought back to UK. It started getting traction, it's getting sold. It's seeing around maybe 5,000 a day. And one of the clients came on board, which was a UK government police force. And then it was Ericsson as a business, which brought like 100,000+ people instantly. And it was a, the solution effectively has a feed, think of like Facebook feed, LinkedIn feed, and, and it just stopped loading, like literally stopped loading. Like the next day we come in the office and, hey, we have a problem, just times out.

Yeah, you're getting request timeouts.

Yeah, all right, that was fun.

And, and one thing I wanted to say as well is that, um, outgrowing your initial database design and all of a sudden your application perhaps— well, not, not suddenly, but over time your application getting slower is not necessarily a bad sign. It just means that you're growing and you need to go back and address any technical debt that you might have, which in this case is architectural, um, database design.

It's what I call the good problem to have.

Yeah, exactly right.

It's not like we're losing clients, oh my God, what we do, that's a bad problem. But it's like we have too many of them. Yeah, that's a very nice problem to have. You actually mentioned technical debt, um, in your maybe current company or companies before. What is the healthiest picture of managing technical debt you ever seen? In terms of actively working on it, or what you would presume is a healthy picture of, of a company or a team, you know, uh, dealing with technical debt or managing it.

Um, so I think it depends a lot on how big and how old the product is. If it's a newish product and if it doesn't have many customers, for example, then it's probably safe to assume that technical debt might not be that high, right? There might not be that much of that to address. But if you have a, if you have an older product with lots of clients and then perhaps you allow the clients to request new features and things like that, and perhaps a client would come along and say, well, we like you and we want to use your product, but you have to implement this feature and then you go ahead and do that. So for this kind of stuff, technical debt is a lot worse. And what I think probably for us, where I'm at right now with my current company, which we will discuss later, I would say probably the healthiest thing would be 50% of development time that we spend would be addressing technical debt at the moment.

That's a lot.

That is a lot. But I don't think, I don't think that would be ongoing full-time. I think maybe that would be 6 months, maybe 12 months. Of that, and then afterwards that should be less.

So it's almost like, uh, you just want to pay off the debt exactly much, much quicker than, than deal with that. So 20% is quite often I see is, um, you know, you have a time as a team, you know. So effectively it's one day a week, you know. How you use it, is it actual day a week? Is it more, you know, two days, uh, two weeks sprint? Or is it You know, maybe you go 3 months without addressing it and then you have like full 2-week sprints for technical debt. Do you have an opinion what works in that sense? Like, what process can manage technical debt quite efficiently?

I think it has to be driven by developers themselves because developers will have a good picture of what they think is out of date and what needs improving and any quick wins. That might be had. And because for— from what I have seen previously, and now this has improved, but previously you would have a product team saying we want to implement these features XYZ, and as developers saying, well, actually we want to spend some time and clear off some of these old, you know, things that we wanted to improve for a while. So there's what be a clash between new features and technical debt. So going back to the question, what was the question again? Sorry, I don't remember.

But anyway, what was your opinion about what process can manage technical debt effectively and efficiently?

Okay, so yeah, so I think it needs to— there needs to be strong involvement from the CTO to perhaps sell the value of clearing and addressing technical debt. I think that there needs to be a strong input from that, um, because as, as developers, you might not have that much, um, influence in terms of what goes next in the next sprint.

I really like that. Yeah.

Um, so I think the healthiest picture would be having a CTO who has been hands-on himself and who realizes the value of addressing technical debt in time and before it builds up.

Yeah, I really like that because you need, you need a buy-in. It's, it's a top-down process. Like, if the business doesn't really understand the value of managing technical debt or paying it off, um, financially speaking, it's going to be very hard to compete to things like, uh, new features which had captured more market share, or just, you know, bigger clients. So it needs to come from top down.

Yeah, and the, the difficult thing about addressing technical debt is that unless there's a speed improvement, like a dramatic speed improvement, there's nothing to show, right? You do something, you pay off the debt, for example, you restructure some code or refactor some code, but the end user doesn't see any of that, you know, it's still the same, right? And that— so unless you do a massive speed up, they won't notice any difference. So what has changed for external eye?

Exactly, 100%. Exactly. I mean, for internal you might measure things like, you know, like from developer experience perspective. So if you have some type of, you know, health assessment of how the team feels towards the things they do every day, you know, this is annoying, I just don't want to touch that side or, you know, I'm happy to work on all of these things. It's challenging, it's interesting. If you capture that measurement somehow, you might see things changing. In the sense that you're getting a much better engagement survey type of results coming from that, which is internal, but that still leads to, you know, talent retention. Yeah, you know, talent attraction things. How do you guys work right now? Um, are you fully remote or are you hybrid? Are you like in office?

We— most of the team are fully remote and some are semi-hybrid. And by semi-hybrid, I mean it's not like two days in the office. It's more like one day this week, then one day the next two weeks. So it's by choice. So, um, by default we are all fully remote, but some team members who live closer to offices, um, have the choice to go in if they would like to. So at the moment we are fully remote.

So does the business have the same amount of offices before you went fully remote? Or is it just like you were always fully remote? It's not like, you know, COVID-induced remoteness.

So it actually was. So it's, it's, it's an interesting story. So the company that I work for at the moment is called— well, they, they were called Duty Sheet, and since a year and a half ago now, I think they got acquired by the Access Group, which is a big corporation. But I joined Duty Sheet with the intention that I will be the first and perhaps the only remote worker, because my plan was to move to Wales with my current girlfriend to live closer to her parents, buy a house, start a family, things like that. So the idea was I'll join Duty Sheet, I will work from the Leatherhead office until I buy a house in Wales and then be fully remote. So that was underway, and then COVID happened, and then our CEO had the foresight to go fully remote for everyone. I think it was a week or two weeks before any lockdowns happened. I was also a bit surprised by that. I thought, oh, everyone's fully remote, okay, oh, that's cool, that's nice. And now that I look at it, that was actually a really good call. Because, you know, the CEO wanted to make sure that we don't have the whole team with COVID because they were all in office and now everyone's out and there's no development going on. So it was like insurance, right? So COVID happened, everyone was remote for a while, and then everyone was still remote even after your lockdown eased up. And then I think another lockdown happened and eased up again, and we started hiring people in remote positions. So at first everyone was an office worker, but that went remote, and then afterwards we started hiring people for remote positions because we saw that it was working quite well for us.

Were you interviewing for that? That's, that's a very interesting point, and I do have a maybe controversial opinion about, about remote. But it starts with or it's around the fact that some people and I lean towards like a junior developers have real challenges of self-organization or self-management. Sure. So I think that understanding of how you structure your day, you know, what's important for that day, what's important in general, you know, being able to see a bigger vision of your role, how you plug in the team and things like that. That comes, you know, with experience and just becoming a little bit more senior. So when you get people in the remote position and they are quite junior, I feel like they're going to really struggle, you know, in just, just performing and gelling. And I was like, why businesses don't actually interview for remote capabilities? Because, you know, when you, when you do interviews for remote positions, you do interviews for like a soft and hard skills, but you don't really go like Did you ever work for a remote company?

Yeah.

You know, if you would, how would you deal with communication? You know, how— like just going through these common and main challenges of actually doing remote. So when you started hiring, did you guys do any of that?

I don't think we did. No, I don't think we did because one of the difficulties would be I don't think most— so most of the development professionals I don't think they've done remote work. Like, there was a minority who had. So, you know, if you were interviewing for a remote position back then, most of the people, I don't think, would have, would have had experience remote in the first place. So it's like a chicken and egg situation, you know, which one comes first. So I think that's why we didn't, um, uh, interview for any remote capabilities as far as I know. And but, you know, I think you raise a very interesting point in terms of like self-organization and, and, and how one would prioritize their day in terms of, uh, work. But then you could also ask the same question in the office, you know, how, how does one, um, prioritize the day in the office?

So that, that's, that's likely where the challenge is coming from. My perspective is like, if you work in the office, you likely gonna mirror what you see. And as well, if you're gonna just be effectively running like a headless chicken, someone will come to you and go like, I lost, like, you know, what's happening? And as well, you can easily, you know, sort of go in, maybe catch people in the kitchen and sort of maybe get shaped into, you know, a better day in that sense. And I got this one feedback which relates to this is, you know, from like a senior mobile developer and he joined a big company for a remote position. And he was basically, you know, onboarding process was weak, so he had a lot of questions. And he was bugging the same guy because he was giving the answers. And at some point he was like, I felt bad of asking the questions because I was like, I'm just taking all your time.

Yeah.

So he stopped asking questions and then he just went off on trying to onboard himself, you know, like, you know, going through Confluence, look at that information, because he was like you know, I feel bad asking all the questions, which I was like, that, that, that's a remote challenge. You wouldn't get that in office, you know, if someone would come in and just go like, how can I help? Yeah, just an opinion though, but that's, yeah, that's where my controversial opinion comes from. And as well, the gelling piece, um, how close you feel to like all the, you know, the, the other team members? Close.

Yeah, quite close, I would say, um, because we are quite— well, I think what helps is we are quite small in terms of our team. You know, we— so when we got acquired, we still stayed as a single team. And, you know, that is like 12, 15 people maybe. And apart from sales, you know, they do their own thing. But, you know, and the rest of the team after sales, like you have, you know, product development, quality assurance, etc., support, we are all like, you know, as a single team. And, um, yeah, it works really well. I think, you know, everyone's quite close, everyone's very supportive of each other. Uh, we are using Teams. We used to use Slack. I still miss Slack. I think Slack is awesome.

So yeah, Teams sucks, man.

Yeah, I know. I mean, even now, you know, uh, we've been using Teams for 2, maybe 3 years. I still want to go back to Slack. I, I love the custom emojis and stuff. Uh, but anyway, um Yeah, I don't know, we just, we gel really well. And one other thing that we do after we started going remote, sometimes we do these remote social things. So, you know, everyone goes on a call, for example, you know, everyone gets pizzas by the company, the company orders pizzas, and then we go play a game like Among Us or go play the Google Street View game. You know, where you go into a random place on Google Street View and you have to guess where you are. GeoGuessr, I think that's called. So we do little activities like that. And then every now and then we also do in-person meetups as well. So during COVID it was quite interesting to see someone who you haven't seen like for a whole year. You know, that person was remote and you've never seen them in person before. You only— well, you've seen them on camera every day, but you've never seen them in person.

It's different communication, isn't it? It's so, it's so old. Like, we talk every day, I see you on video, but then I meet you in the, like, face to face physically, if, like, it doesn't feel like I know you. It's just like that, that, that moment feels like, like, yeah, like we need to somehow reconnect or not. It's interesting. Um, so you, you're basically in the mobile, you're not distant, that's what you're saying?

Yeah, but I think it depends on the size of the company. I think it depends on the structure. I think if you had a— well, Axis is a very large company, but we are siloed as a product team. So I think that's why it works well. So just, I think it depends on the size of the team. If there were, if it were less granular and if we were a few hundred people involved in the whole of our product, I think that would be a lot less chilling. A lot less communication. But now, because there's only so few of us, like, I don't know, 15, I don't know, I would need to count them to get the exact number, um, everyone relies on each other quite a bit. So everyone has to step up and, and help each other. I think that's why.

So effectively, there's a, there's a number where the gelling is, um, quite doable.

Yeah.

And quite there.

Yeah.

And then you, you could replicate that, you're probably having less people but more teams. Yeah, allow the teams to gel. And then do you have any, like, like a team lead or like a team leadership who drives the, you know, the team gelling and the potentially those remote activities, the meetups? Or is it more like a team call?

Um, well, sometimes, sometimes it comes from within a team saying, hey guys, we should meet up, we haven't met up for 3 months or 6 months. Sometimes it comes down from the management saying, hey, we have a new financial year coming along. I don't know, is that in April? When does it start? It's like it starts on a different month for each, you know, company. It's quite funny, I think. Yeah. But it is the way it is. So sometimes, you know, sometimes it comes internally from within a team. Hey, let's meet up. Sometimes it comes, hey guys, it's a financial, new financial year. It would be good if you come into a London office and then, you know, we can go out for some pizzas afterwards. So it's both.

That's quite nice. I do like, I do like that remote but not distant situation and I do like meeting people and I feel like personal opinion, you know, hybrid, hybrid is the best of both planets. So you have, you know, people planet and you have sort of like a business planet. And, you know, the business eventually just cares about results and, you know, things getting done. So they care about efficiency and effectiveness of work. And, you know, people just want to have more life and less work. Yeah. In effect. So I think the value you got from remote is very, very tangible, isn't it? You were able to move to Wales. Yeah. Buy a house at good prices. Yeah, which is— I mean, if people understand London market, yeah, it's just ridiculous.

Absolutely ridiculous.

So, so, you know, you got a house which has enough space, it's a good house, uh, you got two kids as well. Yeah, you got a boy, 6 months old, and then 4 years. So you just being present, just helping the wife, and, and still getting, you know, effectively paid by a company, which is a London-based salary, right?

Yeah, uh, effectively, yeah.

No commute as well, forgot about that.

Yeah, no commute, that helps a lot. So a lot of time is being saved by not having to commute, and also a lot of money is being saved by not having to commute.

I think it's so underestimated how much money is saved. I live and I commute twice a week, and I pay basically £600 a month That's a lot of money. Yeah, that's a lot of money. That's basically a proper holiday for any given year.

If you were leasing a car for £600 a month, you could, you know, lease a very luxurious car. Yeah, like Tesla Cybertruck. Yeah, if you put it into that kind of perspective. Yeah, it's been mostly a blessing, you know, working remotely. Yeah, I get to see my children. I think yourself mentioned when before COVID um, you've— I do remember having this conversation when you said you would go to work to London in the morning and your boys would be asleep, and you would come back in the evening and your boys would be in bed already asleep.

Exactly, 7 to 7.

Yeah, um, and that sucked with me. Um, so yeah, and I take it for granted now, right? Because I've, I've been able to see my boys since they were born. And day one I was able to see them, you know, wake up and go and go to bed every day, pretty much almost. So I take it for granted, right? To me, this is normal, this is how it should be. Um, but also, you know, there, there are some downsides in remote working. So one of them, like you said, perhaps bouncing ideas off people in the office, you know, that is easier. Uh, you know, when you're face to face, that is easier to do, bouncing ideas off each other. Um, and then the other thing is I think there's a— there might be more distractions at home. Because you're working at home. Okay, so you're not on a meeting or whatever, you're doing some coding, and then your child comes along, you know, he's old enough now that he can reach the door and he pull it down, opens the door and comes in like, "Dada, dada." So, and you know, that is a distraction during working hours, which we try to minimize, you know, with my girlfriend. I think the ultimate solution to that would be a garden office. Because then that is enclosed space that is outside the house, but it's still next to the house. So that I think is my long-term idea to get a garden office.

It's a very experience-driven saying over there. I had the same couple of times, you know, in a meeting, kids walk in and I actually tend to find myself unable to concentrate at home if I spend, let's say, at any given week, I actually like to go to the office and just change the scenery, you know, change the offices. It just keeps me on edge. But let's say for whatever reason, you know, I have spent a whole week at home, I would most likely will go and do like a hot desk in, in my town or like a coffee shop for a couple of hours. Just again, just concentration points. So that, that office garden, uh, I've seen that done quite well. Yeah, by other people, just what you mentioned. So overall, you know, it's good. But is there any, like, when you think about other industries, you know, like people who just effectively cannot do remote, it's like, like any feeling where you go like, what advice I could give them, you know? Because, you know, I'm having now a better, let's say, life and work balance. But, you know, people making, I don't know, cups physically in a factory. Yeah, you know, they can't make cups at home, like It's like, do you see the whole planet somehow going remote? It's like, or is it just us, you know, developers being lucky?

Yeah, well, that is a very good question. I think development was one of the first professions that was enabled to go remote with the technologies that are available at the moment, you know, like faster internet and things like that. Because, you know, if we were still using dial-up, we probably wouldn't be doing remote because you wouldn't be using, you know, high-quality video, and even voice probably, you know, would be quite low quality with dial-up. So, you know, I think we are now at a place in terms of technology, having gigabit internet, where we can actually work remotely, and it's quite efficient as well in terms of working as a team and seeing each other, you know, seeing each other's face in real time, well, almost real time. Couple, some milliseconds lag. So for development, for developers, or for software rather, and technology, I think it's a blessing. But, you know, for factory workers, I don't see how they could work remotely unless it's some sort of, say, operating a machine, and you can do that from, from home. That could be a thing. Yeah, that's That could be a thing, right? I mean, uh, but you know, like making cups, that will probably be automated at some point, right? You know, if it's something manually intensive, I, I would imagine most things will be automated sooner or later.

So that is a good question.

So that is a thing that, you know, probably won't be done remotely because it will be automated sooner rather than it can be, um, done remotely, right? It's, it's more efficient to automate rather than to get a worker to do remote work on that, whatever they're doing in the factory. And then also you have a bunch of things where it's quite hard to automate, like, you know, construction workers, for example, bricklaying. I did see things like bricklaying. Some of it can be automated, but you still need someone to supervise the machine and things like that. But then you have other things like plumbing, like, you know, laying pipes in the house or electrical work, you know, and all of that has to be done on site. And I don't see it being done remotely, I don't know, any, any, any time in the next maybe 20 years where you, where we probably, you know, go, go science fiction and imagine like an android where you can jump into virtual reality and then control the android or whatever, like, you know, 20, 30, 50 years from now. I don't know.

That's a good one. Let's go back to AI and VR and how that actually plugs into potentially automating just industries in general. But before we do that Do you think we're gonna have remote workers and on-site workers almost as two different classes, uh, which will always sort of argue about situation and, and, you know, try to equal the, the, the playing game field or not? And one thing which comes to mind is what we have between males and females, and, you know, are the females in executive roles, and that, you know, all that sort of, uh make sure there's a balance. Exactly. Like, I remember, I think it was Elon Musk who said that it's just not fair that there's a, there's a group of people who can do remote and that others can't, because, you know, it's very clearly, you know, beneficial in the sense of life and work balance. Do you see that going that far?

Yeah, well, um, I think the thing that Elon Musk has said, and I think it's also the same thing that is being— that is driving return to office and, and driving from remote to go hybrid. I think, um, I mean, you could— might call it a conspiracy theory or whatever, but I think, I think on management level, people like to control, right? And they want people in the office so they can see what they're doing and, you know, have a sense of control, even if they're not directing them. Control, you know, they can see what people are doing and, you know, have, um, an overview.

Yeah, absolutely.

So, you know, so I think, I think, I don't think that's where Elon Musk is coming, because where he's coming from, because, um, if you don't have your people in the office, then it's probably harder to monitor them. Like, what, what are you doing right now? You know, if they're not in the office, you can't see what they are doing right now, right? You could set up a message on Teams, you know, and then they could reply instantly. They might not reply instantly. So I think it's about, it's about control. And in terms of having like two different classes where one class is you have, let's say, a working class where they are working on site, and then you have another like middle class and they're working remotely. Hopefully it will not come to that because I think you will always have some companies who even like for software companies, they will want people working on site in an office.

I, yeah, I do say I do see that as well. And that pull back to office where you mentioned, uh, it, it's 100% happening. I mean, everyone's probably feeling that. And I subscribe to Remote Work News, uh, and I've, I've seen how the message changed. You know, there was a big campaign about, um, you're not gonna really learn if you're not in an office. And it just accelerates your learning, accelerates skills development. Then there was another push around, you're not going to bump into decision makers, so you're not going to advance your career that quick. So it's, you know, the different angles which are being tried. And at the end it was almost like ultimatum. Like I've seen, you know, I think it was Amazon and it was Salesforce just going like, you just coming back or you're losing job.

Yeah.

And you know, it could be potentially attrition-causing move, so they don't need to let people go. Yeah, exactly. Yeah, or it could be, you know, that is just what's up, like, that's how we see the business, you know, it should be run. All right, so let's go back to that AI VR thing. So how do you think all of what's currently happening with, with large machine, you know, modules and ChatGPT, and then what we're seeing coming up, do you feel like some of this have move towards a lot of, or some of the industries being automated?

I think that one of the first industries to be automated, and it is in place already with chatbots and stuff, is customer service. And I do recall seeing a demo by Google. I don't remember if it was a couple of years ago, maybe 3 years ago, where they did. So I was, I was livestreaming and I think the actual, the demo was in USA somewhere, right? They were doing a live demo and They were using an AI voice assistant to call a hairdresser to make an appointment, and that was all handled in real time. So I think customer services will be one of the first things to really feel the impact of AI. We will probably have a lot less people being employed in customer services, and you will only have a handful of supervisors that if things escalate, for example, and you actually need a human to talk to, then they'll escalate that supervisor. So I think we're at that stage already.

Yeah, 100%. I mean, I get that with Amazon all the time and any bigger players, like it's all just AI bots.

Yeah.

And you know, you can push them, push them, push them. And at some point, then at the end they go like, okay, here's the form or here's the phone number. You can go to real person now. But even this is stopping. I can't remember exactly what I was dealing with, but I was just unable to reach a person. It was just like, you know, this AI question, this, and it's just at the end of the day, it was like, okay, fine, you know, I need to find a different way to find a phone number.

Yeah, yeah, yeah. So customer services is already happening. And then any other areas? As far as I know, there's a few news channels. I think one is maybe from China, maybe one's from India, where they're using an AI avatar to deliver the news. So that's happening. That's quite interesting, I think. Um, then, um, somewhat relatedly, I think Bruce Willis is the first actor who sold his, um, the, the rights to use him as a, um, 3D representation in the movie. So, you know, we could, we could see him. And he's not doing very well in terms of health as well. That's, that's a real shame. But anyway, we might see him in a movie where it's Bruce Willis as a digital representation and there will be some sort of, you know.

So the voice is AI?

Voice will probably be AI, yeah. Deep learning or whatever that is called. And might be, you know, in the acting motion capture by another actor. I don't know.

How that changes our work? As in, if we move away from, you know, industries being automated.

Yeah.

And we go back to development.

Yeah.

So do you think there's a threat of just, just, you know, code production? You just stop coding?

Yeah. Well, I think there is somewhat of a threat at the moment, but the— what is stopping us from, let's say, from using Copilot, you know, Copilot by GitHub or Microsoft and other tools, is that all of these LLMs, I think it's called large language models, they are hosted in the cloud. I mean, with Azure you can, you know, have your own in this instance, but most of them are hosted in the cloud. And whatever you, whatever prompts you submit or whatever code you submit goes in the cloud and the model can learn from that, right? So you are potentially exposing company code to a, you know, LLM. And that is not a great thing to have, right? You don't want to, because it's proprietary, right? This is, you know, it's your, your product, right? You shouldn't be giving away—

and information is exactly—

any information. Yeah, your source code, you know, just giving away source code. So that'll— I think that is what's stopping us currently as a company, same, from, you know, moving towards that. Um, so I think there's a little bit of, um, time before Perhaps there's ways how to make the LLMs more efficient so that, you know, they use less VRAM. We can also run them with CPUs, which run RAM, but as far as I know, that is a bit slower. But from what I've heard, and I do read Hacker News on a daily basis, and there's been some ways how they can improve LLMs, make them smaller, and yet make them more accurate than ChatGPT, for example. So we are moving that way and there's still a bit to go before we can actually host or use an LLM locally within our laptop. You have a laptop and the LLM is inside the laptop and there's nothing that is going to a cloud. I think that would be ideal. But before we get there, we'll probably have our own private instances on Azure or AWS and use that for coding. But anyway, in terms of threat, I, My hope is that we are moving towards where we will not need to worry as much about writing code, but instead we will do more of a managerial, if you like, role where we use prompts to tell LLMs what, what we want to achieve. They output some code, we review the code, is this good code? So I hope that that's where we are moving towards.

So it's less building, but it's more of— less coding, but more of like building and integrating solutions together.

Yeah, I'm hoping that it's moving more towards gains of efficiency in terms of employee productivity, right? So everyone just becomes more productive, and then, you know, we can address technical debt like that, you know, the— what do you guys previously. We can address it in a more timely manner and more effectively. Um, so that's my hope that that's where we're moving towards, into like the medium, short to medium term.

But in effect, they cannot give you solutions which they weren't able to learn, right? So that means if, if, if you're asking something which has not been written yet, they cannot really propose, you know, a code sample, isn't it? So effectively If you think about like a frontier, there's always going to be an edge which is getting pushed around code being written which has not been rewritten yet. So there's still going to be something which needs to get coded, isn't it?

Yeah, I think so. I mean, you know, someone will still need to code all of the stuff behind the AI, right? Until we reach a point where AI can code itself, which I think is called Singularity. But I'm, you know, this is like 2045, I think it was originally Singularity, but I'm not sure if it's just about software or about the hardware as well, whether AI will be able to improve the hardware all by itself and software by itself.

That's a scary time, isn't it? Then it's almost like I'm gonna build you a Terminator.

Yeah, but software, I think, I think it'll happen quite soon. But hardware, I'm not sure. But yeah, in terms of development, will there be any redundancies? There might be eventually. I think there will be a lot of redundancies at some point where everything can just be automated. You'll have, you know, perhaps one person in the whole of Tesco supermarket because everything else is self-checkouts.

Loading times.

Yeah. And we will hopefully, the, you know, our governments will have the foresight to see that this is what's coming and, you know, move towards universal credit to reduce the, um, the pain of, you know, if it's quick.

Yeah, I see that. I mean, if it happens as people are predicting, you know, exponential growth and implementation, and it's just the change is so rapid and it comes so fast that then it's just going to be painful. But at the same time, you can— you might just have some, you know, organic change which is just being managed. So it's not that painful. But yeah, I do agree. I do see a lot of efficiency even right now. So when you think about the businesses and how they use AI, it's not causing redundancies, but it's just causing a much better operational margin on effectively like financial sheets, meaning that you get the same done, but you just need less people to get the same done, which means you just, you know, you're getting more profits by doing exactly the same but with less people. So that's like what's happening. Yeah, like that's, that's quite evident. And a lot of solutions which are built on top of the, you know, strong LLMs like ChatGPT is basically that. It's just efficiency gain. But yeah, market is great if it's going to go somewhere. Do you have like a VR set at home? Do you like ever play or use for anything?

I've got a Quest 2. All right. Which I have used for Microsoft Flight Simulator. Okay, there's a few games actually. I think it was one called a strictly VR game. I forgot the name now, but it's on Steam. It's essentially fighter jets, but it's— the game was built, it was optimized for VR. So it's not real fighter jets. It's not— the cockpits are not real, but it's optimized for ease of use within, you know, AR environment, VR environment. Um, I forgot the name now, but yeah, it's on Steam. Um, so it's quite fun. And then, you know, other games like, um, Beat Saber. But in terms of actually working and doing coding, uh, the Quest 2 is not a device for that. The resolution is not good enough to actually be coding. You could do it if you wanted to, but I kind of tried it and I thought, nah, I prefer my real setup.

Is there anything else outside of entertainment you use VR for right now, or you can see yourself using that in a couple of years?

Well, you know, the Quest 3 is out, and, um, I did look at it. I— in terms of specifications, the resolution is a little bit better, um, it is a lighter headset, um, but I don't think it is still for productivity use, Quest 3. But what I am very interested is in seeing the, um, Apple VR headset, Apple Vision Pro, or whatever the, the catchy name, the fancy name that they call it.

Eyeglasses.

Yeah, um, because it's very expensive, you know, their headset is very expensive. And Apple, usually when they release a product, release a product, it is quite well fleshed out. By the way, I'm not—

often.

Yeah, yeah, often. Yeah, usually it was. I, I had an iPod a long, long time ago, and it was— the user interface and everything was brilliant. It was, it was really nice.

They tend to not release shit.

Yeah, exactly. Yeah, it's— yeah, they, they work on it a lot, they spend a lot of money, then they release it, it's expensive.

But do you think they're gonna aim at, um productivity markets. I still see VR as just being pure entertainment.

So the problem that I see with VR technology, and you could call it, I think another acronym is XR, like extended reality. So it's not augmented, it's not virtual, it's extended, right? So you take your current reality and you extend it with digital stuff. So the problem with VR currently that I see it is that, you know, you have to put on put something on, on your head. It's not like you can sit down on a chair, you have your monitor, you have your keyboard, and you start work, and then you want to take a break, you just get up and go take a break. You have to put something on that is quite bulky, um, it's got a limited battery, and it is not that comfortable for long term. Okay, so I think it's not quite there that I think we have to do a lot of miniaturization. When it's as easy to have augmented reality or virtualized as it is wearing glasses, then for sure, you know, we'll have lots of stuff in terms of working with VR, like you're doing productivity stuff, yeah, for sure. But, um, we— I think we still have a long way to go to get there.

You know, Facebook, uh, released, or like, in a beta, like a like a VR glass— not VR glasses, just like glasses which record stuff. Like you can bind it with your phone and you put it on your face and it's just basically, yeah, you know, you go stream or whatnot.

Yeah, well, Google did their thingy.

Um, Google didn't stick, isn't it? Because I remember Google Glasses.

Yeah, I don't remember the name now, but they've shelved the project.

Yeah.

Um, there's a few products actually which are more like glasses, but the resolution is not that great. The The angle, you know, the field of view is quite narrow. So I think it's slowly moving there, but it's not quite there yet in terms of being productive, doing work, coding. I don't think it's there yet. There's some companies which are working on it. There's some accounts which I've read, people are successfully using it. You know, that goes hand in hand with remote work, I think. You know, we're doing— if you're working remotely, then you're virtually out of reality and you can see accurate representations of your co-workers in virtual reality. Um, I think that'd be—

that'd be pretty cool. That's, that's, that, that's easily imaginable. Yeah, it's easy to imagine that happening. So maybe to close the, the theme of, um, from investment perspective, you know, if you look at public traded companies like, you know, Facebook and NVIDIA and AMD who play into AI scene, you know, one by building the chips and, you know, other by just sort of innovating on tech, there's budgets which they report publicly, which is called R&D budgets or research and development budgets. So there's shitloads of money which is being positioned towards just advancing the AI angle from all big companies. And just looking and thinking about that money going into that to advance the tech, the hardware and the software, it's easy to imagine very interesting planet in like 5 to 10 years and just seeing what happens. So we'll have another conversation in a couple of years with the new headsets.

I, I wonder sometimes, you know, my boys, um, they're super young now, but by the time when they're adults, how, how is the planet gonna look like in terms of technology? I think it'll be very different. You know, for us, when we were you know, when we were born and by the time we were 20, the growth was flatter and now it's becoming more exponential. So for them, the change will be more drastic, I think, in terms of technology improvement. Probably you won't see flying cars and other things.

It would be cool though.

Yeah, it would be cool.

All right, let's go back to development a little bit because that was a sci-fi. We just went like, yeah, deep on AI and VR. Um, if we take back to your team, sure. So one topic which interests me now is, uh, is just how business structure teams and how they align the team skills towards what they do. And there's a concept called team topologies. So you have like, you know, stream-aligned teams, which effectively works with the just business streams, could be just, you know, building new features or, you know, doing new integrations. Then we have like platform teams, you know, who effectively just deal with the platform challenges, just, you know, like DevOps, site lines engineering type of teams. Then you might have even like complexity teams, you know, people working on technical depth. How is your team structured at the current business?

Okay, so when— so the, the company Duty Sheet, when we were acquired, I think we were 15, maybe 16 people, um, and we have two products. The original product is Duty Sheet, which is for special constables within the UK, and that's the name of the company, Duty Sheet Limited, as well as the name of product. DutySheet. And then sometimes afterwards, the company started making another product called Assemble, which is geared for charities. So it's used for managing volunteers. So what we call it a VMS, volunteer management system. Um, so it was quite a small company when we got acquired. We— yeah, I don't remember the exact number, but we were quite small. And I think the reason why, you know, we— before I go back to why we gel so well— is because, you know, we're still kept as like a silo. We, we got acquired by Access, but we're still held together, uh, within the group of Access as a team, as an assembled team.

That's a good call, isn't it?

Yeah, well, um, it's interesting the way they work at Access. They have lots of different products. I mean, there's so many I don't even know, and we are what's called an NPE division, not profit and education. Last time I heard, there were 270 people in that division. It's probably quite a bit more now. And Access constantly acquires small companies. And when a small company acquired is acquired, I think it is very difficult to, for example, to make any redundancies because if a small company, the chances are that everyone is quite important. In the work that they do. Like, everyone's a key person dependency of some sort. So I think that is one of the benefits for us as well, is that when we were acquired, no one was made redundant because everyone was needed to continue working on the product. And obviously, for Axis to see return on their investment as well on the acquisition. We had some people who left, you know, naturally, and then some new people who joined as well. But overall, there was very little turnover. So as a team, you know, we— it's, it's really hard to say, you know, what is a team? We have, we have, we have the Assemble product, and you could say that is a large team, but with it we have development, which is like a smaller team. We have at the moment, I think we have 4 developers, and we do both front-end and back-end, and a few of us will also do a little bit DevOps, and we also have a QA team.

So just QA, so you're all full stackers and you even, you even bite into DevOps?

Yeah.

And then in fact you have quality assurance?

Yeah.

And that's the, that's the setup?

Yeah, that's the setup. So yeah, it is quite efficient. Um, we, we are currently in the, in the process of reducing the bus factor, if you will, reducing the key person dependencies so that if someone goes on holiday, there's still other people to cover.

Single point of failure.

Yeah, exactly. Yeah. So we are currently working towards reducing the probability of single point of failure with another person. But in terms of team structure, yeah, it's pretty simple. You know, we don't have, we don't have the Spotify kind of model where you have, guilds. Well, we do have groups in, in Microsoft Office 365 thingy, some sort of groups. We have like a massive guild of developers, I think 1,000 people or whatever the number is, maybe more than that. So it's everyone from within, within Access, you know, regardless if it's Java,.NET, or PHP, or Python, whatever else, if they're doing DevOps or front end. But, so yeah, so we don't have the Spotify, you know, we have a guild and then you have a, uh, what's the other thing?

Tribes.

Tribes. Yeah, yeah, so we, we were not doing that at the moment, uh, because we, yeah, as in terms of, because that would be, that would have to be done in terms of Assemble as a product. There's loads of many different products, so you could, you could look at these little products, they're almost as if self-contained businesses and companies. Not quite there, but you know, kind of.

It's interesting, I mean, that was one of my Follow-up question is, when you guys got acquired, that's often quite a painful time at that beginning of acquisition because you suddenly, you know, go— we were intimate team.

Yeah.

And we are being plugged into this huge enterprise and, and suddenly, you know, it just depends where you sort of come in and plug yourself in. Yeah. You know, you're getting so, so much more communication nodes and suddenly you know, maybe even your titles changes because you, you know, you're slotting in and then there's reporting lines and everything just becomes quite chaotic until you sort of, you know, get into shape of being part of this new body and then it just becomes disruptive. So, so you, you basically just got like left alone?

Um, well, there was, um, we, we had to move from Jira into Azure DevOps. Um, we had to move from—

I'm not—

I think we, we had to move from, uh, Gmail or, or, um, the Google Office thing into Microsoft Office.

So everything's Microsoft, I guess?

Yeah, uh, we, we still use AWS though for our dev stuff. Yeah, we were on the AWS.

So it's Office 365, which runs the enterprise, like Outlook, SharePoint, and, you know, Teams and all that. And but then the The actual infrastructure of your product is still in AWS?

Yeah, the infrastructure is still in AWS.

Is it because it's better? Is it because it's just, it's just heavy to and bulky to lift and shift into Azure?

Um, probably because it is, um, in terms of benefit, there's not that much benefit to lift and shift it, and there's no real reason to do it. Cost saving doesn't outweigh the work implied No, I mean, there might be cost saving in terms of partnership. I don't know what that cost saving would be, but at the moment there's simply no need to move from, from AWS to Azure DevOps. There are some teams who are using it, but there's also a bunch of teams which are using AWS.

I do like AWS personally, you know, 12 years with AWS, but I do like what Azure is doing as well because they now have a proper edge. With the, with the LLMs.

Yep.

ChatGPT, everyone wants to do their own LLMs. They're giving infrastructure as well. They have a very generous startup funding campaigns, so you can get up to a quarter of a million, you know, if you, if you're basically building on their stack and their tech. And AWS doesn't do that.

Yeah.

So now they're getting the new breed of entrepreneurs basically coming in with, you know, AI and innovating, and they're getting all them into Azure. And, you know, you know, as good as I do, that once you buy into a tech, eventually it's actually becoming quite, quite, you know, difficult and expensive to move. So you're getting some vendor lock situation happening in there for sure. Okay, uh, so the team, is it like 1, 2 teams, 3 teams, or is it just one big family, which is like 15? You mentioned like 12 to 15.

One, I'd say it's probably more like one big family. Yeah, we have, we have development team and we We have a customer success team. Excuse me.

How does your standup look like before you go into the debriefs? Like, how many people are online in that morning standup?

Could be 9, 10 people.

Okay.

So sales are kind of separate, but yeah, we have, you know, product owner, we have customer success. We have support, development.

Who mainly talks in that stand-up? Do you do like a proper let's go across the room?

Yeah, we go across the room and, you know, if anyone's got any updates, if anyone's got any blockers, uh, that kind of thing.

How long does it take then?

Um, 15-20 minutes, sometimes half an hour. Sometimes we use the stand-up to address any issues. For example, hey guys, I had this problem, and then okay, well, maybe try this. So sometimes it does drag on a little bit, but usually it is 95% of the time it's less than half an hour, and we usually do it at 10 AM as well.

Do you get situations where you're like, you know, here's my situation, then you started getting into it, then someone goes like, let's just take it offline?

Uh, sometimes we do. Yeah, sometimes, but it's not strict, you know, it's not strict.

I call it a catch-up. When the stand-up becomes something more than just a stand-up, I'm like, okay, we're doing a catch-up now.

Yeah, well, I suppose because we are remote, so a stand-up is kind of stand-up slash catch-up, you know. What did you do yesterday and what will you do today?

But that's a privilege of synchronous work. So you're still remote, but you all share the same time zone, isn't it? You're all online at the same time.

We have one developer in Romania. At the moment. So I think that is— he is 2 hours plus.

That's still not, not bad.

No, that's really good. That's still really good. It's not like, you know, you have on the other side of the world someone in, I don't know, Malaysia. Yeah, here you go, India or Australia. You know, that, that would be quite difficult.

Then kicks the business into a total different mindset because then you basically— okay, we need to think asynchronously. So, you know, we do the work, someone sleeps, and we go to sleep, someone needs to continue our work. That which just changes a lot of how you run these processes. So if we just talk very quickly around like how you get things done, so stand-up, of course, you know, do you guys do sprint? Did you Kanban? You know, did you Scrum Bands? Like, what's the—

we do 2-week sprints. And we, before the acquisition, we used to do 3-week sprints actually. And we would, at the kickoff of each sprint, we would have an almost all-day meeting and it was quite tiring. Then we went remote. We had a new person come on board who was a dedicated product owner, and she did a brilliant job at actually breaking those meetings up into more but smaller meetings. And that in turn then that reduced the total time, total meeting time, even though you had, you had more meetings that were split up, the total time of the meetings was less than the Nearly a whole day meeting we used to have.

But doesn't that sort of dilute attention if you have— I mean, it's a question of timing, but you know, if you have like one small meeting, half an hour, another small meeting, another an hour, and another third meeting, like small even, like for me that just chops my ear.

Yeah, I don't think it dilutes attention. I think it actually improves attention because you get the time to, for example, to focus on something else, say do some development, and it doesn't have to— it doesn't happen in the same day. You know, you have your meetings spread out. So you'd have your sprint kickoff in one day, you would then have your sprint retro, you know, another day you'd have a planning poker session at another day and it's all spread out. And I actually, and I think that it is, it definitely improved my attention span because then I have half an hour in the day in the meeting where I need to focus in terms of listening to people and, you know, bouncing ideas off each other. Whereas before, when we had that one-day meeting, I would just burn out and get tired and zone out.

Yeah. I mean, yeah, meeting in general is 45 minutes and you're done.

Yeah.

You need to either take a break for 15, come back and continue, or it's going to be like, yeah, you know, your mind just going to go somewhere else. Yeah. So are you doing this like in the mornings and then, you know, it's like every week every day within the week, or is it just, you know, um, one in the morning and one in the evening? It's like, what's the— what's the cadence of these meetings?

Uh, so, well, we, we do our daily 10 AMs, right? We, you know, the stand-up, but it sometimes becomes a catch-up.

10 AMs?

10 AM.

So you start at 10 or you start at 9?

Uh, well, it's— as remote, it depends on the person, you know. They can start at 10 if they like. There's no— there's no hard, um—

okay.

In terms of starting time, there's no hard limits. You have to start at 9 or you have to start at 8, right? So by default, you could say you start at 10 because that is where the, where everyone gets to catch up. I usually start at 10-ish and then I finish at like 6:30. So that makes my contractual hours like, you know, 7.5 a day. Some people like to not start at 9 and, you know, finish 5:30. So it's quite flexible. In terms of when, you know, the start time and the end time. The key thing is to make sure that you attend all of the meetings that are in the calendar. And if that is done, then other than that, there's quite a bit of flexibility in terms of, you know, starting and ending times.

And that's your accountability, likely. It's not like someone follows and checks how many meetings you actually attend. It's not like a KPI. It's just like, hey guys, let's just make sure we're all there.

It's not even— yeah, it hasn't even been communicated, but that's just the way I understand it.

Okay.

Because you shouldn't— like, if there's a meeting, you should attend it, right? You shouldn't—

but sometimes, like, I'll challenge this one because I get invited to bucketloads of meetings and sometimes I'm like, I don't need to be there.

Yeah.

Like, you don't need me at that meeting, right? If I'm going to come, one, my presence will dilute the meeting because everybody will look for me to say something. Yeah. Like, you can make decisions without me. Just let me know where you You know, where we talked, and I get this a lot, and I'm very like aggressive when it comes to protecting my diary from meetings I should not be in.

You see, I think that is because you come from a managerial position, right? So you have more people inviting you to meetings, whereas I come from more of a hands-on, less management position. So any meetings that I'm invited to are most likely where I'm Like a knowledge sharing or someone needs your opinion. Exactly. You know, it's, it's like a quite an important meeting. Well, like sprint planning session or sprint poker session and things like that. Or, you know, we are discussing a new feature of some sorts where there, there is a need for developer input, things like that. So, you know, in terms of calendar busyness, I'm quite lucky that It's not too busy for me.

Okay, so how, let's say, how many meetings a day you have and how much the total time of your meeting is per day on average?

On average, so there's one other thing I'll have to mention. On average, I'll probably say maybe an hour a day, an hour with the daily stand-up.

Yeah, that's healthy.

And also, uh, we do have what we call a water cooler channel. Where— well, it is for devs mostly, but it's essentially you join the channel and you have your camera off but you switch on your Teams avatar. So, you know, Teams do like these animated avatars and we all put mustaches on those out there for no reason.

Yeah, it's not even Mustache November, it still goes up.

So yeah, we have this water cooler channel, so— but it's not required to join it. If you, let's say, want to bounce some ideas of each other, or if you, I don't know, want to socialize a little bit about whatever, join the channel, someone else joins, you know, we chat a little bit. Maybe you don't chat, you know, uh, so we do spend some time on that one as well, but it's not a required meeting per se. It's more like a socializing kind of thing, bouncing ideas off each other.

So gelling, if you would like to. If not, yeah, it's okay. I mean, 1 hour a day is, is very healthy. I wanted to ask if you have no meetings day, which is quite popular.

No, we don't, because every day we have a 10 AM. So there are days where we just have the 10 AM, at least for me I do. Um, I'm sure my manager doesn't have those kind of days. Uh, but yeah, usually a Thursday for me is a— other than the 10 AM is no other meetings on the Thursday usually.

Do you have any software which tries to sync up the diaries and makes, makes a better sense of everyone's time?

I don't think we do. No. Usually, you know, when you— when we create a meeting invite, there's a thing that Outlook does where you can see if people are available.

Yeah.

But other than that, no, we don't do any.

I've seen a couple of them, and I'm— I was actually quite impressed how they just take the whole, you know, connection nodes, meaning all the people who exchange information, and they just look at everyone's diaries, especially on the scheduled meetings, which are, you know, always going and they go like, you know, here's a better timeline for efficiency.

Okay.

Concentration. Yeah, it's, it's impressive on paper though.

Yeah, that sounds impressive.

Yeah, exactly. Like from an action point. Yeah.

But anyway, sorry. So if we go back to, you know, like Sprint Kanban and stuff, so we used to do 3 sprint weeks, then we went to Kanban, and then when we got acquired by Access, we had to go back to sprints because that's how they work in terms of their quarters, you know, financial quarters. They have a bunch of sprints per quarter, and they have a bunch of features that they want to— musts, shoulds, and coulds per quarter. And so we had to go back to 2-week sprints because that is, um, I don't know, seems to work better in terms of iteration.

So if you went Scrum, Kanban, Scrum, you have this like fresh, um, experience of, of, you know, going like, I like this because of this and I didn't like that because of that. It's like, what's, what's your take on like Kanban and Scrum?

Sure. So, uh, 3-week sprints, too long. Um, Kanban is— I like Kanban, but I think things can drag on a little bit. So if you work on a feature and, you know, it's Kanban So there is no, say, a cutoff, sprint cutoff, right, to deliver that feature. It's like, oh, sorry guys, it's taking a little too long, or, you know, we need to also do X, Y, Z.

So I think they lose the finish line. Yeah, kicks the can down. What's the saying? Yeah, but yeah, yeah, yeah, exactly.

But I, I do like Kanban though. I did like it. Uh, but in terms of 2-week sprints, I think there's a benefit of there being like a target where you have to finish the sprint. And even let's say if you don't completely wrap up a ticket, at least there's, well, a level of pressure in terms of making sure there is substantial progress on the ticket because, you know, the things that we put in a sprint, we try to make sure that we can achieve in a sprint. Exactly. And if there's, if there's a, if the ticket is too big to fit in the sprint, that, that means we have to break it up.

Okay, what do you think about— I want to say culture, but it's not really culture— but what do you think about team— what's the word I'm looking for— effectively teams who don't do deadlines and don't do goals? They just go like, it's going to take as long as it's going to take.

Well, if they can, if they have the luxury to afford that, I think that's great. Yeah, you know, I would love that if we were able to say, hey, you know, there's no deadline, fix all the technical debt. Well, there's probably not such a thing, right?

I've been part of this business, uh, I don't want to give it a name, um, because, you know, it might be a negative thing to say, but that was, that was being led by, by, by, by, yeah, quite from, you know, top down. And it was, it was effectively saying that, you know, we don't like deadlines, we don't want to put dates on anything, we just want to, you know, have a thing we want to build and we're going to go ahead and build it. And, and, you know then it's going to take as long as it's going to take. And but, you know, we're just going to manage the process of building it rather than aiming at we have to build it in 2 months. I thought it's healthy. I really liked it as an opinion, but then I experienced it for about like 9 months and I was like, I don't think people actually give a shit. Yeah, it just, it just doesn't feel like people have accountability and it just dilutes accountability. Right. And then it just becomes like I'm doing this, I'm doing this. Oh, look, this nice thing. So I'm gonna go over there and I'm gonna maybe play with this. Now I'm gonna come back to it because there's no real accountability to get a date. You stop prioritizing, you just basically, you know, you start looking at things differently.

So it sounds, it sounds, sounds interesting, but I think in my opinion, when you talk about a thing that needs to built, that you probably still have sub-goals that you want to achieve while you're building it out. And I think it is healthy to have a little bit of pressure and a little bit of worry about achieving something. Not too much, obviously, you know, too much, but no one wants that. But just a little bit where, you know, oh, it would be nice to deliver this by this date, and then you actually try to do that. I think, I think that is healthy.

Yeah, I'm a big believer that nothing, nothing grows in the comfort zone. So like, you have to be at the edge of your comfort. That's where the growth happens. And, and that way, we just said about the, you know, the pressure. So it cannot be too much where you just cave and it just, you know, work out, or you just don't respond well. But it has to be definitely more than what you do on your, like, Sundays by, by yourself, something like that, right? You have to have that area where, where that growth happens.

So yeah, if there's no pressure Yeah, I think, I think I would like to have some sort of goals because then you try to build a timeline. I want to do this by this date, but that way, by that date, it is like a plan, isn't it? You're planning to achieve something. You know how much you can achieve. What is your cadence?

You know where you're going.

Exactly.

Without the goal, you just, you're just drifting. Yeah, effectively, where the wind blows, right?

Yeah.

Okay, so who's a person you know I should interview next.

Sure. So as you know yourself, you brought me into web development. So, you know, I highly respect you and you've been a great mentor as well. And then other person who's been also very influential in terms of being a mentor is Mark, Mark Firth, and he was my manager at Netcent and then he was also my manager at Jellyfish. Really great guy, really knowledgeable. Really someone who achieved a lot in a short amount of time, you know, was able to focus. Anyway, long story short, he, uh, started doing his own, um, consultant cloud consultancy thing called Fernie. Uh, he's doing it with another awesome, really strong DevOps guy. Uh, his name is Ashley Maloney. Um, so Ash and Mark teamed up. They're doing started a company called Fernie. And, uh, if you invite Mark, I think you would have some—

okay, I'll give a shout out—

topics to talk about.

All right, cool. Thanks, thanks, Martin. Let's do New Year's.

All righty, thanks for having me.

All right, let's do this. Cheers!