Typically when an engineer starts out, very rarely do they care about the business itself. The sales, the marketing, the reasoning behind certain decisions; they simply care about the tech. Although this makes sense as a junior-level engineer that’s there to learn, write code, and fix bugs, you can’t have the same mindset as a senior/principal engineer.

In the last blog post of The DevOps/SRE Series, you’ll learn about understanding the business and why it’s important.

Getting Into The Business

When you’re writing code, building apps, creating automation, working in the cloud, or whatever else you’re doing in your day-to-day, you know why you’re doing the work, but you don’t really know why you’re doing the work. The decisions that come down from the top may not make total sense to you. Maybe you’re pulled off of a project that you know is important, but the business needs you on something else.

To fully understand why that’s happening, you’ll need to understand the business decisions. For example, you should always ask why you’re doing something for the business. Depending on your boss’s ego, you may have to sugarcoat things a bit (sometimes people don’t like to be questioned). Once you understand the why, you’ll be able to understand more about the business and its decision. After you know why you’re doing the work, you can branch out to other departments.

As an example, maybe you have to spin up a new webserver to host another front-facing application. Although you may think it’s not important, maybe it’s something that’s crucial for the marketing department to display after the sales department sold the product. That cycle of marketing and sales is what brings in money for the organization, and what gets you a paycheck.

To wrap this section up, understanding the business decisions may work in your favor as well. Let’s say your boss wants to take you off of a project because they want you to work on something else that they feel is business-critical. If you understand why the business needs the other thing, you may be able to go to your boss and say hey, just so you know, this would be much more beneficial if we did X and Y because of Z. Then your boss might say oh yeah, you’re right! Thank you. Let’s get you on X and Y to get Z. It’s a win/win because you’re helping the business and doing the work that you want to be doing.

Why It’s Important

Simply put; it’s going to make your job easier.

When you begin to understand why the business is doing what it’s doing, it makes the decision process way easier to understand. There could be several scenarios where you feel annoyed, irritated, or upset about a decision. Maybe it was to remove a project you were working on and invested heavily in or a technology you were really excited to play with. That stuff may be important to you and the engineering team, but is it important for the organization's success?

Another huge aspect of why it’s important to get why the business is making certain decisions is because it actually makes your job easier as a leader and a DevOps engineer. You have to remember, as a DevOps engineer in today’s world, a lot of organizations and leaders in that organization will be looking to you for guidance. They understand that tech is moving ridiculously fast and they can’t keep up while still running a business. They need you to help them make a decision, and if you make a decision based on what you want vs what the business needs, you’ll either no longer have a job or that part of the business will crumble, and then you’ll no longer have a job.

Let’s take an example; say you’re ridiculously excited about containers. You want to get into Docker and Kubernetes so you can progress yourself as an engineer, and you believe it’ll help the organization. However, after really thinking about it, you might think to yourself serverless may be easier here. I just pop some code in and it auto-scales vs having to manage Kubernetes, hire more engineers to manage the new architecture, building Docker images, etc... Depending on the decision you go with, one is for your well-being and one is for the organization's well-being. As a senior/principal level engineer, it’s your job to understand that you need to make the decision that’s in the organization's best interest.

Understanding why and what an organization is doing to ensure its success is absolutely crucial.

How To Start

First things first, you have to understand that you have to get through the junior-level engineer stage first. Although there aren’t actual junior-level DevOps engineers, you may get hired with that title and your job may be a systems administrator or a junior developer with a fancy title. Once you get past the junior stage, you can start thinking about the business.

When you’re at the mid-level, senior level, and principal level, simply start asking questions. Why one technology was chosen over another. Why a certain piece of work takes priority. As discussed in the previous section, depending on who you’re asking, you may have to sugarcoat it because some people’s egos can’t take being questioned.

In short; the best way to start is by asking why you’re doing certain pieces of work over other pieces of work.