Leadership development looks different depending on where you sit at DataBank. In construction, a mistake shows up in steel and concrete or on a deadline that will not move. In security, a mistake shows up in trust, in the confidential information customers hand over the moment they sign a contract. Different stakes, different daily pressures, and we feel both every day.
A few convictions show up again and again, whichever side of the business you’re on. In this article, we bring together perspectives from both sides to share the strategies and best practices that hold up across DataBank.
Prove It Before You Get the Title
The instinct in most organizations is to hand someone authority first and see what they do with it. We tend to run it the other way.
When a new team function grows from one person to four, and two candidates have equal standing, the answer is not a coin flip and it is not a title. It is six months of informal, shared leadership, with both people told plainly that one of them will end up running the group and the process itself will make it obvious who. Leading without authority is harder than leading with it, and asking someone to prove they can do the harder version first tends to produce a leader people actually want to follow, rather than one they are told to.
The same instinct shows up as patience elsewhere in the business. High potential is not something we spot in a single strong quarter. It takes time, and it takes more than one person’s opinion. A leader who is only impressing the person one level up, while treating peers poorly, is not showing high potential.
That’s something else entirely, and multiple perspectives are what surface the difference. Once a handful of people independently point to the same specific instances of strong judgment or capability, we consider that worth investing in. A gut feeling from one manager is not.
There is No One-Size-Fits-All Development Path
Most career ladders are built in fixed steps: analyst to manager to senior manager, in that order, whether or not the person climbing it actually wants what is waiting at the top. We start from a different question: what does this specific person want, and why?
That means pushing back gently when someone asks for the “logical next step.” Wanting authority is not, by itself, a reason to grant it. The better question is why someone wants the promotion in the first place. A strong individual contributor and a strong manager are frequently not the same skill set, and pushing someone into people-leadership because he or she excelled technically can be a set-up for failure.
It also means learning how each person actually receives feedback before delivering it. The same words, the same tone, land completely differently depending on who is hearing them. Two children raised in the same house, given the exact same sentence, can walk away with two different reactions.
A lot of that comes from raising many children (a total of seven from both executives), and a fair amount from Ted Lasso. Both taught us that you can’t lead everyone the same way and expect the same result. Knowing someone well enough to choose the right words is not a soft skill. It is what makes the rest of coaching possible.
Feedback Is a Question, not a Verdict
We don’t describe our harder conversations as confrontations. We describe them as questions and opportunities to learn and grow together.
Instead of opening with, “You did this wrong,” the more useful opening is, “Do you think we got the result we wanted?” That single question does two things at once: It tells us whether the gap was a skills problem or a communication problem, and it gives the other person room to arrive at the answer rather than defend against it.
One discovery we’ve made through exactly this kind of question is that a missed expectation isn’t always a performance issue. Sometimes it’s a failure to define what success looked like in the first place, which means the fix is a clearer conversation, not a disciplinary one.
Bad news doesn’t improve with time. If a piece of feedback is landing for the first time in a formal performance review, that review has already failed, which is a sign of poor leadership. The fix is small, frequent course correction, delivered as soon as the gap appears, framed around what support is needed rather than what went wrong.
Conflict itself isn’t the problem. Different perspectives are how we learn from each other. It only becomes a problem when it turns personal or chaotic, and that’s when a good leader steps in — not before.
Why the Stakes Shape the Approach
The two sides of our business feel this differently, and that difference is worth naming rather than smoothing over.
On the construction side, the pressure is external and immediate: a labor market stretched thin across general contractors and subcontractors, where people are routinely poached on compensation alone. Our counter to that isn’t matching every offer. It’s building loyalty that survives a competing offer, the kind where people choose to follow a leader they trust rather than stay for a transaction. Autonomy, real investment in someone’s goals, and a workplace people want to recommend to a friend all compound in a way a signing bonus doesn’t.
On the security side, the pressure is about trust. We hold information most people never see, and data centers themselves are increasingly viewed with suspicion by the communities around them. That makes integrity part of the leadership pipeline itself. Identifying high potential isn’t just about capability. It’s about whether someone will handle what they’re trusted with the way they say they will, in public and in private.
While the risks are different, the stakes are still the same: Will this person do right by what he has been given, whether that’s a team, a timeline, or a customer’s trust?
Different Hats, Same Habits
Strip away the hard hats and the security clearances, and the same three habits carry both sides of our business: earn the role before you’re handed it, build a development path around the individual instead of the ladder, and give feedback the moment it’s needed instead of saving it for a form. None of that is unique to data centers. What’s unique is how much is riding on getting it right, and it’s something we take seriously across the board.
Want to learn more about how DataBank’s leaders build and grow strong teams across the business? Visit our Leadership page or explore DataBank Digest for more insights on talent development and management strategies.
This is the fourth article in a series exploring the facts behind the data center debate. You can read parts one, two, and three, or download our full eBook, The Truth About Data Centers, for a closer look at the issues covered in this series.
Water consumption is one of the most emotionally charged concerns raised about data centers today, and it’s one of the most misunderstood. A single statistic can circulate for months before anyone checks where it came from, and by then it may have already shaped local debates and headlines.
The picture looks very different once you look at how these figures actually get built.
Cooling Isn’t One Thing
Lumping every data center into the same water conversation is where most confusion starts. There are three completely different approaches to cooling, and each comes with its own tradeoffs.
Air-based cooling uses no water at all, relying entirely on traditional air conditioning. It’s common in older and smaller facilities, although it becomes less practical as computing density rises.
Evaporative cooling trades water for efficiency. It’s a continuous process: Water goes in and doesn’t come back, and many large legacy facilities run this way because the energy savings are real.
Closed-loop cooling sidesteps that tradeoff entirely. Water (or in some systems, a glycol-based fluid) circulates inside a sealed system rather than getting released, so once the system is charged, ongoing consumption approaches zero.
That distinction is measured through Water Usage Effectiveness, or WUE, the industry’s standard for tracking how much water a facility uses relative to its size and output. DataBank’s standard facility design runs on closed-loop cooling, so new builds start service with a near-zero water footprint from day one, not something the facility works toward over time.
The inflated version counted water lost to evaporation at hydroelectric reservoirs as part of a data center’s footprint, water that evaporates off dammed rivers regardless of who’s drawing power from the dam. It’s a bit like arguing that a retail store uses water every time its cash register rings up a sale, since generating the electricity behind that transaction required water somewhere upstream.
Strip that out and the numbers change dramatically: Masley’s corrected estimate for onsite water use lands around 2.2 milliliters per prompt across the U.S. grid, or about 1/227th of a standard bottle. It’s the same underlying data, but just with a different definition of what actually counts as data center water use.
Real Numbers, Real Context
Compare data center water use against everyday consumption and even the larger figures shrink fast.
A less-discussed piece of this story is the power behind the water. Fossil fuel generation is water-intensive; yet, wind and solar are not. As the grid shifts toward renewables, a data center’s indirect water footprint shrinks along with its carbon footprint, even before accounting for cooling design. That’s a benefit that rarely makes it into the figures critics cite, even though it compounds every year renewable capacity grows.
Drought-prone communities are right to ask hard questions here, and those concerns reasonably extend beyond onsite cooling to the water used generating the electricity in the first place. The honest answer is that the industry isn’t moving at a uniform pace, which is exactly why specifics matter more than pledges.
The Bottom Line
Water figures that sound alarming often turn out to be measuring the wrong thing, not the wrong facility. Once the boundaries get examined, a modern, closed-loop data center tends to look a lot more like an office building than an industrial plant.
Data centers are essential infrastructure, and concerns about their footprint deserve real answers, not headlines that never checked their own math.
Want to stay ahead of the trends shaping digital infrastructure? DataBank Digest delivers analysis, insights, and the latest news from the world of colocation and digital infrastructure.
Network latency has quietly shifted from an operational metric to a strategic risk. For years, IT teams measured performance almost entirely in uptime, watching for outages, tracking service level agreements, and treating five nines on a dashboard as proof the network was doing its job. That measure is no longer sufficient. A network can be fully available and still be costing the business money every day, one slow response at a time.
That cost has a name: latency. It is the delay between a request and a response, and it rarely announces itself as a failure. Instead, it shows up as a checkout page that loads a second too slowly, a trading algorithm that reacts a few milliseconds too late, or a fraud detection system that flags a transaction after the damage is done.
These delays are easy to overlook because nothing technically breaks. They are also easy to underestimate, because the cost accumulates across thousands of small moments rather than one visible incident, which is exactly what makes it dangerous for leaders who are only watching uptime.
Where Latency Actually Comes From
Latency rarely comes from a single failure point. It accumulates anywhere data travels farther or through more steps than necessary, and most networks have several of these points built in without anyone noticing.
Public internet routing is the most common source. Traffic moving across the open internet takes an indirect path by design, hopping between networks before reaching its destination. Each hop adds delay, and each additional network in the path becomes a place where congestion or packet loss can slow things down further. The internet was built for resilience, not speed, and that tradeoff shows up as latency.
Physical distance compounds the problem. A request traveling from a data center on one coast to a cloud region on the other carries transmission time that no amount of software optimization can fully remove. Layer in the number of applications, APIs, and third-party services most businesses now depend on, and it becomes clear why latency compounds quickly across a modern technology stack, often in ways that are difficult to trace back to a single cause.
Why This Matters More Than It Used To
A decade ago, a little extra latency was a tolerable inconvenience, something IT teams optimized around when time allowed. That tolerance has disappeared. Across nearly every industry, latency has become a measurable competitive disadvantage, and the businesses that treat it as a minor technical detail are absorbing costs their competitors have already engineered away.
Financial services. Firms build entire infrastructure strategies around shaving microseconds off trade execution, because in that industry, microsecond translate directly into dollars.
Retail. A slower checkout experience leads to more abandoned carts and lower conversion rates.
Healthcare. Fast, reliable data exchange matters for systems where delay is not just inconvenient but potentially harmful.
AI workloads. Training large models and running real time inference both depend on moving enormous volumes of data quickly and predictably. When the network cannot keep pace, businesses either accept degraded performance or delay the AI initiatives they were counting on to drive growth.
None of this is hypothetical. Across these industries, the cost of latency shows up in lost revenue, lower conversion rates, and missed opportunities, and it rarely arrives with a clear root cause attached. That is what makes it dangerous. The businesses that get ahead of it are the ones actively looking for it, rather than waiting for it to show up on a balance sheet.
Interconnections Change the Equation
Interconnections solve the latency problem by giving data a more direct route instead of relying on the public internet to move information between applications, clouds, and partners. A few core approaches make this possible.
Cross connects. A direct, dedicated link inside a data center connects two networks directly, often reducing what would be a multi-hop journey to a single, predictable connection.
Direct cloud on-ramps. Rather than sending traffic out to the public internet to reach a cloud provider, a private connection carries that traffic straight to the cloud environment. The result is lower latency, more consistent performance, and fewer variables that can introduce delay.
Internet exchanges. Networks peer directly with each other, cutting out the transit providers that would otherwise sit in the middle of every exchange.
Together, these approaches replace an unpredictable, multi-hop path with a shorter, more direct one.
What This Looks Like in Practice
Consider a mid-size fintech firm running algorithmic trading systems. Every millisecond of delay between its systems and the exchanges it trades on represents a measurable financial risk, one that shows up directly in execution quality rather than as an abstract performance metric.
By colocating its infrastructure in a facility with direct, low latency connections to major exchanges, the firm removes the unpredictable variable of public internet routing entirely. Trades execute faster, risk models run closer to real time, and infrastructure costs become more predictable, since the firm is no longer paying for the inefficiencies of a longer network path or absorbing the cost of unplanned volatility in its connection quality.
That advantage compounds when the firm’s own infrastructure sits inside the same facility as its network provider. The connection is not just faster, it is also physically protected by the same power redundancy, cooling systems, and access controls that safeguard the network equipment itself. A firm relying on a remote connection back to its infrastructure is exposed to a failure at either end. A firm colocated alongside its provider closes that gap.
The underlying principle extends well past financial services. Any organization moving data between clouds, partners, or physical locations at meaningful volume is running the same risk calculation, even if the consequences are less immediately visible than a missed trade. A retailer’s fraud check, a healthcare system’s record exchange, and a manufacturer’s supply chain data feed all depend on the same fundamentals: shorter paths, fewer hops, and fewer variables outside the organization’s control.
The businesses that recognize this early are the ones designing their infrastructure around it, rather than discovering the cost after the fact.
The Real Return on Interconnections
Latency is often invisible until someone quantifies it, and by then the cost has usually already accumulated. The businesses that get ahead of the problem are the ones that treat connectivity as a strategic decision rather than an afterthought. Interconnections offer a proven way to shorten the distance between systems that need to talk to each other quickly, reliably, and without the unpredictability of the open internet.
The hidden cost of latency is real, but it does not have to be permanent. With the right interconnection strategy in place, it becomes a cost businesses simply stop paying.
Want to learn more about how DataBank’s interconnection ecosystem can help reduce latency across your network? Visit our Interconnections page or explore DataBank Digest for more insights on network performance and infrastructure strategy.
In another example of DataBank employees giving back to the community, employees from across the country recently came together for a backpack drive to help local students start the school year off right. This time, the effort centered on something every kid needs on day one: a backpack stocked with supplies.
The effort came together in two rounds of generosity. First, DataBank employees, along with vendors and customers, donated funds to purchase backpacks and the supplies to fill them. Then, many of the same volunteers gathered at our Salt Lake City data center to stuff the backpacks before delivering them to a local elementary school. In total, contributors gave over $1,250 toward the project in addition to their time.
DataBank employees participated in a backpack drive to donate 60 backpacks of school supplies to students and teachers at a local school.
Twenty-Seven Volunteers, One Classroom-Ready Delivery
Twenty-seven DataBank employees pitched in to pack the backpacks, some of which were branded with the DataBank logo. Each one was filled with a water bottle, notebook, ruler, crayons, pocket folder, pencil pouch with pencils, eraser, pencil sharpener, glue stick, and kid scissors. The team also set aside extra water bottles, notebooks, erasers, pocket folders, pencils, and crayons for teachers, recognizing that classroom needs do not stop with students.
The finished backpacks were delivered directly to Bluffdale Elementary, giving local kids and their teachers a boost heading into the school year. It is a small gesture with an outsized impact for families who could use the help.
A Culture of Giving Back
Backpacks are one more example of a commitment that shows up across DataBank markets throughout the year. A few recent examples:
Kindness Kits: Employees across Houston, Dallas, Salt Lake City, and Denver assembled and donated 852 care packages this spring for organizations serving women, children, and individuals in need.
DFW Metro Blood Drive: DataBankers, customers, and vendor partners came together at our DFW3 facility, with 21 donors giving blood and two giving double donations.
Letters to the Troops: Teams across eight data centers wrote and sent more than 500 letters of gratitude and encouragement to U.S. service members.
DataBank employees consistently look for ways to support the neighborhoods surrounding our data centers, and Salt Lake City’s backpack drive is a good example of that spirit in action.
We are proud of every DataBank employee, vendor, and customer who contributed to this effort. We are especially proud of our Salt Lake City team, who stepped up a second time to pack and deliver the backpacks, making sure Bluffdale Elementary students and teachers started the year with what they needed.
Want to learn more about how DataBank is investing in the communities where we operate? Visit our Community Relations page or explore DataBank Digest for more stories about our people, our partners, and the neighborhoods we’re proud to call home.
Your choice of hosting provider will determine the quality of your hosting experience. This means it’s vital to go through a robust evaluation process before choosing a vendor. With that in mind, here is a straightforward guide to finding an enterprise Proxmox hosting provider. It covers the shortlist criteria most teams skip.
Why most enterprise Proxmox shortlists look right on paper but fail in production
Selecting an enterprise Proxmox hosting provider often begins with a familiar pattern. It goes: compare pricing, check feature lists, review SLA percentages, and confirm that “managed support” is included.
The problem is that these surface-level criteria rarely predict real-world operational success.
Proxmox is a flexible and powerful virtualization platform, but at enterprise scale it depends heavily on how it is engineered, operated, and supported day-to-day. Providers that look identical during procurement can behave very differently once workloads are live, incidents occur, or scaling is required.
For enterprise IT decision-makers, the real risk is not choosing Proxmox itself. It is choosing a provider whose operational maturity is not visible during the initial evaluation phase.
Depth of in-house expertise is the first real differentiator
Many Proxmox hosting providers advertise “expert support,” but enterprise environments require more than general familiarity with virtualization.
What matters is whether expertise exists in-house and is directly responsible for operations.
What enterprise-grade expertise looks like
A credible enterprise Proxmox provider should have:
Dedicated virtualization engineers (not generalized support staff)
Hands-on experience with clustered Proxmox environments at scale
Deep knowledge of storage backends (e.g., Ceph or ZFS-based architectures)
Familiarity with HA configurations and failure scenarios
Real-world troubleshooting experience under production conditions
Why this matters
In production environments, issues rarely fit neatly into one category. A single incident may involve:
Storage latency across nodes
VM scheduling conflicts
Network misconfiguration
Kernel or hypervisor-level behavior
Without deep in-house expertise, providers often rely on escalation chains that extend resolution time and increase downtime risk.
Architecture review capability separates operators from resellers
One of the most overlooked evaluation criteria is whether the provider actively participates in architecture design or simply deploys pre-built infrastructure.
What strong providers offer during evaluation
Enterprise Proxmox providers should be able to:
Review workload profiles before deployment
Recommend cluster sizing based on CPU, memory, and I/O demand
Design storage layouts aligned with performance needs
Define HA and failover strategies based on application criticality
Why this matters
Proxmox is not a one-size-fits-all platform. Poor initial design decisions can lead to:
Overloaded nodes and performance bottlenecks
Inefficient storage utilization
Unbalanced cluster scaling
Increased operational overhead over time
Architecture review is where long-term stability is either designed in or missed entirely.
Reference checks reveal operational reality
Reference customers are one of the most reliable ways to validate provider capability, but many procurement processes treat them as a formality.
What to ask during reference calls
Instead of general satisfaction questions, enterprise teams should focus on operational detail:
How quickly are incidents typically resolved?
How does the provider handle upgrade cycles?
Have there been any major outages and how were they handled?
How transparent is capacity planning?
How responsive is escalation support during critical events?
Why this matters
Marketing materials describe intended service quality. References reveal actual operational behavior under pressure.
Providers with strong enterprise Proxmox capabilities should be able to provide customers who can speak confidently about stability, responsiveness, and engineering depth.
Support model structure is more important than SLA percentages
SLAs often dominate provider comparisons, but they rarely reflect how support actually functions during an incident.
Key areas to evaluate
Enterprise buyers should understand:
Whether support is in-house or outsourced
Whether Tier 3 engineers are directly accessible
How escalation is triggered and handled
Whether 24×7 engineering coverage is truly available
What tools support teams use for full-stack visibility
Why this matters in Proxmox environments
Proxmox environments are tightly integrated systems involving:
Virtualization layers
Storage clusters
Networking configuration
Host-level dependencies
Without deep engineering access, even small incidents can take significantly longer to resolve due to multiple hand-offs.
Lifecycle management discipline is critical but often invisible
Another frequently overlooked criterion is how providers handle lifecycle operations such as updates and upgrades.
What enterprise lifecycle management should include
A mature Proxmox hosting provider should have:
Planned upgrade schedules across clusters
Pre-production testing of updates
Version consistency across nodes
Controlled rollback procedures
Clear communication of maintenance windows
Why this matters
Uncoordinated updates can introduce:
Cluster instability
Storage replication issues
VM performance inconsistencies
Unexpected downtime during maintenance windows
Lifecycle discipline is one of the strongest indicators of operational maturity.
Architecture consistency across environments
Enterprise Proxmox deployments often scale across multiple clusters or sites. Consistency becomes critical at this stage.
What to look for
Providers should maintain:
Standardized node configurations
Consistent storage architectures
Unified networking design patterns
Predictable scaling models
Documented deployment standards
Why this matters
Without consistency:
Troubleshooting becomes more complex
Performance benchmarking becomes unreliable
Scaling introduces configuration drift
Operational overhead increases significantly
Enterprise environments depend on predictability, not variation.
Monitoring and visibility are non-negotiable
A strong enterprise Proxmox provider should deliver full-stack observability, not just basic uptime alerts.
Expected monitoring capabilities
Node-level health metrics
VM performance tracking
Storage latency and throughput visibility
Cluster quorum and HA status monitoring
Network performance analysis
Historical performance reporting
Why this matters
Without visibility:
Capacity issues are detected too late
Performance degradation becomes user-reported
Incident root cause analysis takes longer
Planning becomes reactive instead of proactive
Monitoring maturity is often a direct reflection of operational maturity.
Disaster recovery capability should be proven, not theoretical
Enterprise environments depend heavily on recoverability, not just uptime.
What to validate
Defined RPO and RTO targets
Multi-site replication capability
Regular DR testing procedures
Documented failover workflows
Evidence of successful recovery tests
Why this matters
Many environments fail during recovery events not because DR was absent but because it was never tested under real conditions.
A strong provider treats DR as an operational process, not a documentation exercise.
Security integration must be built into the platform
If any of these areas are unclear or underdeveloped, the risk typically surfaces after production deployment.
Why provider selection matters more than the platform
Proxmox is a capable and widely adopted virtualization platform, but enterprise outcomes depend far more on the provider operating it than the software itself.
The provider determines:
How reliably systems are maintained
How quickly incidents are resolved
How predictable performance remains
How effectively scaling is managed
How secure and compliant the environment is over time
In enterprise environments, operational execution outweighs platform capability.
Conclusion: the shortlist should reflect operational reality, not marketing claims
Finding the right enterprise Proxmox hosting provider is less about comparing feature lists and more about evaluating operational depth.
The most reliable providers demonstrate expertise through architecture design capability, disciplined lifecycle management, strong escalation paths, consistent monitoring, and proven disaster recovery execution.
Teams that skip these deeper evaluation criteria often discover gaps only after the environment is live. By this point, however, changes are harder, incidents are more disruptive, and operational expectations are already set.
Ready to evaluate an enterprise-grade Proxmox hosting provider?
DataBank delivers managed Proxmox infrastructure with enterprise-grade architecture design, in-house engineering expertise, disciplined lifecycle management, and 24×7 operational support designed for mission-critical environments. Contact DataBank to evaluate your current virtualization strategy and build a more resilient, scalable private cloud foundation.
