What Splunk Does — and Why It Matters

Splunk (NASDAQ: SPLK) occupies a compelling position in the enterprise data market. The company’s core product — its “data-to-everything” platform — ingests machine-generated data at scale, surfaces patterns through search and analytics, and delivers operational intelligence to IT, security, and business teams. The pitch is straightforward: instead of having human operators spend hours sifting through log files and event streams, Splunk’s platform does the heavy lifting automatically.

For DevOps and platform engineering teams specifically, Splunk has long been a go-to solution for centralized log management, infrastructure monitoring, and security information and event management (SIEM). The ability to query terabytes of log data in near-real time and set threshold-based alerts has made it a staple in enterprise operations centers.

High-profile enterprise clients have publicly credited the platform with improving operational efficiency across their organizations. Airbus (OTCMKTS: EADSY) is among the well-known names that have adopted Splunk at scale, citing gains in visibility and process efficiency — a strong signal for any enterprise software vendor.

The “Data-to-Everything” Vision: Ambition vs. Reality

Splunk’s branding around “data-to-everything” is intentionally broad — and that breadth is both its strength and a legitimate source of investor skepticism. The platform genuinely excels in environments where the underlying data is structured or semi-structured and where the questions being asked are quantifiable: Is this server responding within SLA? Is this login pattern anomalous? How many errors occurred in the last 15 minutes?

Where the platform runs into limits is in domains that blend quantitative data with qualitative, contextual, or socio-economic judgment — areas like brand marketing strategy, customer sentiment interpretation, or novel threat detection that falls outside known signatures. These use cases require a level of contextual reasoning that current machine learning and AI systems, including those embedded in Splunk, cannot reliably replicate.

This is not a criticism unique to Splunk — it reflects a broader constraint on today’s AI. Narrow AI systems, including ML-powered analytics platforms, are highly effective at pattern recognition within well-defined problem spaces. Artificial General Intelligence (AGI) — the ability for machines to apply reasoning flexibly across arbitrary domains the way humans do — remains a long-term research goal, not a current commercial product. Any vendor claiming otherwise deserves scrutiny.

For DevOps practitioners, this means Splunk is an excellent tool for instrumented, data-rich environments — and a poor fit for problems that fundamentally require human judgment and domain expertise.

Revenue Growth Trajectory: Signs of Deceleration

As of the quarter ending July 31, 2019, Splunk reported year-over-year revenue growth of approximately 33%. While strong in absolute terms, this represented a deceleration from the approximately 39% growth recorded in the same quarter the prior year. For a high-multiple growth stock, sustained deceleration in top-line growth tends to compress valuation multiples, even when the underlying business remains healthy.

This dynamic — slowing growth coinciding with increased investment spend — created a more cautious near-term investment profile at the time, even for observers bullish on the company’s long-term direction.

Technical Signals Worth Watching

From a technical analysis perspective, SPLK stock in late September 2019 was trading below both its 50-day and 200-day moving averages. The 50-day moving average was approaching a crossover below the 200-day — a pattern commonly referred to as a “death cross,” which technical analysts typically interpret as a bearish near-term signal. The stock had also been trading in a mildly negative trend channel since late February 2019, following strong early-year performance.

Technical signals of this kind do not predict fundamental outcomes, but they often reflect the aggregated sentiment of market participants and can influence short-term entry points for investors weighing a position.

Key Takeaways for Technical and Engineering Professionals

• Platform strengths are real: Splunk delivers genuine value for log aggregation, security analytics, and operational intelligence in data-rich enterprise environments.
• AI limitations apply: The “data-to-everything” vision is aspirational. Current AI cannot replace human reasoning in ambiguous, qualitative domains. Evaluate vendor AI claims critically.
• Growth deceleration matters for valuation: Even strong SaaS businesses face valuation pressure when revenue growth slows. This affects how and when investors are willing to buy in.
• Competitive landscape is intense: Splunk competes with Elastic, Datadog, Sumo Logic, and cloud-native observability tools from AWS, Azure, and Google Cloud — a factor that influences both product roadmap and pricing power.
• Long-term thesis remains intact: The enterprise demand for operational data intelligence is structural, not cyclical. Companies that solve the signal-to-noise problem in large data environments will continue to attract investment and adoption.

Bottom Line

Splunk’s platform addresses a genuine and growing enterprise need. For DevOps, security, and platform engineering teams, it remains one of the most capable tools available for operational data intelligence at scale. The honest constraint on its “data-to-everything” ambition is the current state of AI — a ceiling that applies across the industry, not just to Splunk.

From an investment standpoint, the analysis from September 2019 cautioned that the combination of slowing revenue growth and bearish technical signals warranted patience — not abandonment of the thesis, but a more disciplined approach to entry. That kind of distinction between a good product and a good stock at a given price is a useful framework regardless of the company in question.

Note: This article reflects market conditions and financial data as of September 2019. Splunk was subsequently acquired by Cisco in 2024. Do not rely on figures cited here for current investment analysis.

1. Jenkins

Jenkins is one of the most widely adopted open-source automation servers in the DevOps ecosystem. It can function as a standalone CI server, a CD orchestration hub, or a general-purpose job scheduler — including cron-style scheduled tasks. Jenkins supports distributed builds, allowing workloads to be spread across multiple agents so teams can build, test, and deploy across different platforms in parallel.

Its extensibility is a major selling point. A large plugin ecosystem — available through the Jenkins update centre — lets teams integrate Jenkins with a broad range of tools covering version control, build systems, cloud providers, and notification services. This flexibility makes Jenkins a practical choice for heterogeneous environments where no single vendor toolchain dominates.

2. CircleCI

CircleCI is a cloud-based CI/CD platform that automates the pipeline from code commit through to deployment. Teams define workflows in a YAML configuration file, specifying jobs for build, test, and deploy stages. The dashboard gives a consolidated view of pipeline status across all branches and projects.

A notable feature is per-job resource configuration: teams can allocate different CPU and memory classes to different pipeline stages, avoiding over-provisioning on lightweight jobs and under-provisioning on resource-heavy test suites. CircleCI supports any language that compiles or runs on Linux or macOS, including JavaScript, Python, Ruby, PHP, C++, and .NET.

3. Microsoft Team Foundation Server (TFS)

Microsoft Team Foundation Server is an on-premises application lifecycle management (ALM) platform. It brings together version control, work item tracking, build automation, and release management under one roof — making it a common choice for enterprises that require their tooling to remain within their own data centres for compliance or security reasons.

TFS supports multiple programming languages including Java, C#, Python, and HTML5, and integrates with IDEs such as Visual Studio, Eclipse, and Xcode. Teams can model their processes using agile frameworks including Scrum and Kanban, with built-in dashboards for tracking progress. Note: Microsoft has since evolved TFS into Azure DevOps Server; organisations evaluating this tool should assess whether the newer product better fits their roadmap.

4. Sourcetree

Sourcetree is a free desktop Git client developed by Atlassian for macOS and Windows. Its primary purpose is to give developers a visual interface for interacting with Git (and Mercurial) repositories, reducing reliance on the command line for routine operations like branching, merging, staging, and committing.

The built-in branch-flow visualiser makes it straightforward to understand a repository’s commit graph at a glance, which is particularly helpful when onboarding new team members or reviewing complex branch histories. Sourcetree integrates natively with Bitbucket but works with any Git remote.

5. AWS CloudFormation

AWS CloudFormation is Amazon’s infrastructure-as-code (IaC) service. Engineers describe the desired state of AWS resources — EC2 instances, VPCs, RDS databases, IAM roles, and so on — in a JSON or YAML template file. CloudFormation reads that template and provisions or updates resources in the correct dependency order, without manual steps.

Storing infrastructure definitions as code means they can be version-controlled, peer-reviewed, and reused across environments. CloudFormation’s stack model also provides rollback capability: if a deployment fails, the service can automatically revert the stack to its previous known-good state. This repeatability and auditability makes it a foundation for compliance-conscious DevOps practices on AWS.

6. GitLab

GitLab positions itself as a single application covering the entire DevOps lifecycle — from planning and source control through CI/CD, security scanning, and monitoring. Having these capabilities in one platform reduces the integration overhead that comes with stitching together multiple point tools.

GitLab’s built-in CI/CD uses a .gitlab-ci.yml file to define pipelines. It also includes Value Stream Analytics (formerly Cycle Analytics), which surfaces where time is being spent across the software delivery lifecycle so teams can target bottlenecks. On the access-control side, GitLab supports LDAP, SAML, OmniAuth, and Okta for authentication.

7. Codeship

Codeship is a hosted CI/CD service aimed at reducing pipeline configuration overhead. Common CI dependencies come pre-installed on build machines, and both CI and deployment workflows can be configured through the web interface — useful for teams that want to avoid managing their own CI infrastructure.

Codeship connects to GitHub, Bitbucket, and GitLab for source control and supports one-click deployment integrations with common hosting targets. It offers two tiers: Codeship Basic (UI-driven, simpler pipelines) and Codeship Pro (Docker-based, more configurable). Note: Codeship was acquired by CloudBees; teams evaluating it should check the current product status and roadmap.

8. GitHub

GitHub is the largest web-based code hosting platform, used for both public open-source projects and private enterprise repositories. Its pull request model has become the de facto standard for collaborative code review: developers propose changes on a branch, reviewers comment inline, and changes are merged only after approval.

GitHub integrates with a broad ecosystem of tools via webhooks and the GitHub Marketplace. Repository security features include protected branches, required status checks, SAML/SSO, and granular permission controls. GitHub Actions — released after this list was originally compiled — has since become a significant built-in CI/CD option worth evaluating alongside the tools listed here.

9. Bitbucket

Bitbucket is Atlassian’s Git code management platform, available as a cloud service (Bitbucket Cloud) and a self-hosted option (Bitbucket Data Center). It integrates tightly with other Atlassian products — Jira for issue tracking and Confluence for documentation — making it a natural fit for teams already in the Atlassian ecosystem.

Bitbucket Pipelines provides built-in CI/CD configured via a bitbucket-pipelines.yml file. Branch permissions and two-step verification help teams enforce code review policies and protect production-bound branches.

10. Apache Maven

Apache Maven is an open-source build automation and project management tool, primarily used in the Java ecosystem. It is based on the concept of a Project Object Model (POM), defined in a pom.xml file that declares a project’s dependencies, build plugins, and lifecycle phases.

Maven’s convention-over-configuration approach standardises project structure, which simplifies onboarding and makes builds reproducible across developer workstations and CI servers alike. Its central repository system handles dependency resolution automatically. Maven can be extended with a wide range of core and third-party plugins covering code quality checks, documentation generation, and deployment.

11. Git

Git is the distributed version control system that underpins most modern software development workflows. Created by Linus Torvalds, it is free and open source, designed to handle everything from small personal projects to very large codebases with thousands of contributors.

Key capabilities include fast branching and merging, a staging area (index) that gives developers fine-grained control over what goes into each commit, and support for non-linear workflows. Because every clone is a full repository with complete history, Git works well in offline or distributed team environments. Platforms like GitHub, GitLab, and Bitbucket are all built on top of Git.

12. PyCharm

PyCharm is an IDE developed by JetBrains specifically for Python development. It includes features oriented toward large or complex codebases: smart code completion, real-time code inspections with error highlighting, automated refactoring, and a powerful code navigation system.

PyCharm is available in a free Community edition and a paid Professional edition that adds support for web frameworks (Django, Flask), database tools, and remote interpreter configuration — the latter being relevant for DevOps workflows where code runs in containers or on remote servers. It integrates with Git and other VCS systems directly from the IDE.

Choosing the Right Tools for Your Pipeline

No single tool on this list solves every DevOps challenge, and most mature pipelines combine several of them. A common baseline might pair Git for source control, GitHub or GitLab for repository hosting and code review, Jenkins or CircleCI for CI, and AWS CloudFormation for infrastructure provisioning. Build tooling like Maven sits at the application level, while Sourcetree and PyCharm operate at the individual developer’s workstation.

When evaluating tools, weigh integration compatibility with your existing stack, total cost of ownership (hosted versus self-managed), and the learning curve for your team. The tools listed here have broad community adoption, which generally means better documentation, more available plugins, and easier hiring — practical factors that matter as much as feature lists.

This article is based on a list originally reported by CMSWire, sourced from G2 Crowd’s aggregated data on DevOps tooling adoption.

Having a strong DevOps culture is like having good taste. Everyone wants it – but is everyone equipped with the skills, instincts, and sheer luck needed to actually have it?

The reality is, building a great DevOps culture is easier said than done. Here are the major challenges facing strong DevOps cultures and how to overcome them.

1. Inability to give and listen to feedback

Teams must learn how to give and receive feedback if they are to improve and take each other forward in the process. Engineers and operators are smart cookies with high IQs, but many need to improve their EQs to collaborate more effectively as a team. Teams with high EQ will always destroy those with low EQ because they can learn and achieve more. 

Feedback is about sharing what is working and what can be improved every single day. It’s important that teams don’t just focus on the good or the bad, but rather keep a sharp focus on feedback and bias.

2. The revolving door problem


Part of the challenge facing DevOps culture is the short tenure of DevOps professionals themselves. The average tenure of a DevOps engineer is less than three years. Engineers often find themselves lured away for the promise of better compensation, better equity, or the “next hot startup company.”

This doesn’t do any favors to the ongoing battle to achieve true alignment between Dev and Ops teams: How they can play together when team members are constantly jumping ship, leaving behind unfinished projects, and forcing new people to join and ramp up quickly? If there were more stability in engineering teams, it might be easier to build the foundations of a stable and durable DevOps culture.

3. Well-meaning but time-wasting acts of heroism

Often you’ll be at a developer conference and an enthusiastic, well-meaning presenter is gushing about the unbelievably complex, bespoke platform that her team has built – one that has nothing to do with their core competency. She demonstrates how they spent six months and $300,000 to create it and the whole room bursts into applause.

The “build it not buy It” mentality is one that truly holds back top-performing engineering teams. In 2018, the platform you need has likely been built – and built extremely well – by a third party. Save your engineering heroics for what your customer actually requires; the rest is a needless waste of time and resources. Be an expert in your business, not the tools business.

4. The term “DevOps” is a problem

If you ask many high-performing engineering teams about DevOps, the response you’ll often get is an eye roll – even if those teams are uncommonly good at DevOps. The word has been beaten down, over-publicized, and over-discussed. (I know, this article doesn’t help that situation.)

If DevOps refers to the cultural alignment of development and operations so that both teams are responsible for the success of production environments, then the term has enormous value. But if the word has been drained of all meaning by a tsunami of think pieces and keynote presentations, then it’s difficult to have a meaningful discussion about it.

Try to remember that the concept has value, even if it’s been beaten down by so many analyses, conversations, and misunderstandings.

5. The right culture isn’t modeled from above

You all know the truth of this statement: There’s no culture unless it’s shown by example, set by the teams above. It takes a superhuman effort for a team to enact its own unique culture within an organization that doesn’t itself value culture or take it seriously.

If you have an organization where the executive and management team isn’t truly facilitating team alignment, including between the developer and operations teams, how can a DevOps team survive and thrive? Culture comes from the top.

6. DevOps goals aren’t aligned to business goals

99.9 percent of companies using DevOps are wielding it as a catalyst to drive business outcomes faster, and a strong DevOps culture is one that truly understands the levers of its business. DevOps is not about having a team of “rock stars” that improves technical KPIs; in fact, measuring availability is pointless unless you can measure and report the real business impact.

 Technical metrics are great, but goals drive behavior – and goals that focus on the needs of the business constitute the foundation of a solid DevOps culture.

How to beat the DevOps barriers

I’ve spent a lot of time describing the barriers that keep DevOps teams from reaching their full potential. But the reality is, there are plenty of positive forces helping DevOps teams build strong cultures. For one, the will to do so is stronger than ever: Companies want strong DevOps organizations to help them achieve business goals. For another, technology is better than ever and can help teams focus on the same shared metrics and set of goals.

Wherever you find the twin enablers of genuine will and solid technology, a strong DevOps culture can’t be too far behind. In addition to will and technology, companies seeking to build that culture must:

• Focus as much on EQ as IQ, making sure engineers and operators really listen to each other while building a DevOps culture from the ground up. This will also help maintain collaboration and stability on Dev and Ops teams, making constant turnover less of a cultural and business problem. (See our related story: 10 things leaders with emotional intelligence never do.)
• Stay in the business you’re in: Allow engineers to focus on what your company was created for, rather than distracting them.
• Have open discussions on what DevOps really means, and what it means to your teams, independent of the hype that the word has taken on in recent years.
• Ensure leadership is taking DevOps seriously by showing, not telling, how to build a collaborative culture – and by linking DevOps goals directly to business goals.

Slack has become one of the most widely adopted communication platforms for DevOps teams, and for good reason: it combines persistent chat, third-party integrations, file sharing, and audio/video calling in a single workspace. This article covers the real collaboration challenges DevOps teams face and how to configure Slack to address them.

Why Collaboration Is Still a Challenge in DevOps

Most organizations do not have a full DevOps team available around the clock. When a production incident occurs at 2 a.m., the burden of response often falls on whoever is on call — frequently just one or two engineers working without real-time support from the broader team.

This creates several compounding problems:

• Context is siloed. The engineer who knows the affected service best may be asleep. The person who is awake lacks critical context.
• Decisions slow down. Without easy access to teammates, responders hesitate or make decisions with incomplete information.
• Burnout accumulates. When the same small group repeatedly handles incidents alone, morale and retention suffer.

A well-configured communication platform does not eliminate these pressures, but it significantly lowers the friction of pulling the right people into a conversation at the right time.

Why Slack Works Well for DevOps Teams

Slack’s value for DevOps goes beyond simple chat. Its integration ecosystem connects it to virtually every tool in a modern software delivery pipeline — version control, CI/CD systems, monitoring, alerting, and log management platforms. This means your team can receive and act on signals from your infrastructure inside the same workspace where they already communicate.

Commonly used Slack integrations for DevOps include:

• GitHub / GitLab — receive notifications for pull requests, code reviews, and merge events.
• Jenkins / CircleCI / GitHub Actions — post build and deployment status directly into a channel.
• PagerDuty / OpsGenie — surface on-call alerts and allow acknowledgment from within Slack.
• Datadog / Prometheus / Grafana — send monitoring alerts and threshold breaches to dedicated channels.
• Jira / Linear — link tickets to conversations and update issue status without leaving Slack.

Custom integrations are also straightforward to build using Slack’s Bolt SDK or its incoming webhooks API, making it practical to connect internal tools that lack off-the-shelf Slack apps. For example, the team at Logz.io built a Kibana Snapshots integration that lets engineers share Kibana dashboard visualizations directly in a Slack channel, enabling the team to see and discuss log anomalies in real time without switching tools.

Practical Tips for Using Slack in a DevOps Workflow

1. Structure Your Channels Deliberately

Unstructured Slack workspaces become noisy fast. A thoughtful channel structure keeps signal separate from noise:

• #incidents or #ops-alerts — a dedicated channel for production alerts and active incident response. Pin runbooks and postmortem links here.
• #deploys — automated deployment notifications from your CI/CD pipeline, giving everyone visibility into what is shipping and when.
• #team-[service-name] — per-service or per-squad channels so conversations stay scoped and relevant.
• #monitoring — aggregated infrastructure and application metrics alerts.
• #general-devops — async discussion, questions, and knowledge sharing across the broader team.

Use channel naming conventions consistently so any team member can find the right channel without asking.

2. Use Huddles and Calls for Active Incidents

Text chat is efficient for async communication but becomes a bottleneck during high-pressure incidents. Slack Huddles (lightweight audio calls) or full video calls allow teams to coordinate verbally, which is faster when dozens of messages are flying in simultaneously.

A reasonable convention: escalate from chat to a huddle when the incident has been active for more than a few minutes and multiple engineers are involved. Reserve calls for genuine emergencies and be respectful of off-hours time — unnecessary calls outside working hours erode trust quickly.

3. Manage Notification Overload Proactively

One of the most common Slack anti-patterns is integrating every possible tool and letting every event post to a channel. The result is alert fatigue — engineers start ignoring channels because the noise-to-signal ratio is too high.

Practical mitigation strategies:

• Only post actionable alerts to Slack. Informational logs belong in your logging platform, not a chat channel.
• Set alert thresholds high enough that only genuine anomalies trigger a notification.
• Use Slack’s notification schedules feature so engineers can define quiet hours without fully disconnecting.
• Periodically audit active integrations and remove or silence those that no longer provide value.

4. Document Decisions in Threads

Slack’s threaded replies are underused in many teams. During an incident or a design discussion, use threads to keep a coherent record of the decision-making process. After the incident is resolved, copy key findings into your postmortem document or wiki. Treat Slack as a real-time communication layer, not a long-term knowledge store — important conclusions should always be captured somewhere durable.

5. Automate Incident Workflows with Slack Bots

Several incident management platforms (PagerDuty, Opsgenie, FireHydrant, and others) offer Slack bot integrations that let you acknowledge alerts, assign incident commanders, create dedicated incident channels automatically, and post status updates — all from within Slack. Automating these steps reduces the cognitive load on the engineer who first picks up an alert and ensures a consistent response process every time.

The Broader Value of Communication in DevOps

Slack is a tool, not a strategy. The underlying goal is a culture where developers and operations engineers communicate openly, share context early, and feel comfortable raising problems without blame. No chat platform can manufacture that culture on its own, but a well-organized, well-integrated Slack workspace removes a significant amount of friction that would otherwise slow teams down.

When collaboration works — when an alert fires and the right people are in a channel within minutes, with relevant dashboard snapshots and runbook links already surfaced — teams ship faster, recover faster, and spend less time firefighting. That is the DevOps promise, and thoughtful use of tools like Slack is a meaningful step toward delivering on it.

Original article sourced from TechTarget / DevOps Agenda.

Why Compensation Alone Won’t Build a Thriving DevOps Team

How do you keep software engineers happy and genuinely productive? The answer goes well beyond salary bands and office perks. Engineers who have adopted the DevOps mindset are motivated by more than a paycheck — they care deeply about how they work, what tools they use, and whether the culture around them enables continuous improvement.

Competitive compensation, a comfortable working environment, and performance bonuses are all necessary to attract DevOps talent. But on their own, these factors are insufficient. Organizations that rely on financial incentives alone frequently find that their best engineers remain disengaged, leave for competitors, or quietly underperform within processes they find frustrating.

The real differentiator is culture. To get the most from DevOps professionals — and to keep them — you need to build an environment that aligns with how they think and what they value.

Five Cultural Characteristics That Motivate DevOps Engineers

The following characteristics reflect what DevOps professionals consistently look for in their working environment. Organizations that embed these qualities into their culture are far better positioned to attract, retain, and get the best work out of DevOps talent.

1. Flexible, Overlapping Roles

One of the core premises of DevOps is the breaking down of silos between development, IT operations, security, and other disciplines. Engineers who embrace DevOps expect their day-to-day responsibilities to reflect this philosophy. Rigid job titles that strictly define what an engineer can and cannot do are antithetical to the DevOps model.

This does not mean eliminating roles entirely — structure still has value. But it does mean allowing engineers to step outside their official remit when it makes sense, and actively considering hybrid roles that span traditional boundaries (such as platform engineering or site reliability engineering).

2. Autonomy to Choose Their Own Tools

DevOps practitioners tend to have strong, well-informed opinions about tooling. Mandating a specific tool set without giving engineers any input is a reliable way to generate resentment and reduce effectiveness. Teams that are forced to use tools they find inferior or poorly suited to the task are less efficient and less engaged.

Within the constraints of organisational security, compliance, and interoperability requirements, empower teams to select the tools that best fit their workflow. If a team prefers a different CI tool, a different container orchestration approach, or a different monitoring stack than the rest of the organisation, evaluate the request on its merits rather than dismissing it reflexively.

3. A Safe Environment for Dissent

Continuous improvement — a foundational DevOps principle — is impossible without honest feedback. DevOps engineers want to be able to raise concerns about processes, tooling, and ways of working without fear of political fallout. If team members feel that speaking up will be ignored or penalised, problems accumulate and morale erodes.

Building psychological safety into your engineering culture is not a soft, optional extra. It is a prerequisite for the blameless post-mortems, retrospectives, and iterative process improvements that make DevOps work in practice.

4. Freedom from Unnecessary Redundancy

DevOps engineers are strongly drawn to the principle of building once and deploying anywhere. Repetitive manual tasks that could be standardised or eliminated are a persistent source of frustration. Wherever possible, streamline workflows to remove duplication — in pipeline steps, configuration management, environment provisioning, and deployment procedures.

It is worth noting that redundancy is not always a problem: deliberate redundancy in testing strategies, failover systems, and data backups is a feature, not a bug. The target of simplification should be unnecessary duplication of effort, not resilience architecture.

5. Automation of Tedious, Repeatable Work

DevOps engineers are natural automators. Tasks that are manual, repetitive, and clearly automatable — server provisioning, incident alert routing, backup jobs, schedule management, environment teardown — are deeply unsatisfying when left as toil. Beyond the morale impact, toil is also a practical problem: it consumes engineering time that could be spent on higher-value work.

Encourage and fund automation efforts. Give engineers the time and mandate to reduce toil across the delivery pipeline and operations runbook. This pays dividends both in engineer satisfaction and in operational reliability.

Putting It All Together

Compensation sets the floor. Culture determines the ceiling. Organisations that pair fair pay with flexible roles, tool autonomy, psychological safety, lean workflows, and a commitment to automation create environments where DevOps engineers can do their best work — and want to stay.

The investment required to build this kind of culture is largely organisational rather than financial. It demands deliberate leadership decisions, a willingness to cede some control to engineering teams, and a genuine commitment to continuous improvement at every level of the organisation. The return on that investment — in productivity, retention, and delivery quality — is substantial.

Building DevOps characteristics into your culture is not a one-time initiative. It is an ongoing practice that needs to be modelled from the top and reinforced through everyday decisions about how work gets done.

The main goal of DevOps is quite simple: ship software updates frequently, reliably, and with better quality. This goal is somewhat “motherhood and apple pie,” since almost every organization will agree that they want to get there. Many will tell you they’ve already embarked on the DevOps journey by following some commonly followed frameworks, such as “CALMS.”

However, very few will express complete satisfaction with the results. After speaking to 200+ DevOps professionals at various stages of the adoption lifecycle, we found that organizations generally fall in one of three categories:

We were most interested in groups two and three since they were actually in the middle of their DevOps journey. When asked to better explain the challenges and roadblocks, here is what we found:

• 68% said that the lack of connectivity between the various DevOps tools in their toolchain was the most frustrating aspect
• 52% said that a large portion of their testing was still manual, slowing them down
• 38% pointed out that they had a mix of legacy and modern applications, i.e. a brownfield environment. This created complexity in terms of deployment strategies and endpoints, toolchain, etc.
• 27% were still struggling with siloed teams that could not collaborate as expected
• 23% had limited access to self-service infrastructure
• Other notable pain points included finding the right DevOps skill set, difficulty managing the complexity of multiple services and environments, lack of budget and urgency, and limited support from executive leadership

Let us look at each of these challenges in greater detail.

#1: Lack of connectivity in the DevOps toolchain
There are many DevOps tools available that help automate different tasks like CI, infrastructure provisioning, testing, deployments, config management, release management, etc. While these have helped tremendously as organizations start adopting DevOps processes, they often do not work well together.

As a classic example, a Principal DevOps engineer whose team uses Capistrano for deployments told us that he still communicates with Test and Ops teams via JIRA tickets whenever a new version of the application had to be deployed, or whenever a config change had to be applied across their infrastructure.

All the information required to run Capistrano scripts was available in the JIRA ticket, which he manually copied over to his scripts before running them. This process usually took several hours and needed to be carefully managed since the required config was manually transferred twice: once when entered into JIRA, and again when he copied it to Capistrano.

This is one simple example, but this problem exists across the entire toolchain.

Smaller organizations get around this problem by writing custom scripts that glue their toolchain together. This works fine for a couple of applications, but quickly escalates to spaghetti hell since these scripts aren’t usually written in a standard fashion. They are also difficult to maintain and often contain tokens, keys and other sensitive information. Worse still, these scripts are highly customized for each application and cannot be reused to easily scale automation workflows.

For most serious organizations, it is an expensive and complex effort to build this homegrown “DevOps glue,” and unless they have the discipline and resources of the Facebooks and Amazons of the world, it ultimately becomes a roadblock for DevOps progress.

Continuous Delivery is very difficult to achieve when the tools in your DevOps toolchain cannot collaborate and you manage dependencies manually or through custom scripts.

Challenge #2: Lack of test automation
Despite all the focus on TDD, most organizations still struggle with automating their tests. If the testing is manual, it is almost impossible to execute the entire test suite for every commit, becoming a barrier for Continuous Delivery. Teams try to optimize this by running a core set of tests for every commit and running the complete test suite only periodically. This means that most bugs are found later in your software delivery workflow and are much more expensive to find and fix.

Test automation is an important part of the DevOps adoption process and hence needs to be a top priority.

Challenge #3: Brownfield environments
Typical IT portfolios are heterogeneous in nature, spanning multiple decades of technology, cloud platform vendors, private and public clouds in their labs and data centers, all at the same time. It is very challenging to create a workflow that spans across these aspects since most tools work with specific architectures and technologies. This leads to toolchain sprawl as each team uses the toolchain best serving their needs.

The rise of Docker has also encouraged many organizations to develop microservices-based applications. This has also increased the complexity for DevOps automation since an application now needs hundreds of deployment pipelines for heterogeneous microservices.

Challenge #4: Cultural problems
Applications evolve across functionals silos. Developers craft software, which is stabilized by QA, and then deployed and operated by IT Operations. Even though all these teams are expected to work together and collaborate, they often have conflicting interests.

Developers are driven to move as fast as they can and build new stuff. QA and Release management teams are driven to be as thorough as possible, making sure no software errors can escape past their watchful eyes. Both teams are often gated by SecOps and Infrastructure Ops, who are incentivized to ensure production doesn’t break.

Governance and compliance also plays a role in slowing things down. Cost centers are under pressure to do more with less, which leads to a culture that opposes change, since change introduces risk and destabilizes things, which means more money and resources are required to manage the impact.

This breakdown across functional silos leads to collaboration and coordination issues, slowing down the flow of application changes.

Some organizations try to address this by making developers build, test and operate software. Though this might work in theory, developers are bogged down by production issues, and a majority of time is spent on operating what they built last month as opposed innovating on new things. Most organizations try to get all teams involved across all phases of the SDLC, but this approach still relies on manual collaboration.

Automation is the best way to broker peace and help Dev and Ops collaborate. But as we see in other challenges, ad-hoc automation itself can slow you down and introduce risk and errors.

Challenge #5: Limited access to self-service infrastructure and environments
For many organizations, virtual machines and cloud computing transformed the process of obtaining the right infrastructure on-demand. What previously took months could now be achieved in a few minutes. IaaS providers like AWS have hundreds of machines with flexible configurations and many options for pre-installed OS and other tools. Tools like Ansible, Chef, Puppet help represent infrastructure-as-code, which further speeds up provisioning and re-provisioning of machines.

However, this is still a problem in many organizations, especially those running their own data centers or those that haven’t embraced the cloud yet.

We Need more from DevOps
A popular DevOps framework describes a CALMS approach, consisting of Culture, Automation, Lean, Measurement and Sharing. The DevOps movement started as a cultural movement, and even today, most implementations focus heavily on culture.

While culture is an important part of any DevOps story, changing organizational culture is the hardest thing of all. Culture forms over a period of time due to ground realities. Ops teams don’t hate change because they are irrational or want to be blockers. Over the years, they’ve taken the heat every time an over-enthusiastic Dev team tried to fast-track changes to production without following every step along the way.

Seating them with the developers might help make the work environment a little friendlier but it doesn’t address the root cause, no matter how many beers they have together.

Why DevOps Hiring Is So Difficult

DevOps sits at the intersection of software development and IT operations. A competent DevOps engineer must understand application development, infrastructure, networking, security, and automation — often simultaneously. That breadth of required knowledge makes the role genuinely hard to fill. On top of technical depth, DevOps demands strong interpersonal skills: the ability to break down organizational silos and foster continuous collaboration between teams that have historically worked in isolation.

The practical results of successful DevOps adoption speak for themselves. Organizations that have committed to DevOps methodologies report meaningful reductions in system downtime, faster application deployment cycles, and lower overall software delivery costs. Those outcomes drive executive demand — which in turn drives fierce competition for the people who can deliver them.

1. Articulate Your Own DevOps Vision First

Before you write a single job description, you need clarity on what DevOps means inside your organization. DevOps is not a single, universal implementation — it means different things in different contexts:

• Cultural transformation: Breaking silos so that developers, operations staff, DBAs, security engineers, and network administrators collaborate throughout the application lifecycle.
• Process automation: Using toolchains (CI/CD pipelines, infrastructure-as-code, configuration management) to reduce manual work and accelerate delivery.
• Both simultaneously: Most mature DevOps implementations combine cultural change with tooling.

Experienced DevOps engineers have career goals and preferences of their own. A candidate who thrives on greenfield automation work may leave quickly if your primary need is cultural change management. Misalignment between the role as sold and the role as lived is one of the most avoidable causes of early attrition. Define your DevOps vision internally before you hire externally.

2. Look for the Right Technical Skills

The skill set required of a strong DevOps engineer is genuinely broad. When evaluating candidates, look for demonstrated competence in as many of the following areas as possible:

• System build, configuration, and administration
• Virtualization and container technologies (e.g., VMware, Docker, Kubernetes)
• Infrastructure-as-code tools (e.g., Terraform, Ansible, Puppet, Chef)
• CI/CD pipeline design and management (e.g., Jenkins, GitLab CI, GitHub Actions)
• Scripting and automation (e.g., Python, Bash, Go)
• Cloud platform experience (AWS, Azure, GCP)
• Monitoring, observability, and incident response
• Security practices relevant to software delivery (DevSecOps)

It is rare to find all of these skills at an expert level in a single person. Identify which competencies are critical for your current needs and which can be developed on the job. Prioritizing a short, honest list of must-haves leads to better hiring decisions than chasing an impossible generalist unicorn.

3. Evaluate Attitude and Cultural Fit

Technical skills can be taught; attitude is much harder to change. DevOps requires people to collaborate across traditional IT boundaries, share ownership of outcomes, and embrace continuous learning. When interviewing, look for candidates who:

• Show genuine curiosity about systems and processes outside their primary specialty
• Can articulate how they have improved collaboration between development and operations teams
• Are comfortable with ambiguity and iterative improvement
• Take a service-oriented approach — they care about the outcome for end users, not just completing a ticket

It is also worth assessing your existing team’s readiness for change. Introducing a DevOps engineer into an organization that is resistant to the cultural shift can isolate that individual and undermine the entire initiative. Internal change management is as important as external hiring.

4. Find the DevOps Community Watering Holes

Passive job postings are unlikely to surface the best DevOps candidates. Experienced engineers in this field are typically employed and are not actively searching. To reach them, you need to be present where they gather:

• Professional networks: LinkedIn groups focused on DevOps, SRE, and platform engineering
• Conferences: DevOpsDays events (held in cities worldwide), KubeCon, HashiConf, and similar practitioner-focused conferences
• Online communities: Slack workspaces, Discord servers, and forums dedicated to specific tools (Kubernetes, Terraform, etc.)
• Local meetups: Many cities have active DevOps, SRE, and cloud-native user groups
• Open-source projects: Contributors to relevant projects are demonstrably skilled and motivated

Your own engineering staff are often the best source of referrals. They know the community, and candidates who come through employee referrals tend to be better matches and retain longer.

5. Grow Your Own Engineers

External hiring alone is not a sustainable DevOps talent strategy, particularly in a competitive market. Consider two internal pipelines:

• University partnerships: Engage computer science and information systems programs at nearby colleges. Early internship relationships with strong students allow you to evaluate potential hires before committing to a full-time offer. Some universities now offer DevOps-specific coursework or certificates.
• Internal upskilling: Audit your existing IT staff. Systems administrators, network engineers, and application developers who show initiative and curiosity about adjacent disciplines are strong candidates for DevOps cross-training. Providing formal training, mentorship, and stretch assignments is often more cost-effective than recruiting experienced engineers from outside.

Internal candidates already understand your systems, culture, and business domain — advantages that take months to develop in an external hire.

6. Use Staffing Agencies Selectively — Not Exclusively

Specialized IT staffing firms can accelerate your search, particularly when you need to fill a role quickly or lack internal recruiting capacity. However, there are important caveats:

• Avoid exclusive agreements. As your hiring effort progresses, you will develop your own candidate channels — referrals, community relationships, university pipelines — and you do not want a contractual obligation that prevents you from using them.
• Vet agencies for genuine DevOps expertise. Some generalist agencies lack the technical depth to screen DevOps candidates effectively. Look for firms whose recruiters can have a credible conversation about CI/CD pipelines or infrastructure-as-code.
• Use agencies as one channel among several, not as a replacement for a broader talent strategy.

7. Do Not Limit Yourself Geographically

The shortage of experienced DevOps engineers means that insisting on local candidates significantly reduces your addressable talent pool. Consider the following adjustments:

• Budget for relocation assistance when a candidate is an excellent match but lives outside commuting distance. For a senior-level DevOps role, relocation costs are modest relative to the cost of a prolonged vacancy or a bad hire.
• Embrace remote or hybrid work arrangements where your infrastructure and security posture allow it. Remote-friendly positions dramatically expand the candidate pool and are increasingly expected by experienced engineers.
• Consider international candidates if your organization has the capacity to navigate visa and employment requirements.

8. Convert Independent Consultants Into Permanent Hires

Many skilled DevOps professionals work as independent consultants or contractors. While daily rates for experienced independents are high, not every consultant prefers the instability of contract work indefinitely. Some actively look for the right permanent opportunity — one that offers technical challenge, organizational support, and long-term career development.

If you engage a DevOps consultant for a project and they perform well, it is worth having a frank conversation about whether a staff role would interest them. Offering a senior title with appropriate compensation and genuine technical ownership can be compelling to the right person. You already have direct evidence of their skills and working style — which removes much of the risk inherent in a traditional hire.

Putting It All Together

No single approach reliably fills a DevOps role in a competitive market. The most effective hiring strategies combine several of these practices simultaneously: maintaining active community presence, upskilling internal staff, keeping geographic constraints minimal, using agencies as one tool among many, and staying alert for consultants who may be ready for a permanent role.

Accept that finding the right DevOps engineer may take several months, and plan accordingly. A rushed hire that results in a poor cultural or technical fit is more disruptive and costly than a patient, disciplined search. Define what success looks like in your specific context, communicate that vision clearly to candidates, and invest in developing talent at every level — external hires, internal transfers, and early-career engineers alike.

Research published by Axway in partnership with analyst firm Ovum surveyed 450 senior IT decision makers on the state of B2B integration and digital transformation readiness. Two findings stood out as particularly sobering: more than half of the enterprises surveyed had experienced SLA failures or compliance shortfalls, and nearly a third had not yet explored the role of APIs in their digital strategy. Both gaps carry significant business risk — and both require executive-level action to address.

If your organisation is in a similar position, the sections below offer practical guidance on how to elevate DevOps from an engineering conversation to a boardroom priority.

Speak Truth to Power: Translating Tech into Business Language

One of the most common mistakes DevOps advocates make when addressing the C-suite is leading with technology. Executives do not make decisions based on framework names, pipeline configurations, or API gateway throughput figures. They respond to revenue risk, competitive positioning, legal exposure, and brand reputation.

Despite this, the same Axway/Ovum research found that 36 per cent of businesses surveyed had no plans to invest in APIs — suggesting either that digital initiatives lacked internal priority, or that IT teams had failed to frame the investment compellingly enough to unlock funding. Neither situation is acceptable in a competitive digital environment.

Two arguments tend to cut through at the board level:

• Slow IT is an existential threat. Failure to invest in modern delivery practices and API integration directly limits a business’s ability to launch new digital services, respond to customer demand, and outpace competitors. The customer experience deteriorates, brand equity erodes, and revenue follows. Framing DevOps investment as a growth enabler — not a cost centre — changes the conversation.
• Security and compliance failures can carry personal legal consequences. Data breaches and regulatory non-compliance are not just IT problems; they can result in civil penalties and, in some jurisdictions, criminal liability for named executives. Partnering with the Chief Compliance Officer or Chief Legal Officer to present concrete risk scenarios to the CEO and CFO is far more persuasive than a technical risk register. Make it clear that up-to-date, fit-for-purpose technology is a prerequisite for the compliance posture the business legally requires.

Don’t Fly Blind: Integration Visibility and Technical Debt

More than 50 per cent of respondents in the Axway/Ovum survey cited a lack of end-to-end visibility, security compliance gaps, and poor integration with backend systems as active concerns. Compounding this, 57 per cent reported relying on B2B integration gateways more than five years old — infrastructure that typically lacks modern API management capabilities and struggles to support cloud-native or hybrid architectures.

Ageing integration layers create compounding risk. As digital surface area grows — more partners, more endpoints, more data flows — the brittleness of legacy middleware becomes increasingly costly to manage and nearly impossible to audit comprehensively. The result is exactly the kind of visibility deficit that makes SLA failures and compliance breaches more likely.

APIs, when adopted as part of a structured integration strategy, address this directly. They provide a consistent, observable, and governable interface layer across systems — enabling the real-time monitoring, access control, and audit trails that compliance frameworks demand.

Before committing to a modernisation roadmap, DevOps teams should work through a set of foundational questions:

• Which internal services and products need to be re-engineered or re-integrated to support the organisation’s digital strategy?
• Does the current technology platform satisfy existing compliance requirements, and can it adapt to regulatory change without significant rework?
• Does the team manage APIs across a full lifecycle — from design and development through versioning, deprecation, and retirement?
• Is the team’s organisational structure genuinely compatible with a DevOps model, where parallel continuous delivery is the default rather than the exception?

These are not comfortable questions, but answering them honestly before beginning a transformation programme is far less expensive than discovering the gaps mid-rollout.

Always Think Ahead: Building a Future-Ready DevOps Strategy

Digital transformation is not a project with an end date — it is a sustained organisational capability. DevOps teams that treat it as a one-time migration risk finding themselves back in the same position within a few years, defending another modernisation spend to a sceptical board.

Three principles help build a strategy that holds up over time:

• Personalise the plan. There is no universal DevOps template. The right approach depends on your organisation’s size, industry, existing tooling, team structure, and business model. Audit your current state honestly, identify the gaps most material to your strategic goals, and build a roadmap that reflects your specific context — not a vendor’s reference architecture.
• Take a holistic view. DevOps is not a checklist of sequential process steps. It is a philosophy that spans people, process, and tooling. Optimise the whole system: eliminate redundant tools, reduce handoff friction between teams, and focus on flow rather than local efficiency. A deployment pipeline that is technically fast but surrounded by slow manual approvals is not a DevOps pipeline.
• Invest in continuous delivery as a long-term capability. The ability to ship small, frequent, low-risk changes is the foundation of organisational agility. It allows teams to respond to shifting customer expectations, incorporate feedback quickly, and reduce the blast radius of any single release. Building this capability now pays compounding dividends as market conditions evolve.

The Boardroom Conversation Is Worth Having

Digital transformation at the infrastructure and delivery layer is rarely glamorous, and it rarely sells itself. The DevOps professionals best positioned to drive it forward are those who can move fluently between technical detail and business consequence — who know when to talk about deployment frequency and when to talk about competitive risk.

The organisations that make this transition effectively — that modernise their integration layer, adopt API-driven architectures, and instil a continuous delivery culture — are those that will be positioned to meet rising customer expectations rather than scramble to catch up with them. The conversation starts with walking into the boardroom prepared.