Several years ago, I led a transformation project that fundamentally changed how I think about "modern" infrastructure. We were migrating a legacy monolith to microservices—the kind of project every engineering manager has war stories about. But halfway through, one of the engineers asked a question that stopped me cold: "Are we actually making things worse for the environment?"
They weren't being difficult. They'd done the maths. Our shiny new cloud-native architecture was consuming nearly three times the energy of the creaky old system we were replacing. The irony wasn't lost on any of us—we were calling it "modernisation" whilst substantially increasing our carbon footprint.
That moment forced us to rethink our approach. We couldn't scrap months of work, but we could redesign our architecture with energy efficiency in mind. What followed was some of the most thoughtful technical work I've ever been part of. We optimised database queries, consolidated redundant services, and chose more efficient infrastructure patterns. The result? A system that delivered all our performance goals while consuming 30% less energy than our original "modern" design.
That project taught me something crucial: digital transformation and environmental responsibility don't have to be opposing forces. But they also don't align automatically. It takes intentional leadership to navigate both delivery pressure and climate impact without compromising either.
The Hidden Environmental Cost of Going "Modern"
The uncomfortable truth about many transformation projects is that they increase energy consumption dramatically, at least initially. Cloud providers have made it incredibly easy to spin up infrastructure, but that convenience comes with environmental costs that most engineering teams never calculate.
Legacy systems, for all their flaws, often run on surprisingly efficient infrastructure. That mainframe from 2003 might handle thousands of transactions per kilowatt-hour. Your new Kubernetes cluster, with its load balancers, service meshes, and redundant databases, might consume ten times the energy for the same workload.
The Infrastructure Multiplication Problem
I've seen transformation projects where teams deployed separate development, staging, and production environments for each microservice. Fifteen services meant forty-five running environments. Nobody calculated the carbon footprint of keeping all that infrastructure humming 24/7, most of it sitting idle.
The migration period is particularly wasteful. You're running both old and new systems in parallel, often for months. Data synchronisation processes consume additional resources. Load testing and performance validation require even more infrastructure. What should be a temporary state often becomes semi-permanent as launch dates slip.
Beyond Lift and Shift
This doesn't mean transformation projects are environmentally irresponsible. But it does mean we need to be honest about the trade-offs. "Lift and shift" migrations are often criticised as technically lazy, but they're also environmentally costly. Moving workloads to the cloud without optimising them wastes energy on a massive scale.
Building Climate Awareness Without Becoming the Green Police
The generational divide on climate issues is real, and it shows up in engineering teams. Younger engineers increasingly want their work to align with their environmental values. They'll ask uncomfortable questions about carbon footprints and energy consumption. Some will even leave for climate tech companies if they feel their current role conflicts with their principles.
As managers, we can't ignore this shift. But we also can't let environmental concerns paralyse every technical decision. The key is creating space for these conversations without turning every architecture review into a climate debate.
Making Trade-offs Visible
I've found success in being upfront about trade-offs. When we're evaluating options, I'll explicitly ask: "What's the environmental impact of each approach?" Not to veto high-energy solutions, but to make the cost visible. Sometimes the answer is "we don't know," which is useful information too.
This transparency helps team members understand that climate impact is one factor among many, not a binary pass/fail test. A database cluster that consumes more energy but enables better user experience and business outcomes might still be the right choice. The important thing is making that decision consciously rather than by accident.
Building Psychological Safety Around Climate Concerns
Creating psychological safety around these discussions matters enormously. Engineers need to feel they can raise environmental concerns without being dismissed as idealistic or unrealistic. At the same time, they need to understand that business constraints and delivery timelines are equally valid considerations.
A Practical Framework for Climate-Conscious Transformation
Over the past few years, I've developed what I call the Three-Lens Review for transformation decisions. It's not revolutionary, but it's practical enough to use in real project meetings without slowing everything down.
Understanding Each Lens
The Performance Lens covers traditional engineering concerns: speed, reliability, scalability, and cost. This is familiar territory. We know how to measure response times, uptime percentages, and infrastructure costs. These metrics drive most transformation decisions, and rightly so.
The Sustainability Lens examines energy consumption, carbon footprint, and resource efficiency. This is newer territory for most teams, but cloud providers are making it easier. AWS has carbon footprint tools. Google Cloud offers sustainability dashboards. Azure provides energy consumption metrics. The data exists; we just need to start looking at it.
The People Lens considers team capability, change management, and long-term maintenance. Will your team be able to support this architecture in two years? How much training is required? What's the cognitive load of the new system? These human factors often determine whether transformations succeed or become technical debt.
Weighting the Lenses Appropriately
The key is weighting these lenses appropriately for each decision. A user-facing API that affects customer experience might prioritise performance over sustainability. A background data processing system might optimise for energy efficiency. A system that requires extensive on-call support might prioritise simplicity over theoretical performance gains.
I don't have a formula for this weighting—it depends on your business, your team, and your constraints. But making the evaluation explicit helps everyone understand why decisions were made and builds confidence in the transformation approach.
Managing Stakeholder Expectations When Environment Meets Timeline
The most challenging conversations happen when environmental considerations affect delivery timelines or increase costs. Non-technical stakeholders often view sustainability requirements as "nice-to-have" features that can be deprioritised under pressure.
These discussions require translating environmental impact into business language. Instead of talking about carbon emissions, I focus on operational efficiency and long-term costs. Energy-efficient systems often have lower running costs. Optimised architectures usually perform better and require less maintenance. Environmental responsibility and business efficiency frequently align.
When to Push Back and When to Compromise
When they don't align, honesty works better than advocacy. I'll explain the trade-offs clearly: "We can deliver faster by provisioning more infrastructure, but it'll increase our energy consumption by 40% and our monthly costs by £3,000." Let the business stakeholders make informed decisions rather than hiding the environmental costs.
Sometimes you need to push back on environmentally costly shortcuts. I've had success framing this around technical debt: "This approach will work for launch, but we'll need to refactor within six months or our infrastructure costs will become unsustainable." Business leaders understand debt metaphors, even when they don't understand Kubernetes.
Building Long-Term Business Cases
Building business cases that include long-term environmental costs requires patience and persistence. Founders focused on Series A fundraising might not care about carbon footprints, but they will care about operational costs that scale with user growth. The key is finding the business angle that resonates with your specific stakeholders.
The Long-Term Advantage of Climate-Conscious Transformation
What I've learned from that original project—and several transformation initiatives since—is that considering environmental impact doesn't slow down delivery. It actually makes transformations better.
Teams that think about energy consumption build more efficient systems. Engineers who consider carbon footprints write more optimised code. Managers who balance environmental and business concerns make more thoughtful architectural decisions.
The Talent and Competitive Advantages
There's also a talent advantage. The engineers who care most about climate impact are often the ones who think most carefully about system design. They're the developers who optimise database queries and question whether every microservice needs its own cache. They're the architects who design for efficiency, not just scalability.
As environmental regulations tighten and carbon costs become more visible, the companies that integrated climate considerations early will have competitive advantages. Their systems will already be optimised for energy efficiency. Their teams will understand how to balance environmental and business concerns. Their technical debt won't include massive sustainability retrofits.
Making It Work in Practice
That original transformation project delivered successfully, on time and within budget, because we learned to integrate environmental thinking into our decision-making process rather than treating it as an afterthought. The 30% energy reduction wasn't achieved through compromise—it came from being more intentional about our technical choices.
Your next transformation project is an opportunity to embed these considerations from the start. The question isn't whether your team should care about climate impact—it's how you'll lead them to balance environmental responsibility with delivery excellence. Both are possible, but only with intentional leadership that makes the trade-offs visible and the decisions conscious.
The engineers joining your team increasingly expect this kind of thinking. The business environment is moving towards greater environmental accountability. The technology exists to measure and optimise for sustainability alongside traditional metrics.
The only question remaining is whether you'll lead this change or be forced to catch up later.