1. Engineers love spinning things up.
2. Finance loves asking why the bill looks like a phone number.

That’s exactly why I lean heavily on FinOps. For me, it’s not just a framework — it’s the reality check that keeps cloud engineering both technically smart and financially sane. The lifecycle is simple: plan smart, track everything, optimise constantly, stay visible, and keep everyone accountable.

Start With Reality

Before anything exciting goes live, I sit down with finance, leadership, and engineers to figure out goals and realistic spending. I look at historical usage, upcoming workloads, and growth patterns to forecast costs that actually make sense. Budgets aren’t there to block innovation — they set guardrails so teams can move fast without accidentally lighting the budget on fire. When expectations are clear early, fewer surprises show up later.

Know Who’s Using What

Once budgets exist, visibility becomes everything. That’s where tagging comes in. I push teams to tag resources by project, environment, and ownership from day one. Yip, people complain at first — until costs spike and we instantly know where the money went. Good tagging turns “cloud is expensive” into specific insights like “that test environment hasn’t been touched in weeks.” Suddenly optimisation becomes straightforward instead of detective work.

Stop Paying for Things Nobody Uses

There’s always waste hiding somewhere: oversized VMs, idle resources, forgotten demos, or storage that outlived its purpose. I spend a lot of time right-sizing workloads, implementing auto-scaling, and removing anything that doesn’t deliver real value. Optimisation isn’t about cutting corners; it’s about aligning spend with actual business needs. If something helps performance or growth, great — it stays. If not, it’s probably getting turned off.

No More Billing Surprises

After optimisation, continuous visibility keeps everything under control. I rely on dashboards, alerts, and live monitoring so teams see usage changes immediately instead of discovering problems at the end of each month. When engineers can see the cost impact of their actions in real time, they naturally become more intentional. Small adjustments happen quickly, and massive billing surprises become rare.

Make the Numbers Meaningful

Finally, I turn cost data into clear reports that everyone understands. Regular reviews help engineering, finance, and leadership stay aligned on spending and priorities. The goal isn’t blame — it’s awareness. When teams understand the financial impact of their technical decisions, they start designing smarter by default. Reporting closes the loop and feeds directly back into the next round of planning.

Conclusion

For me, FinOps is a continuous rhythm: budget, tag, optimise, monitor, report — repeat. When done well, cloud spending becomes intentional rather than reactive, and cost management becomes part of good engineering instead of a last-minute panic. And honestly, fewer awkward meetings about mysterious cloud bills are a pretty great bonus.

Right-Sizing Resources

One of the first things I look at during any cost review is resource utilisation. More often than not, I find instances that were provisioned for peak usage but rarely operate at that level. By analysing usage metrics, I make it a routine to review usage patterns and compare them to what’s actually provisioned. If workloads are consistently underutilising resources, I adjust. Optimisation is small, continuous corrections that prevent waste from compounding.

Automating Resource Scaling

Manual scaling almost always leads to inefficiency. Either systems are overbuilt to “be safe,” or they struggle during peak periods. Aligning infrastructure with real-time demand is one of the most effective ways to control costs without sacrificing performance. When systems automatically adjust to traffic patterns, they stay lean during quiet periods and responsive during spikes. That dynamic balance is where optimisation really starts to feel natural.

Optimise Storage Costs

Snapshots, backups, test environments, and unused volumes accumulate over time and take up your storage quickly. If no one is actively reviewing them, they just sit there generating cost. Now, I treat storage reviews as a recurring discipline. I separate what truly needs high-performance access from what can live in cheaper tiers. The orphaned resources are cleaned up regularly to prevent unnecessary cost drift.

Implement Cost Governance Policies

Most people underestimate the importance of governance policies, where I’ve learned that governance works best when it guides behaviour rather than ignores it. Clear ownership, consistent tagging, and shared cost visibility create accountability without slowing teams down. When people understand the financial impact of their decisions, optimisation becomes proactive rather than enforced.

Use Flexibility Strategically

Not every workload needs guaranteed uptime or premium performance. I’ve been able to significantly reduce costs by identifying which processes can tolerate interruption or variability. Batch jobs, test environments, and non-critical tasks often don’t need the same level of stability as production systems. When I categorise workloads properly, I can apply the right cost strategy to each one instead of treating everything equally.

Conclusion

By applying these strategies, I’ve seen how cloud cost optimisation can become a natural extension of efficient cloud resource management. It’s not about cutting corners—it’s about making sure you’re getting the most value out of every dollar you spend. Whether it’s through right-sizing, automating scaling, or taking advantage of cost-saving plans, the goal is to maintain the flexibility and power of the cloud without letting costs spiral out of control. With the right approach, optimising costs becomes an integral part of running an effective cloud operation.

Why Cost Visibility Matters

In traditional environments, costs were predictable. Infrastructure was purchased upfront, and budgets were relatively stable. In the cloud, that predictability disappears. Usage fluctuates daily, sometimes hourly. Once I implemented proper cost visibility, decision-making changed completely. Teams could see the impact of their deployments, and conversations shifted from reacting to bills at month-end to managing spend proactively. Visibility became the foundation of everything else in our FinOps practice.

The Tools I Rely On

The first practical step I took was making sure we had the right tooling in place. Native tools like AWS Cost Explorer, Azure Cost Management, and Google Cloud’s billing dashboards gave us a solid starting point. As our environment grew more complex, tools like CloudHealth and Cloudability helped with my multi-cloud solutions to break spend down by team, product, or environment, making cost data actionable instead of just informational. When people can see exactly what they’re responsible for, accountability follows naturally.

Why Tagging Changed Everything

I worked with engineering teams to standardise tags across projects, environments, and cost centres. In some cases, we used tools like Cloud Custodian to help enforce tagging policies automatically. Once resources were consistently labelled, we could allocate costs accurately and eliminate the guesswork during reporting. That clarity reduced friction between teams and made financial discussions far more productive.

Digging Into Spending Patterns

Visibility alone isn’t enough. Once I had clean data, I started analysing trends regularly. I looked at which services were growing fastest, which workloads had unpredictable spikes, and where resources were underutilised. Instead of being surprised by the next invoice, we could anticipate it. That shift from reactive to predictive cost management was a major turning point.

Sharing Visibility Across Teams

Cost visibility shouldn’t live in a finance spreadsheet. It needs to be accessible to engineers, product owners, and leadership. It shifts the mindset from “Finance handles costs” to “We all have a role in managing cloud efficiency.” Collaboration between engineers, finance, and leadership is crucial in keeping cloud spend aligned with business objectives, and visibility is the glue that holds it all together.

Conclusion

By focusing on cost visibility, tracking real-time usage, organising resources effectively, and sharing insights across teams, you can transform how your organisation manages cloud spending. Visibility isn’t just about knowing what you’re spending—it’s about empowering teams to take ownership of their cloud costs, optimise resources, and drive better financial outcomes. In my experience, making cloud spend transparent and trackable is one of the most important steps you can take in your FinOps journey.

The FinOps Lead

Every strong FinOps setup I’ve worked with had someone clearly driving it. The FinOps Lead acts as the connector between engineering, finance, and leadership. They don’t just look at numbers; they turn cost data into action. They run cost reviews, align spending with business priorities, introduce guardrails, and make sure the right tools and processes are in place. Most importantly, they keep everyone accountable without turning FinOps into a policing function. It’s about enablement, not restriction.

Cloud Engineers and DevOps Practitioners

Engineers play a bigger role in cost control than they often realise. In the teams I’ve worked with, engineers take ownership of tagging, right-sizing workloads, automating shutdowns, and designing systems that balance performance with cost efficiency. When engineers understand cost implications, optimisation becomes part of everyday decision-making rather than a reactive exercise.

Finance Teams

Finance can’t sit on the sidelines. I’ve seen the biggest improvements happen when finance teams actively engage with engineering instead of just reviewing invoices at the end of the month. They help interpret billing data, build forecasts, set budgets, and translate technical consumption into business language leadership understands. When finance and engineering speak the same language, decisions become faster and far more strategic.

Product Owners and Project Managers

These roles often become the bridge between business value and cloud spend. In practice, I’ve seen strong product leaders challenge teams with the right questions: Are we getting value from this workload? Is this feature worth the cost to run it? They ensure initiatives stay aligned with budgets while still delivering impact. FinOps becomes much smoother when cost awareness is built into project planning rather than treated as an afterthought.

Executives and Leadership

None of this works without leadership backing it. The most successful FinOps transformations I’ve been part of had executive sponsorship from day one. Leadership sets expectations around accountability and reinforces that cost efficiency is not about limiting innovation, but about funding it sustainably. When that message comes from the top, teams take it seriously.

Conclusion

FinOps stops being “someone else’s problem” and becomes embedded in how the organisation operates. It’s not about cutting for the sake of cutting. It’s about building a culture where performance, innovation, and financial responsibility exist side by side. When everyone understands their role and works collaboratively, FinOps becomes less of a framework and more of a natural way of working. And that’s when you start seeing real, measurable impact.

Cost Management Dashboards

The first and most important type of tool for any FinOps initiative is a robust cost management dashboard. These tools provide real-time visibility into cloud spending across your organisation. AWS Cost Explorer, Azure Cost Management + Billing, and Google Cloud Cost Management tools are great for native solutions. But if you’re working in a multi-cloud environment or need more detailed breakdowns, third-party platforms like Tanzu CloudHealth or Apptio Cloudability are lifesavers.

Automation for Optimisation

One of the biggest challenges with cloud usage is managing unused or underused resources. This is where automation tools come in handy. Platforms like Flexera or ParkMyCloud help identify idle resources, automate shutdowns, and right‑size instances dynamically, meaning you spend less time babysitting the cloud and more time iterating.

Tagging and Resource Allocation Tools

To effectively track cloud costs, proper resource tagging is essential. Tools like Cloud Custodian or CloudCheckr allow you to create policies that enforce consistent tagging across your environment. Without proper tagging, visibility into cloud spend becomes difficult, and your FinOps initiative can lose focus.

Budgeting and Forecasting Tools

Beyond tracking current usage, FinOps is about planning ahead. Tools like Apptio Cloudability and Harness provide robust budgeting and forecasting capabilities. These tools let you predict future cloud costs based on historical usage patterns and adjust your budgets accordingly. This proactive approach helps ensure that teams don’t go over budget and can adjust their strategies when necessary.

Collaboration and Reporting Platforms

FinOps is all about creating a shared responsibility between engineering, finance, and leadership. Collaboration tools like Slack integrations with cost management platforms, or reporting tools like Tableau, ensure that cloud cost data is easily accessible and actionable for all stakeholders. This helps teams stay aligned on financial and technical goals.

Conclusion

By leveraging these FinOps tools, I’ve seen firsthand how much easier it becomes to manage cloud spending efficiently. These technologies provide the insights, automation, and collaboration needed to make informed decisions and optimise usage. If you’re serious about FinOps, having the right tools in place is non-negotiable. They help you scale, control costs, and make cloud operations as efficient as possible, allowing you to focus on innovation while keeping your budget in check.

Start with Alignment

The first thing I did was bring together engineers, finance teams, and leadership to make sure we were all on the same page. I worked with them to define shared objectives, so everyone understood not just what we were doing in the cloud, but why. By creating this shared understanding, I set the foundation for everything else in the framework.

Create Visibility and Accountability

Next, I focused on visibility. I implemented dashboards and reporting tools that gave real-time insights into our cloud usage and spending. I made sure every team member could see how their decisions impacted costs. But visibility alone wasn’t enough—I also made accountability clear. I worked with engineers to take ownership of the resources they used and collaborated with finance to make sure spending was understood across the board. Shifting the mindset in this way was critical to making FinOps work for us.

Define Metrics and KPIs

Once we had visibility and alignment, I defined measurable KPIs that connected cost to value. I tracked things like cost per workload, cost per user, and efficiency of storage and compute. These metrics let me monitor how effectively we were using our cloud resources and identify areas for improvement. Having these KPIs in place meant I could make informed decisions and adjust our strategy in real time.

Implement Continuous Optimisation

Finally, I made FinOps an ongoing practice rather than a one-time setup. I regularly reviewed our usage, identified waste, and optimised resources. I automated scaling wherever possible and shut down unused instances. By continuously monitoring and refining our cloud environment, I ensured that our infrastructure was not only efficient but also aligned with our business priorities.

Conclusion

Setting up this FinOps framework transformed the way my teams operate in the cloud. It’s not just about saving money—it’s about making every dollar work harder, enabling innovation while keeping us efficient and accountable. When teams are aligned, informed, and committed to continuous improvement, FinOps becomes a powerful tool for both innovation and financial efficiency.

FinOps represents a shift in mindset, one where we move beyond the traditional silos of IT and finance and start thinking holistically about cloud usage. Cloud platforms have given us incredible flexibility and speed, but that comes with complexity—especially when it comes to costs. What makes FinOps so valuable is that it ensures we’re making the best use of the cloud while keeping our spending in check.

Here’s why this mindset shift is essential:

Cloud Costs Are Not Fixed

One of the biggest challenges in the cloud is that costs are dynamic. You don’t just buy servers or storage and call it a day; your cloud spend can change daily based on usage, scaling, or even poorly optimised resources. Without a FinOps approach, it’s easy to lose track of spending and waste money on unused or underused services. Shifting to a FinOps mindset helps you stay proactive about cloud costs, making real-time adjustments to optimise efficiency.

Accountability Across Teams

In traditional on-prem setups, finance and IT had distinct roles. But in the cloud, everything is interconnected. Engineers make decisions that directly impact costs, while finance teams are trying to understand cloud bills that are often cryptic and hard to parse. FinOps changes that dynamic by creating shared responsibility. It brings engineers, finance, and leadership to the table, ensuring that everyone is accountable for cloud efficiency. By working together, we can all make smarter, more informed decisions.

Balancing Innovation with Cost Management

A big misconception about FinOps is that it’s just about cutting costs. In reality, FinOps is about aligning cloud usage with business goals. We need the freedom to innovate, but that doesn’t mean we can be reckless with cloud spending. With a FinOps approach, we can strike that balance. It’s about maximising the value of every dollar spent in the cloud, whether it’s optimising infrastructure or scaling smartly during peak demand.

Conclusion

By adopting FinOps, we empower our teams to innovate without waste. It’s not just about saving money—it’s about creating a culture of efficiency and collaboration. In today’s cloud-driven world, mastering FinOps is essential for staying competitive and maintaining agility. I’ve seen the difference FinOps can make, and it all starts with a shift in mindset. When teams understand that cloud efficiency is everyone’s responsibility, we unlock the full potential of the cloud without unnecessary costs. FinOps is the key to cloud success.

First off, FinOps stands for Financial Operations, and it’s all about bringing financial accountability into the cloud. Traditionally, finance and IT teams operated separately, but with cloud services, we need to work together more closely. FinOps helps bridge that gap by making sure engineers, finance teams, and leadership all collaborate to make smart, cost-efficient decisions.

Here’s how I approach it:

Create Visibility

The first thing I always do is ensure we have complete visibility into our cloud usage and spending. Without that, it’s impossible to know where our money is going. We can use tools that provide real-time insights into costs, broken down by team, project, or service. Once everyone can see the numbers, it’s a lot easier to make informed decisions.

Set Budgets and KPIs

After getting visibility, the next step is to set clear budgets and performance goals. I’m not just trying to cut costs for the sake of it—I want to align our spending with our actual business objectives. By setting the right key performance indicators (KPIs), we can measure whether we’re getting the most value from our cloud investments while staying within budget.

Build a Collaborative Culture

Finally, FinOps is about collaboration. It’s not just a set of tools or rules, it’s a mindset. I make sure that our engineers, finance teams, and leadership work together consistently to optimise cloud usage without sacrificing performance.

By following these steps, I’ve seen real improvements in how we manage cloud costs, and I believe it’s something any team can benefit from. FinOps is not just about saving money—it’s about making sure every dollar we spend on the cloud is working as hard as we are.

The developers I know/respect—the ones actually shipping, not just posting about shipping—stopped talking about MCP. No dramatic announcement. No hot take thread. They just… moved on. Back to the terminal, back to tools they’d been using for years, and suddenly their agents started doing things that felt almost unfair to watch.

Turns out the future of agentic coding was already installed on my machine.

Here’s what nobody wants to admit

We got seduced by abstraction. MCP looked clean on a diagram—standardized tool servers, structured integrations, everything typed and documented. Very enterprise. Very serious.

But diagrams don’t ship code. And in practice? You’re burning context on schema definitions before your agent has done a single useful thing. You’re maintaining custom servers that duplicate CLIs which already exist and work fine. You’re losing the thing that makes Unix tools genuinely great—the ability to pipe five commands together in ways nobody anticipated, solving problems that weren’t supposed to be solvable.

I’ve watched developers spend a week building an MCP integration for something curl | jq would’ve handled in eleven seconds. That’s not a workflow. That’s a hobby.

What actually works

Shell access.
Strong model.
Real tools.

git for version control (obviously). 
rg when grep isn’t cutting it. 
docker for environments. 
tail when something’s on fire in production. 
gh for PRs without leaving the terminal.

Tools with twenty years of documentation, Stack Overflow answers, and—crucially—training data.

Models that have seen millions of shell sessions. They understand pipes and flags and stderr in a way that feels almost native.

Drop your agent into the project directory, describe the goal, and the loop basically runs itself. It checks what’s broken, edits what needs changing, runs tests, reads the failure output, tries again. No handholding. No elaborate integration layer sitting between the model and the work.

The agents people are actually using

Claude Code

• Strong at large refactors
• Understands architectural tradeoffs
• Safer with destructive changes
• Slower but deliberate

Used when:

• Touching many files
• Migrating frameworks
• Reworking design patterns

ChatGPT (Advanced / o-series)

Not CLI-first, but heavily used in:

• System design
• DevOps debugging
• Infrastructure planning
• Terraform/Bicep design
• Incident analysis

People use it as:

• A co-architect
• A reasoning partner
• A debugging analyst

Especially strong in structured reasoning tasks.

Fast Build / CLI-Driven Agents

Codex CLI

• Lightweight
• Direct
• Good when intent is clear

Used for:

• “Generate this feature”
• “Write the tests”
• “Build a quick API”

Gemini CLI

• Fast
• Handles big repos
• Good multimodal support

Used when:

You want decent reasoning but not deep deliberation

Large project context needed

You want speed

IDE-Native Agent Experiences

Cursor

Probably the most used dev agent right now.

Why:

• Feels native
• Whole-codebase context
• Inline refactors
• Agent mode that edits multiple files

Used heavily in:

• Startup teams
• Full-stack dev
• Rapid iteration

GitHub Copilot (with Copilot Chat / Workspace)

Still massive adoption.

Used for:

• Autocomplete
• PR summarisation
• Test generation
• Code explanation

Not as autonomous as others, but very embedded in enterprise.

Infra / DevOps-Focused Agents

Warp AI

Terminal-native agent.
Good for:

• Command generation
• Explaining CLI output
• Kubernetes debugging

Aider

Very popular with engineers who:

• Like git-driven workflows
• Want structured file edits
• Want diffs instead of magic overwrites

Feels very DevOps-y.

What this looks like in practice

Say there’s a deprecated function scattered across a monorepo. The agent runs rg to find every instance, builds a plan, makes the changes, diffs them, runs the test suite, fixes what breaks, commits with a sensible message. Start to finish, maybe fifteen minutes. No GitHub integration required. No MCP server. Just the tools your CI pipeline already uses.

Or a production auth bug. Agent pulls latest, installs, starts the dev server, tails the logs, curls the failing endpoint, reads the error, adjusts, tests again. It’s methodical in a way junior developers often aren’t—and it doesn’t get frustrated at 11pm.

Why this actually makes sense

These models weren’t trained on MCP schemas. They were trained on decades of shell history, documentation, tutorials, Stack Overflow threads, GitHub repos. The terminal isn’t a workaround—it’s the environment they know best. You’re not constraining them by using bash. You’re putting them in their natural habitat.

The teams figuring this out are shipping faster, spending less on tokens, and—maybe most importantly—actually understanding what their agents are doing. Every command is visible. Every decision is traceable. The loop is transparent in a way that elaborate integration layers fundamentally aren’t.

Skip the architecture diagram. Skip the custom server.

Open a terminal. Point the agent at your codebase. Tell it what you need.

That’s it. That’s the whole thing.

Here’s what DevOps might look like when applied to Microsoft Fabric:

1. Version Control with Git: With Git integration in Fabric, data teams can now manage their code, data pipelines, notebooks, and models in a version-controlled environment. Just like developers use Git for code, data professionals can track changes to their work, collaborate with others, and ensure that different versions of their projects are clearly documented.
   
   Example: A data engineer might develop a complex data pipeline in Fabric. With Git, they can version control their scripts, track changes, and collaborate with other team members to improve and enhance the pipeline.
   
   
2. CI/CD for Data Pipelines: In a traditional DevOps environment, CI/CD is used to automate code deployment. In the case of Microsoft Fabric, CI/CD can now be applied to data pipelines as well. Changes to data pipelines, analytics reports, or machine learning models can be tested and deployed automatically, ensuring that updates are released reliably.
   
   Example: When a change is made to a data transformation script, the change is automatically tested in a development environment through a CI pipeline. After passing tests, the change is automatically deployed to production, ensuring that data updates or changes are delivered seamlessly.
   
   
3. Infrastructure as Code (IaC): Just as DevOps practices encourage automating the provisioning of infrastructure in cloud environments (such as AWS, Azure, or Google Cloud), the same principles can be applied to managing data infrastructure in Fabric. This means provisioning resources such as storage accounts, compute clusters, and data pipelines using code instead of manual intervention.
   
   Example: A team can define their data infrastructure as code, using tools like Azure Resource Manager (ARM) templates or Terraform, to automatically provision the resources needed for Fabric to run. This ensures that infrastructure is consistent, repeatable, and scalable.
   
   
4. Monitoring and Observability: In a DevOps setup, monitoring application performance in real time is critical. In Fabric, data engineers and operations teams can leverage built-in monitoring tools to track the health and performance of data pipelines, machine learning models, and analytics processes. This enables proactive issue resolution and continuous optimisation of the system.
   
   Example: By integrating monitoring tools with Fabric, teams can track metrics like pipeline execution times, resource usage, and data quality. If a pipeline fails, they get immediate alerts to investigate and fix the issue.
   
   
5. Collaborative Workflow: DevOps encourages teams to collaborate and share feedback early and often. With Git integration, teams working in Fabric can collaborate on code, data, and workflows. Data scientists, data engineers, and analysts can seamlessly share their work and iterate on solutions together, ensuring that the entire team is aligned and that new features or fixes can be rolled out quickly.
   
   Example: A data scientist might develop a new predictive model in Fabric. Using Git, they can collaborate with data engineers to test the model in real-world environments, refine it, and deploy it as part of a data pipeline, all while working in parallel with the development team.
   

Extended Reading

In a traditional DevOps environment, you see a strong focus on integrating development and operations through automation, continuous delivery, and collaboration. With the addition of Git integration in Microsoft Fabric, these practices are now applicable to data-driven projects as well. DevOps in Fabric will enable teams to work more collaboratively, automate data workflows, and manage the lifecycle of data projects just like software development. By merging DevOps principles with the lifecycle management tools that Fabric provides, organisations can deliver better software and data solutions faster and more efficiently, while also ensuring that their infrastructure and workflows remain scalable and maintainable.

If you’re exploring how DevOps practices apply to Microsoft Fabric, these resources provide deeper guidance on lifecycle management, Git integration, and automated deployment patterns.

Microsoft Fabric DevOps & CI/CD

• Microsoft Fabric – CI/CD and lifecycle management best practices
  https://learn.microsoft.com/en-us/fabric/cicd/best-practices-cicd
  A detailed guide from Microsoft on implementing CI/CD workflows for Fabric artifacts using Git integration and deployment pipelines.
• Fabric Deployment Pipelines
  https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines
  Explains how Fabric deployment pipelines allow teams to promote content across Dev → Test → Productionenvironments.
• Azure DevOps + Fabric integration
  https://learn.microsoft.com/en-us/fabric/cicd/git-integration/intro-to-git-integration
  Shows how Git repositories can be used to manage Fabric workspaces, enabling proper version control and collaboration.

DataOps & Analytics Engineering

• dbt – Analytics engineering workflows
  https://docs.getdbt.com/docs/introduction
  Many of the DevOps concepts applied to Fabric—testing, version control, CI/CD—originate from analytics engineering practices.
• Apache Airflow concepts applied to DataOps
  https://airflow.apache.org/docs/
  Understanding workflow orchestration patterns helps when designing reliable Fabric data pipelines.

DevOps Foundations

• **Continuous Integration and Continuous Delivery
  https://martinfowler.com/articles/continuousIntegration.html
  A foundational explanation of CI/CD practices that underpin modern DevOps approaches across both application and data platforms.

Related Articles

You may also enjoy these posts:

• DevOps: It’s About the Team, Not Just the Tech
  https://hybriddbablog.com/2024/03/20/devops-its-about-the-team-not-just-the-tech/