Originally inspired by coverage on business2community.com. Published August 2020.
Remote work went from an occasional perk to a widespread operational requirement almost overnight. While many technology organizations already had some work-from-home policies in place before 2020, the COVID-19 pandemic forced a full-scale, unplanned shift that exposed gaps in tooling, process, and team communication across the entire software delivery lifecycle.
For DevOps and development teams specifically, the impact has been significant — and not entirely negative. Constraints have driven innovation in areas that were previously handled through physical proximity and informal collaboration. Below we explore the key ways remote work has reshaped DevOps practice and what the longer-term implications look like.
New Trends Emerging in DevOps Under Remote Conditions
Revisiting Mature DevOps Programs: The Push Toward DevOps 2.0
Organizations that adopted cloud-native DevOps practices several years ago are discovering that those implementations need to be revisited. Standards, tooling, and security expectations have evolved considerably since the early wave of cloud-native adoption. When remote work removed the informal, in-person coordination that many teams relied on, gaps in automation and process maturity became visible.
This has prompted a wave of what some practitioners are calling DevOps 2.0 — a deliberate re-evaluation and modernization of existing DevOps programs. For teams that went cloud-native four or five years ago, this typically involves:
- Re-platforming: Moving workloads to more current infrastructure or container orchestration approaches that better support distributed teams.
- Re-defining pipelines: Updating CI/CD configurations to reduce manual handoffs that previously depended on physical presence or informal desk-side conversations.
- Re-developing internal tooling: Replacing bespoke scripts and tribal-knowledge processes with documented, automated, reproducible workflows.
The underlying driver is straightforward: a DevOps program designed around open-plan offices, co-located teams, and impromptu whiteboard sessions needs structural changes to function well when team members are geographically distributed.
DevOps for Firmware: A Particularly Difficult Remote Work Problem
Software-only teams can move most of their workflow online with relatively little friction. Firmware development teams face a harder problem: the work involves physical hardware. Applying DevOps principles — continuous integration, automated testing, and continuous delivery — to firmware requires bridging the gap between the software pipeline and real devices.
In a co-located environment, the traditional process is straightforward: a developer flashes a new firmware build onto a device, passes it to a QA engineer who validates it, and the cycle continues with everyone in the same room. Remote work breaks that physical handoff entirely.
Several challenges emerge in a distributed firmware development context:
- A firmware developer may take a device home, but may not be the person who normally handles flashing or physical provisioning.
- QA engineers and beta testers working remotely need access to devices running the latest builds, including bug fixes and new features.
- Hardware-in-the-loop testing that previously happened on a shared bench now needs to be reproducible without physical co-location.
The practical response has been increased adoption of Over-the-Air (OTA) firmware delivery mechanisms, which allow updated firmware builds to be pushed to development and test devices remotely. When combined with a properly automated CI/CD pipeline, OTA delivery enables QA engineers and beta testers to receive new builds without requiring anyone to physically touch the device. This is not a new technology, but remote work accelerated its adoption as a first-class part of the firmware development workflow rather than a production-only concern.
Collaboration and Communication: What Remote Work Changed
One of the less-discussed effects of full-time remote work on DevOps teams is the change in communication overhead. In an office, many coordination tasks happen informally — a quick question across a desk, a two-minute whiteboard sketch, a hallway conversation that prevents a misunderstanding from becoming an incident. Remotely, every one of those interactions requires a deliberate action: opening a chat message, scheduling a video call, or writing up a comment in a ticket.
This has two observable effects on DevOps teams:
- Increased reliance on documentation and asynchronous communication: Teams that previously operated on shared context and informal knowledge transfer have had to invest in wikis, runbooks, architecture decision records (ADRs), and more detailed pull request descriptions.
- Meeting fatigue: The volume of scheduled video calls tends to increase to compensate for lost informal interaction, creating cognitive load and reducing deep-focus time for engineering work.
The net result is that many DevOps teams have improved their written documentation and process formalization as a direct consequence of remote work — improvements that will benefit future team members regardless of where they sit.
Will Remote Work Become Permanent for DevOps Teams?
The widespread shift to remote work has demonstrated that most software development and DevOps work can be performed productively outside of a traditional office. Video conferencing, cloud-based development environments, shared CI/CD platforms, and chat tools have made distributed engineering teams viable at scale.
However, the evidence also suggests that most engineers do not want a fully remote arrangement indefinitely. Common reasons cited for wanting at least some in-person time include:
- The social dimension of working alongside colleagues.
- Faster resolution of complex, ambiguous problems through in-person whiteboarding and discussion.
- Clearer boundaries between work and home life when commuting to a separate location.
- Reduced video call fatigue by allowing quick, informal in-person exchanges.
The most likely long-term outcome for many DevOps and software engineering teams is a hybrid model: a defined number of in-office days per week combined with the flexibility to work remotely the remainder of the time. This approach attempts to capture the productivity and autonomy benefits of remote work while preserving the collaboration and social advantages of physical presence.
Lasting Process Improvements Driven by Remote Work
Regardless of where teams ultimately land on the remote versus in-office spectrum, several process improvements triggered by the forced remote work period are likely to persist:
- Greater automation of manual handoffs: Steps in deployment pipelines that relied on physical presence or informal coordination have been automated, reducing toil and increasing reliability.
- Improved asynchronous communication practices: Better written documentation, clearer ticket descriptions, and more structured code review processes benefit distributed and co-located teams alike.
- Expanded OTA and remote provisioning capabilities: Firmware and embedded teams that built remote delivery infrastructure out of necessity now have capabilities that improve their overall development velocity.
- More inclusive meeting practices: Teams accustomed to running effective remote meetings tend to run better hybrid meetings, reducing the disadvantage for participants who dial in from other locations.
Key Takeaways for DevOps Teams
The shift to remote work was disruptive, but it served as a forcing function for DevOps maturity in many organizations. Teams that invested in automation, documentation, and remote-friendly tooling came through the transition in better shape than those that relied heavily on co-location and informal process.
- Audit your CI/CD pipeline for steps that still depend on manual, location-dependent actions and automate them.
- If your cloud-native DevOps implementation is several years old, treat it as a candidate for modernization — tooling and best practices have moved on.
- For firmware teams, evaluate OTA delivery infrastructure as a standard part of your development pipeline, not just a production deployment concern.
- Invest in written process documentation now; it pays dividends whether your team is remote, hybrid, or fully co-located.
The future of work for engineering teams remains in flux, but the teams best positioned to adapt are those that treat process resilience and automation as core engineering values — not optional extras.