One thing that's tough for a lot of organizations is how to put a value on engineers. Not too long ago, tech departments weren't looked at as money makers (and most still aren't). They were looked at from a financial perspective as simply a spend. Now, organizations creating software look at tech departments much differently. Even if an organization isn't a software company, they're still creating apps for people to use (iPhone apps, Android, etc.) and thinking about how to manage data. Because of that, tech departments are now being looked at as essential.

What does this mean for the tech departments? Simply put, engineers must now think about the business impact and value, but also continue to think about the technical impact.

In this blog post, you'll learn about how DevOps engineers and Site Reliability Engineers (SRE) provide value from a technical and business perspective.

Business Impact

Tech departments were always known as the we keep the lights on department, but that's not the case anymore. Now they're the departments that manage applications running in the cloud, getting new updates out to iPhone/Android users, and bringing money into the organization. After all, the more an organization has to offer in the tech-centric world we're living in, the better. The more that organizations move towards technical-focused areas, the more they must rely on tech departments.

The biggest issue used to be hi, I can't log into my computer because the domain server is down. Now it's the entire organization is impacted and losing millions because our apps aren't working.

The way that engineers think about deploying and creating applications literally impacts an organization by the millions.

This way of thinking is a bit different than the original flood of engineers. It used to be the person that was locked away in a basement writing code. Now it's the person sitting in meetings with the leadership team explaining how an application will be deployed.

When thinking about the business impact, there are a few key components to always keep in your head:

• What is the business actually trying to accomplish? This can be very different than what you as an engineer want to accomplish.
• Do the deadlines make sense, or do you, as an engineer, need to speak with the leadership team and help them understand why or why not the deadline makes sense?
• Can you speak at a high level and help people understand the impact?
• How can you show value in numbers and metrics? One of the best ways today is by using Value Stream Management (VSM) tools.

Technical Impact

Now that you understand the business impact, let's talk about the technical impact, which ultimately impacts the business greatly.

Have you ever started working on something, got really interested in it, and went down a rabbit hole wasting hours on something that probably wasn't a huge impact? Sure you have! All engineers have and that's what arguably makes it fun. In fact, some of the best inventions have come out of doing that. However, you must understand when too much is too much.

If you're rabbit holing for hours on a feature or a nuance addition that really makes no difference, you're impacting the business from a technical and business perspective. The code you're working on, the deployment you're creating, the monitoring you're setting up, all take time, and that time is impacting the business.

When you're engineering a solution, you must think about the value you're providing. Value is all that matters. Not the hours or the minutes, but the value.

When you're deep in a rabbit hole next time, ask yourself is this solution I'm spending so much time on providing value? Hopefully, the answer is yes. If the answer is no, it's time to re-think what you're doing.

A few things to keep in mind from a technical impact perspective are:

• Is what you're doing providing value?
• Are you spending too much time on something?
• Is the solution you're implementing impactful in a positive way to the organization?

From a technical perspective, value is everything. An SRE/DevOps engineer provides value, technically, in a few ways:

• Making deployments faster
• Making deployments more efficient
• Monitoring performance and applications across the entire organization
• Automating solutions that used to be done manually, while ensuring they're made more effective
• Helping organizations understand the business impact if a technical implementation is done the wrong way

Engineers Should Make Decisions

Making decisions is tough. It could be as little as wasting a few hours, or it could be as large as making an organization lose hundreds of thousands (perhaps even millions). One of the trends that are continuing to grow in organizations is engineers making more impactful business decisions, and they should.

The truth of the matter is, most of the leadership team is most likely not technical, and that's perfectly fine. It's not their job to be technical, it's your job.

And because it's your job, that means you have to help them make the proper decisions.

All engineers moving forward should be comfortable speaking with the leadership teams and management around why a technical implementation should be done, why timelines should be thought of first, and why good engineering resources are so important.

Why?

Because it's the make or break of many organizations in today's world. It's your job to help business leaders with tough technical decisions.