In today's episode, we dive into Ben's experience in navigating the career ladder. Expect to learn why your leveling matrix is probably wrong and how you should actually spend your time to maximize career growth.

 

Michael Berk:

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 Databricks and I'm joined by my wonderful co-host.

 

Ben Wilson:

Ben Wilson, I write software so you don't have to.

 

Michael Berk:

Beautiful. Thank you for your service. So today we are going to be talking about something that is probably top of mind for, for most people in the work world. And it's about how you can make yourself indispensable, how you can get that promotion and how you can be sort of recognized as an influential person and someone that gets shit done. So starting off, uh, Ben, do you have any initial thoughts on how the career ladder is structured? in most organizations.

 

Ben Wilson:

Um, depends on what department you're in and what the overall general culture is, as well as the size of your company. But.

 

Michael Berk:

Let's focus on machine learning and sort of that applied data science to ML ops engine.

 

Ben Wilson:

Sure. If you're working at a startup, small size company, you're more than likely not even looking at a career ladder. There's probably one, maybe two job titles that you could be seeing in your first three or four years of the company starting. And if you're a data scientist, you probably hired, unless you're a founder of a company that's focused purely on data science You're probably not in the first 20 or 30 people hired for that company. If you're an applied data scientist coming in to work at a company that's not focused just on ML, um, then you're probably going to be the first one. Maybe it'll be two people hired, but you're both just going to be called data scientists, or maybe one's data scientists. Another one's like MLOps engineer or pick your superficial job title of the week. that somebody's going to create to make people feel like more important and keep them in a job. And that's going to be your job title. There's no real concept of advancement, but once you hit a critical mass at the size of a company as it's growing, the questions are going to start. A lot of people in like backend or front end engineering, which would be a counterpart department to the data science group. Uh, and data science could be embedded with them or something, but they're going to have structured levels because this has all been industry standardized over many decades and people have those expectations of like, Hey, I'm an L6 engineer over at, you know, this company. When I moved to my next job, I want to be an L7 because I have 15 years experience building this stuff. And I know all this stuff and I can get all this done. So data scientists don't generally have that. at a smaller company because there isn't really an industry standard right now. You have so many different job titles that are thrown around in different companies. I've seen people with very fancy sounding job titles that are basically doing what I would have classified at previous roles as an analyst role. Yeah, you know how to query tables. You know how to build. reports and do analyses and you can figure out business questions. Like a lot of companies have called us BI analysts, business intelligence people, but they now have this role title data scientist somewhere. And then you go to a different company that maybe is more technically focused and that's the primary role is science and engineering. And somebody with a job title data scientist. is implementing new algorithms from scratch. So because of that disparity of you have these people that have the same job title and their experience and skills and the capabilities are so wildly different, there's no leveling that's consistent. You can look at a software engineer like an L4 software engineer. coming from one company to another, people have an expectation of what they're capable of doing. You're not going to take them, hire them as an L5 and then say, Hey, we have to, we have to build this whole new service from scratch. Uh, you got two weeks to design it, get the approvals, and then start working on engineering design docs and start working on the first couple of feature requests. You got this, go. You're not going to do that. Cause the person's completely what is going on? Like, I don't know any of this stuff. I've never done this before, but you can hire an L7 and give them that a same assignment they'll be done before the two weeks is up of everything. And it'll just work. So, I mean, if they're, if they're good, um, so data science, you don't quite have that, but within the confines of a single company, when we move on from that startup phase and levels start getting created, depends on what the mission is. because there's no definite definition of what capabilities and competencies are, that's going to be defined by somebody at that company. Now that somebody could be a data science lead who they have their own history and their own expectations of what people should want. They'll probably meet with a couple of managers and HR, and they're going to draft up some sort of leveling system. Hey, we now have 10 data scientists and people are wondering when are they going to get a new job title and how do we create structure around this? HR is going to be pushing for that when you hire enough people. They're like, hey, if people don't get promoted, they're going to leave for greener past years. Be surprised how motivating it is just a made up job title is for a lot of people. Some people

 

Michael Berk:

Yeah.

 

Ben Wilson:

don't care about that. They care about the money or the benefits. But there's a lot of people that they... They really feel proud when they can say like, oh, I'm a principal data scientist. It's like, yeah, you're still doing the same work as the other people. You're just

 

Michael Berk:

Right.

 

Ben Wilson:

more experienced at it.

 

Michael Berk:

Quick question. So in your experience, how aligned are those career ladders with the actual roles of the job?

 

Ben Wilson:

It depends on the company. I've worked at places that so much thought has gone into leveling within an organization that when you look at like a week in the life of these different roles, they're actually aligned to what those roles and responsibilities are and they're meant to be more complex and also differentiated. So you get specialization as you move up and that's what you'll see in an engineering at a serious tech company, the lower in the totem pole engineers are going to be focusing on discrete things like, hey, I need to implement this one feature, which is a part of this bigger thing. And I'm focusing on just getting this right and making sure that my tests are all passing. And then the higher that you get up to a certain point, you're... doing more broad things like you're designing the entire service or you're designing a whole new implementation of something. And you might not build the whole thing yourself. You might have some of those more junior people help out and build other components, but you're building the core critical component, like the critical path MVP part of that. And then you get to an even higher level and that's more of your strategy. You're thinking about what should we be building the next three quarters? I'm going to do research or I'm going to work with different people. I'm going to communicate with people across the organization and make sure that we're focusing our entire organization from an engineering standpoint on the right problems and preparing for that and having a lot of meetings and making a lot of decisions about what that will look like and what we should focus on and not focus on. But for data science, with the exception of certain organizations like the big tech companies, going to have that in place yet. You're like the tech lead, the lead data scientists or principal data scientists. They might be doing some of that, but generally they're not, they're not the ones in the decision seat of what major projects are going on. You have customers, which engineering has customers as well, but you're more dependent on what exactly the business use case is going to be. in order to build something that's successful. And you also have a much higher barrier to entry to have a lay person interfacing conversation.

 

Michael Berk:

Right.

 

Ben Wilson:

People understand software generally, like a lay person, you could say, Hey, we're building this thing that allows you to input a bunch of data in a spreadsheet and we're going to load it into a database that you can then query or we're creating. a service that you can go to this internal website that allows you to do these things with data and you can look up our customers and get the history of them. We're creating something that's tangible that people understand. They don't need to understand the backend components of that and they would have no idea why they chose the implementation details that they did for service level stuff. That's pure engineering. But they can understand that broad concept of. What are we building and why are we building it this way? Data science projects are different. So it's like, what's the actual use case that you want to solve? I want to predict, you know, whether this thing is going to happen or not. Like, should we invest more in this area of the business? I want reports

 

Michael Berk:

you

 

Ben Wilson:

on projections of conversion rates or something for our customers. And we want to build, you know, a custom application that's going to... you know, help our customers make purchasing decisions better, whatever it may be. That's so vague and broad that the data scientists can understand that. And that tech lead can probably start formulating, okay, here's probably the domain that I'll be talking about or thinking of that we would implement this type of model, but you're not going to start talking about a product that's coming out of that until a much longer conversation. And it's not like you can just take that on as a lead data scientist and say, Hey, I know the tech stacks that we're going to be looking for. I know what model we're going to be using. I know where the data is. You don't know any of that stuff. You have to go figure that out. So the separation between, well, a junior data scientist, they're just going to be building logistic regression models and time series models. And then the senior data scientist just going to be working on deep learning. I've never seen that happen.

 

Michael Berk:

Yeah.

 

Ben Wilson:

It's always like a community involvement and the leveling is more arbitrary. It's more assigned to how long has this person been at the company? How good are they? How much do people like them? How nice are they? All that stuff is super important by the way. And how many major projects have they shipped? And that's really what defines that leveling, which is, but when that project comes, it's probably going to be. A large portion of the team is going to be focusing on that together.

 

Michael Berk:

Right. So that's actually really interesting that you say that because it sort of aligns with my experience. I've worked a couple of data science jobs and at basically each company, the leveling is quite different. And one thing that I found really helpful in my prior role is that each leveling, each level had different levels of how much you should handle ambiguity. So junior person will just be given tasks and they should have a lot of handholding. and should do a good job implementing. Sort of middle should be able to scope their own projects, determine what's valuable and what's not, but will still rely heavily on managers. And then senior should be able to take a project end to end and even delegate to lower level people. I think that's a really, really good leveling criteria. But a lot of these other things, as you mentioned, is like, they're sort of fuzzy and ambiguous. So how nice is the person? How many major projects have they shipped? How do you define major? How do you define shipped? What if something failed that was out of their control? If I'm given all of the hardest projects on my team and I ship five of them and another person is given all the easiest projects on the team and also ships five, that should probably be taken into account in the perfect world. So are there sort of rules that you can think of that would indicate that someone should be or should not be promoted? beyond sort of these fuzzy things. Like, can you give me a case statement or an if else?

 

Ben Wilson:

Um, I wish the world was, was organized that way. Um, I've never seen promotions work that way, um, about pure objective measures of something like, even if you were to attempt to do that and say, we're just going to let data decide who gets promoted and maybe our, our requirement is number of lines of code committed. and approved to be merged into master or main. What if you got one person on your team that's just doing docs and that's all they do? Like writing guides. You could be easily looking at them being 10x the number of lines of codes committed to your repository than anybody else on the team. So that's kind of out the window. Well, what if you put a heuristic on that and you say, all right, for, you know, every 50 lines of docs counts as one line of code. Is that fair? Probably not. So applying rules like that, or to take your example, the project complexity. It's almost, I think, impossible to do that in a purely data driven way without somebody assigning the amount of complexity of that project. You can't look at number of lines of code or size of artifact or, you know, the projected amount of work, like how long, how many person weeks was this supposed to take? and we'll assign some formula associated with that and number of lines of code, people will figure stuff like that out and start gaming the system. And it will happen, it's human nature. If you're all of a sudden like, hey, I'm measured in my job performance by number of lines of code written. All right, I will write the most verbose code possible. How do you like for loops? So you need gatekeepers in place for... stuff like that. And in order for that system to function correctly, the gatekeeper has to be aware of stuff like you need your technical lead to be super stringent about code quality and not allowing people to do stuff like that. Like, hey, this implementation, I kind of see what you're doing here. This sucks. This can all be condensed down into four lines of code. Please rewrite the 400 that you put here, because this is ridiculous. It's really hard to read. Um, so you can do that, but then you're also going to need the tech lead to, to, and the manager to be aware of what that project is, how complex was it? How ambiguous was it? You could provide sort of rating scores to all that stuff and keep that in a private spreadsheet. And it's like, Hey, this person, this quarter, they worked on a level five ambiguity, a level three complex implementation complexity, and a level like interfacing with other teams. So like cross-functional operations. And that might give you a lot of points in how much you got done if you were successful with that versus somebody that got one straight across the board because, except for like number of lines of code, like, you know, number of lines of code five and then complexity one didn't have to interface with anybody. It's just an internal thing that they had to work on. Like maybe they were just writing integration tests and, or refactoring code to, to go into a new framework. Yeah, it takes a lot of time, but is it challenging work? Is it what should green light you for a promotion? Probably not. But it shouldn't hold you back either. So that there's always a subjective nature to it. And that's what I've witnessed in every company I've worked for is... Yeah, what you get done, it seems like as a technical person that that's what everybody should be judged on, but that's really not the whole story. There's a huge amount of subjectivity that goes into it for a reason.

 

Michael Berk:

Yeah. That, okay. That makes sense. I think I'm, I'm bought in. My next question is around how you should decide what to and what not to work on. So let's say you have a 40 hour work week and you were assigned a bunch of projects. Let's say they take you anywhere from 20 to 30, let's call it 25 hours. So that gives you 15 hours of your work week to stare at your screen. Bre read emails. That's one option. Another option is to go out and learn stuff and like read a book, maybe get a certification. Another would be to volunteer within the organization and contribute to other initiatives. And there's many other ways that you can spend your time. So how do you think about spending your quote unquote free time?

 

Ben Wilson:

You mean like back when I had free time, which was

 

Michael Berk:

Yes.

 

Ben Wilson:

many years ago. Um,

 

Michael Berk:

Will you

 

Ben Wilson:

now

 

Michael Berk:

still

 

Ben Wilson:

it's a.

 

Michael Berk:

carve out free time now, right?

 

Ben Wilson:

Uh,

 

Michael Berk:

Or are you just Swant2412?

 

Ben Wilson:

not really. Um,

 

Michael Berk:

Okay.

 

Ben Wilson:

so the reason, the way to get to a place where you're focusing on important things and you're consuming your time in a way that you're interacting with other people to like build cool stuff. Uh, it might not be things that you're directly assigned to, but it could be, this is just sort of a general pro tip for people that want to know. How do you become valuable as a data scientist, as an ML engineer, as an engineer, whatever? You can take that free time that you have, and everybody's going to have that exactly as you said. You're going to have that at first at a job. You'll be directly assigned 20, 30 hours of actual real work that you would, heads down, on the keyboard, banging out some code, banging your head against the keyboard when things are just continuously breaking. Everybody's going to go through that and then you're going to have some amount of buffer time where I think people get, they make an assumption of what they need to do to get to like a position of higher value within an organization or working on more interesting projects. They think that the way to do that is by learning like, Hey, I'm going to spend this 10 hours and I'm just going to read books. or hey, I'm going to work on project code that I have this cool idea of something I want to build. Maybe people will use it. That stuff is valuable. It's important to just crank out code that maybe you never show anybody. And that's building up your technical skills or keeping them sharp. Super valuable. But what's more valuable is making yourself useful to others. The way that you can do that is I guess the one thing that you could focus on. And what I found works really well is listening. And what I mean by listening is not just hearing what people are saying and paying attention to exactly the things that they're talking about they're working on or things that are happening at the company, but listening and digesting. the main thematic elements of what they're talking about. Are they talking about a project that they're working on that they don't have enough time to get everything done? Or there's something that you could spend some of your time capital to help them out in some way. That doesn't mean go to another department in the organization and be like, hey, can I do a PR for that part of this? They're going to be like, what are you talking about? Uh, we're not, we're not letting you do that, uh, because you probably don't have context, but more like people on your team, people that are doing the same sort of work that you're doing. Uh, you're in a data science organization. You have free time. Somebody else is working on a project. Pull their code, like fetch their PR from, you know, their branch and understand it. maybe make comments or ask them questions about, Hey, I think this might be a really cool idea. And instead of just being the idea person that says, I think it would be really cool if you did this X, Y, and Z. Most people that are knee deep in a project do not want to hear comments from the peanut gallery of like these amazing ideas. It's usually, hopefully your work is scoped beforehand and you know what you need to deliver and that you've probably already thought about that cool idea and it's out of scope for what you're working on right now. But if you say, you know, if you ask that person like, hey, is there another follow on piece of work that you just don't have time to do? Or hey, do you want somebody to write the docs for this? I'd like to understand what you're building. And I think the best way that I can understand it is to write the examples or write the docs for what you're building. I think most people are pretty cool with that. They're like, thanks for helping out. Like, are you sure you want to do that? And like, yeah, yeah. It, it hits on so many different levels of being like a really good colleague. You're learning new technology because you're looking through somebody else's code. You're seeing how somebody else works and you're also helping somebody. So don't ever underestimate the power there is in being. a helpful human being, particularly in a technical environment. It is so valued if you're willing to take on work to help somebody else, but that work that you're taking on has to be something that they need to get done, but they just might not have all the time that they would want to do. It's amazing when you start doing that. You build these... It's not really, they're not friendships, but it's, it's like, you have this relationship with this person where they know that you have their back if they get swamped on something and you know that they have your back and that's the start of building a really good team cohesion when everybody is looking out for one another and you're like, Hey, I got free time. I'm willing to, to help you out and whatever you need to do. Even if the work is super boring. I mean, I don't know a lot of people like writing docs for stuff. There are some people that do, but.

 

Michael Berk:

psychopaths.

 

Ben Wilson:

It's important work that should get done. And if you're willing to volunteer for that, and even if it's excruciating to do it, if you set yourself up mentally to prepare for, hey, I'm not doing this to work on docs. I'm doing this to help my coworker and learn something new and get another set of eyes on this implementation. So that maybe you catch something that they missed and you can catch that earlier on and be like, Hey, I'm testing this out and I don't know if this is exactly how we want this to work. You find something like that while somebody's working on something, they're going to be ecstatic. They're going to be like, thank you for catching this is awesome. They're going to want to collaborate with you more. Those messages are what sets promotions apart. When that's why a lot of companies do peer review. That's the whole reason for it is, are you a good team member? And it's not being a good team member in technical terms is not what a lot of people think it is. It's not, nobody is like, Oh yeah, that person is amazing at writing Python or writing Java. Nobody writes stuff like that on peer reviews. And if you do. Please don't. People are writing stuff like, hey, Michael was super helpful on this project or helped, took ownership of this major initiative that we're doing and took on all of this additional work on like just volunteered to do it so that he could understand how to make the product better. That's the stuff that people pay attention to and people in management when they read stuff like that, they're like, wow, this person is going. That's the above and beyond stuff. Like you're being a team player because anybody who's managing an effective organization full of technical people realizes that team cohesion paired with technical excellence is the most important thing that that team can focus on. And if everybody likes one another and they're all working together and people are happy, you keep a really good team around that is high performing that people will, they're just motivated. They want to work with one another and get things done. And you have less issues, less service disruptions, better features. You just are building a better product, which makes the company more money, which makes the manager look better and everybody becomes more successful. So approaching technical, technical free time from a project, from a non- egocentric place, or it's not, Hey, I can get better by spending my time working on these things. I can get these certifications or I can do this project that people are going to recognize. Nobody cares. Um, it's just your own ego cares about that. It makes you feel better, but management's like, okay, you built a project. Great. Why didn't you help out the team when they're struggling with this thing? So Thinking of the team first, of your coworkers first, and helping out. That's the way that you take that 15 to 20 hours of free time that you have during the week, that'll evaporate. But you're trading that off to people on your team, loving to work with you and trusting you, and you get brought into greater and greater complexity of things that you're going to be working on. So

 

Michael Berk:

Got

 

Ben Wilson:

that's

 

Michael Berk:

it.

 

Ben Wilson:

my

 

Michael Berk:

All

 

Ben Wilson:

take on it.

 

Michael Berk:

right. Some devil's advocating questions. First one is, will your learning slow down if you are just helping people? Because I could go in an isolated box, take a Coursera course and become an expert in XYZ theoretically.

 

Ben Wilson:

Arguably. I doubt it.

 

Michael Berk:

But if I'm working on the job on someone else's project, I'm sort of at the whim of what is being worked on. So I have less freedom over selecting what I wanna be working on. And so therefore I might be learning less valuable things. What do you think about that?

 

Ben Wilson:

My argument to that is if you're the valuable person that everybody sees is, you know, performing GSD work. You know, we talked about before recording, getting shit done. If you're that person and people see that you're 25 or 30 hours of assigned work in that week is going to be the hard stuff because it could be like, Hey, Michael's killing it. He's doing all this like extra stuff, helping out the team. The management will start recognizing that the team at a higher functioning level is capable of taking on as a team, more complex tasks. Cause they're like, Hey, everybody's just like knocking out of the park. We're, we're just tearing through all of our OKRs. We're getting all these features released. They're stable. They're working. People are happy. You just signed up for more complexity, which is a good thing. You're going to get more interesting projects. You're going to be like, Hey, I know we could solve this problem with this old school methodology, but we really want to implement this new project with the latest and greatest because we think that it's going to solve the problem a little bit better. Well, management, if they have faith in your team and that everybody's working well together, you might be one of the two people or three people that are sent to, hey, we trust you. go figure out if this is possible. And that's when you're gonna get exposed to, you'll get to a point if your company functions correctly, where you'll be exposed to stuff that is so far beyond your realm of safety and comfort that you might get pushed to a place where you get a little bit scared. And that's kind of what you want. Where if management has so much faith in you and your team leads have so much faith and executives have so much faith in your team. that they're willing to take a gamble and are okay if you fail. You should have a safe environment like that. But they know that you're going to go through the due diligence and you're all going to work together and have each other's backs and you can tackle anything together. Then they're going to let you go and go nuts.

 

Michael Berk:

Yeah.

 

Ben Wilson:

They'll be like, oh, you want to try out this brand new thing that is so experimental that we have no idea if it'll work? You guys have been... knocking out of the park the last six straight quarters, yeah, take a month and figure out if we can do this. We trust you.

 

Michael Berk:

All

 

Ben Wilson:

And

 

Michael Berk:

right,

 

Ben Wilson:

because

 

Michael Berk:

well here's...

 

Ben Wilson:

of that cohesion, you're going to do a good job evaluating that and come to a conclusion very early.

 

Michael Berk:

Yeah. So I agree that it would, it optimizes your increase in the level of complexity of your work, but let's say I know I want to learn time series forecasting. And there's just no one in my vicinity that is vaguely related to time series forecasting. Do you think that a, my interest in learning time series forecasting is misinformed or be like, like basically how do I go about learning what I want to learn? if maybe the vicinity isn't conducive to that.

 

Ben Wilson:

It's, that's similar to, let's say you and I worked as data engineers in an organization. There's no data science team to speak of, or maybe there is a data science department, but we don't work with them. And you have, you come to me and you're like, man, I really want to learn machine learning. I think it's the future. I'd be like, cool, man. Uh, how are you going to learn it? That's kind of the, what you're asking about is like, how do you get into something that either is so far removed from the department and your role, or the company is not focused on it. So if you want to burn company time learning something like that, good luck avoiding getting fired. If you're doing that for a large amount of time during like working hours and your rest of your responsibilities aren't being met. If you want to learn that because you're really interested in it and you want to see about applying it, That's what nights and weekends are for, man. Like, you know, you're, you're interested in something that you just want to learn more, go pull in an open source dataset and hammer through it, figure it out. And if you can find a way to make that something that is useful to your company, build a really good demo that's based on that open source stuff that you did over the weekend. It shouldn't take that long to like do a proof of concept of something new. It doesn't have to be perfect. It's not even an MVP. It's just a demo. Like, Hey, I have this idea. Maybe your company has, maybe the company that we work for has a hackathon time. And you want to say,

 

Michael Berk:

true.

 

Ben Wilson:

I want to do time series forecasting for the hackathon. That's free green lit time for you to do whatever you want to do with that. And it's on the clock, you know, so

 

Michael Berk:

Right.

 

Ben Wilson:

spend the time doing that build a cool demo that people will give a big thumbs up to. If it's. if it's useful. That's what I recommend for anybody who wants to learn new things in their field is to just build something. You learn way more than if you say, okay, I'm going to take a course in this. I'm going to buy all these books in this topic. I'm going to read them all. You understand the high level stuff from that, or you understand the concepts and the theory that way. But that doesn't exactly translate into doing something for a company that would have eventually potentially make it into production. What preps you for that is building something and seeing what are these libraries like? What are their APIs like? What's the performance like? What happens if I take my dataset and replicate it 1.4 million times? Does this just like blow up? Does it even run?

 

Michael Berk:

And

 

Ben Wilson:

Doing

 

Michael Berk:

uh...

 

Ben Wilson:

those experiments and understanding. the nuances of how these algorithms work or how the libraries and the APIs work. You'll learn so much in such a short period of time that if somebody looks at that demo and says, Hey Michael, we really love this. We want you to take two months and build out an MVP for this. That's when you go buy the books and

 

Michael Berk:

Right.

 

Ben Wilson:

spend a weekend like tearing through them and getting up to speed on what are the things that are going to burn me in this project. Um, or just read stuff online of, and I don't mean read the copy pasted blog posts that 733 people wrote about the profit library, um, where the code is all exactly the same in all of them.

 

Michael Berk:

true.

 

Ben Wilson:

Um, it's go read the API docs and see their examples and read notes in the source code that some developer wrote in there, like reminder. This doesn't work well for this thing. Sometimes that's not in the docs, but that's in the code. And you're like, Oh, that's why that, that argument is set like that. Got it. Keep notes of as you're reading through that so that when, you know, Tuesday morning starts and you're ready to actually do it, like start on design docs, you are having an informed state and position of how you're going to approach this project. Where's my data at? How are we going to get it? how, where are we going to run the models? How are we going to run the models? What, how are we going to do tuning? Start planning all that stuff out and then start cranking out code. But

 

Michael Berk:

Cut it.

 

Ben Wilson:

if it's just purely, Hey, my company doesn't believe in deep learning where we only use linear and logistic regression and decision trees. And I really want to get into time series forecasting and deep learning. And I want to get into LLMs because that's the big hype right now. And your company just doesn't have the appetite for that. Find another job. Cause you're never going to convince them to build a project out of that. If culturally there's resistance to change and you're somebody who really wants to go and, and actively learn and build new things, you'll never learn what you could learn at another job who's interested in pursuing that sort of technology. Cause there's plenty of people that'll backfill you that love Stability that love

 

Michael Berk:

Hmm

 

Ben Wilson:

like, Hey, I want to fine tune this model that was, you know, originally built 13 years ago. And I want to make sure that I can eke out a 0.05% improvement in RMSE. There's people that live for that stuff. But if

 

Michael Berk:

Yeah.

 

Ben Wilson:

you're somebody who's not one of those people, update your resume.

 

Michael Berk:

Got it. Are there any other things that you should explicitly not do with your extra 10-15 hours a week?

 

Ben Wilson:

Lots of things. I'd say the biggest and most obnoxious thing that I've seen people do with extra time is doing sort of hero development where they have this amazing idea that is in their head and they want to do something to get recognized. So nobody's asking for it. Nobody cares. Or you haven't validated it if anybody cares that you're going to be doing this. and you're trying to do something in a silo, like alone. You don't want anybody seeing what you're doing. You don't want to hear any feedback about like, is this a good idea or not? You want to just like surprise everybody and bring this nice, wrap present to everybody. And your ego is going to start building that up in your head of like, man, people are going to be amazed that I built this and I'm going to get promoted and I'm going to get all these cool projects because of this. Never happens, man. Like ever. What does work in that situation is before working on that project, you go and talk to 50 people and 48 of them are like, dude, that's a pretty good idea. Uh, do you need any help on that? You're like, yeah, I'd love for you to review my plan. And you get 12 people that are super excited to give feedback on your documentation that you're going to write of what you're planning on doing. And then in the process of you building that thing. you get four or five peers who are giving you direct feedback on the implementation and you get three other people who are willing to test it and everybody's excited about it. That goes over so much better when you're presenting something to management or to the business at large, where you have all these people that believe in this because they were involved in it. And they, like part of them is in that because their feedback is what helped guide that to be better than it would have. if you had just built it on your own. So that's another big thing that I see people, I've seen that, I don't know how many hundreds of times in my career, somebody who wants glory alone. And I've actually never seen it work out ever.

 

Michael Berk:

Yeah,

 

Ben Wilson:

I have

 

Michael Berk:

I think

 

Ben Wilson:

seen

 

Michael Berk:

it's...

 

Ben Wilson:

people build something alone that they got feedback from people and just, you know, okay, here's the struggle that these people are having. I'm going to go off and build that thing, but it's not built from their own head. It's built from what people were complaining about. And it's a pain point that they have. Those projects are successful and those people generally, you know, get asked to do a higher level of responsibility at a company, but it's a huge gamble. And I've seen that succeed. I'd say less than 2% of the time,

 

Michael Berk:

Cheers.

 

Ben Wilson:

just like certain sorts of people can do that really well. But most people work, it works much better if they get a community to help them out.

 

Michael Berk:

Yeah, there's this stereotype of a genius in a basement that codes up Linux or codes up Apple or whatever it may be. And Ben and I were talking at length before we started recording about sort of how innovation actually occurs. And all these people, like let's say Albert Einstein, they get all the credit, but there were tons and tons of supporting research that he was building upon. There was also a lot of colleagues that I'm sure were invaluable in his brainstorming sessions. And also there were other people that quote unquote invented the same thing almost at the exact same time, if not a little bit later, if you waited five years, someone else might've come up with a similar theory. So these zero to one jumps in product development, they seem like zero to one jumps because that's what the outside world sees, but when the, where the sausage is actually made, it's just day in, day out, pushing against the same structure and trying to get it to work.

 

Ben Wilson:

Mm-hmm.

 

Michael Berk:

So yeah, people working in isolation, it's sometimes fun and you can ego trip for a bit, but it's not the best if you're looking for results.

 

Ben Wilson:

It's not aligned to a reality. It's a story that people who are unaware of how these things work, tell themselves and they convince themselves that I can do the same thing. Any technology that people are excited about these days, you talk about like LLMs we've talked about a bunch of times. The team at OpenAI, that's not one genius sitting in some cubicle. sure they don't have cubicles at open AI offices, but wherever they're working from, it's not one person doing that. That is a ridiculous army of humans who are all brilliant and know how to work with one another and think through some really challenging problems. They also partnered with a bunch of other companies to build infrastructure to get these things off the ground. They built upon decades and decades of research and learning that have happened. So they're the latest culmination. There's other services that are out there right now. It coheres another one. There are these people are dropping these other big language models that are highly advanced and can do all these things. It's like we talked about last week's episode or the week before with the sort of the steam roll effect. Once that flywheel starts getting enough momentum, you start innovation starts coming out more, you know, faster and faster, but there was an unbelievable amount of people that were behind getting that wheel moving in the first place. Sometimes for marketing purposes or political purposes, or it's just how things go at a particular company, there's one person's name or just a handful of people's names that are attached to some big thing that comes out, but it's exceptionally rare that it's just like one person that does that. It's always a huge group.

 

Michael Berk:

Yeah, got it. Cool. We're actually sort of coming up on time, so I'll do a quick wrap. Uh, and then we can let you guys return to your amazing lives. So sort of in summary, when thinking about leveling and making yourself indispensable, there are a few axes to consider, and this is typically. Constant between a bunch of different roles, but for each role, whether you're in technical or non-technical capacities, it will definitely change. But the main axis is value. So that can be defined many different ways. The way that I've seen it defined a lot is how well you can handle ambiguity if you're given a problem, how much hand holding you need to solve it. And also Ben mentioned that sort of the amount of planning and direction providing that you give to your team, typically as you get more senior, you have to manage a bunch of different politics and a bunch of different perspectives and distill that into one direction from your team. that it's sort of, they're sort of isolated from all of that chaos. So those are a couple of axes, but again, think about for your specific role, what is value and how is value defined? Another thing is when thinking about leveling, especially from a managerial perspective, it's important to rate projects on consistent rules. There's a lot of soft touchy feely ways that people can get promoted. But one example for keeping it consistent is looking at complexity. size and maybe sort of controlling for external challenges and using that to see how difficult a project was to actually implement. And then let's say you have some free time because you're that awesome and you want to do some additional things that might help you get recognized. Some don'ts suggest cool stuff that increases scope. No one likes that. Also building stuff in isolation. The success rate for that can be pretty, pretty low. And then also something we didn't really touch on, but, uh, was sort of hinted at is pitching yourself to your manager or sort of advocating for yourself. Your word with other people when you're not in the room is actually what is valuable and you selling yourself isn't, isn't super important. So what instead you should do is make yourself useful to others. And this can be volunteering to do boring stuff, such as write docs. maybe do some unit tests or whatever it may be, whatever is necessary to a project success that a person doesn't want to do that can sort of help you get in the door and learn about that project. And this is an art here where you sort of need to find an intersection between your personal goals for learning and then helping the organization. And it's definitely not a zero sum game. There's certainly some projects somewhere where one plus one equals three. So Ben, anything else you want to add before we, before we. uh, end it off.

 

Ben Wilson:

No, it was perfect summary, man. Particularly the last part about not, not being zero sum. It rarely is zero sum. It's always. taking on that stuff and helping out, it always benefits you and the company and the group and the morale of the team. So it's, I don't know why people don't do it more.

 

Michael Berk:

that. Yeah, I wonder if you listeners have ideas, let us know. Cool, well until next time it's been Michael Burke and my co-host.

 

Ben Wilson:

Ben Wilson,

 

Michael Berk:

Have a good day everyone.

 

Ben Wilson:

take it easy.