Oscar Baruffa @ IDH | Hiring for skills you don't have | Data Science Hangout
We were joined by Oscar Baruffa, Senior Analytics Manager at IDH. We discussed the "soft skills" side of data science and how we manage ourselves, our teams and our projects - along with hiring. Specifically at 34:14, Oscar talked about the difference in hiring to replace you versus hiring for skills you don't have. "When you're getting into a management position, at some point you need to start hiring people and a team around you. Hiring is actually very different depending on different points in your career. I thought that it had been the same, because I had done hiring before, even when I wasn't a manager. There comes this split that I think takes some people by surprise the first time. So before you're, let's say, a “manager manager”, if you are growing in your career and you do happen to be hiring someone, you are hiring someone most likely to replace you - like a more junior version of yourself. You're going to train them and you are an expert of some level, and you're going to bring them up to your level or something like that. You feel, I suppose, in a way, quite secure in what it is you're doing because you've already got much more knowledge than them and you are bringing them up to your level. You feel very confident in answering the questions and mentoring them and all of that. But it becomes very different if you're starting to hire for skills you don't have. For example, I don't have a stats background. I don't have a data engineering background. I don't have even that much, actually, of an analyst background. I was a market analyst, not a data analyst, per se. When you start hiring these team members into your team, these are for skills I don't have. It becomes much more difficult for me to also assess - what are they good at or not? I first started - like I think most people start - trying to learn as much data engineering and data science as I could to try and just stay at least up with them. But there's no way that you can do that. It clicks and you're like, OK, wait, my job is not to be the expert of all of the people in my team. I am the facilitator of their work. If I know more than them, that's probably actually a problem. We can't have me spend 10% of time on all of these different vast fields while still being the expert in everything. That's not going to be great and that's quite a different switch. I think it takes a bit of getting used to - to start not understanding bits of what it is. Then the tables turn a little bit. I'm in some ways the non-technical manager of technical people, although I'm kind of technical myself. They'll talk about things, and I also have to be like, whoa, whoa. Then I start also clicking a lot of what my directors and execs feel like sometimes. I'm like, yeah, you're getting into way too much detail. I can't do anything with what you're telling me. My role mostly is to try and not just prioritize work but try and help them uncover where there's work that needs to be done. Or if there's a dilemma, try and break down, well, what if we go this direction? How bad will it be if this happens? Or how good will it be if this happens? Can we weigh risk like this? So I can convey to them as well where things just aren't a priority. Because no matter what they do or stress about here, it isn’t going to matter later. That's quite a different ballpark. I think it probably happens the first time you hire someone that's not a replacement for you, it's an addition to your team. It can catch you by surprise." ► Subscribe to Our Channel Here: https://bit.ly/2TzgcOu Follow Us Here: Website: https://www.posit.co LinkedIn: https://www.linkedin.com/company/posit-software Twitter: https://twitter.com/posit_pbc To join future data science hangouts, add to your calendar here: pos.it/dsh (All are welcome! We'd love to see you!)
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Welcome to the Data Science Hangout, hope everybody is having a great week. I'm having an extra great week because I'm calling in from Puerto Rico today. I'm Rachel Dempsey and I lead our pro community at Posit. I always want to put this plug out there that we have the Posit conference coming up in September. And we just extended the call for talks to April 7. So I just want to make sure everybody knew that that call for talks got extended.
But back to regular scheduled programming. The Data Science Hangout is our open space to chat about data science leadership, questions you're facing and getting to hear about what's going on in the world of data across different industries. And it happens every Thursday at the same time, same place. So if you're watching this recording on YouTube later in the future, the link to add these sessions to your calendar will be in the details below.
But every week we get to feature a different data science leader as my co host to help lead our discussion and answer questions from you all. So together we're all dedicated to making this a welcoming environment for everybody that joins. So we love to hear from everyone no matter your level of experience or industry or area of work. It is totally okay to just listen in as well. But there's also three ways you can jump in to either ask questions or provide your own perspective too. So you can raise your hand on Zoom and I'll be on the lookout here. You can put questions into the Zoom chat and feel free to put a little star next to it if it's maybe loud where you are and you want me to read it. And then third we also have a Slido link where you can ask questions anonymously.
But thank you so much Oscar for joining us today as our co host. Oscar Baruffa is joining us as our featured leader. And Oscar, I would love to have you maybe jump in and introduce yourself and share a little bit about your role. And I guess also something you like to do outside of work too.
Oh, yeah, thanks. Yeah, so it's really nice to meet everyone. I'm a senior analytics manager at a company called IDH. IDH is a international development organization that works on improving the sustainability of global supply chains, mostly in the agricultural and manufacturing sectors. And the team, now these, you know, development organizations are usually organized into sort of specific programs that you work on. And the program that I'm working on specifically works with businesses that work with smallholder farmers across the world.
So you can think, you know, like maybe there's a company that's, you know, maybe a local company in Africa that's sourcing potatoes for the local market. Maybe there's international coffee companies sourcing coffee from all over the world, basically. And we work with those companies to improve the business model that's interaction, let's say, between these companies that source produce and the farmers that produce it, right? Because often many of these farmers are, you know, living quite far below the poverty line, they need a lot of services delivered to them and various things like that.
And my team very specifically analyzes data from lots of different business models. And we're trying to understand which characteristics of these models improve outcomes for the profitability and sustainability, like economic sustainability of the company working with them, and the livelihoods of the farmers that are part of that interaction as well. That's a lot what we do. It's quite a small team as well. And so we're basically, there's myself as an analytics manager, then there's two data analysts and a data engineer.
A lot of work, I'd say my time is split quite evenly between, I still do more data stuff, like I blog quite a lot about data related, career related topics. I also, one of my pride and joys is I created and I maintain this repository of R programming books, it's called the Big Book of R. And yeah, so just recommend anyone to go have a look at it. It's got over 350 titles of just about any topic focused on R programming.
And the remainder of my time, I've got some young children who are just at the age now, which is fantastic that they can start playing Mario Kart, the ones getting into Raspberry Pi. So I spent most of my last weekend trying to get a VJ screen to work with a Raspberry Pi and I was not successful. And so this weekend, I think we're going to try to find an old HDMI screen. But yes, that's all my free time, basically.
Theory of constraints and data work
And Oscar, I know we chatted a little bit about some discussion points that we wanted to bring up in the beginning as we wait for questions to come in. But one thing I wanted to ask you about, as you mentioned, like theory of constraints and visible work, along with the negative feedback loop and data work. And I was curious to have you kind of expand on that and share a little bit more about what that means to you.
Yeah, so, you know, I've always managed like a bit of the background here. I've always thought of myself as a competent project manager of projects. So it doesn't matter. I mean, I wouldn't say I'm the best ever, but I'm pretty OK. I'd say I get things delivered on time and usually within budget and under sometimes very difficult conditions. And so it really interests me a lot about the management of projects. And I even wrote a very short book that's free to newsletter subscribers, but it can be free to anyone here as well, about project management fundamentals, specifically for data analysts.
So I think about this type of thing a lot. And, you know, I'm aware of, you know, you get agile practices and a few others for managing projects. But I only very recently picked up this book, The Phoenix Project, which I'm sure probably many people here have read or some have heard. I'd highly recommend reading it. It's really, it's interesting from a few ways, one in its delivery of teaching you theoretical material through the use of a novel. I'd never experienced something like that before. So that was just interesting on its own. But the second was that it introduced, so it's teaching of this concept, the theory of constraints and how it relates to management of delivery of projects.
That book itself is based on another book called The Goal. And The Goal was written in the 80s by, I can't remember his name exactly, but it's, his surname is Goldblatt, I think. And this, so yeah, it's talking about the theory of constraints and what its implication is for how you manage work and how you assign resources and how you, yeah, prioritize things basically. And why it's also interesting is because out of it, and out of all this, you know, this idea of visible work also emerges. So these things are all like quite tightly interwoven, right?
And I've developed this, I had a bit of an epiphany while reading The Goal, which is, and I think I need to read both again to like really dig in. But I had a bit of an epiphany that I'm hoping others recognize or they've seen the solution to or people just like, oh yeah, you know, that is a thing. Or, you know, am I just being a bit crazier?
So if you're not familiar with the theory of constraints, the very, very basics of it is, is that in any system of production, and that includes knowledge work, where the work is being handed off between people, or like in a manufacturing setting, you know, like your car parts need to go through some machine at some point, somewhere in this line of like the series of work events, one or more of the items or one or more of the work sensors, as they call it, is your bottleneck. Your bottleneck is your constraints. And you need to, you'll get optimum performance out of the whole system if you design around the constraints, like most people design around the full capacity of maximizing every single work sensors capacity. And that causes huge all sorts of issues.
I'm not going to recount the whole book, but the idea is that you basically scale everything down and keep the constraints fully, let's say fully capacitated. And, and when I was reading it, I thought, okay, this is, yeah, it makes a lot of sense. And a lot of what they were saying, I recognize in my own kind of stuff I've learned in a reverse engineered kind of way, like, oh, yeah, you know, you don't want to maximize everyone's capacity and queues and workloads. And I thought, okay, this, so it was really like quite mind blowing, lots of those readings.
But there's one thing that I know, here's my epiphany, that the idea is that your constraints needs to be able to keep pulling work as it's available. And that's the whole idea of having visible work, you keep pulling work as it's available. And that's work going through the constraints goes to other work sensors. If there's any delay at the constraints or any lowering of capacity at the constraints, the problem is that you keep building like each of those delays becomes cumulative. And that's why small delays, especially if your constraints somewhere near the front or on remember the exact positioning, but you get very large delays later on. And that's why you'll see I mean, you can see it when when people are working like small issues up front become someone else's massive nightmare down the chain, and they can just never catch up with work that was overwhelming, because they're dealing with all this upstream cumulative delays.
But now the solution, I think, doesn't quite work for much of data work that just in maximizing the capacity of your, of your bottleneck. And I think the reason is, now I'm not talking, okay, so most of my data work has been around, you could say, like, data analytical work, not productionizing, machine learning systems, I think productionizing that is more akin to the DevOps environment, like an IT, someone designing and developing something and then handing over to someone else to deploy. That's more like how everything else usually works. But in a lot of data work, that's very iterative. There's this huge problem in that most likely your bottleneck becomes a victim of its own delays.
There's this huge problem in that most likely your bottleneck becomes a victim of its own delays.
Right, because work often is not done, it's not just handed over, by necessity, you've got to hand over an analysis to someone. But that's not the end of it, we all know it comes back again. And a lot of the techniques that otherwise you might build in to reduce that rework. You know, in a software setting, you know, the whole theory of constraints talks about having feedback of information, but not of the work itself, the work itself isn't supposed to come back. We deal with the work coming back again, because you can't, a lot of the work you can't, especially like if it's an exploratory, any kind of exploratory data analysis, you're doing kind of research, and you're not sure what the answer is going to be like, there's no way you can specify upfront, what the outputs should be.
So my, now the only the only further bits I've gotten of how you might be able to deal with this is when you, you need to tweak the whole visible work and all of the system a little bit is not to maximize your constraints. Your constraints also need slack to take up the rework that's coming back. And the, you know, the reworking of work that comes back, you need to probably have some variable system that you'll, I mean, it's going to be very hard to get this to an exact science, but it'll be a function of how much have you already pushed out. So the more that you pushed out, the more variability you need to leave in your capacity until you show that this is not going to come back again. You'll need some way to know that this work ticket item is done, the project's done, the investment's been made, the whatever, and you're not going to get more coming back.
It's interesting you just said that exact part there, because I was just reading that part in the Making Work Visible book. It's taking me a little bit to get through it, but we just talked about that part.
Hi, Oscar. Thanks for the talk this morning. Well, it's morning where I'm at. Yeah, I'm just curious, you're talking about decisions that get compounded down the line, right? Especially in production systems. I'm just wondering, in your experience, how much of those constraints have happened from managers, supervisors, C-suite, anybody kind of above you on the totem pole versus maybe, you know, lateral to you or below? Like what, roughly what percentage do you think you've seen that?
Good question. I don't know, it would be hard. You know, I think, I think it's maybe more those who are dependent on the output to move forward at all are the ones who, I would say maybe more excluding the C-suite or the exact decision maker. Because my experience is, in a way, they don't seem to get impacted at all other than still just moving forward without your information. Right. So there's usually maybe like a lot of the work we do is often in as well in like publishing some kind of documents or a report of some kind. It's that person, that last one, maybe just before it gets to the C-suite, like in the Theory of Constraints Language, and that's where it leaves the workshop.
So I'd say it's, for me, it's, I would maybe classify this 100% laterally. Above that from the decision, like they'll, they need to go forward anyway. Right. And that's also where it starts becoming important to manage these things better, because you don't want to become a like irrelevant work centre service provider to the organisation. If your stuff is just never ready or good enough because of your delays or whatever, people are going to go ahead. Right. They were going ahead before your data team was around and they're going to keep going ahead without you. You know, maybe not for the better of the organisation. But yeah, I'd say I'd say it's 100% laterally. That's for me, at least where my focus has been.
The Big Book of R
I see there was a question in Slido that was, what compelled you to start the Big Book of R?
Ah, yeah, that's a good one. So I love talking about the Big Book of R. So that was, it was about, yeah, so it was August 2020 that I launched it. And a little bit before that, I'd just been bookmarking lots and lots of books, right, especially then. Well, I mean, until just recently, I was on Twitter a lot. And then I was, you know, all the time on Twitter. And people were sharing their books and that. And I just started bookmarking them.
And I remember at once seeing my bookmarks folder had 80 of these R books. And I'd not seen a collection of such. And I just put out a call basically. I said, hey, anyone else is collecting? Like, how many do you have? Like, I was just trying to compare, like, and most people coming back with 5, 10, 25. I thought, wow, okay, actually, I've somehow stumbled upon this massive repository. And, and then also, it was one of the things I thought, maybe I could just quickly, you know, put this together, because I'd also just actually written a book called Twitter for R Programmers, which was a collaborative effort with Feriluf and Son. And so I just had this was my first time using R Markdown and write. So I quite liked this idea of being able to make a book really easily. So then these things just came together. So I've got this massive thing, you know, this great repository and, and this great collection. So that was the start of it, 80 books. And yeah, it's been really fun project.
Thank you for that contribution to the community, too. And I know there's so many people who have used that resource.
There is actually a way you can you can help me actually, everyone, if you want, there's a there's a I'm applying for a R Consortium grant to basically upgrade the big book of R. And so I'm collecting basically, like, I know, like, it's a two minute survey, we can just like add your name. And if you think this is a good idea or not, and it's part of the submission. So I think I've got about 110 responses. So if I can get like 150, then it can be like, really, wow, everyone really thinks this is a great resource. So I'll share it in the chat just now.
Ben, I see you had asked a question in the chat a bit earlier. Do you want to jump in?
Yeah, Oscar. First of all, thanks for all the contributions to open source, especially in the R environment. But what benefits have you seen from those contributions to your career overall?
Oh, good question. Um, yeah, I'd say quite a few. One is, is just that it's, yeah, how do I put up with this? It's, there's a certain, this isn't the right word, but a certain like level of confidence that you get that it's like, wow, you know, I'm doing something that gets validated quite quickly. Like a lot of our work, a lot of my work anyway, like there's so much stuff that I really like doing and it's really good, but who's going to know that it's good or bad other than me? It's like really difficult to know. My managers are like non-technical. If I make something that's like a really kind of terrible backend and everything's held jankily together, or it's like a super, super great system, it's hard for them to do that, right?
So this is one way that's at least, it's great to get that kind of validation externally that, yeah, you know, apply the same kind of, let's say, level of efforts and enjoyment in both elements. So at least this is one, a sample of my work that gets, you know, a lot of thumbs up. So that's really great. It's also been quite useful in like getting a good overview of the R ecosystem and what people are using it for. And for example, like, you know, I noticed, you know, if you want to do stats or something, there's tons of books, like lots of them. If you want to do geographic information stuff, there's quite a few books as well. I work a lot with Excel in my daily work as well. Lots and lots and lots. And there's Excel packages. No books about working with Excel, right?
And so when I was doing quite a, quite a big project and we do interact quite a lot with it, but I always knew that at some point we would be limited with what some of what R could do with Excel. And we did hit indeed those limits, but I was not surprised by them at all. That's a small thing, right? But had I not already had this big overview of everything that goes on in R, I may have walked a bit more blindly into that. And also meeting people has been really fantastic. So often people tag me on stuff and then I start recognizing authors or I've been asked to review some book, book proposals as well. So, you know, you'll get, especially from CRC press, they do quite a lot of R books publications. So I've been asked to, you know, look at some of those. It's quite nice to see what some people are working on way before it's released.
Hiring for skills you don't have
Another question for you, Oscar. We talk a lot about this like shift from being an individual contributor to moving into management. And something I've seen you write about before is hiring to replace you versus hiring for the skills you don't have. And just wanted to open up the discussion about that too.
Yeah, so this was, I'll give credit to, I think his name is Michael Kaminski from the locally optimistic Slack group. It's also highly recommended for anyone who's on this call to join that as well. But yeah, so when you're getting into a management position, at some point you need to start hiring people and a team around you. And hiring is actually very different depending at different points in your career. Like I thought that it had been the same because I had done hiring before, even when I wasn't a manager.
And there does actually come this split that I think takes some people by surprise the first time it starts happening because it certainly took me by surprise. So before you're like, let's say a manager manager, if you are growing in your career and you do happen to be hiring someone, you are hiring someone most likely to replace you like a more junior version of yourself. And you're going to train them and you're going to, you know, you are the experts of some level and you're going to bring them up to your level or something like that. Right. And also you feel, I suppose, in a way quite secure in what it is you're doing because you've already got much more knowledge than them and you are bringing them up to your level. And so you feel very confident in answering the questions and mentoring them and all of that.
But it becomes very different if you're starting to hire for skills you don't have. So for example, you know, I don't have a stats background. I don't have a data engineering background. I don't have even that much actually of an analyst background. I was sort of like a market analyst, not a data analyst per se. And when you start hiring these team members into your team, these are for skills I don't have. It becomes much more difficult for me to also assess, you know, what's, are they good or not?
And also very quickly, like it's kind of weird, like I first started, like I think most people start, I was trying to learn as much data engineering and data science as I could to try and just stay at least up with them. But there's no ways that you can do that. And actually it's, then the sort of click happens and you're like, okay, wait, actually my job is not to be the experts of all of the people in my team. I am just the, mostly really a glorified facilitator of their work. And, you know, if they, if I know more than them, that's probably actually a problem.
I am just the, mostly really a glorified facilitator of their work. And, you know, if they, if I know more than them, that's probably actually a problem.
Like we can't have me be, you know, with my 10% of time on all of these different vast fields, be still the experts and everything. That's not going to be great. And that's quite a difference, which, and when it's, it's, I think it takes a bit of getting used to, to start not understanding bits of what it is, you know, then, then the tables turn a little bit, right. I'm in some ways the non-technical manager of technical people, although I'm kind of technical myself, but they'll talk about things.
And I also have to be like, well, well, then I start also clicking a lot of like what my directors and execs feel like sometimes I'm like, yeah, you're getting into way too much detail. Like I can't do anything with, you know, what you're telling me, but then also it gets much better. Right. In, in trying to assess like, okay, what's the options that like my role mostly is to try and not just prioritize work, but try and help, help them uncover like where it is work needs to be done. Or if there's a dilemma, try and break down. Okay. Well, you know, what's, if we go this direction, how bad will it be if this happens or how good will it be? If this happens, can we weigh risks like this? So I can convert, convey to them as well where things just aren't a priority because no matter what they do or stress about here, it ain't going to matter later.
Right. So it's quite a different ballpark and yeah, I think it probably happens the first time you hire someone that's not a replacement for you. It's an addition to your team. So yeah, it can catch you by surprise.
I'm very clear that upfront that I am not the skilled person that they will be able to come to for, you know, you know, X, Y, Z technical thing. I just don't have that. And they can't expect that of me, but I am quite clear about what I can provide. And what my role is and that I am interested still in their technical developments and in, you know, but they need to guide me about what they think, where they think they should go, right. They're going to tell me some gobbledygook new thing, like, okay. And then I'm like, okay, I just need to assess, you know, this is what I'll need to assess if this is going to be good or not.
So I suppose being much more, like, I'm very clear about my, like my thought processes and my decision-making. So I do that very vocally. Like if I'm weighing up things, I'm talking out loud, like, okay, if we do this and this, so that it's not this black box for them about, you know, they gave me some information and then I just gave a decision back. I think that's also been quite helpful in getting our communication to work quite well.
Career development and team growth
I feel like career development is such a big part of being a manager, but I don't know if it's necessarily something that managers are always taught. And I'm wondering, like, how do you learn about growing your team's career and having those conversations with them?
Yeah. I think in one way, now for many of this might sound blasphemous, but in one way, I try and take the company out of this equation. Totally, you know, not just our immediate needs. And I think, okay, what's going to be really great for this person's career in general? Like if I bump into you five years or 10 years down the line, in a selfish way, it would be fantastic if your career was just going swimmingly, right? It's good to have contacts whose careers are just really flying. And then I sort of work backwards from that. And I say, okay, you know, I think, you know, would this be better for you? Would that be better for you? Or, you know, don't worry too much. Like if you could do anything, what would you do? And then, of course, you need to try and whittle it down and say, could we apply some of that now in what we're doing?
And that really helps a lot. But actually, I found another way as well is to let people go with their curiosity as well. And I think that's one thing that at least I can appreciate coming from some kind of technical background is actually most of my career developments has been from just the bits that I was curious about that I couldn't explain to someone exactly like what was the ROI on this thing going to be? I don't know. It's just sort of you get a sense that some things may pay off, even if it doesn't, you're going to learn quite a lot. So I try and give a lot of room for, you know, if you want to go try that, just, you know, go do it. I sort of trust that some way your benefits and will benefits, whether it's successful or not, try and make a lot of room for that.
Working with stakeholders
I wanted to put a plug out here for your, your website as well. Um, cause I came across a, an article that you wrote that I found very interesting on dealing with difficult stakeholders. Um, and I would love to give some time to that, that topic and for people who might be on the call who are hearing, like, we're too busy to go forward with this project, or this is way down on our priority list. Like what are some things they can do to get past that?
Yeah. Yeah. So, so, uh, that it's, um, that post is like a collection of every, um, let's say approach that I could think of that I've employed to make working with stakeholders easier in some way. Um, and they'll, they'll work in different contexts, but I think that for me, the most effective has always been canvassing. I don't know, but I think I put eight there or nine, I can't remember, but canvassing and, and most of you probably already do this, or you're not sure it's called canvassing or whatever, but, um, you know, when you're like getting the buy-in, especially when there's a group or any kind of committee or any joint decision, getting their buy-in before the actual public facing meeting is really the only way to get really good progress.
And what's difficult about it is it's extremely time consuming because of course, the bigger the committee or whatever it is, the bigger you've got to go. Um, and the key to that is that, um, you know, trying to understand people's incentives, like politically in the organization, whatever the incentives for accepting things or not. And, um, you know, so when you're trying to set up these one-on-one meetings and that those you want to keep quite small because you, you, the best thing I've found is people need to be able to back out of things. Like if you put people in a corner and you want the, you know, they're, uh, they're, um, that's what doing publicly in the group is not a good idea, right? If you're trying to get people's, uh, you want to give them wiggle room and doing the one-on-ones beforehand, um, and, uh, not following those up in writing, right?
So, I mean, unless you're, you're already in some kind of combative situation and you need to do it, you need to do it, but this is ideally all the legwork you do way ahead of time that, uh, you understand where they're coming from, what they can agree to, what they can't agree to. And, you know, it's great if you can, um, go around and you understand what's their main concerns or what it is that they're looking for from this project or from this, whatever. And you build that all in beforehand that ideally you've got the agreements, then by the time it comes to the group agreement, everyone's already agreed.
And you will have to sometimes live with this uncertainty of some people not agreeing, but they will at least not object to the work or object to what it is you're doing. Um, and, um, you know, sometimes I find that's, that was also for me in the first few times I had to do this kind of thing. I wanted the certainty, right? Of everyone giving me the yes before I go and spend all this time. But the reality is you won't get it from everyone. But for me, you know, not no objection is as good. And usually to then after the thing's got a bit of momentum, the objections don't, uh, they're too late then right later. But a lot of people, they want the ability to back out. And sometimes I think if that's what they need to be able to let this thing go forward, then you just got to be pragmatic about it. Right. And then just say, great. That's, that's as good as it's going to get.
ChatGPT and the future of data work
Hi everyone. I'm in sunny Jamaica, just to let you know, um, I do work for a multinational firm in Jamaica. Um, IGT, if you look up us, you can look on a stock exchange and you'll find us. Right. All right. So I've been watching the conversations around the very new shiny toy, chat, GPT, and even Bard from Google, right. You know, I've been watching the conversations about what we think and it's still evolving about what this will mean for us. Will we be writing code or not? You know, so I just wanted to get your thoughts on how do you see those applications affecting what we do positively or negatively.
Yeah. Thanks. Thanks. Uh, so yeah, we'll see if, uh, uh, what the test of time will tell us. Um, I think it'll be a useful tool and, uh, but we will soon find out what its limitations are, you know. Uh, I'm a bit, I'm mostly worried that it's not going to be as cool as we think that, uh, it's not going to be as useful and revolutionary mostly. I'm not worried that it's going to be so, you know, going to take over everything. And that, I suppose, cause I saw, uh, AR and VR was going to change everything. And then it sort of fizzled out and blockchain was going to change everything. And that kind of, you know, there's a couple of useful things for it. And then I saw NFTs were going to change everything and then that's kind of died, my opinion, thank goodness. So then crypto was going to change everything.
And then, uh, I mean, the difference is chat, GTP, I've used it a few times and I've found it useful. At least the version I have, we've got a, um, a, uh, well, it's on my wishlist in a way to use it for, uh, some elements of our work, especially we've got a lot of contextual information. So I liked the idea of being able to retrain it on our own, uh, on our own content and then use it in some very specific applications of trying to summarize some stuff. Um, and I think, yeah, I think if it does very, very well, it'll be useful. History shows it's going to fizzle out to, you know, a couple of, a couple of other use cases or, you know, I really hope it does fantastically well.
Because I think what my, my feeling is it's going to, if it does fantastically well, it's going to, yeah, it's, it's going to ease a lot of the low level work that is not of enough value to hire someone for, or to farm out to someone. We just live with the mess of not doing the summary or not, uh, you know, drafting this thing or whatever. We just kind of deal with it because it's not, you know, it's not enough value and then it will be fantastic. Right. And, and I think on balance it's, uh, will be very useful if it's very good. So we'll see, but we'll see what, uh, what happens.
Because I think what my, my feeling is it's going to, if it does fantastically well, it's going to, yeah, it's, it's going to ease a lot of the low level work that is not of enough value to hire someone for, or to farm out to someone.
Well, thank you so much, Oscar, for, for joining and sharing your insights with us. This has been so fun. Um, if people want to stay in touch with you is the best way through LinkedIn or Twitter?
Uh, yeah, I'd say probably LinkedIn is the one I really, I would check the most these days. Um, I'm just trying to find my LinkedIn. Um, yeah, if I'm like checking messages, um, thanks. Yeah, please. Everyone do, do, um, next with me. I've seen some connection requests come through. I'll also post it. Yeah. And, um, yeah, I'd say there, and then also if you, my newsletter as well, I mean, if you kind of interested in that, uh, always read any email replies to that, but yeah, probably LinkedIn's, uh, the best these days. So thanks. And this hour went by so fast.
It goes by very quickly, right? I wanted to put one more plug at the end for the big book of R and the form that you mentioned to get, um, support. Uh, so I just put that form there. If anybody is interested in, in helping out there too, but thank you so much, Oscar. That was great. Yeah. Thanks for the invite. I really appreciate it. Thanks. Have a great rest of the day, everybody.