Hi, this is Tom Henricksen and humans are hard, code is easy. Here's a string of thoughts that ran across my mind early in my programming career. Why can't people just leave me alone and I can do my work? I can figure this stuff out myself. I don't need others help or any input to turn this thing around. Why don't people understand me? I think it must be they're just dumb. They don't recognize genius when they see it. Perhaps you've been there too, a frustrated developer who feels like they know enough. However, the success you thought you'd have is out of reach. You see others who make better strides, but why is it a skills gap? I want to share with you how I learned about my skills gap. Java check. Linux check. Sql check. Humans what humans are hard code is easy. So I focused on the technology. One of my first mentors was a database administrator named Doyle. He really knew his stuff but didn't say much. That can make learning challenging. One thing Doyle would do is fix the problem for me. Doyle would fix it so quickly and then leave. What did you do? He was already gone. Working with Doyle gave me some insight. Technical people hate explaining basic stuff. Ask them a simple question and they will flip the bozo bit on you. What is the bozo bit? You say? A few years after working with Doyle, I got to work with a software architect named Corey. He had many interesting observations. One thing he would do if you asked him a stupid know the basic question you could have figured out by doing some research on your own. He wouldn't answer your questions or work with you. That, my friends, is the bozo. But bozo, of course, refers to bozo the clown. The bit in reference to computer bit or binary storage code was pretty extreme, but many developers can be that way. To gain respect from those developers, we need to know the technology. Humans are hard, code is easy. So I focused on the coding. I learned new technologies. I kept my head down and tried to avoid getting the bozo, but flipped on me. A few years later, I transitioned into a new role, technical lead. One year, during my annual evaluation, my leader said to me, tom, we think you have solid credentials. Coding skills got you the job, but we need you to develop other skills. My leader shared with me where I was failing delegation. He shared how I wasn't delegating work to my teammates. Case in point, there was an upgrade that needed to be done. I did the work in 10 minutes or so. To explain that would take a couple of minutes, 10 minutes or more. Another trap I fell into with delegation is the belief in our values. We can convince ourselves that we are worth more when others can't do the same work as us. I remember working with Jamie the first time. I wasn't quite sure he understood what we were doing. He was always done quickly. Then I finally asked him here. He had created a script to deploy changes and update dependencies. I was doing all this work manually. I had to figure out a way to do this better. I could have figured this out better myself, but sometimes you make these mistakes. A few years later, I got to work with a leader named John. We knew each other through a mutual friend. I had begun to coach individuals and teams. John wanted an outside resource to help him change his team's mindset. He shared how most it people work with others in a transactional fashion. We get the requirements and we solve the issue. John said, tom, my team is like bank tellers. They get asked to fix something and they do. Just like a teller gets a check and deposits the check. I want my team to be more like financial planners. A financial planner builds a relationship, then they can anticipate needs. So you're saying, john, you want your team to have better relationships with their customers? John said, tom, if they have better relationships, they will be. But to build relationships and empathy and understanding relationships. Understanding and. Huh. That won't work. That's what I thought at the time, but I was wrong. John's team. John knew his team needed to understand and develop empathy. Each change John made helped his team understand. The community directors had many things on their plate. These conversations also worked the other way too. The community directors began to give John's team space. If something went wrong, they trusted them to resolve it. John proved me wrong. He overcame his deficit by being curious and empathetic. He was able to change the way his team interacted with the organization, so much so that he has since been given additional responsibilities. From bank tellers to financial planners, he remained the image of his it team. This brings me to my main idea. Coding skills got you the job, influence will get you the career. Coding skills got you the job, influence will get you the career. What do I mean? Developers are focusing on technology skills only if we truly want to set ourselves apart. We need to know how to influence and collaboration with teams. Gone are the days when we could just send in the requirements with pizza and out pops. Code organizations are looking for more from their developers. The problem? My problem was I was terrible at relationships. I had confirmation. I had proof. Although I didn't start out as a developer, though, my first stop, my professional career was quite different. My first job out of college. It seems like yesterday I started at Wallace. What is Wallace, you say? Well, we sold business forms and office supplies in Des Moines, Iowa, kind of like Dunder Mifflin. Armed with a business management degree and no real idea, I had three job options when I graduated from college. I could sell insurance, or I could sell life insurance, or I could sell business forms. So I did what any sane person would do. I sold business forms. Who wants to call on our friend's parents for insurance? Anyways, did I mention that Des Moines is the insurance capital of the world? Back to my first day at Wallace. Can you believe I had to make a few cold calls before lunch? Let me remind you, in college, the only time I called my friends was when we were having a kegger. Getting people to buy business forms is a bit more difficult than getting college students to drink beer. Now, I really didn't want to make those calls, but lunch was getting close. I was given three prospects from another sales representative to call on. Hello, is Mike Huff available? Sure. Can you tell him that Tom Henricksen called? Yeah, I'm from Wallace. Click. Hello, this is Tom Hendrickson, your new Wallace representative. Oh, sorry, Mr. Hegna. I apologize. If our labels fall off your product. Click. Whoa. I guess we got disconnected there. Okay, just one more and we can go to lunch. What do we call on gentlemen's clubs? My coworkers all die laughing. Turns out this is their way of initiating new sales representatives. My sales career went down in flames pretty quickly. Similar to Tommy boy, my sales techniques were not appreciated. Soon after my first day in sales, I started to realize something. This wasn't going anywhere. A friend of mine from high school shared with me the opportunity in technology. So I began to pursue a different path and get a new degree. I left my job in sales and began work as a developer. Now, working as a developer is quite a bit different than working in sales. The sales office I worked in was always full of people talking. They would be talking on the phones to customers or talking to each other. The developers I worked with, well, they were a quiet bunch on the whole. Friday afternoon in the sales office, the newest rep had to go get beer for everyone. Friday afternoon for the developers was quiet, just like the rest of the week. Now perhaps it's starting to sound like I didn't want to make this change, but that was not the case. I slowly began to realize I was more spock than Jimmy Fallon. The quiet, contemplative work of a developer suited me more as my technology career began, I started to work with lots of different tools and technologies, but I wanted to move into something more current. I started to hear a lot of buzz around the Java language in my free time and nights and weekends, I would read and work through tutorials. All this work paid off a few months later when a company leader came to me and said, tom, would you be able to help Dave with a new application? It turned out they needed someone who could write an application using Java. I, of course, agreed. Like Luke beginning to use the force. I was starting with some basics. As my java skills began to improve from experience, I learned a few other things, too. I began to work with someone who was quite sharp from a technical perspective. But Eric wasn't easy to get along with. He would yell at people he worked with. You might say he was a complete jerk. Sometimes the managers and team allowed this to happen, in large part because he was productive. Now, I can still see it. Now when I closed my eyes, Eric was a smoker and he was trying to quit. This made Eric even testier. Eric and Sri were working together on some files when I came walking down a row of cubes, and Eric was in Sri's cube yelling, you know how people get mad and their veins look like they're going to pop out of their head? Eric's veins were about ready to explode. Then he ran out the door. I guess he needed the smoke. I asked Sree if he was okay. He looked at me and said he was okay, but that no one should have to put up with him. Sri couldn't have been more correct. Eric was a tyrant who ran around like Darth Vader, intimidating people. But we all put up with his terrible treatment just because he was able to code a lot. Even though many developers act like Spock, we have feelings, too. I would like to tell you that Eric was let go and the team was able to move on. The company did nothing to him. His behavior was left unhandled. Learning how to be a good team player doesn't come naturally to some. We need to learn the basics to understand how to make the team thrive. Eric wasn't a team player. He was but for himself. If you work with a coding hero like Eric, they might take all the tough work and make it easier for others. But this can stunt the overall growth of the group. If you work with a coding hero and they take vacation, things can fall apart. Let me tell you a story about a leader who dealt with a similar issue. Now, Ben was a leader that I worked with, and he had a coding hero. We'll call him Dave now. Dave would code solutions that were more complex than others could understand. Dave was coming up on a milestone birthday. To celebrate, he was going to bike across multiple states with all his gear. So he took off, three weeks. Now, Ben knew this was going to be an issue, so he met with the team and they discussed the challenges. The team decided to begin to have knowledge transfer sessions with Dave. Ben helped foster this collaboration with the team. This enabled the team to slowly chip away at the knowledge gap, and the team became more resilient. At my next stop, I began to master my skills in Java. I was responsible for an application that required me to learn some new technologies. Software development can be a bit like trending song sales on iTunes. One day something's hot, the next day it's out of date. During this time in my career, many open source tools became popular. Mastery for Luke Skywalker came after a battle with Darth Vader. Programming is a lot like writing. As the author Stephen Pressfield says, the amateur tweets the pro works. Professional programmers show up every day and slay small demons. The first skills I had to master as a developer was debugging. Of course, today the tools are much more mature. One of the first applications I had to debug didn't have any such tools. I was armed with print statements and a log file, quite primitive by today's standards. All right, let's see here. Where does that value get set? Here, let's add a print statement recompile. Oh, compile. Error. Forgot the semicolon. Okay, let's add that semicolon recompile. Run the report. No, the database isn't separate. Okay, let me update that table. Run the report. Table up. Now that looks better. Of course, debugging is so much easier today, but we still need to use the old beam. As Steve McConnell points out in his book, Code Complete, we need to learn the types of mistakes we make. Early in my Java career, I made the same mistake time and again. I would forget to initialize my variables. I can still hear my coworker Ken laughing at me when he would look at my code and point out my obvious error. We need to think about our errors and think about how we can make them better and learn from them. We need to periodically take a step back and reflect. How can I or we do this better. Think, apply, reflect. Software developers like to impress each other. I had to use the singleton pattern to fix that. Don't worry, most developers don't know what that means either. There are many esoteric topics we can talk about for hours in essentialism, the disciplined pursuit of less. Greg McEwen shares how important editing is to journalism. Now the journalists bring the stories and the editor. The journalists bring the stories and write up the ideas. However, the editor has the important job. They review the piece and rework it. Over my years, I've mentored many developers. One in particular sticks out. He began reading about code basics. This made him add unnecessary code from time to time. I remember debugging an error he was getting together. When I asked him, why is this loop here? He looked at me, unsure, and said, I don't know. I thought it would help. He thought it would help. Once we removed his unnecessary loop, we resolved his error. Adding code is easy. Knowing what to keep is hard. Now, it's not that I'm saying computer science basics are not important. We need to master these too. However, if we put our sole focus on them, though, our careers will falter. I spoke before, but Eric. He had mastered computer science. His teammates, though, couldn't stand him. We need to be good at our work and get along with our team. If we do just one of these, we aren't doing our job. As I learned more about soft skills, my career progressed. Starting out as a developer. Then I moved into a senior developer role. Next I was a technical lead, and then finally I moved into manager of software development. This point I was feeling really good about my career progression. I remember it like it was yesterday. It was a Friday morning in May. I took my kids to school and came into the office at my normal time, a little before 08:00 a.m. Oddly enough though, my boss was in. He usually came in at nine or after. I sat down and unpacked my things. And then Scott, my boss, came to my desk and said, tom, can I talk with you? I said, sure, and I followed him to his office. Although when we came to his office, he took a right. Hmm, that's strange. As I thought, as I followed Scott down the hallway. Then he took a left into Sandy's office. Who is Sandy, you ask? Well, she was the director of human resources. We sat down and then Scott looked at me and said, tom, this is your last day here. If you've ever had that said to you at work or in a relationship, you know what it feels like. The rest was strange as I felt a calm come over me. I knew something was going to happen, although as I looked across the table, I could tell Scott and Sandy felt terrible. They discussed the next steps. I packed my things and left. Getting fired gives us good chance to reflect. What did we do wrong? How could this have been avoided? As I looked back, I realized one lesson. First. What led to this was a lack of clarity. I needed to ask better questions. Therefore, the team I led did not execute accordingly. Processing this, though, took times. At first, we can get frustrated and want to blame others. However, we need to own our mistakes. That helped me move forward. The second lesson I learned was the importance of relationship management. As John taught us earlier, we need to continually foster our connections. I began to reach out to my network, and the opportunities were plentiful. So even in something as trying as getting fired can be, a moment for learning. If we take time to unpack the wisdom, mastering basic skills requires guidance. Early in my career, I worked with Wei. He instilled in me a systemic approach that I still use today. Software development is essentially problem solving, and Wei began to notice. Oftentimes I was trying to solve five different things at once. Wei's guidance was brought clear to me a few years later when I attended a seminar at Michael Hyatt's best year ever conference. He discussed goal setting. Michael said, detailed plans are great if you're building a nuclear submarine. He continued, for everything else, just focus on the next step. Wei and Michael agreed on this point. Don't overthink it. In Proverbs, it is said in the multitude of counselors, there is safety. Luke's journey first brought him to Obi Wan Kenobi, where he learned some basics similar to what I learned from Wei. He kept learning, and so have I. Reflection doesn't come easy for me. I want to move on to the next thing. In David Marquis'book leadership is language. He details the red work, the doing, and the blue work, the thinking. In the book, David discusses how important they both are to making progress. He walks us through the industrial revolution, where the workers did the red work and the managers did the blue work. Today, us knowledge workers must do both. A simple pause can give us a chance to step back and reflect. How can I, or we do this better. Think, apply, reflect. By now you're starting to think, Tom, I'm a developer. I don't need no stinking soft skills. Of course, if you don't want your career to get better, keep on keeping on. My career path has changed dramatically as I've learned the importance of communication, relationships, and influence. Let's explore the three core soft skills. These will set the stage for a career transformation. So remember, coding skills got you the job. Influence will get you the career at the code of communication is listening. We need to listen to what is being said, make eye contact and observe their body language, ask good questions and seek clarity. Developers who do this write better code. They don't assume they know the answer. In the book, the pragmatic programmer Andy Hunt and Dave Thomas talk about the importance of digging for requirements. We need to look between the lines. Number two at the core of relationships is understanding their interests. A few years ago, as we were potty training our daughter, we were trying to get her to stay focused. Although she was easily distracted, she would peek her head out the door as she wanted to watch Elmo, or as she called him, Melmo. Then I realized something. If I tilted the television a little bit, we didn't have the problem. She could see the tv and see Elmo. A subtle change helped us both get what we wanted. Sesame street was her focus. So both of us were able to get what we wanted. At the code of influence is connecting with someone at a personal level. Ted is a tight lipped project manager. Nobody on the team can get a good read on him. We both joined the Zoom meeting early on a Friday morning. When I ask him, good morning, Ted. Any plans for the weekend? He hesitates and then says, yes. In fact, I do. I'm going to show my welsh springer spaniel at the dog show this weekend. I ask a few follow up questions and Ted starts to share more. This short interchange helps us begin to connect. Bonus time. We have the three core soft skills. K is for knowledge. We need to apply this knowledge. L-U-C and K listen, understand their interest, connect and apply the knowledge. Lu C K. Remember, with luck you can find influence. These are the three code soft skills. They can change your career. In my first role as a manager, I tried to get to know the team. This can help build trust and influence with them. Perhaps you're starting to think, Tom, this won't work for me. AJ was a strong developer, but he rarely talked. He worked in a slow, methodical fashion, kept his emotions in check. Over time, his teammates became irritated with his style. I tried to get to know him. For instance. We connected on a few things. AJ traveled to Germany to pick up his new bmw. He was quite excited about that. Still, his unwillingness to communicate with others and with the product owner was wearing thin. That's when my manager came to me and said, tom, it is time for AJ to decide if he wants to be part of the team. My manager asked me to put AJ on a pip or performance improvement plan. I had 60 days to help him improve or else. Despite his strong coding skills, his career was on a downward trajectory. When I met with AJ and explained the situation, he began yelling at me and said, I'm the best developer you got and stormed right out of the meeting. The first two weeks after this incident were really shaky. AJ wouldn't talk to me or anyone. I kept checking in with him daily. I knew he was an introvert. He needed his space and time. Eventually, AJ and I sat down and discussed the pip and how it made him feel. That's when I got AJ to agree to try some experiments. We met as a team and created some working agreements. These clarified everyone's role. Also, it stated how we would work together. I got the product owner to give him one final shot. In the end, we were able to give AJ the space he needed. Along with coaching him and his teammates, we were able to work through it. I was able to communicate and influence the team using the three code soft skills and AJ was able to develop the soft skills he needed to change his career direction. I learned how to help AJ, myself and others. You can do this too. Coding is important, but it's not enough. We can keep our head down and Bozo at our career, but that won't get us where we want to go. Relationships matter. Empathy and understanding matter. Communication matters. Practicing these soft skills can give you more influence, which leads to more success.