many engineers have misunderstood the value they bring to the table and therefore have misunderstood so much about the transition that the industry is making into agentic coding and ai driven workflows and in today's episode i want to help you understand more about your valuable skills more about what this shift this kind of seismic shift in the industry really means for you but most importantly i want to give you a framework for thinking about building skills going into the future and perhaps you know understanding the skills that you already have that maybe you've discounted or didn't realize somebody would write down on a list of skills my name is jonathan guttrell my goal on the show is to help driven developers like you find clarity perspective and purpose in their careers and when we talk about finding purpose in your career a lot of what we're talking about there is finding value things that you value doing ways that you value spending your time we've talked about this annie dillard quote many times on the show before how you spend your days is of course how you spend your life that might be a little bit paraphrased but the fundamental idea is that the things that you're doing right now the momentary work that you're doing minute to minute hour to hour that becomes how you spend all of your time of course there's critical moments there are you know high intensity moments this last couple of months is going to stand out as high leverage for most people in this career right it's going to change the trajectory of a lot of careers but ultimately the things you're doing over and over the way you're spending your time this is how you spend your career it's how you spend your time and it's how you spend your career it's how you spend your life so finding something that you value is not some lofty goal it can be something as simple as enjoying the kinds of tasks that you are assigned the kinds of work that you're doing with your team the kind of domain you're working in the actual technologies that you're working with all of these things are a part of finding your values it doesn't have to be a lot of work it doesn't have to necessarily be platitudes and philosophy all the time right it can be as simple as minute to minute what you're doing with your hands your mind your body your your brain etc right okay with that said so many of us so many engineers have misunderstood uh value as it relates to the rest of the industry and the way that we're doing things right so many of us so many engineers have misunderstood their role in a business context and more specifically we have kind of adapted or adopted the message that what we do as engineers is code what we do as engineers is write code build features build software sure but really so much of it has happened in the past and it's not something that we're going to forget about it's not something that we're going to forget about it's not something that we're going to forget about it's not something on our ability to write code and some of this is because it's an easy way to grasp and understand the job it is a uh uh you know a unique skill that not everyone has right uh there are a lot of nuances to it it is the thing that we believed that we learned in order to get into the industry It's the thing that we engaged in by reading books and blogs and going through video tutorials and building pet projects on the side to try to learn how to code. There's products on the shelf in big box stores teaching kids how to code. So it makes plenty of sense why we would believe that our fundamental skill, the thing that we bring to the table as software engineers, a major flagship at least, is writing code. And you wouldn't be blamed for believing that. In fact, most of you probably still believe that code is a critical part of your jobs. That it's a valuable thing that you can do. But I want to make the argument to you that... Viewing an engineer's value as whether or not they can code is dangerously reductive as we probably many of you have learned. If coding is the value that you bring to the table, then AI is threatening that value. If AI can code as good as you, and for many tasks we've found that it can. Not every task, certainly, but for many tasks we've found that AI can solve the actual coding problem. The sliver that is implementation of some specification. If that is the value that you bring, then you're in kind of a very narrow place. And so I want to make the argument that... We have confused the things that we value, the enjoyment that we get from the coding process, with the things that are valuable. From a business sense, from a role perspective, even from a true engineering perspective, we have overloaded this concept and we've underserved other concepts. Right? Okay? And so as a result of this, we have a bunch of skills that we may be underutilizing or undervaluing. In this sense, I mean undervaluing in terms of market value. We're not tapping into the things that we could be tapping into and generating value from, because we've seen coding as kind of the king of the hill for so long. Right? So we're going to talk about... We're going to talk about ways of thinking about the value chain of your skills. And, you know, another thing that kind of tricks us or tricked us early on is that we had this access. If you said you could code, if people knew you could code, you have this new kind of gate opened up to you. And it's a career-changing opportunity. Right? And for many people, it started out as just that, that you were given a coding task to do. And, you know, I've talked to plenty of people as a result of this podcast who, they were in a totally different field and they learned how to code in order to automate some of their tasks. And so then they decided to jump in headfirst. And the truth is that coding is a small slice of what an engineer does. And good engineers, this will resonate. You may not necessarily, cognitively, you may not have arrived at this articulation before. But what I'm saying will resonate because if you think about the last, you know, project that you were involved on, our perception is that... The code is the important thing. And that, you know, building with code was the important thing. But most likely, the things that made you valuable to the team were ancillary to that. There were different skills. We're going to talk about some of these skills right now. For example, you may have a lot of domain knowledge. You may be an expert, subject matter expert in the field. And so you know more about intuitively what the right kinds of things are. You know more about the user base or you know more about the actual domain itself. Right? There's something that is kind of adjacent to coding that is a different skill, which is technical ability. Right? In this specific sense, what I mean is... The ability to understand very information-dense topics. Right? Information-dense topics. Or highly complex flows or systems. All right? So technical doesn't always mean software-related. It doesn't necessarily mean, you know, technology, to be clear. Right? Technical, in this sense, just means it's very detailed. Dense, information-rich. And it's not something necessarily that, you know, just anybody could pick up this information, learn about the key parts of it, understand, you know, how this system works, what are the interaction points, etc. And then to build on that technical knowledge and to be able to leverage that technical knowledge to make good decisions is another skill set. To be able to understand what parts of this system... Represent a risk scenario. Or what parts are likely to become a bottleneck with a certain kind of throughput in that system. Right? So this kind of systems thinking comes into play. On the totally, you know, opposite side of this would be something like the ability to understand the relationships of the teams. Or organizational design around a project. And how to avoid blocking each other. Or how to organize work so that the throughput of that work is efficient. Right? So maybe you're leaning more into kind of a managerial set of skills. But even your manager may not necessarily know how to connect that to the work itself. And so you... Maybe you're a tech lead, right? And you help the manager understand that, okay, well, actually, we need to shift this around. This team over here should own this service. And this team over here has expertise. They can own this for a while. And then we'll cut over. Right? There's a lot of this kind of process orientation. And how... Who's going to... You know, what are the marching orders? Who's going to be solving problem A versus problem B versus problem C? Where are the integration points? Should we slice it horizontally or vertically? You know, how does this all fit together? Both now and in the long run. What's the continuity plan if we lose the tech lead? These are all things that... You gain experience in your career. Part of what you're doing is coding as a result of what you decide or what you build with these other skills. And another example of this is purely relational. Purely relational. These are skills that help you uncover complexity. That help you... Push through really difficult periods in a company's tenure. Right? And it may have very little to do with the code that you're writing. But it has everything to do with the value that you bring as an engineer. You may be able to see... And, you know, I could keep going for a very long time here about all of the other skills that kind of sit outside or around or supporting. Your ability to code. So I want to give you a framework for thinking about skill development. And thinking about your existing skills. You've probably discounted a lot of the skills that you have. And if you're like most engineers. The advent of AI as a primary tool in your toolkit is both new to you. But it can also feel a little bit threatening. Because if you do believe, like most engineers have for many years. That coding is one of your. absolute critical value generating skills, and now there's something else that may be able to do that, you may feel fear. You may feel threatened. Similarly, we recently talked about this on the show. You may feel a sense of grief over losing something that you did value, that you enjoyed coding by hand. You didn't necessarily want to become a manager of a robot. So I want to give you a framework for thinking about skill development during this AI boom and beyond. We're going to do that right after we talk about today's sponsor. Your coding agents have access to your code base and probably more at this point. And maybe you've connected other tools via MCPs or you've built skills, but it's not easy to keep up with everything. And access doesn't necessarily mean true context. And your skills may be going out of date. Agents can't reason across MCPs very easily. They don't know your architectural decisions, your team's patterns, or, why the API was shaped the way it was in the first place. So agents can tend to look in the wrong place and deliver bad outputs, whether it's because it's old, it's out of date, or because it's totally wrong. Then you spend time correcting the agent, trying to teach it how to do it right next time. And maybe it will, maybe it won't. You're wasting your time and your tokens. Unblocked is the context layer your agents are missing. It synthesizes your PRs, your docs, your Slack messages, JIRA issues, and more into organizational context that agents actually understand. So they make better plans. They write higher quality code. They use fewer tokens, which saves you money and require fewer correction loops, which makes it faster. If you're running clogged code, cursor, or any agentic workflow, and you probably are at this point, Unblocked is worth a look. Get a free three-week trial at getunblocked.com. That's G-E-T unblocked.com slash developer T. unblocked.com slash developer T. Thanks again to Unblocked for sponsoring today's episode of Team. So I want to give you this, this simple framework, uh, a way of thinking about skill development. And how you can think about your existing skills and kind of map them. Um, the most valuable skills, the most valuable skills are the ones that have three things. All right. Three things. And when I say valuable in this case, I mean valuable to you and your career. Okay. One is they represent clear business value. All right. So they're valuable in the business sense. Okay. Uh, maybe we should say that these are, these are desirable skills or things that, that would make them, uh, useful, good skills to have. Right. Um, valuable in the business sense. So, so they, they represent some kind of clear business need or they meet a clear business need. They're durable. We'll talk about that in just a second. What, what does durable mean? And then they're transferable. And so you kind of know what business value means. Right. And so you kind of know what business value means. Right. And so you means here. Coding meets a business need, right? So that makes sense, right? We need something to exist to solve problem X. So coding in a roundabout way does do that. But there's other business needs that coding absolutely doesn't solve that you are solving as an engineer. Knowing what to build in the first place, for example, right? Okay. So meets a business need, that one's pretty clear. But what about these other two? Durable and transferable. Durable and transferable. And these are kind of a spectrum, by the way, right? You can have something that is, and it's not opposing ends of the spectrum either. You can have something that is durable partially because it is transferable and vice versa, okay? But I want to differentiate these because I think they do have something that is clearly differentiated between them. Durable means that this is likely to persist even if there are major changes in the industry, right? That means state of the art, in this case, agentic workflows are replacing coding, which means that coding is probably not a very durable skill on its own, right? So what is a durable skill? A durable skill, certainly relationship building, right? Soft skills, most of those are pretty durable. Something that would not be considered durable is a specific relationship optimization, knowing a particular person very well. That doesn't mean it's a bad thing, but it means that if you put all of your effort and attention, into, let's say, impressing your manager, right? It's a typical response to our jobs. That person seems to have the most power over my career. I'm going to pour a bunch of time into building a great relationship with them. If you do that, then it's very possible that the durability there is very low, right? If that person leaves for any reason, or if you get moved to a different team, it's not a very good, it's not a very durable, way to spend your time. That's arguable whether that would even be considered a skill. But think about this as places to invest, right? So you're going to invest your time in building, maybe you could call it a skill of knowing that particular person. It's really hyper-specific. What you'll recognize is with both durability and transferability, that we're going to try to abstract away from really specific circumstances, okay? Another durable skill is a skill that you can use to build a relationship. So if you're going to build a relationship, durable skill right now, especially, is understanding architecture. Understanding, in particular, software architecture, right? In this case, what we mean by architecture is kind of how does this system work together? And there's different levels and layers that you can understand this at. But the interesting thing about that is if you understand how architecture generally works, then you're going to be able to understand how architecture generally works. Then you can abstract as far as you need to, and the same principles apply, right? So if you can understand kind of at a micro level, you know, the architecture of this really specific routine or, you know, this particular part, then you can abstract and use very similar, you know, domain language, or you can use kind of the same kind of mental constructs to understand architecture at a higher level, right? All right. Durable skills tend to be the ones that take a long time to build. They tend to be the ones that are used in multiple industries as well, right? So this is the mental model. Think about what change would have to occur to make this skill obsolete. What change would have to occur? For soft skills, for example, you'd have to stop working with people for that to not matter anymore. And arguably, we're a long way off from that. Okay. So transferability, transferability. So we kind of touched on it a little bit with the, as I said, there's some crossover here between durability and transferability. Uh, being able to transfer between domain, for example, is, is important. Um, but I want to specifically, talk about transferability as you grow in your influence and scale in, in, in your career. So instead of just thinking about lateral transferability, in other words, does this skill apply if I work in a different industry or on a different team? Think about transferability as does the skill apply as I continue to grow in my career into more and more senior roles. A great example of this going back to the durability skills would be, relationship building. Relationship building becomes arguably even more important as you continue to grow up in your career, as you continue to grow more senior in your roles. So, uh, soft skills become more and more important. They are transferable, right? So you can kind of see the shape of this, uh, similarly transferable skills, uh, being able to deal with complexity, higher level roles. You continue to deal with complexity. You just deal with higher leverage complexity, right? But being able to analyze risk or analyze bottlenecks, understanding system level, uh, uh, you know, pros and cons of things, making better decisions, all of this is in the realm of technical thinking or, or thinking about high information density and high complexity, right? So lots of conditional thinking, for example, that's going to be transferable, right? A lot of times, what, transferable skills is a skill that you might see applied in a really narrow context, but the transferable part is whatever principles govern that same skill. A good example of this is understanding compound interest. We've talked about mental models a lot on this show, and we're certainly not the first to tell you, I imagine, that mental models from all kinds of backgrounds and disciplines can apply in other disciplines. Compound interest is a great example. If you have a 401k, if you are aware of any kind of investing portfolio and financing, then you know that interest rates create compound interest. What this means is that instead of putting money into, let's say, a paper envelope on your desk, which would just end up having the same amount of interest, you're going to have a compound interest. You can put it into an interest-bearing account, and that interest will grow. The important part, the insight, is that the interest grows on top of the interest that's already grown as well. Not only are you growing interest on whatever you put in that paper envelope, but now you're also growing interest on what you've earned in interest. This is kind of a difficult, and you can kind of even see the way that I'm describing it, is a difficult concept to grasp just using language the first time you hear it. But if you know what I'm talking about, you all certainly are trying to fast forward this section of the podcast because this is something that is very clear to you. As you build these models in your mind, and you also probably could immediately start to think about what you're going to do next, you're going to start to think about immediately recognize this if you've taken an algorithm course, that there's a transferability in compound interest because if you know a big O notation, then you know that compound interest is specifically an exponential growth pattern, and it would be big O of n squared. If you don't know what I'm talking about, you can go Google these things, and the visuals will show up, and you'll learn something new that you can apply. There's a lot of other things in your life where this particular skill of compound interest applies. It's not necessarily even a skill. It's understanding what it is. This idea is that you have transferability in this knowledge, in this applied knowledge. Arguably, this is a skill to be able to apply this thing that's in one domain to apply it to another domain. To be able to extract the principles out of that and understand how they apply in another domain. This is the framework. It's very simple. You want to optimize for skills that hit as many of these points as possible, that maximize on value, on business value, on durability, and on transferability. That's the important triad to make these skills long-term you more successful in your career. All right, so my argument here is, one, that engineers for a long time have, I believe, incorrectly believed that coding is their primary value that they bring to the table, perhaps the only value they bring to the table. And two, so if that's the wrong belief, then there's another kind of accompanying wrong belief, which is there's a bunch of other skills that you have that are actually on this list, right, that are valuable, that are durable, and that are transferable. And so the homework I'm going to leave you with is go figure out what those skills are. It's different for everybody. Not every engineer brings the same skills to the table. Go figure out which one you're going to use. For you are valuable, durable, and transferable. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Unblocked for sponsoring today's episode. Head over to getunblocked.com slash developer tea to get started today. Building your context. It's a free three-week trial, and you're going to have better context with Unblocked than you would if you tried to homespin a bunch of MCPs or figure out how they all map together. Unblocked. We'll do a much better job for you looking at all of your sources. Go check it out. Getunblocked.com slash developer tea. If you are enjoying this episode, if you're enjoying the show, subscribe in all the places, right? We've got a YouTube channel. We have a podcast. Of course, that's the longest running thing that we have. These episodes are on iTunes. They're on every podcasting platform. If you're listening to a podcasting platform, go ahead and subscribe in that platform so you don't miss out on future episodes, but also leave a review. Leave a review. iTunes. It's still the most important review platform for us, but leave a comment in YouTube. Share this video. Those are the ways. This is how you make every show that you watch successful, so don't just do it for me. Do it for all the shows that you enjoy that are bringing you content for free. This is certainly not the easiest thing in the world to pull together, so you all taking the time to go and share and show your support is incredibly important. Thank you so much for listening. Until next time, enjoy your tea. .