This article draws on data reported in GitLab’s 2018 Global Developer Report, as summarized by TechTarget. The original survey covered 5,296 development professionals.
The Manager–Developer Perception Gap in DevOps
If your DevOps implementation feels like it is working brilliantly in the boardroom but struggling on the ground floor, you are not alone. GitLab’s 2018 Global Developer Report — based on responses from 5,296 development professionals — uncovered a striking disconnect between how managers and developers assess the success of DevOps at their organizations.
According to the survey data:
- 81% of managers said DevOps was saving the company time, while only 65% of developers agreed.
- 47% of managers believed their organization could deploy code on demand or multiple times a day, but only 35% of developers shared that view.
Ashish Kuthiala, then Director of Product Marketing at GitLab, summed up the finding plainly: “Managers are focused on saving time and things getting better, but developers see the day-to-day challenges and that they’re still in silos and that needs to change. In a lot of companies, code is still being passed from one team to another.”
This gap is not simply a morale problem — it has real consequences for prioritization, tooling investment, and how quickly organizations can identify and fix broken processes.
The Three Toughest DevOps Implementation Challenges
The report identified three perennial pain points that continue to slow DevOps adoption:
- Choosing the right technology — cited by 39% of respondents as the single biggest hurdle.
- Integration concerns — getting disparate tools and systems to work together reliably.
- Poor internal processes — long-standing organizational habits that resist change.
The tooling problem deserves particular attention. Kuthiala noted that the sheer number of available tools has become its own obstacle: “Developers are spending a lot of time focused on getting the tools they have to actually work. It’s kind of a badge of honor for them, but it takes away from valuable time spent coding.”
When asked to name their most critical tools, developers ranked these three at the top:
- A version control system (e.g., Git)
- An integrated development environment (IDE)
- A chat or collaboration tool
DevOps vs. Agile vs. Chaos: How Teams Describe Their Own Processes
When respondents were asked to label their own development methodology, the results were illuminating:
- 69% described their process as Agile
- 23% said DevOps
- 16% used Waterfall
- A notable portion chose “other” — and many of those respondents described their reality as “chaos”
The fact that Agile far outpaces DevOps as a self-descriptor suggests many teams are still treating DevOps as a distinct, separate practice rather than a natural evolution of Agile principles. For teams still in the “chaos” category, this data provides a useful mirror.
Where Development Bottlenecks Actually Occur
Consistent with findings from other DevOps industry surveys, testing emerged as the dominant bottleneck in the development pipeline. The full ranking from the GitLab report:
| Bottleneck | % of Respondents |
|---|---|
| Testing | 52% |
| Planning | 47% |
| Deploying to production | 31% |
| Code review | 30% |
The prominence of testing at the top of this list is worth unpacking. Manual testing cycles, insufficient test coverage, and slow CI pipelines all compound to create delays that developers feel acutely — but that can be invisible to management dashboards focused on release cadence alone.
What High-Performing DevOps Teams Do Differently
Despite the challenges, the survey’s most actionable finding may be what separates high-performing DevOps teams from the rest. According to Kuthiala, the differentiator is not necessarily advanced tooling or large budgets — it is discipline around small, incremental changes.
“High-performing teams pay a lot of attention to one single small change and making sure that it works. That gets their confidence up, and that’s not something you see with lower-performing teams.”
— Ashish Kuthiala, GitLab
This aligns with the broader DevOps principle of reducing batch size and increasing deployment frequency — shipping smaller changes more often rather than large, risky releases. Success in small increments builds team confidence, which compounds into stronger Agile execution over time.
Practical Advice: Start Small, Iterate Fast
For organizations still hesitant to commit to a full DevOps transformation, Kuthiala’s guidance from the report remains relevant:
“It’s a journey and you’re not going to know if it works or not until you get started. Get it started, get going, learn from it, fail fast and keep improving. You don’t have to take organizations and break them up into DevOps teams. Just pilot out projects and see if DevOps works for you.”
— Ashish Kuthiala, GitLab
This is sound, practical advice. A pilot project approach allows teams to:
- Demonstrate measurable value to management without organizational disruption
- Identify tool and process gaps in a low-risk environment
- Build internal advocates who can champion broader adoption
- Establish baseline metrics before scaling practices across teams
Closing the Perception Gap: What Managers and Developers Both Need to Do
The manager–developer perception gap is ultimately a communication and measurement problem. Managers are often measuring outcomes (releases shipped, time saved at a high level) while developers are experiencing process friction day to day. Closing this gap requires:
- Shared metrics — agree on what “good” looks like using objective pipeline data: lead time, deployment frequency, mean time to recovery (MTTR), and change failure rate.
- Developer visibility — give developers a direct line to surface process pain points to leadership, not just through annual surveys.
- Realistic deployment benchmarks — if managers believe code is deploying on demand when developers know it isn’t, that discrepancy needs to be investigated, not papered over.
- Iterative culture — reward teams for learning from failures, not just for hitting release dates.
The data from GitLab’s 2018 report may be several years old, but the underlying dynamic — optimistic leadership, friction-weary developers, and tool overload — remains one of the most commonly reported challenges in DevOps transformations today.