Discover the power of cloud cost intelligence
Give your team a better cost platform
Give engineering a cloud cost coach
Learn more about CloudZero and who we are
Learn more about CloudZero's pricing
Take a customized tour of CloudZero
Understand your cloud unit economics and measure cost per customer
Discover and monitor your real Kubernetes and container costs
Measure and monitor the unit metrics that matter most to your business
Allocate cost and gain cost visibility even if your tagging isn’t perfect
Identify and measure your software COGS
Decentralize cost decisions to your engineering teams
Automatically identify wasted spend, then proactively build cost-effective infrastructure
Discover the best cloud cost intelligence resources
Browse webinars, ebooks, press releases, and other helpful resourcesBlog
Discover the best cloud cost intelligence contentCase Studies
Learn how we’ve helped happy customers like SeatGeek, Drift, Remitly, and moreEvents
Check out our best upcoming and past eventsFree Cloud Cost Assessment
Gauge the health and maturity level of your cost management and optimization efforts
Discover how SeatGeek decoded its AWS bill and measures cost per customerRead customer story
Learn how Skyscanner decentralized cloud cost to their engineering teamsRead customer story
Learn how Malwarebytes measures cloud cost per productRead customer story
Learn how Remitly built an engineering culture of cost autonomyRead customer story
Discover how Ninjacat uses cloud cost intelligence to inform business decisionsRead customer story
Learn Smartbear optimized engineering use and inform go-to-market strategiesRead customer story
The most crucial DevOps skills for engineers have changed over the years. Here’s what to look for if your company operates in the cloud.
DevOps doesn’t necessarily look like it used to. Engineers used to build software designed for on-prem hardware; they had a specific methodology for efficient production and distribution schedules; and they didn’t interface very much with non-engineers, if at all. Today, all that has been flipped upside-down.
Cloud-era DevOps engineers now must possess wildly different skill sets, and some previously non-negotiable skills have faded into the past.
If you’re managing a DevOps team — or hiring new engineers — you’ll want to stay on top of the current trends to make sure your team is capable of fulfilling all the DevOps best practices that will keep a cloud-based company running smoothly, efficiently, and hopefully under-budget.
The following skills are listed in no particular order, because the needs of every company will vary on an individual basis.
In past decades, if an engineer lacked very specific technology skills, they were considered unfit for a development job. The ability to write functional code in the languages the company used superseded almost everything else during the hiring process.
Today, the coding process is different.
Engineers still need to know how to write software, of course, but some technical skills can be taught on the job if there’s an area that’s lacking. If an engineer has experience with a different development language than the one you need, this doesn’t always mean trouble.
In most cases, if a candidate has a rich understanding of development concepts and methodologies, as well as a demonstrated growth mindset, their syntactic knowledge will easily transfer.
The same is true for many of the tools and technologies they will use on the job, such as libraries, workflow managers and DevTools. It’s no longer as important that a candidate be an exact match for a company’s tech stack, as long as they have a basic understanding of the concepts and why they’re important.
If you’re hiring a new engineer or evaluating an existing team, don’t base your decision solely on an exact tech stack match. Instead, look for a general ability to write clean code, make good architecture decisions, and problem solve.
You’ll find that in today’s ever evolving cloud computing environment, there is more value in engineers who possess a growth mindset, and can pivot based on need, and less on those that check every immediate technology box.
I’m sure you are familiar with the stereotype of software engineers as cold, impersonal egoists who are great with code, but terrible with people. They might create amazing software, but they should not be allowed to interact with clients or even peers. At least, not ones you want to keep.
This lone wolf in a dark room stereotype couldn’t possibly be more different now.
Today, engineers are expected to work in collaboration with not only other engineers, but also with people outside the engineering department, such as sales, product or customer service teams. Occasionally, they may even be asked to help guide a client through a particularly tough issue.
With this in mind, gone are the days when it was acceptable to be difficult to work with.
When a big ego was acceptable as long as the work was well done. Instead, engineers must work collaboratively with users and peers alike, guiding a project through planning and design, and working with many other colleagues to build and deliver that project.
Frequently these collaborations are carried out remotely, with a majority of communication happening in Slack or Teams chats, when nuance and body language is lost.
Good written communication skills are vital to avoid frustration, misunderstandings and friction between peers.
Importantly, though technical skills can often be taught to a certain degree, these soft skills around communication and collaboration are crucial to today’s marketplace. Unfortunately, they are also usually the skills hardest to teach, and as such, are the ones that most engineers must bring to the table.
From the antiquated Waterfall to the more modern Agile and Kanban methodologies, there are plenty of ways an organization might approach the development lifecycle.
Experience with a specific methodology is not as important as it once was. Today, engineers are expected to have a familiarity with general process concepts, but more importantly - a desire and willingness to participate within the confines of whatever methodology works for a particular organization.
Although not every company follows the same development framework, what is important is that your team, and any new engineers you hire, all understand and function optimally under the framework that works best in your circumstances.
In an on-prem environment, engineers hardly ever have to think about cost. The hardware costs what it costs, and as long as the engineers build software that runs efficiently on those machines, that’s all that matters.
The cloud world is completely different.
When a company moves to the cloud, or an engineer joins a cloud-based company for the first time, there are often growing pains.
Costs for on-prem hosting are more nebulous and harder to quantify to the engineers who build the products that need them. However, when you are in the cloud, the cost of the products and features an engineer produces becomes increasingly obvious.
Where before the consequences of inefficiently built systems manifested themselves in support headaches, customer complaints and overtaxed servers. Now, if an engineer builds something without cost efficiency in mind, they might actually cause the company to lose money in very visible ways.
It’s not vital to limit potential candidates to only those who have experience working on cloud teams, but this experience shows they probably have an awareness of the importance of cloud costs, and shouldn’t be discounted.
For engineers without this experience, they should at least be able to demonstrate an understanding of why monitoring costs and building cost-efficient software is so important to cloud-based companies.
The engineering team or candidate should not only understand their role in generating cloud costs, but they also should have the motivation to strive for cost efficiency.
A large part of this comes down to whether or not the engineering team has a good way of monitoring costs in something close to real time.
With CloudZero, for example, engineers can see the cost impact of their engineering decisions. Cost anomaly alerts also notify engineers of abnormal costs to help teams to prevent expensive cost overruns.
Engineers without these tools will have a harder time staying on top of costs, and therefore won’t likely show as much motivation to improve. This means if you don’t have a way of tracking your company’s cloud costs in detail, you could be leaving money on the table.
If you do provide cost-tracking tools to your team and they still don’t show an interest in improving the cost efficiency of their products, this could signal a problem that needs to be addressed in another area.
Perhaps the company needs to strengthen its culture around cost-awareness, for example, or the engineers need a better way to choose more efficient infrastructure at will without unnecessary red tape.
In a job interview situation, it might be helpful to provide the candidate with a snapshot of a past project’s details and cost metrics and ask a few questions about what they think could be improved for future projects.
Their answers will give you clues to their motivations, so pay attention if cost doesn’t feature highly on their list.
Considering that your engineers’ decisions can quite literally make or break your company’s margins, we believe the understanding of costs and the desire to improve costs are two high-priority items to look for in a potential job candidate or an existing team.
Some companies are fortunate enough to find engineers who do understand cloud costs and have a strong desire to build high-quality software that functions well for consumers and improves the company’s bottom line.
But even the best engineering team in the world can’t optimize a company’s cloud spending if they don’t have a way to monitor the impact of their technology choices.
CloudZero opens the door for engineers — and everyone else in the company — to view cloud costs in depth and detail. They’ll be able to see when one product operates more efficiently than another, so they’ll know how to replicate what works and eliminate what doesn’t.
Cody Slingerland, a FinOps certified practitioner, is an avid content creator with over 10 years of experience creating content for SaaS and technology companies. Cody collaborates with internal team members and subject matter experts to create expert-written content on the CloudZero blog.
CloudZero is the only solution that enables you to allocate 100% of your spend in hours — so you can align everyone around cost dimensions that matter to your business.