Combating Burnout in Machine Learning: Strategies for Balance and Collaboration - ML 178

Welcome back to another episode of Adventures in Machine Learning. I'm one of your hosts, Michael Burke, and I do data engineering and machine learning at Data Bricks, and I'm joined by my eloquent, beautiful and lovely co host Ben Wilson. I write gethub actions workflows for integration data riggs. Nice.

Today, we are going to be doing a panelist episode, and we're going to be talking about a very interesting topic that's near and dear to both of our hearts. It's called burnout. It's a cliche word, and there's a lot of really really great advice on the internet. Ben and I have been reviewing it in depth for the past thirty minutes, so at a high level, it's just going to be giving tips and tricks and reviewing some stuff that we found on the internet.

So I'm going to start us off with actually the best piece of advice that I've seen ever on Reddit. The first one is realize that today can be your last day here on Earth. We all die someday. Wake up every day and look at yourself in the mirror and say what would I do if today was my last day on Earth?

One day you will actually die so much the best of it. What are your thoughts? I mean, they're not wrong. That's definitely a true statement that can be.

We all get to everything in the existence, right. I always kind of inwardly cringe when I hear an answer like that of. Like hey, and the overused cliche term of like Kirby dum, like you gotta just seize the day every day. It's like, that's very easy to say from an ivy tower when you're not spending your day in the great capitalist machine that is modern society, where you need to make a paycheck and you happen to be somewhat good or maybe just moderately good at something that you've been doing for a while that you're just so tired of.

It's really hard to look on the bright side if your entire daily like work life, is just dealing with frustration. Yeah, so. You don't look at yourself in the mirror every day, give yourself a pep talk, and then go thank the Lord that you can write code. I don't believe I've ever done that in my entire lay.

Okay, maybe I should, Maybe maybe I should start doing that, no no doubt. Okay, sir, directly into my own eyes and focusing at myself and like you need to enjoy today, see. At the moment. Yeah, so let's go back to defining burnout.

We looked at a Harvard Business Review article and it's cited three components. The first is exhaustion, the second is cynicism, and the third is inefficiency. Is that genuinely how you think about burnout? And if so, anything to elaborate on.

I think there's different burnouts can happen, depending on your core personality, the job you're doing, and the level of complexity. And I've experienced burnout. In multiple different industries for different reasons, and I think everybody is susceptible to it to some certain degree, and there's just sort of certain jobs that aren't for everyone. But then those jobs that might not be for you, there's somebody who's almost perfect for it and that's their ideal job.

But if you're for the frustration aspect. Of burnout, being in the wrong role is going to burn you out, and you're going to hate it eventually, no matter how long it takes or how long you're doing it. Eventually you're going to burn out if you don't really like the job. But then there's another specialty a burnout, which is you're in a great job that you really love.

And you thrive at. It's just the velocity of that and the amount of work and the consistent, like never ending slog of doing something. Even if you really enjoy it and you're really good at it, there's only so much you can do and when you hit a breaking point of like, Okay, I love this, I'm excited about doing this, but it feels like my brain isn't working. As well as it used to.

And that's a sign of like that the high level tech burnout that I've seen, And it's not just in software. I've seen that and like other engineering roles I've had in the past. Got it. So this is a machine learning podcast, typically in the machine learning space or those types of roles, whether it be internal facing or external facing.

What are some common symptoms that you see of burnout? I can I can tell you what I experienced, like why I'm no longer at the scientist. Yeah, it's like the first time that you do any sort of apply at mL for a new novel use case, or at least when I was doing stuff, I would get excited about it, like this is something cool, and something new to learn, and I get to think through and research what other people have done and then kind of apply it to the business and talk to a bunch of people and create a product that is hopefully solving some problems and then improve that over time.

And at a certain point when you make something successful, other people are going to ask for a version of it for them and it may work or it may not. But if you build something for like let's say we're at a company and we're helping out the sales team, and this company has within the sales department forty different main product lines, and your first project is working with the top revenue generating product line, and you build something that makes their job, like build some sort of automation or predictive modeling that makes their job so much more effective, and sales goes.

Up and it's a huge success. What's going to happen is you probably want to work on something different, like a new area of like, oh I help. That team out, super cool, and now I'm going. To go work with like the fraud team or something, or I'm going to work with inventory team and build a novel implementation that's going to help those teams out but in reality, what happens is your next three years is building individual implementations for each of the separate sales teams, and after like the tenth of the twelfth one of them, you're just like, I don't want.

To do this anymore. This is so boring. But I can't abstract this to make one meta model that solves the like every thing for all of the teams. It just doesn't work.

I need to make bespoke implementations because business logic is different, and maybe the products and what you're trying to sell is different, so it becomes very boring. That's super interesting. I have follow up questions unrelated to burnout, but we'll try to stick on the burnout path for now. What techniques did you use to avoid burnout in that space?

Or is it just inevitable. I tried to be clever and do the abstraction stuff. I like, oh, I bet I could figure out a way to kind of automate having to make more of these, and I had convinced myself that it would work, and I spent a bunch of time delving into Okay, how am I going to build a framework for this? And I'm going to write all that code only to find out is like what a waste of time, Like it would have been faster for me to just do it, Like, in the amount of time that I wasted doing that, I could have done three of the implementations.

So I stopped doing that and just started banging out the implementations as fast as I could. But there's a point at which you're like, Okay, I. Can't do this alone. There's too many requests coming in.

So you go to your boss and say, like, we need to hire more people. Let's get some people that are familiar with this type of modeling. You go hire other people, but then you're kind of signing them up for the same burnout. So it's all about balancing, like making sure that one person isn't working on the same sort of project for too long and making sure that they have interesting, novel things to work on.

So I would canvass other teams that we could talk to while maybe I spend my morning prepping for a model training run of a new idea for you know, some hypothesis that I had that would solve this modeling problem for this business unit. And then after lunch or during lunch, I'd like sit and talk with a completely different department and want to get their ideas. So my brain is kind of shifted focus to think about something that's new, and it kind of gives my brain a break from the tedium of Okay, how many iterations do I need to do for this feature engineering test that I'm going to do after lunch, and you know, creating a to do list in my head and then on paper of all the things I need to do that are just like checking boxes.

Okay, ran this experiment, and I ran this one, and I ran this one. Stuff like that just bores me, Like doing that day in day out for weeks and weeks and weeks on end. Interesting. I thought I was teeing you up for a different.

Answer. The answer that I do now, and it's because you told me how to do it or like to do it, is teach other people to do it. Like adding value to your org can be done in a variety of different ways. And if you're this, I don't know what the word is, but if you're the only person that can implement something that adds value in this space, yeah, you have a ton of job security, but you're really not disseminating the knowledge and adding as much value for the org as you could be.

Instead, the higher ROI thing is teaching other people to be like many us in this space or have some of the skill sets so that they can expand in scale. And then you are by definition not doing the repetitive task. You are teaching how to do the repetitive task, which is a bit of a break that said that. The repetitive I mean it can.

I don't. I never get tired of doing that, though I don't know how. But it's all about It's all about like how many humans you have available. So the story I was telling that was.

Just me, as the only data scientist at a company doing that. Wasn't anybody to like pass this off. But when hiring more people, yeah, the first thing is like not, I would never do something, and I'm sure you can confirm from you and I working together. I never just take an implementation be like hey, dude, go build this.

But for this other thing, it's more like, hey, here's the problem statement that we need. What do you come up with? Because I can learn something from the other person as well, they might think of this, think of a solution that is completely different than what I was thinking of, and could subvert my bias about what an optimal solution is. So I see all of those.

Interactions when teaching somebody, or I don't really see it as teaching. I see it as just collaborating. And I may have more context about the problem than they do, but they're going to approach it in a way that my brain wasn't thinking of. And I love that experience.

That's why I love mentoring. I love that like back and forth or seeing what somebody comes up with and like that was super clever. I'm using that in the future sort of thing. I think people who don't do that, who assume that they know everything and don't ever want to pass on information, or they're like, I'm going to intentionally make this complicated.

I'm the only one that can be called to fix this. That's the dumbest thing you can do as a professional, Like the most stupid thing, because at some point you're going to get a manager who actually knows what they're doing that's going to come in and look at what you're. Doing and they be like, Okay, I see what you did. Now make it so that everybody else can contribute to this, and now you've just created mountains of work for yourself and are probably just going to quit because it's too much, and you've also you're being called out on your BS like oh job security, we don't play that game here and you should never approach problems like that.

So forcibly doing the mentoring thing and collaboration thing, that ensures that you're not building something that is unmaintainable by other people because you're getting clear signal immediately like did we. Come up with something that other people can just build on top of? Get tested out? You're working with your mentee and asking them to build a new integration for it, and you're like, yep, that was successful.

And they did it in like two days and this is awesome. So yeah, now they can go and get somebody else to do another couple of those as well. Yeah, it's an interesting chain of knowledge transfer. How much do you think is lost at each level of the tree in terms of skill and competence and knowledge.

I think there are there are losses that happen, but there's also gains that don't happen that couldn't be traced back to that original person. So if you're the first person who implemented something and then pass it on to one person, they passed it on to another, and now they're doing implementations. When you get further away from the original implementation and people start working together and building something that might deviate from the original plan, if everybody's sort of checking each other's work and making sure that they're doing it thoroughly and properly, after a certain number of time and certain number of people touching it, it's almost inevitable that the product is going to become better than it ever was originally.

So it's going to surpass the abilities of the person who had initially developed the initial implementation. I can't even count how many times that's happened with stuff I built, and I love it when I see it, I was like, Wow, this project is so much better with all of these other people working on it. And I learned a bunch. Of stuff along the way by seeing how they've changed what I did.

And it delights me when somebody just like deletes an entire module that I wrote and rewrites it, and I'm like, now that's properly done. They come with fresh eyes, fresh perspective. Maybe they're a better software engineer, or maybe they're they're just able to see the whole picture and how that all of the other components have been built into it. That I didn't have that vision when building that first thing, But I love saying that.

It's it's awesome. Yeah, and it's interesting to think about how the skill set this is. This is really going into the weeds, but I think it might be cool. So the way that I think about a lot of things is from an ecology perspective, just because I've liked nature and studied it in school, et cetera.

And when you have a food chain, you have producers so like grass, trees. Et cetera. They don't actually need another living organism to produce energy. And then each step of the food chain you lose ninety percent of the energy that was originally in the prior level.

Yeah, that said each of the higher levels, so primary consumer, secondary consumer, all the way up to like sharks, tigers, bears, there's really cool adaptations and sort of modifications of that base energy. So tying it back to knowledge, you start off with, hey, how do I build a forecasting model for a sales use case or whatever. The example is that exact knowledge might lose. You might lose a lot of components of that as you go down the food chain or down the knowledge chain.

But the creativity and the sort of modification of that starting point via each human's own customization leads to really really cool results. Yeah, and I'm fine with being grass. Fine so that I can see a bear catch a fish eventually right in mid air as it's jumping through a stream. And that's kind of how I see it.

Is that sort of except do you enjoy being grass? The first ask that of any professional software engineer, they'd say yes, m hm. Anybody who's like building the framework infrastructure code that other people are using and improving and proved. Definitely, any open.

Source developer who's out there, who has it, who has the goal of building a community that other people can contribute to. Yeah, like people are Everyone that I've met, including my own self, love that hurt? Okay, cool, I'm just curious. So, going back to the Harvard Business Review, We've talked about the components.

This can take a variety of forms. I want to chat about cynicism. How do you manage that? I did not manage that well when I was younger?

Uh and what older me. Now realizes looking back? And I realized this. Many many years ago, was I was just doing the wrong work, and I was doing things, not like doing bad work intentionally or anything, but I was when I would get really bored with things and I would project outward or think about everything but myself, like, man, the job sucks and I hate doing these things.

And what really changed it for me was like a couple of people in management that I had in a couple of really good companies that I worked for, who kind of change my perspective on it more by demonstrating how they do things. And I'd sit there and kind of watch them, like, how can you enjoy? Like I know how good you are and how smart you are, how can you enjoy doing this menial task? And kind of watch them and be like, I don't know if they enjoy it, but they enjoy how well they do it, and they thoroughly enjoy it more when somebody gets value out of what they're producing.

And by shifting my mindset to that to be like, I don't really care what I'm building, and certainly today I don't care what I build. The only thing I care about is is somebody going to. Get value out of it. I could be doing the most boring you know, unsexy software development stuff.

I'm writing Bash scripts that move files around. Anybody can do that. But am I doing it in a way that is actually going to be solving a problem that somebody has And I'm making it easier for other people to use this? And if I am, and people.

Are providing the feedback like thanks for building this super annoying and I'm glad you built it, not me sort of thing that makes me feel good. All right? So for context, Ben started at Data Brooks as an RSA and then went to principal and record time and then moved over to software engineering and is now the TL for the open source team. Ben, do you think you add more value as a software engineer or as an RSA?

Uh, that's an interesting question. I'd say anything that I anything involving a keyboard right now had more value. Just because of blast radius. There's like more people using it.

But I don't know, depends on what value you're talking about, fair Like, are we talking about the bottom line of our company of like sales? I mean, yeah, I guess we would have to get into definitions. The basis of that question is you said you like providing value. That's the thing you optimize for.

Did you make the shift to engineering because you thought it was cool or because you thought you'd add more value or something else. Definitely the value aspect. I thought that I could be able to work on things and also learn more of the craft that I was really interested in in that role versus what I was doing in the field at the time when I made that transition. Got it okay?

Interesting, So maybe the value optimization is consistent. That was the intention, and it was like partially self serving, but it wasn't a I didn't approach it from a position of like, I deserve to do this job, so I'm going to tell somebody I want to really do this. It was I know nothing, I want to learn from people who know how to do this really well. And I'm interested in this and it's an opportunity to make myself.

Feel really stupid, and that I love feeling really stupid. So that's why I pursued it, and also thinking like if i'm if I turn out to be somewhat okay at this, then maybe I could build some stuff that a lot of people. Want to use. Got it?

How much of that transition was motivated by burnout? Quite a bit cool. But it was more of a burnout in the fact that I was doing a lot of things that were very similar every day, and each of those things that were that I was being asked to do or just getting involved with to try to help people out and provide value for customers, it wasn't things that appealed to me because it wasn't based in objective fact I don't deal with with subjectivity, and a lot of the interactions I was having weren't based on any sort of scientific methodology like Okay, we tested this and this doesn't work, and here's what we need to fix this, and we evaluated this, and.

It was more like I don't like this, and like, well, why I just don't like it? It would be cooler if it did this, Like. I'm not product like I don't make those decisions, but how can I help you and move this forward? And it was a lot a lot of interacting with certain types of companies that didn't make objective decisions, more like gut feeling type things.

And I just kind of got burned out of having discussions like that over and over. I didn't feel like I was adding value to those discussions. Got it interesting And now with software, it's a lot more objective, like there's a. Right and no wrong.

Obviously there's gradients of better and worse, but well, pretty factual. For probably not as much as you think. When you're talking about implementation, you're either you either did it well enough to make it work for what it was trying to do, or it's broken and you need to fix it. So that, Yeah, that is objective, like does this run, yes or no?

Does this solve the problem that it's trying to solve, yes or no, But there's a huge amount of subjectivity that comes about guessing whether this is something that people want. When you're doing green field development, like bug fixing is one thing, or building onto an established product is another thing. But when you're going into like hey, we're creating this new feature that does X, Y, and z, you have no idea of people are going to even use it, like no idea, and sometimes you got a sleeper thing that goes out where you you're.

Kind of thinking that this was gonna be something that was big. You work on it, you release it, and you're looking at instrumentation like looking at metrics, and you're like, okay, we had ten. People use it. This last week?

Cool? Four months later, how many API calls this past week? Twelve? Well, it went up and then the next week, oh, there's one API call?

Should we just kill this with fire? Like this sucks? And then you forget to kill it with fire and you check a year later and you look and you're like, eighty four seven and thirty two API calls last week? What the hell is going on?

Who's using this fun fact that happened to me two days ago when checking metric usage of something package that I built two and a half years ago. It's diviner. I was like, what's this? Yeah, all right, we'll chat after So.

Yeah, sometimes stuff like that happens, like and then you're like, oh no, do I need to like add features to this? But nobody's asking for anything, so yeah, you never know. Like so that's there's like this unknown subjectivity aspect of like is this good? Should we should we keep this around?

Or is this just a waste of time? So there is that uncertainty. Heard, Okay, cool? Did you ever get inefficient when you were burnt out?

Oh? For sure? Yeah? You does that look like?

I mean, I think there's physical manifestations to burn out. It's not just that mental fog that a lot of people get where you're just like I. Got to do this again. You know, living in a state of perpetual annoyance or frustration is not good mentally, but also it physically it isn't good either because.

At least personally, it makes me less. Motivated to like work out, It makes me less motivated to be interested in things that are not focused around that negativity of frustration. So there's ways that I've handled that, even if we're doing some sort of crunch right now, where like, hey, we got a deadline, we got to get this thing out, and there's a lot of stuff you have to do in a short period of time. It's very important to have a separation between you know, your time on keyboard two when you're not doing that consciously, not dwelling on it, not thinking about it.

And also hobbies. Get as many hobbies as you can hold onto and make them interesting, time consuming, and something that feels like you're making progress on do hobbies. You try to optimize your hobbies to be different from your work. For sure, Like I don't.

I no longer code outside of working hommurs. I used to, but I have zero desire to do that anymore. Yeah, An example was I started to learn to produce music, and it was way too similar to my job, and that's like you're using your hands on a different type of keyboard, but watching YouTube videos and like teaching yourself something was just like to triggering, so because it used the same part of your brain and really didn't refresh. So now I do the opposite of that.

Yeah, I keep my guitars right next to my desk, so sometimes I'll take a break midway through the day and play like ten minutes of guitar, or if I want to learn a new song, I'll do that in the evening. And just kind of focus on that. I'll also do stuff like play video games, like, yeah. It is involving a mouse and keyboard, but it's completely different.

You know, part of your brain that's involved in that. It's just like, oh, I'm doing this thing that is creative in a different means and or is just killing demon hordes, you know whatever. Big into diabo for Yeah, it's it's a way to check out. And then also making sure to always like set a schedule with gym time, like eight three days a week.

Here's my routines that I'm doing and keeping track of how that progresses as well. Yeah, I have a question curious if you've experienced this as well. So I completely agree with literally everything you've said, and I've noticed that the human brain is pretty holistic, and if one area of requirement is lacking, all the areas suffer. So to put it tangibly, like.

If I have friends, I have professional life, I have health, and I have I don't know, hobbies or something else like personal things. If any of those quadrants are lacking, all of the others suffer. And then likewise, if I can level up any of these quadrants, all of the levels level up, all the quadrants level up. What are your thoughts?

I have potentially a controversial take. I don't remember where I first heard it, but I definitely definitely didn't come up with this theory, but I'm gonna co opt it. And it's it's the burner uh not burnout, but burner like theory. So imagine a stove, like a gas stove in a house, and you have four stations on that stove, but there's a fixed with diameter of flow rate of gas that can come into that stove, and the four different burners are your health, the health of your relationships and family, the health of your relationships to friends and community, and then your work.

So those are the four burner, Like four burners that you can change the flow rate to. If you turn all of them to maximum, no burner will go above medium, so you can never get the high bright you know, crazy flame. But if you. Believe that, do you believe that that there's a fiah?

I think I don't. I think two plus two can equal five. Not in my experience, there's only so many times like this. Like the theory of that gas flow rate is you can change the gas.

That's actually so what I think what you're talking about is you can change the gas type that you're using, so you can get the. Color to change on it to make it more appealing. You can get it to be more efficient, but you can't get the flame to be bigger because the limitation that you. Have is hours of daylight or hours in a day where you're not sleeping.

Because time is the the ultimate fixed you know, quantity, and it's you. I think you would have a different respective perspective if you had a couple of kids, because they take up a lot of time in the day and you need to spend that time with your kids or else you just can be like a checked out parent and just not good for their wellbeing typically, But there's certain points in life where you have to actually turn one of those burners way down or completely off. But there's side effects to doing that.

So if you turn the work one way down. I've worked with people that are like that, Like they have like five kids. They're constantly doing stuff out of work with like friends and their family and social life is their reason of living, and they seem very happy with that. But then a riff happens at the job and they're the first person to get canned.

So they get fired, which is unfortunate. It's just like, man, that sucks. I really like that person, but I can understand why the company did that, because they do the bare minimum and are. Frequently leaving early and not really contributing that much to the team.

More often than not, in high tech scenarios, I see people turn the work all the way up, and then other things they try to turn those up, but they don't have enough gas left because they're working sixteen seventeen hour days and on the weekends they're too freaking tired to go and hang out with their friends and family, so that dad ends up suffering, or they're just like physically and emotionally burnt out from working an eighty hour work week, you know, sixteen weeks in a row, and they just they've hit a wall.

So I think there's a finite gas I'm out that can be applied to that stove. Okay, fuck gears for turning all right, first thing, objectively, that seems right, but I still have experienced other areas of my life. As they improve, they reinforce each other. Of course.

Yeah, so then how I'm taking that as okay? You're saying gas is time, Like you're twenty four hours in a day. The volume of gas is time. What you're talking about quality is the quality of the gas.

So you're removing it, water vapor from it because you're like, oh, I'm better at my job, or I'm better at my hobbies, or I'm better at interacting with friends and family, so I feel better as a person and everything kind of benefits. You're just removing impurities from your gas. I have a question. Yeah, I have never in my job been okay, for the types of jobs that we do, we need to type stuff on a keyboard, and that's like eighty percent of it, then talk to people for twenty percent or whatever, whatever the split is.

Typing the right keys doesn't take that much time getting to understanding what the right key should be. That's the hard part. So design, testing, exploration, figuring stuff out, rewriting. If you knew from the outset the correct case type and you had like a screen on one side and the typing screen on the other, how many hours a day would it take for you to do all of your typing work you're just copying code or docs or whatever.

Interesting question. I don't think I've ever thought about that. If I had no changes to make on any code that I wrote, and I didn't need to do design, and I knew the correct answer of how to implement something, I would my day would probably be an hour development and probably three hours of meetings, and then it would have like tons of extra time. So that's the asmptope, right, that's the truth threshold of the amount of time that your job takes if you were a omnipotent genius, and.

It's a sliding scale. So if that's my work output and it only takes me an hour to write six thousand lines of code and it's flawless. I now can work on six times more stuff. Right, and that's up to you.

Like the job description determines that your current required work would take one hour, and of course you can now do extra. But if you were perfect at your job, you would have one hour of work. No, it's still have ten hours, because I would be doing ten x because you want to though, No, that's. Determined by the needs of the business.

Like the faster we get features out, the more customers we get, the happier our customers are. So I would be doing that, right. But the point is, like, if you could do you're currently doing well at your job, Let's say, hypothetically, if you can do all of your job in three plus one hours, that's the exact same output but much less input. Right, Yeah, but I wouldn't cap my output.

Right, so you would be by definition doing extra, Like if you're doing good enough now okay, cool? Yeah, yeah, I have seen this. So this this has actually been a really interesting paradigm shift for how I do work is thinking about that assimp tote and thinking about how I can get closer to that assomp tote because again, the right answer is doesn't take that much time. Reaching the right answer takes so much time.

And that is skill, that is intensity, that is quality. Of the gas, and also wisdom, so. Yeah, oh yeah, and luck and all this other stuff. Yeah, and it's also a different job role.

So when I was doing your job, I approached it in the same way, which is like the faster I can get to an answer and unblock a customer or bang out some code for a customer. I'm on this fixed timescale of consulting hours. It's like they paid for this amount of time for me to do this stuff. And my goal was.

Always can I get all of this done in a tenth of the time that they purchased my time? And then I can ask them what else do you want me to do? Or hey, do you want to just do it like a hackathon or like let's build something new together. And people love that.

They're like, thanks for doing all the annoying work and now we can do some awesome stuff that we wanted to do but we didn't know how to do it. I'm like, yeah, rock all, let's do it. And that's that was fun for me. It was getting able to do that stuff.

But on like where I am now, we have that perpetual backlog. There's in order to clear the backlog, we would need to quadruple the size of the team in order to get it done in a year. And that's just the nature of our business. And there's always ideas and things that.

We want to do and paper cut that's the need fixing. And you're always limited by time, but it's not limited by people's competency. It's just there's so much work. I struggle to understand the line between competency and like efficiency of output.

Like you, there's there's a threshold to the human capabilities. The ASMP tote is one screen has the answers, one screen has the you typing, and maybe you can copy and paste to make the ASM toat even like lower. Maybe it's thirty minutes if you have a copy and paste feature. But the question is like, and I think the fun of this job is how quickly can you reach that answer?

Well, we don't know what the answer is. That's the problem. Right, we know how to implement something, we don't know if we're implementing the right thing. And the only way to know that is to get feedback.

So we have to release something and then either watch how people are using it or how they're not using it, or we actually just have to go out and ask them and say, like did we build something dumb here? Like do you like this? Sometimes you get the response of no, this is amazing, we love this. Can we get like these five things.

Added to it, like you know backlogs we or or it's more like yeah, it's okay, we tried it, or it's like yeah, we tried it and it doesn't work and here's why, and you suck at life. And then we go and fix that as mean, like as quickly as we possibly can. What we're not looking for is oh, that's a thing we had. No idea, or eh, it's okay.

That means like the it's okay, it's like okay, they're being nice and this is totally stupid and we shouldn't have built this, or it's missing the mark on what we thought. We thought this was something that people cared about, and they they give zero shits about it, so maybe we we just delete it, like we don't need it. Nobody was asking for that. But when you get the response of yeah, this is awesome, but we need these things in order to make this more useful, we've just amplified the amount of work that we have to do, and there's no longer a right answer on how to do that.

Some things there are like, yeah, we kind of know that it needs to do this, but we might have to go back and rework a bunch of stuff to make it work in that way, so that the amount of work increases. For all of those things. It's easier when it's like, yeah, we love it, but this is broken, and here's what broke with what we're trying to do. That's more cut and dry, and usually we can bang out those fixes in minutes, get emerged.

We're good. But it's more that it'd be cool if it did this that that requires. A lot of thought. Got it okay?

Cool? Tying it back to the burnout conversation and the stove analogy, which I think we've I think this is still generally on topic, but to summarize the point, I think it's really valuable to have areas of your life that reinforce your professional life so that the quality of the gas is a lot higher, because if there's burnout, that's typically a function of the amount of time you're spending. If you can do the same amount of work in less time, A, it's more fun. B you have more time to do other things, and generally there's less burnout.

Yeah, sound reasonable. Yeah, if you're if you're producing something, I'd say that's very reasonable. Versus versus if you're just helping people. Oh god, okay, you're just.

There to answer questions like that can be a different sort of burnout. Yeah. Technical capacity. Oh you're the expert.

You should be able to answer this stuff. They're like, Okay, do I answer this for eight hundred and thirty seven people, or do I write a blog about it? Or do I write documentation and just point people there? And that that's a way to alleviate that repetitive nature of like answering the same question.

Over and over. I don't think anybody can endure that for too long before just like starting to feel like they're losing patients. Yeah, that's an interesting point. I was chatting with a couple miscellaneous humans, doesn't matter who or what, but they were asking some pretty simple questions and I was explaining via socratic method, like how I was thinking about the problem.

And I started getting frustrated. And I've been doing that recently, and I'm trying to not And a really valuable reframe that I've been leveraging is how can I be so good that this person knows exactly what they need to do and has the issue intuition to proceed that now is an interesting challenge if they're like, what is I don't know SQL, and you're like, it's this thing, and then how do I write a select statement? You do this instead? Be so good that they will become self sufficient as well as learning the knowledge that they needed from this meeting.

Did you ever try that as a reframe? Yeah? I tried a bunch of different approaches. One of them was I was like, oh, oh, we need is like a.

Master guide that answers the four hundred most frequently asked questions, and it. Got so big that nobody looked at it. It was like, okay, this is like an ebook now, and it's it gets out of date like fairly quickly, because you know, our company is releasing features all the time or changing functionality. So I gave up on that, and then I was like, maybe I.

Could do. And like, what are the questions that people struggle with that I can't answer quickly? And that I can't just like point to a slide deck or something where they can get that top level information and move on once they groped this concept. So I did a couple of those and sent and I would use them as prepackaged things.

I would send it out sometimes as a preface to our initial meeting, like, Hey, here's this cool guide. That might give you a primer on what it is that we're going to be talking about. And some people were like, this was awesome, thanks for doing that. Yeah, sure, not knowing like they don't know that I've already sent it out to one hundred and seventeen different companies before meetings.

But it saved me a lot of time and effort, and sometimes people really enjoyed it. Other times people were like, yeah, I knew all that stuff in there, and I was like, oh, I didn't want to make any assumptions. Yeah. And then that morphed into a couple of long form engagements that I was having with customers where they're really struggling, not on the modeling part, Like they knew how to write code to generate a model, and they knew how to do all the feature engineering stuff, and they were excellent technicians about data science operations, and what they wanted to talk to me about was mostly about like API usages, and they're like, well, we want to deploy this model and then do this ab test, and we need to know like the best way to do that in data bricks and with mlflow, and and then they collect the data after we built that, and they're like, how do we do the statistical processing of comparison?

And that's when it started to dawn on me a lot of times that like we're not seeing any benefits to these models being deployed. Or you look at usage statistics of this deployed endpoint, I'm like, is something wrong here? Like why are there only four requests of this model in the last twenty four hours? And come to find out, nobody in the company is using it, nobody cares.

They build this thing that's going to be integrated to a Tableau dashboard and you look at the usage of this thing. There's four data scientists spent. Sixteen weeks building this thing and one person's used it in a week. And I start having these conversations with them about how why did you come and get me to help you with this?

Like what was what happened in the three months leading up to me showing up here that made you think that you needed somebody who knew how to do this to help you out. Who did you talk to before starting this project? What department is your point of contact for the actual owner of this? And I started realizing that a lot of these teams were just building stuff that they thought was going to be a good idea without telling anybody.

And that's why I wrote that book. And that's what that book is about. It's like, how do you figure out what to build? And there's some tech stuff in there about like showing examples of things, but mostly it's that's the most important part of data science.

And once I realized that and sunk a lot of my time into answering that question and the only way that I knew how to answer it, which was by writing a book on the topic because it's very long form to explain that, then I felt a sort of a Cathartis Catharsis of doing that, Like I think I did an okay job of answering that question. And then in the future I wasn't even the one making the suggestions. It was like salespeople that was like, hey, buy this dude's book before you start doing data science stuff and then getting the feedback from that and like random thousands of people and randomly on LinkedIn being like I got your book and it changed how we did stuff.

I was like, that's why I wrote it. Awesome, glad to hear it. Yeah. It's a uh machine learning engineering and action.

Right, machine learning engineering and action. Yeah yeah, yeah, listeners, it's very good. Like if you haven't, it's it's the key thing is it's different from existing textbooks, Like it does walk you through like what ladear regression is. Actually I don't think it does.

It does some like time serious stuff, serious stuff, but the decision making criteria. If you can internalize some of those lessons, you don't have to use them per se, but if you understand the logic, it really helps. So highly recommend. But also Ben gives me five cents per copy per royalty, So okay, cool.

I had one more topic I wanted to ask about before you can just sort of rapid fire and or summarize. I'm still sort of early in my care and the past several years have been absolutely game changing in terms of understanding myself and what I like and don't like and one of the recommendations we also were looking through Reddit before this, aside from being nature take PTO focus on wellness and then realize you're going to die one day, there's another that suggests energizes and drains reflection, which is basically what exercise energizes you and what exercise drains you.

How do you I mean, yeah, you can like go and create a list that's not that hard, but do you have just general thoughts on how to acquire this knowledge and also does it change over time? I think you need to explore a bunch of things and do self reflection. I don't write stuff like. This down, but I do think about what my emotional state is when I'm doing certain things in a job, and I have done that in the past, and try to think, like, what, Okay, I feel annoyed right now, why is it about this?

Like the last two hours of work that annoyed me so much? And realizing that, okay, it was this. I'm not going to bring up specifics here, but like this one aspect of what I used to do used to really aggravate me, and I would just try to think about how can I solve this one thing so that it's not as painful and is it Like, oh, I was dragged into a two hour long meeting that had no point whatsoever, and it just became this free for all of people just dropping anecdotal evidence without any factual basis of things that or just random thoughts that pop into their head and nothing comes out of this thing.

And getting pulled into those meetings, and after getting off of them was like. Man, that sucked. I hated that. So I started doing things that made it so that that was impossible to happen.

Well, like saying, Hey, if if I'm going to come on this call, here's the. Twenty seven questions I want answered before the call starts. And here's the thing, the ten things based on those answers that we're going to talk about, and we're going to go through those ten things, and then we're going to have five minutes at the end, and when that five minutes is up to do random discussions, I'm going to hang up the video call and I'm going to leave and go do something else. And setting that stage for people, people started to kind of under appreciate that in some ways.

Other people were like, it's super cool, how we we did this asynchronously at first, and then that two hour long meeting it took eleven minutes and everybody got all their questions answered. This is awesome, Like the customer really appreciated that, and I'm like, I really appreciated it. So bringing that structure in order to discussions reduced a ton of stress for me, so I could go do other things. And it's all about identifying that stuff and then coming up with proposals that might work for everybody.

Right, that's crystal clear. How do you balance seeming like a curmudgeon with efficiency. It's all about ruthless efficiency. I don't editorialize when making those requests because it's irrelevant and it just makes me seem like a jerk.

So I if it seems short, you can always swing something like that to the efficiency thing, like, hey, I know everybody's really busy. Here's a bunch of things that we need to discuss before the meetings, so that we can all spend the least amount of time possible discussing this and we can really hone in on what the problem here is. Most people read something like that and they're like, yeah, sounds like a plan to me. I've got other stuff I need to do too.

Yeah. Versus, Hey everybody, how is your weekend? What are we talking about today? Oh yeah, hey Bob, didn't you have that weird thing that happened in that notebook?

Oh yeah, can you bring that up? Yeah it's it's screen share. No, it's not that notebook, it's this other one. Oh geez, yeah, well I didn't run it, so I got to start a cluster.

Now It's like, why am I here? You could have screen captured that before this meeting, taking that stack trace, saved it in a file and then we can talk about that. So stuff like that just drove me insane when people were just doing stuff like that, like do you have nothing better to do with your time? Yeah?

No, it's it's a really good call out. I've started doing that as well, and there's been a couple of times where I'm just like, I'm not going to. Go to these meetings. Sorry, if you have issues with it, let me know.

Yeah, And people usually don't care, but sometimes you're talking about for the meetings you do need to be attending. There's a I've developed a sort of shift in my brain where it's we're friends and then we're in work mode and friends, I will I enjoy chatting like I'm down to Oh, your kid hit a home run in baseball. That's that's actually very boring. But there's some interesting things in people's personal lives, oh of course.

And so when we're in that mode, there's no time like I'm or time limit. But once we enter work mode, it's like, we are going to do this as efficiently as possible in the most direct and concise way, because yeah, that's how we're going to operate. And people usually love that sort of dichotomy of come in chat, be like, these are the six things that I've done. What are the six things you've done?

Everybody's prepared. We wrap the meeting five minutes early, boom yep. So yeah, and everybody appreciates that, particularly about technical stuff because you see us do that on the engineering side quite a bit. When we of these meetings with people in the field.

We're sticking to a script because we don't want scope creep. If it's if it's like sort of this unbounded you know, discussion where people people are going to be people, which ideas pop into people's heads like oh, it'd be really cool if we did this thing. There are meetings for that, brainstorming sessions that are specifically for that thing. But when you're talking about something like hey, here's the status of this feature that's being built, we don't want to go into that brainstorming mode or go into ideation or oh it could do this thing.

And a lot of times we'll cut those conversations off, like we're going to talk about this offline. Nobody talks about it offline. It's more it's a polite way of saying, please stop, like we're committed to building this in this way, here's the status of. What's going on, and.

That if like that sort of ruthless efficiency is there to protect a team's time right to make sure it because if you're working on a project, and it also was like that with when I was in the field as well. You're talking to a customer about a deliverable and somebody just starts ideating like, oh, it'd be really cool if we had this extra feature or if we could do this thing with that, and I would always just slap that down in a very polite professional way, sometimes having to explain we can't deal with this scope creep right now, or this is going to introduce this complexity to this deliverable.

So if I choose to do that, please tell me the other three things that we can drop from the project in order to fulfill this request. And we present things in that way, people instantly stop. They're like, oh, no, no, no, we can't drop anything, like yeah, all right, moving on, let's talk about the next topic and making it all about that finite resource of time and human energy. It usually stops conversations like that.

But I didn't know to do all that stuff at first, so I would just sit there and stew and be annoyed, like, why are there like five people on this call trying to increase the scope of this project by ten x? None of this is gonna have Like we don't have time. To do all this stuff. And if you don't know to say no to that stuff, that magic.

Word no, you don't know when to use that, or to bring up the point that, hey, you've got five weeks of my time and right now I'm booked two five weeks and anything more that you want, you're either gonna have to buy more of my time at this rate, or you're gonna have to let something else go. And people that don't know how to say that and don't know when to do that. A lot of times. They'll just agree to all that stuff and they take on extra work or try to like, Oh, I think I'm smart enough to just like hack this around and get this done and I can deliver all what they're asking for.

And they turned out that day before the delivery five weeks later they are very burnt out because they've overworked themselves. Yeah, or they built an abomination that doesn't really meet any of the needs. Yes, I've been there, I've done that, learn from it. Yeah, it's crazy.

Like data Bricks has three months of onboarding and training, but the soft skills there's a playbook and the most frequently used one like scope creep happens probably one out of three to five projects at least. And the phrase I can do that, but what do you want us to remove from the initial SOW is magic. It's literally a silver bullet. And I really wish we had like a dock of like the five like phrases to reuse over and over because it's also like it's correct, like you were putting the customer first, the project first, you're focusing on value and people who tend to be a bit add with with their goals and the goals of their team.

Sometimes they need a bit of steering and focusing them back onto first principles. Isn't always like a core skill of an RSA. It should be, though, Yeah, when you talk about a project plan being sacker sanct for consulting and that trade offs are entirely possible and. Should be welcomed.

But you put it in the terms of finite resources of time or money, you're like, yeah, we can do this, but it's going to extend the project by three weeks, so it's going to cost you another one hundred and twenty thousand dollars. Is that accept Is that how much this feature is worth to you? And sometimes you'll get a response of like, there's no way this takes three weeks and you better be right on like the extension of when your estimates are. But you get that over time, you understand how complex stuff is and you just listed out or you say like, hey, we'll come up with a proposal after this that like here's a statement of work modified, and they get that, and a lot of times they're like, yeah, we don't have that kind of budget for this one feature, you know, like, okay, so let's stick to the original plan.

Or they do, and that's it and then everybody. Will win win. Yeah, but it's all about that like objective measure of what is the level of effort required to to do that. I didn't know that starting out, so I would get very frustrated.

Early on in consulting. I was just a yes man. I was like, yeah, i'll do that. That sounds cool.

I don't know how to do that, but I'll do it. And you find out, like, why did I agree to this? This is way. Beyond my capabilities to figure this out in that amount of time.

Yeah, I guess I'm pulling it all night or yep. Yeah cool, so almost that time. Uh. For the final exercise before I summarize, let's take turns naming tips and or pieces of advice and or just wisdom that we've gotten over the past years for how to deal with burnout.

And we'll do three each. That sound good to you? Yeah cool? You want to kick us off?

Yeah, First one, get a hobby that's not related to your job. Can you define related? If you're spending all day at a computer figuring out technical problems don't do that as a hobby, Like your hobby shouldn't be I'm going to contribute to open source projects. That's just doing more of your job, like figure out how to do open source projects during your workday, work on things that your company cares about, or if that is something that really gives you a sincere sense of satisfaction, time box it.

And then have another hobby that has nothing to do with computers. They go pick up an instrument, go learn photography. They do something that's interesting, thing that makes you go out and touch grass. You know that's very.

Important, all right, Yeah, just to piggyback really really quickly feel how it makes you feel if you feel drained by the activity. It's that simple. Like if you spend a ten hour day coding and you're like, all right, I'm going to code some more, maybe that does energize you. But just pay attention to how it makes you feel.

Yeah. My pro tip number one is reframe, make up a reality where you're interested. Like, it's that simple. That's a good one.

My second one is don't be afraid to bail. So if you're doing something that the core tasks of what it is that you're doing, not in your company, but analyze whether it is your company's version of that role that you don't like, or is it that role no matter what company it is either one of those things. Either think about Hey, I've talked to people, or I understand how this role is at this other company and I know it's different, Go try to work for them. Or is it I.

Understand that this is pretty universal across this entire profession, Go find another profession. Like, life is way too short to sit there and just suffer in misery. If you like fundamentally hate the nature of your job, I've done it five times now, Like, just completely change industry and job entirely. What I do now has nothing to do with any other job that I've ever done.

Just pop, smoke and vote with your feet. If it's not working for you. How long do you think this job is going to last? Oh?

I don't know. I've been doing it in a while. It's still fun. Heard, Okay?

Cool online. I think contact switching is essential, and the most detrimental and energy draining thing for me is thinking that something is complete and then having it not be complete. So, of course things will break, of course there will be bugs, but really, focus on excellence and successfully wrapping stuff so that when you call something done, it frees up the mental space to work on something else. Yeah, that's a great one.

My final one is don't neglect your health. It's really easy, protectarly in tech, to work too many hours, to not go out and touch grass, but to eat poorly and not exercise. And it might seem like, oh, you know, I see a lot of like San Francisco dude bros like encoding, they're all in great shape. They do that not in order to get attention from people.

They do it because they know that it's healthy for them and they want to live a long time and they want to feel good. So the more more physically fit you are, particularly in a desk job, the better you're gonna do it your job, the more efficient you're gonna be, the better sleep you're going to get, the more energize you're gonna be for after work. So yeah, never never neglect that. Heard, there's like three ish that are conglomerating.

I'm going to try to put them on the one. So we've talked a lot about getting different inputs to your brain and different styles of input. One thing that I try to optimize is inputs that give you perspective not to be morbid, but like if a family member dies, suddenly your. Job is not important.

If like there's an economic crash, suddenly your job is not important. It's a job like chill. And so with that, there are ways that you can get reminded of that. I personally do a lot of charity and like nonprofit work, and it's a nice way to remind yourself that retail company X is not they actually don't matter at all, and helping humanity like smiling at people being present, that's actually what matters.

So Pouford thought, yeah, that's an excellent one. Perspective is everything it is. Don't get caught up in corporate America or yeah, whatever country you live in that you're listening from. Yeah.

I remember Ben's old manager, Alex. I was chatting with him. He's now a Skip Skip manager for me, and I was like, damn, I'm kind of burnt out. These these projects are boring.

And he was like, in the nicest way possible, he was like, shut up. Your life is great. Have perspective. And I was like, now that you put it like that, that doesn't make sense.

I'll be happier and it actually worked. Yeah, exactly. It's really easy, I think to convince yourself that you're suffering through stuff that that's like if you have something that you're doing that you really enjoy, and then you have too much of something that you don't enjoy that you have to do it can. Like our brains are just programmed to just want to do the thing that we want to do, and.

Sometimes we'll rush through that stuff that we don't want to do or just dread it, like, oh man, I got all these meetings that I got to sit through. Yeah, sometimes just having a perspective shift and be like can I make the most out of this stuff? Sometimes I try to, like if I know I'm going to be in a meeting that I don't really want to be in, or I don't do it so much anymore because I don't have non essential meetings anymore, but I used to have a ton of them, I would think of interesting things that I could do, like during that meeting while still paying attention.

Can I get somebody to say the same obscure word eight times in this Do things that entertain myself while still paying attention to what's going on? Or can I use the same very obscure word twenty times in this conversation. I'll keep tally me and one of the executives do miyos? Whoever can say more miaos during a meeting lens?

Yeah, from super troopers or wherever? Yeah, I think, yeah, But it's better if you pick a really obscure word from actual language and what just some synonym of a common word that is has. Now seventeenth century? Got it?

And just use that every time in place of this other word and see if anybody notices heard. Okay, so that's our seventh tip for Bernard. Find ways boring, stuff entertaining, and you will enjoy yourself more. Yeah, danger nut Yeah cool.

All right, So I'll quickly summarize not those tips, but some other things that stood out at least to me. If you're successful in your projects, that will lead to repetition and demand for you building the same thing and scaling it. So a, if you're a manager or a direct report, try to get diversity of projects for either counterpart. You can also try to automate a lot of this work.

And then finally, if you have people who can benefit from the skill and can scale out via humans, try to teach them the skill burnout is specific to the person and their desires. There's no specific playbook for what energizes and what drains. And that said, hobbies are a great way to have an outlet and then final point be the person that brings efficiency. There are ways to do it without seeming like a dick, but overall everybody will appreciate it, especially yourself.

Anything else that is good, cool, all right, Well until next time. It's been Michael Burke am my co host. But also and have a good day everyone.