lamborghini parked in front of a hotel with a crowd surrounding it
PHOTO: Danilo Capece | unsplash

When we think of Ferruccio Lamborghini, we generally think of fast, glamorous cars that people want to drive. But what springs to mind when you hear the name John Loudon McAdam?

Even if you’ve heard of him, I doubt you’re thinking about flashy sports cars. I’ll be honest, I didn’t even know who he was before writing this article.

McAdam was the great Scotsman who invented tarmac roads, paving the way (ahem) for automotive manufacturers like Lamborghini to create their iconic vehicles. Without McAdam, we’d probably still be bumping around on cobblestone tracks, and Lamborghini may never have achieved its global recognition.

My point is that it’s the McAdams of this world that facilitate the Lamborghinis to build incredible products, which is especially true in software development.


The harsh reality is that most organizations focus heavily on software, hiring cream-of-the-crop software developers to build their dream products. Don’t get me wrong, the market is mature enough to understand what it takes to build software and approach quality assurance (QA), but it starts to get hazy when we get to the operational side of things.

Companies often treat non-functional requirements and system design as an afterthought. Many have compelling stories for their software architecture, but they still grossly overlook essentials like security, monitoring and scaling.

From a business perspective, it’s imperative to understand how much you’ll need to scale and design a system to meet those requirements — we can’t overstate that enough. However, companies will say they’re addressing these non-functional requirements but never actually follow through.

Related Article: So Many Breaches, So Little Proactive Action

Placing Your Team in Pole-Position

I often see companies hiring developers and architects who don’t know operating systems, networking, security and infrastructure — all the aspects that determine how secure your system is and how much capability it has for scaling.

Think of it this way: how are you going to drive around town in your Lambo without any roads?

It’s all too easy to focus on the customer-facing front-end interface, ignoring the non-functional requirements like capacity, observability, security and maintainability. These vast areas of concern require more skills than most software developers and DevOps engineers have. DevOps has become so ubiquitous with the development side that it’s losing the operations side of its meaning.

The industry typically thinks of DevOps engineers as people who can write, design, and implement software, pipelines, release management processes, and infrastructure solutions. I’ve always seen the role more of an “operations engineer,” “cloud engineer” or “release management engineer,” all of which exemplify the knowledge they bring to the table.

How do you deal with operating systems from a security perspective? How about infrastructure from a scalability perspective? Do your DevOps teams understand how the software was built in relation to the systems that will run it?

Organizations need to hire people who have the answers to these questions, then allow them to build the roads that their Lambo requires.

Related Article: Demystifying Modern Application Development

Owning the Less Glamorous Side of Software

People need the freedom to make decisions based on their level of knowledge around operations, security and infrastructure. I’ll be the first to admit that none of this is glamorous, but it’s more important than anything else as it defines how the glamorous stuff actually works.

Assess the talent you have available and find out who has the skills and capabilities to run production. They should understand capacity, infrastructure, operating systems, and the theory behind how distributed systems should work. As a rule of thumb, they should also know the solutions to common problems and understand how software relates to operating systems and infrastructure. Basic networking knowledge also helps, covering things like switching, routing, secure network design, the AlwaysOn model, and how to scale up the network protocols that you already use.

Ideally, you’d have one person overview this portion of infrastructure from an operational standpoint, then another person to look at it from a security perspective. The latter hires need to know how software is hacked, how attackers think, and how the general security landscape works, then apply that knowledge to the infrastructure design, which is a usually full-time job for more than one person.

People have devoted their lives to these types of skills. They understand how software is made from an agile standpoint and can easily interact with an all-inclusive team of experts that build systems, not software.

Related Article: A Cost-Cutting Cloud Optimization Strategy for Your Skyrocketing Cloud Bills

Race to the Finish

When you focus on systems development, you have full command over how people will interact with your software, allowing you to scale appropriately. It’s also more likely that you’ll be able to anticipate how people will use the software and increase observability on that usage.

Organizations can benefit from dropping the mindset of simply writing code and releasing it into the wild. They should instead become disciplined about writing the code, implementing the security, implementing the operations, implementing observability tools and preparing to scale — all at the same time. When you take that path, your product runs well, it’s secure and users want to use it.

When you treat the operational side of things as part of the software development process, you can produce secure, operable solutions by design. This approach also makes them much more cost-effective to run, directly impacting your profit margins, much like solving the cloud overspend problem.

So next time you get excited about building that new Lamborghini, don’t forget to hire your McAdams to construct a smooth, straight road right to the finish line.