The End of the Classroom-Only Training Era

Learning and development (L&D) has always sat at the heart of organisational growth, but the format it takes has changed dramatically. Group classroom sessions and once-a-year induction programmes are no longer sufficient for a workforce that is distributed, always connected, and operating in rapidly changing technical environments.

The digital revolution has not only changed the tools used to train employees — it has reshaped expectations around how, when, and where learning should happen. The challenge for organisations is keeping L&D aligned with those evolving expectations, especially for remote teams.

Cloud computing has emerged as a core enabler of this shift. As David White, head of project management at Best Response Media, puts it: “Techniques and methods are constantly evolving, so you need to be constantly learning or you will quickly fall behind.”

Creating a Learning Environment That Supports All Employees

One often-overlooked benefit of cloud-based L&D infrastructure is its role in talent retention and workforce equity. Ian Cook, vice president for people solutions at Visier, points to data from his firm’s Gender Equity report, which identified what he calls a “manager divide” — a growing under-representation of women aged 32 and above in management roles.

“The manager divide is closely tied to the childcare years,” says Cook, “when women experience increased demands from their home life and may even exit the workforce as a result.”

Offering flexible, location-independent training is one practical response. Victoria Usher, founder and CEO of communications consultancy GingerMay, has built her organisation’s working practices around cloud tools including Google Drive, Dropbox, and Slack. Her senior leadership team is 85 per cent female and 85 per cent working parents. “We offer our 50-plus employees very flexible working opportunities and career progression,” she says.

Cloud-based platforms make it structurally easier to deliver training that is not tied to a physical office, removing a barrier that disproportionately affects employees with caregiving responsibilities or those working across different time zones.

Continuous Feedback Replaces the Annual Review Cycle

Perhaps the most significant cultural change enabled by cloud-based L&D is the shift from periodic, formal reviews to continuous feedback loops. When training modules, performance notes, and check-in records all live in shared cloud environments, managers and employees can maintain an ongoing development dialogue rather than waiting for a six-month or annual review.

“Constant contact on feedback, training and performance makes employees feel they are more engaged with the business, compared to six-month or yearly reviews,” says White. This is especially valuable for remote teams, where cloud platforms allow managers to verify that distributed team members have completed the same L&D modules before taking on shared projects.

“We’re all used to consuming infinite apps, content and games, and we’re looking for this same experience at work. This conversational review cycle can help employees learn and grow more quickly, and keep them motivated.”

Ian Cook, VP People Solutions, Visier

The Limits of Digital: Personalisation and Human Judgment Still Matter

Despite the clear advantages, cloud-based training is not a substitute for structured managerial engagement. Digitising delivery does not automatically accelerate the pace at which people acquire and internalise new skills.

“Although our flow of feedback has grown faster, the human ability to grow and master skills hasn’t,” notes Cook. Organisations that simply move existing training content to the cloud without rethinking the underlying process can end up with employees who feel disconnected — submitting work or completing modules with no sense that anything meaningful is being heard or acted upon.

White agrees: “This responsibility comes down to the manager. There is nothing worse than giving feedback that you don’t think is going to be listened to.” Cloud tools amplify good management practices; they cannot replace them. Managers must actively build training plans, listen to feedback, and make employees feel their development is genuinely valued.

Transformative Business Outcomes: What Practitioners Report

For organisations that have integrated cloud-based L&D thoughtfully, the reported business impact is significant. At GingerMay, Usher says that combining multiple cloud solutions has enabled more attentive people management: over two-thirds of staff (68 per cent) work part time, on flexi-hours, or from home — reducing office costs while improving employee satisfaction.

White describes the shift as transformational for Best Response Media: “These technologies have single-handedly had the biggest impact on our workforce and performance. We have been able to increase efficiencies and reduce costs at the same time.”

Cook highlights training analytics as the next frontier. Having lots of content available in the cloud is not the same as having effective training. Analysing completion rates, assessment scores, and downstream performance metrics allows organisations to identify which programmes genuinely improve capability — and to retire those that do not. The same data can surface systemic issues: anomalies in promotion rates, performance review scores, or resignation patterns that point to problems in organisational culture rather than individual performance.

Three Practitioners on Cloud-Based Employee Development

1. James McAulay, Founder of Encore (Musician Bookings Platform)

Encore built its onboarding programme — the “Encore Academy” — entirely in the cloud. New hires work through a master spreadsheet that links to reading materials, checklists, and milestones they can mark as completed during their first weeks. Because everything lives in shared cloud storage, any team member can update the master document as new content is created, keeping onboarding materials continuously current without a formal review process.

Every employee has a fortnightly one-to-one with their manager, with notes kept in Google Sheets. This gives managers a persistent, searchable record of recurring issues and positive achievements — making it far easier to spot patterns over time and to recognise progress between formal reviews.

2. Nigel Davies, Founder and CEO of Claromentis (Intranet Software)

At Claromentis, a distributed team that largely works from home, the digital workplace is the primary environment for everything from product development to HR. E-learning was a natural fit — but Davies found that making budget available was not enough on its own.

Each employee receives an annual training budget (Davies cites £1,500 per person), but when uptake was lower than expected, the company made learning a cultural priority rather than just a financial benefit. Employees are now encouraged to attend training in small groups to preserve the social dimension of learning, and to share highlights with colleagues afterwards. The learning management system (LMS) is now prominently positioned in the digital workplace, visible as soon as employees log in each morning.

3. Sean Marshall, VP Worldwide Sales at Klaviyo (Ecommerce Marketing Platform)

Klaviyo’s sales team uses the Chorus.ai conversation intelligence platform to record, transcribe, and analyse client calls. Recorded calls become group training material: in monthly team sessions, managers play back selected calls, pause at critical moments, and ask structured questions — “How do you think this person handled that objection?” or “What would you have done differently at the close?”

The approach replaces subjective retelling with an objective, shared record of what actually happened. It also surfaces real customer objections and responses to messaging, feeding directly into sales strategy. Marshall reports quarter-by-quarter improvements in win rate as a result of this programme.

Key Takeaways for L&D and DevOps Teams

• Cloud platforms lower the barrier to flexible, location-independent training — critical for distributed engineering teams across time zones.
• Continuous feedback loops outperform annual reviews in keeping employees engaged and identifying skill gaps early.
• Analytics matter as much as content delivery. Knowing that a module was completed is not the same as knowing it improved performance. Build measurement in from the start.
• Culture determines adoption. Providing cloud tools and training budgets is a starting point, not an endpoint. Active managerial engagement and visible cultural commitment are required.
• Cloud data can surface systemic equity issues — such as demographic gaps in promotion or retention — that traditional annual reporting cycles miss entirely.

We often talk about how DevOps and automation can help speed up release cycles and get the latest code changes and updates out in a quick, stable and efficient way. This DevOps mindset keeps developers and operations teams in sync and ensures that the software they produce is always on the cutting edge. But is this all too much?

With a continual focus on trimming the release cycle time and automating this process, do DevOps organizations put enough focus on the application itself? The DevOps mindset has fostered a more aggressive schedule of change. Is it always for the right reason? While this level of agility and change is often shown as a positive aspect for business, any change — large or small — affects customers.

When you make a change to your application, the customer may need to internally test and validate the app before it’s deployed into production. In fact, that is normally the case with production-level software. If the application in question is updated monthly or quarterly, that can be a serious drain on your customers’ resources for these internal processes. This is a piece of the puzzle can get missed in the DevOps mindset.

The Hidden Cost of High-Velocity Releases

Every time your team ships a change, your customers bear a cost. Production software doesn’t exist in a vacuum. Enterprises that depend on your application typically have their own change-management processes: internal regression testing, compliance reviews, staged rollouts, and sign-off procedures. A change that takes your team an afternoon to ship may require days of validation effort on the customer’s side.

If your team releases updates monthly or even weekly, that overhead compounds quickly. Customers may struggle to keep up, skip validations to save time, or grow frustrated with the constant churn. None of those outcomes serve the business goals DevOps is supposed to advance.

The key question every DevOps team should ask before shipping is not can we release this? but should we release this now, and are our customers ready for it?

Orient Your DevOps Mindset Around the User

High-velocity CI/CD pipelines are engineered to reduce friction for the development and operations teams. That’s genuinely valuable. But those pipelines accelerate the release process, not the adoption process. Automation helps your team get code out the door faster; it doesn’t automatically help your customers absorb, test, and deploy that code in their own environments.

Change for the sake of change imposes a real tax on customers. A stream of small, low-impact updates may keep developers busy and dashboards green, but if those updates don’t meaningfully improve the user experience, the net effect is churn without value. Frequent, minor changes accumulate into upgrade fatigue.

This is not an argument for returning to monolithic, infrequent releases. Waterfall-style delivery cycles have well-documented drawbacks: large batches increase risk, delays reduce responsiveness, and big-bang deployments are harder to roll back. The goal is deliberate cadence, not slowness.

Define and Publish a Predictable Release Cadence

One of the clearest signals that a DevOps organization has lost its customer focus is the absence of a defined release schedule. Shipping whenever a feature is ready — or whenever the pipeline goes green — makes it impossible for customers to plan. If your release cadence is unpredictable or undocumented, that is a serious process gap.

A well-managed release cadence should be:

• Predictable: Customers should know in advance when to expect updates so they can schedule their own validation work.
• Documented: Release notes, changelogs, and migration guides give customers the information they need to assess impact.
• Risk-categorized: Distinguish between patch-level bug fixes, minor feature additions, and breaking changes. Not every update warrants the same customer response.
• Communicated early: Advance notice — especially for changes that affect APIs, data schemas, or integrations — lets customers prepare rather than react.

Communicate Software Changes Clearly

Production systems fail in unexpected ways. The assumption that a minor change is safe has preceded many significant outages in the software industry. A small configuration tweak, a dependency version bump, or a subtle behavior change in a shared library can cascade into a major incident in a complex production environment. This doesn’t mean teams should be paralyzed by caution, but it does mean every change deserves deliberate communication.

Clear communication requires effort and time. It can’t happen effectively when changes are arriving faster than your team can document and explain them. If your release velocity prevents you from writing meaningful release notes or notifying customers of upcoming changes, that’s a signal to slow down and recalibrate.

Practical communication practices for DevOps teams include:

• Maintaining a public or customer-facing changelog with each release.
• Sending advance notifications for changes that affect integrations or workflows.
• Providing a deprecation timeline for features or APIs being retired.
• Offering a way for customers to opt into early releases or preview environments.
• Keeping a known-issues register that is updated alongside each release.

Finding the Right Balance

DevOps is ultimately about delivering value to users reliably and sustainably. Speed is an enabler of that goal, not the goal itself. A team that releases continuously but leaves customers overwhelmed, under-informed, or perpetually fire-fighting has optimized the wrong metric.

The right balance depends on your product, your customers, and the nature of the changes you’re shipping. Some SaaS products can sustain daily deployments because they control the end-user environment entirely. Others — particularly those integrated deeply into enterprise workflows — may need a more measured cadence with stronger communication support.

The discipline is in asking the question honestly: are we releasing at this pace because it genuinely serves our users, or because it’s what our pipeline makes easy? A mature DevOps mindset holds both technical efficiency and customer impact in view at the same time.

Slow down when the situation calls for it. Communicate proactively. Measure success by outcomes for users, not just throughput from the pipeline. That’s what a customer-centered DevOps practice looks like.

Why “Mindset” Is the Wrong Frame

Telling a team to “adopt a DevOps mindset” is a bit like telling someone to “think differently.” It sounds meaningful, but it gives people nothing concrete to work with. Most engineering leaders are not particularly good at reading the internal mental states of their team members — and that’s fine, because they don’t need to be.

What leaders can do is observe what people actually do every day: how they communicate, how they hand off work, how they respond to incidents, whether they write tests, whether they collaborate with downstream teams before a deployment. These are behaviors. They are observable, discussable, and changeable.

The practical argument is straightforward: DevOps is not a mindset — it is a collection of behaviors and habits that, when practiced consistently by enough people in an organization, produce a recognizable culture. Culture, in this view, is simply what people do habitually. If you want a DevOps culture, you need to change what people do, not how they think.

Culture Is Group Habit

This reframing has a powerful implication: you don’t need organizational consensus on abstract values to make progress. You don’t need everyone to agree on what DevOps “means.” You need enough people to consistently exhibit the right behaviors. Over time, those behaviors become norms. Norms become culture.

This is not a new insight in organizational psychology — habits and routines are widely recognized as the foundation of both individual and group behavior — but it is underused in DevOps transformation discussions. Too many transformation programs begin with workshops about values and end without changing any daily practices.

A behavior-first approach inverts that. It asks: What do we need people to do differently, starting tomorrow? Once the right behaviors are in place and producing results, the corresponding values and culture tend to follow naturally.

Finding the Right Behaviors Through Self-Discovery

The behaviors that matter most are context-specific. Every organization has different people, goals, technology constraints, and delivery pressures. There is no universal list of “DevOps behaviors” that applies equally everywhere. The starting point is understanding where your specific organization is struggling.

A structured self-assessment helps. Ask these diagnostic questions across your teams:

• Where are the bottlenecks in your delivery pipeline?
• What are customers or end users complaining about most frequently?
• What problems does your team encounter repeatedly that could be prevented?
• What stops your team from delivering high-quality service reliably?
• Where are the longest delays between hand-offs — between dev and QA, QA and ops, ops and release?
• What information does one team routinely lack that another team holds?

The answers will point directly at behavioral gaps. If hand-off delays are the biggest problem, the behavior change you need might be: start measuring and reviewing hand-off wait times in every sprint retrospective. That is specific, actionable, and observable. It is far more useful than telling the team to “think like a DevOps organization.”

Behaviors Are Observable and Coachable

One of the most practical advantages of focusing on behaviors is that managers can actually work with them. You can observe whether someone is following the team’s agreed incident response procedure. You can give direct, specific feedback: “I noticed you deployed without running the integration test suite — here’s why that matters and what I’d like you to do differently next time.”

You cannot give equivalent feedback about mindset. “Your mindset isn’t DevOps enough” is both unhelpful and demoralizing. “You escalated this incident to the ops team without first checking the runbook” is something a person can act on immediately.

This also means that behavioral progress is measurable. You can track whether on-call response times are improving, whether post-mortems are being completed, whether deployment frequency is increasing, or whether cross-team communication is happening earlier in the development cycle. These metrics give you signal about whether your behavior-change efforts are working.

Practical Steps for a Behavior-First DevOps Transformation

1. Run a delivery retrospective. Gather data on where delays, defects, and friction actually occur. Use the diagnostic questions above as a starting framework.
2. Name specific behaviors you want to see more of. “We will hold a blameless post-mortem within 48 hours of every production incident” is a behavior. Write them down explicitly.
3. Name specific behaviors you want to stop. “We will stop deploying on Fridays without an on-call engineer available” is a behavior. Be equally explicit about what you’re stopping.
4. Make the new behaviors as easy as possible to perform. Remove friction. Create templates, checklists, and automation that make the desired behavior the path of least resistance.
5. Measure outcomes, not attitudes. Track deployment frequency, change failure rate, mean time to recovery, and lead time for changes — not survey scores about whether people “feel” like a DevOps team.
6. Give regular, specific behavioral feedback. In one-on-ones and retrospectives, reference observed behaviors explicitly. Celebrate when people exhibit the right ones. Redirect when they don’t.

The Bottom Line

The DevOps mindset is a useful shorthand for communicating broad intent, but it is a poor tool for driving actual organizational change. Behaviors and habits are concrete, observable, teachable, and measurable. If you want your organization to operate differently, focus relentlessly on what people do every day — not on how they think. Get the behaviors right consistently, and the culture will follow.

Stories about various industries and companies going digital cram the headlines. For example, airlines are readying for the digital shift to tackle increasing air traffic; meanwhile, Marks & Spencer has hired a principal technology partner to ‘drive digital-first.’ At the centre of all this is the need to boost productivity.

Many companies still use inefficient manual processes instead of automation, however. Building apps to eliminate paper and streamline operations provides the obvious advantage of saving time, but it can also uncover new insights for continuous improvement and competitive advantage. But after the apps are developed, the process of moving them to operations can encounter a bottleneck in the form of another set of inefficient practices. That’s where DevOps enters the picture.

Rather than being a skill, a position you can hire in your IT department, or a specific tool you can purchase, DevOps is a philosophy. The goals are to increase the value software brings to customers and to enable organisations to react faster to change in the business.

Here are nine steps for developing a DevOps mindset in your organisation:

1.   Define and validate the expected impact of development on IT before you start.
2.   Automate infrastructure provisioning to boost the speed of your development and testing.
3.   Mimic production as closely as possible in all non-production environments.
4.   Anticipate failure by testing scenarios in a self-healing infrastructure.
5.   Continuously integrate your code during app development.
6.   Register your configurations in a shared central repository and track every application change.
7.   Orchestrate deployment with automation that defines all steps of the process for each application.
8.   Measure app health and performance and the impact of your apps on your business and customers once they reach production.
9.   Make sure feedback you collect is shared with all stakeholders.

Let’s take a look at these in closer detail and see how they build on each other to accelerate transformation. Impact analysis is a handy tool to get you started; it validates if a deployment can be completed without affecting other applications running in the target environment. This process determines global dependencies and makes sure that nothing breaks when the application goes live.

Then, infrastructure automation brings agility to both development and operations. By describing your infrastructure as a set of scripts, you can replicate environments with significantly fewer errors. Self-healing capabilities automatically correct problems or inform developers of any corrections they must handle. It automatically validates changes as you go.

In the testing phase, depending on complexity and how critical each project is, the delivery team should apply different types of testing. We recommend unit testing or using behaviour-driven development and test-driven development practices.

Then, of course, you will want to measure your performance and the impact on customers and share findings with stakeholders. If all has gone well, the results can be remarkable. For example,BlueZest, a technology-based specialised property investment funder, released its digital mortgage underwriting application in October 2017. Now, BlueZest is citing speeds as fast as 15 minutes for initial loan quotes and 30 minutes for confirmed offers.

Ultimately, DevOps is all about bridging the gap between development and operations. Low-code development platforms offer capabilities that enable these nine steps so your organisation can cross that chasm.

Examples include a unified application lifecycle management console, embedded version control and build server with continuous integration, built-in monitoring and analytics, high-availability configuration, and centralised configuration management.

Combining the speed of low-code visual development with the agility of DevOps can greatly accelerate digital transformation, thereby enabling organisations to reap the efficiency, productivity, and competitive benefits quickly.

Culture shifts such as DevOps take a lot of hard work, because you need every single person to buy into the new culture. The most successful adoptions we’ve seen of the DevOps mindset start with an organic, bottoms-up approach.

Where to start with DevOps culture

Start with a concrete, immediate problem. For example, at many cloud software companies, engineers are paged when an error occurs. Since no one enjoys being paged, the engineers who are frequently paged are motivated to figure out ways to get a more restful night’s sleep. At one organization we worked with, an engineer realized that pages (errors) correlated with new releases of the application. So she decided to introduce “canary deployments:” running a new version with a small percentage of real traffic side-by-side with the old version and gradually increasing traffic over time. Other developers in the organization saw the success of this approach and adopted it for their own services.

At this company, a developer – in search of more sleep – introduced an operational best practice that an organization then adopted.

We’ve seen this pattern repeatedly. At its core, it comes down to recognizing two facts:

• For IT pros, the most credible recommendation for a better approach comes from their peers. Managers, vendors, and technical journals are all good sources of information, but a peer recommendation carries special weight.
• Developers are biased to adopting solutions that make their immediate lives easier.

Based on what we’ve observed in DevOps environments (including within our own company, Datawire), consider these steps to nurture a DevOps culture:

1. Start small and solve specific, concrete problems

2. Support the problem-solving engineers

It’s essential to let the engineer who is experiencing the problem personally try to solve it. If that engineer doesn’t have the know-how or skills to directly solve the problem, give him or her the right resources (other people, training, time) to tackle the problem. The engineer who is closest to the problem will be able to validate that the solution actually works.

3. Create forums to share successes

Internal DevOps Days, lunch-and-learns, regular engineering meetings, and blog posts are all good ways to share successes and create awareness.

4. Make time to help spread the solution

The engineer who built the canary system wouldn’t have been able to drive adoption if she hadn’t been given time to document her approach – and coach other teams through it.

5. Encourage engineers to engage outside your organization

Valuable outside interaction happens through conference talks, speaking engagements, or public engineering blogs (e.g., the Yelp engineering blogor the Lyft engineering blog). External validation and recognition of an engineer’s work helps with internal advocacy (wow, all these other engineers love this person’s work!). It also gives the engineer a different type of personal satisfaction.

Cultural shifts are not successful unless they’re internalized by the entire team. So, think carefully about how you nurture grassroots efforts when adopting DevOps in your organization.