In today's episode, we'll talk about putting process in it's correct place, and problems we can face when we use process incorrectly in our business. Today's episode is sponsored by Linode. Head over to Linode.com/developertea or use the code DeveloperTea20 at checkout for a $20 credit towards your cloud hosting account! Thanks again to Linode for your support of Developer Tea.
In today's episode, we'll talk about putting process in it's correct place, and problems we can face when we use process incorrectly in our business.
Today's episode is sponsored by Linode! Head over to Linode.com/developertea or use the code DeveloperTea20 at checkout for a $20 credit towards your cloud hosting account! Thanks again to Linode for your support of Developer Tea.
Please take a moment and subscribe and review the show! Click here to review Developer Tea in iTunes.
Hey, everyone, and welcome to Developer Team. My name is Jonathan Cottrell, and in today's episode, we're going to be talking about putting process in its place. Today's episode is part of the Great Developer Mindset series. This series is dedicated to guiding you, the listener, towards the mindset of the great developer. My job on this podcast in every episode is to help you and provide you with the tools, the insights, and the inspiration that you need to shape your career as a developer and become truly great at what you do. Developer Team is, of course, part of the Spec Network, and that is exactly what Spec is all about, helping designers and developers level up. So that's what we're here to do today, and I hope that you enjoy this episode about process. Today's episode is brought to you by Linode. With Linode, you can instantly deploy and manage an SSD server in the Linode cloud. You can get a server running in just seconds with your choice of distribution, resources, and node location. Of course, we will talk more about what Linode has to offer to you later on in today's episode. And if you're a longtime Developer Team listener, make sure you tune in because Linode is offering some new features that you may not know about. Of course, Linode has been a longtime sponsor of the show, so we're very grateful for Linode putting process in its place. That's today's episode. We're talking about putting process in its place. When we say the word process, a few things probably come to mind to most of you. Certainly, the algorithms that we create, the code that we write, all of that has associated processes that they represent, but that's not the type of process we're talking about today. Every company, whether they do so intentionally or not, chooses a process for completing work, whether that's for a client or for a product that you're building for yourself. For some companies, the process is a process that you're building for yourself. The process is such a core part of the company's DNA and their way of working that they may even have it patented and they keep it secret. But for most, process is discovered over a period of analyzing common problems and common solutions that the company routinely employs. The things that the company is regularly doing, that's what they build their processes around. We also commonly get information from the outside business world around what processes are most effective. Right? Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. in the future. But instead, for today's episode, we're going to be focusing on putting process into its correct place mentally, right? We're going to discuss two common problems in how companies tend to approach and think about process right after this quick sponsor break from Linode. Today's episode is sponsored by Linode. With Linode, you can instantly deploy and manage an SSD server in the Linode cloud. They have eight data centers and their plans start at just $10 a month. You can get a server running in less than a minute. They have hourly billing and a monthly cap on all plans and add-on services. That includes backups and node balancers as well as long view. You can spin up your own virtual machine for full control. You can run a Docker container on that VM. You can have an encrypted disk. You can have VPNs, pretty much anything you want to do with your Linux server you can do on Linode. You can also run a private Git server, for example. You have native SSD, storage, a 40 gigabit internal network, and Intel E5 processors, and it's all backed by a seven-day money-back guarantee. I mentioned in the intro that if you're a longtime developer T listener, that you needed to listen up whenever we talk about Linode. And that's because as of last month, Linode now offers two gigabytes of RAM for only $10 a month. That is more RAM than they were offering before, by the way. Go and check it out, linode.com slash developer T. And if you use the code developer T, you can get a free copy of the Linode software. And if you use the code developer T20, Linode will provide you with $20 worth of credit at checkout. That's equivalent to two months of free service on Linode's plan. So go and check it out, linode.com slash developer T. And don't forget the code developer T20 for $20 worth of credit at checkout. Thanks again to Linode for sponsoring today's episode of developer T. So in today's episode, we're talking about putting process in its correct place. And I said that there are two common problems, with the way the average software development company approaches process. And we're going to talk about those two problems today. They're both centered around the same idea. The first problem is employing process as a response to an issue you are facing. In other words, employing process only in a reactionary way. And you may be able to guess why that's going to be a problem. The second problem is having an overfocus on the process, such that the work you produce becomes, a byproduct of the process you follow. Let's think about that one more time. I'm going to repeat that. The second problem is having an overfocus on the process, such that the work you produce becomes a byproduct of the process you follow. Most of your energy then is consumed by trying to follow the process. And there are probably times when you fall into both of these categories. They are not exclusive from each other. And here's the reason for that. These two mindsets are so problematic. The way we put process in its place is by treating it as a tool rather than a set of rules. We treat process as a tool instead of a set of rules. We should be using process as a tool, not as our one true solution to every problem we face. And when we don't rely on the tool of process enough, as in the first example, when we fly by the seat of our pants, so to speak, and we only employ process in a reactionary way, we don't rely on the tool of process. We only employ it when we think it's going to fix our issue that we're facing. We are not using the tool correctly. However, on the opposite end of the spectrum, if we believe that the solution to all of our problems is a perfect process, we can tend to miss out on huge, huge opportunities. When our work becomes a byproduct of the process that we follow, then what we are actually putting our energy into is the process, not the work. And if we don't have the right tools, we don't have the right tools, we don't have the right And what ends up happening is our work suffers. The quality of our work tends to go down as the quality of our process tends to go up. And a better way of saying it is the perceived quality of our process tends to go up. And that's when we see our work degrading. So the more common scenario is the second. We're overusing process. This is particularly more common with companies that have been around for a while. We tend to call it something like red tape. So we're going to focus on this problem a bit more. We're going to focus on the problem of red tape. We're going to focus on the problem of process more than the first one in today's episode. Here are some signs of a company that uses process as a set of rules rather than as a tool and who is focusing on process more than they're focusing on the work. Sign number one, your team complains about your clients not understanding the process or not getting it. A better way of saying this is if your team is complaining more than they're helping your clients, then that's probably an effect of the process. This is problematic because your job as a great developer is to instruct and enlighten your clients or to instruct and enlighten your users, not to belittle or hold captive all of the great concepts and ideas for yourself. And when your clients are stubborn or when your users are unhappy, it is still your job to persuade them. Which leads me to my second point. The second sign that your company is using processes as a set of rules is that your company is losing the interest of clients. And that's when you're losing the interest of your clients. And that's when you're losing the interest of your clients. And that's when you're losing the interest of your clients. Because the process is inflexible. That's the idea of having rules. They're inflexible. Now I can hear you getting a little bit uncomfortable on the other end of the speakers. Process is a comfortable thing because when it's used the right way, it can create sustainability and predictability. However, when we get addicted to that predictability as business owners, this is especially true for freelance business owners and consultants, we tend to forget that with any business, we tend to forget that we're not going to be able to do anything. There is risk. And when we use our process as a set of rules to increase the predictability and to increase the sustainability of our business, we inherently are shifting that risk somewhere else, perhaps to the shoulders of our clients. And not all clients will be willing to carry that risk. When process is used correctly, it is actually a risk reduction method for everyone involved. You as the developer and for your clients. So how do you fix this problem? You have to remember that flexibility is key and that risk is inevitable. And oftentimes flexibility is worth the extra risks it might bring with it. Here's what flexibility doesn't mean. Flexibility doesn't mean making estimates that you know are unrealistic. Don't make estimates that you know are overpromising just to win someone over. Now this is a sliding scale. If you think that you are making an estimate that is 95% correct and the 5% is to win someone over and you know that you can kind of fudge the numbers, then that's on you. You can make that if you want to make it. That's totally up to you. You're not going to destroy your business that way. But making estimates that you know are totally unrealistic, in my opinion, that edges on an ethical issue and you have to decide for yourself how you want to handle that. Another thing that flexibility does not mean is making estimates for work that you know you can't accurately make. And that's not going to make And that's not going to make you feel like you're making estimates for work that you know you can't accurately estimate. In other words, if you can't make an estimate, even if you aren't knowingly making an unrealistic estimate, perhaps you're making an estimate for work that you know you can't estimate yet. Work that's, let's say, a year into the future, for example. That's going to be nearly impossible to estimate. So that doesn't mean they're being more flexible when you're trying to make an estimate for that. Instead, you're really just lying, right? You're trying to lie to make somebody comfortable. And that doesn't mean doing free or cheap work, right? That's just simply being cheap. That's your client being cheap. That's you carrying 100% of the risk, which is also not what flexibility means. You shouldn't be carrying 100% of the risk for your client's venture. Flexibility also doesn't mean overworking on a regular basis because you made a promise that you couldn't keep. On a recent episode, we talked about working on Saturdays and when that might be appropriate. And in my opinion, flexibility means that sometimes working on a Saturday may go a very long way with your relationship with your boss or with your client. So keep that in mind. When you think about flexibility, when you introduce flexibility into your process, right? Instead of saying that your process is nine to five Monday through Friday, think about what happens when you are flexible from five to seven one night a week. Am I saying that you're not flexible? Am I saying that you're not flexible? Am I saying that you have to be flexible and work the extra hours to get ahead? Not necessarily. But what I can tell you is that if you stick to your process as a set of rules, then opportunities, the doors to certain opportunities will be closed to you. So here's what flexibility does mean. Making promises that might make you slightly uncomfortable or that you know will stretch you and will take hard work to keep. Don't just make promises that you know will stretch you and will take hard work to keep. Don't just make promises that you don't know will stretch you and will take hard work to keep. Don't just make promises that you know absolutely without a doubt you can keep. Make promises that are going to take hard work. That's how you get ahead. That's how you become a great developer. Flexibility may also mean changing your routine or your normal way of doing things if the situation calls for it. If you are normally working with one particular programming language and you really like that language, but a project calls for a different language and you know that you can wrap your head around it. Well, that's not going to happen. You're going to have to make promises that are changing your routine or your normal way of doing things if the situation calls for it. Well, that may be a very good opportunity for you to open the door to that project. But if you stick to your process, if you stick to your process as a set of rules, then you become inflexible and you're not going to go and take on that new opportunity. Being flexible also means being open to new methodologies in management. Whether you are agile or waterfall or something in between or nothing at all, being flexible means being open to new ideas and new ways of doing things. And if you're not flexible, then you're not going to be or revisiting old ways of doing things. So a quick recap of today's episode. Process is a good thing if it's used as a tool and not as a set of rules. When used correctly, process can be a risk reduction method for you and for your clients. But for that to work smoothly, you have to remain flexible. Thank you so much for listening to today's episode. And thank you again to Linode for sponsoring this episode. If you want to learn more about Linode, please visit linode.com. Don't forget that you can get two gigabytes of RAM for only $10 a month on a Linode server. You can get it up and running in just a minute. And by the way, they're giving you $20 of free credit by simply using the code developer T20 at checkout. Go and check it out. Linode.com slash developer T. If you don't want to miss out on future episodes of developer T, make sure you subscribe in whatever podcasting app you use that will ensure that those episodes are delivered straight to your device. Three times a week. Thank you so much for listening. And until next time, enjoy your tea.