This article is based on reporting originally published at searchitoperations.techtarget.com in March 2020, covering expert guidance on remote DevOps work during the COVID-19 pandemic.
DevOps Teams and the Sudden Shift to Remote Work
The COVID-19 pandemic forced enterprises around the world to move their workforces remote with little warning. For DevOps teams, this transition was both more manageable and more disruptive than it might initially appear. On the positive side, DevOps engineers are already more likely than most knowledge workers to have experience with remote collaboration, distributed teams, and web-accessible tooling — especially for public cloud environments. Most IT management platforms expose a web interface that works equally well from a home office as from a corporate desk.
On the negative side, many Agile and DevOps practices had quietly evolved around physical co-location: daily standups in front of shared whiteboards, spontaneous hallway conversations, and the kind of organic, unplanned collaboration that is difficult to replicate over a video call.
“I don’t know anyone who doesn’t have remote access via VPN in the worst-case scenario. However, the disasters people plan for aren’t this disaster — they plan for one site or another to be down, but not, ‘what if nobody can come in to work?'”
Tom Petrocelli, Analyst, Amalgam Insights
Petrocelli’s observation points to a critical gap: business continuity planning in many organizations focused on infrastructure failures, not on enterprise-wide, sustained workforce displacement. The practical challenge was less about technology access and more about re-establishing team rhythms and coordination patterns in an entirely new context.
Why Disruption Was Inevitable
In the years before the pandemic, many major companies — including Yahoo and IBM — had reversed earlier remote-work policies and called distributed employees back to central offices. The result was that large portions of the enterprise workforce had lost familiarity with remote collaboration workflows just as they needed them most.
“This is kind of the chickens coming home to roost. Some companies eliminated remote work a few years ago and all adjusted to the idea of working in proximity to each other, and there will be disruptions in management.”
Tom Petrocelli, Analyst, Amalgam Insights
Gary McKay, Director of Agile Service Delivery at Somos — a registry management vendor for telecommunications customers based in East Brunswick, N.J. — observed this friction firsthand when his team went fully remote:
“A lot of things happen organically — you may have a hallway conversation. Most of our targets that were in flight are still in flight, but there may be a little bit of a delay because we’re not having the face-to-face coordination — it’s taking more conversation to get done.”
Gary McKay, Director of Agile Service Delivery, Somos
Six Practical Tips for DevOps Teams Working Remotely
1. Standardize Communication and Collaboration Tools
The single most important step when transitioning to remote work is agreeing on a standard set of communication tools — and enforcing that standard uniformly across the entire team. Tool fragmentation (where some people use Slack, others use Teams, and others rely on email) creates information silos and coordination failures.
“When people have a choice about which tools to use, that defeats the purpose of common collaboration tools and makes them ineffective. Everyone has to be at the same standard. Even if you have half the team remote and half the team in the office, everyone should still be on a conference call together.”
Jeremy Pullen, Principal Technical Consultant, Polodis
Critically, standardize at the lowest common denominator of access. If one team member cannot reliably use video, the whole team should default to audio-only calls. This prevents a two-tier experience where remote participants are disadvantaged relative to those with better bandwidth or equipment.
McKay’s team at Somos standardized on Slack for day-to-day communication, supplemented by phone calls when needed, deliberately minimizing email use. “Things get lost in translation with email,” McKay noted. “It’s easier to just pick up the phone.”
2. Eliminate Individual Specialization Bottlenecks
The DevOps community has long recognized the danger of the “hero” engineer — the person upon whom an entire team depends for a specific critical skill or system knowledge. This concept is illustrated prominently in The Phoenix Project through the character of “Brent,” whose indispensability makes the team fragile rather than resilient.
Remote work, combined with the unpredictable personal disruptions of a pandemic (school closures, family illness, caregiving responsibilities), makes single points of human failure especially dangerous. The mitigation strategy is straightforward: create a centralized, shared work queue from which any team member can pick up tasks based on availability and capacity.
“Even though no one wants to go through this, I think we’re actually going to become better, because it’s going to force us to do some things we should’ve already been doing. It will force us to get away from command and control meetings to more true collaboration and more of a work pool model.”
Carmen DeArdo, Independent DevOps Consultant and Senior Value Stream Management Strategist, Tasktop
3. Make Work Visible and Measurable
Shared work queues only function when work is accurately documented and tracked. Remote teams cannot rely on the ambient awareness that comes from working in the same physical space. Tools like Jira, Trello, and IT ticketing systems need to be kept meticulously up to date.
“When you have everyone at a whiteboard, you can get lazy about updating Kanban cards and other systems. But when teams are remote, it’s crucial that people be able to pull detailed information about an issue or work item.”
Carmen DeArdo
Recording meetings and maintaining thorough Slack channel histories also reduces the penalty for schedule disruptions. Team members who need to step away to care for children or family members can catch up asynchronously, without being forced to choose between personal responsibilities and professional participation.
4. Double Down on Automated Testing and Quality
Remote and distributed work can increase the risk of quality regressions. When developers work in isolation on separate branches or components, integration defects can accumulate undetected until they surface at merge or release time.
“Distributed teams can deliver faster, but quality issues emerge when that distributed work is reintegrated. Now is the time to double down on automated testing before things are put into production.”
Charles Betz, Analyst, Forrester
Practical steps include shrinking work increments so that integration happens more frequently, enforcing automated test gates in CI/CD pipelines before any code reaches staging or production, and being disciplined about code review coverage. Remote work is not an excuse to relax quality controls; if anything, it is a reason to tighten them.
5. Manage Outcomes, Not Activity
Micromanagement is counterproductive in normal times. During a period of widespread disruption — when team members are simultaneously managing childcare, potential illness, and general anxiety — it becomes actively harmful to morale and productivity.
“Focus more on results than activity. Focus on specific goals rather than whether people are ‘doing’ something and ‘looking busy’ — if you’re requiring every employee to be ‘green on Slack’ from 8 to 5, that’s a sign you’re already lost.”
Carmen DeArdo
Leaders should set clear, measurable goals for each sprint or work cycle, trust team members to manage their own schedules around personal obligations, and evaluate performance against delivered outcomes. At the same time, teams should be encouraged to experiment with new ways of working and given space to adapt without penalty during the adjustment period.
Virtual recognition — a simple appreciation channel in Slack, or a digital equivalent of an office bulletin board — can meaningfully sustain morale during an extended remote period.
“Something as simple as a virtual appreciation wall can help morale and mental health. These are still important points of social interaction even when everyone’s sitting in front of a screen.”
Charles Betz, Analyst, Forrester
6. Use Downtime to Address Technical Debt and Back-Burner Projects
Economic slowdowns typically reduce new feature demand, which can leave DevOps teams with more capacity than usual once existing backlogs are cleared. This is an opportunity, not a problem. Most DevOps teams maintain a long list of deferred improvements: infrastructure automation opportunities, security hardening work, pipeline efficiency improvements, and documentation gaps that never quite make it to the top of the sprint backlog during normal operations.
“The whole damn economy is distracted right now — nobody’s going to be innovating. Now’s the time to patch the roof, update your inventory and work on quality issues.”
Charles Betz, Analyst, Forrester
Teams that use this period productively — reducing technical debt, improving observability, refining deployment pipelines — will emerge from the disruption in a stronger engineering position than those that treat the slowdown purely as lost time.
Key Takeaways
- Standardize tooling immediately — pick one communication platform and enforce it uniformly across the whole team.
- Build shared work queues — reduce dependency on individual specialists and enable asynchronous, flexible task assignment.
- Document everything — remote teams cannot afford ambiguity in work tracking; keep Jira, Trello, or equivalent systems current.
- Invest in automated testing — integration quality risks increase with distribution; CI/CD pipelines and automated test coverage are essential safeguards.
- Lead with outcomes, not presence — measure what gets done, not when people are online.
- Address deferred work — reduced feature demand is an opportunity to pay down technical debt and improve foundational infrastructure.
The challenges the COVID-19 pandemic imposed on DevOps teams were real, but they also accelerated the adoption of practices — asynchronous workflows, shared work pools, rigorous documentation, outcome-based management — that represent genuine improvements over the status quo for many organizations.