Author: Mark McNiel

A booth makes you a vendor; a podium makes you a source

Technical conferences are the highest-leverage access instrument available at the architecture layer, and the dates that govern your access are the abstract deadlines, not the show dates.

For a company selling at the architecture layer, technical conferences are the best access instrument there is. Almost everyone works them wrong, and the way they work them wrong is expensive, visible and annual.

The wrong version is familiar. Book a stand, ship the demo, staff it for three days, collect badge scans, report interest. The exhibit hall is where people go to be sold to, which makes it the one room in the building where nobody is deciding anything. A booth establishes that you exist and are solvent. It does not get you in front of the person who writes a thermal requirement, because that person is in a session.

The right version is the technical program. Requirements are written in committees and working groups, and they are written by people who are at the conference to argue with peers about physics. A paper accepted into the program puts you in that category rather than in the vendor category, which changes what happens when you follow up afterwards: you are someone whose work they saw, not a company whose booth they walked past. A podium buys a year of meetings a stand never will, and it does it with the one form of credibility that carries at this layer, which is technical rather than commercial.

That has a scheduling consequence, and it is the entire practical point of this note. Your access calendar is governed by abstract submission deadlines, not by show dates, and the deadlines fall eight to nine months ahead of the conference. As I write this in September 2026, the ITherm 2027 abstract deadline is at the end of this month and the ECTC 2027 deadline is in the first week of October, for conferences that meet in mid-2027. A commercial plan that lists conferences without listing their submission deadlines has already missed the cycle it was written for, and will miss the next one too, because it will get written again in January.

Which events matter depends entirely on which layer you sell into, and collapsing them into a single category called conferences is how travel budgets get spent on nothing. The Open Compute Project’s global summit in October is where open specifications get released and is the single densest week in the year for anyone selling into rack-scale architecture. SC in November is the high-performance computing and operator crowd. DesignCon and Chiplet Summit in the spring are the package layer. OFC in March is optics. ECTC in June is packaging and thermal, and it is where the papers that shape thermal requirements actually land. SEMICON events reach the fab, test and advanced-packaging supply chain. Those audiences barely overlap.

The strongest version of this is not a conference at all, it is a standards body. A paper is read once; a contribution to an open specification becomes the document other people design against, and it persists. Open Compute Project working groups are where a good deal of the rack-scale, power and thermal vocabulary in AI infrastructure is currently being settled, and the companies in those rooms are shaping the envelope their competitors will have to fit inside. That work is slow, unglamorous, has no attributable pipeline, and is almost impossible to justify in a quarterly review, which is precisely why so much of it is being done by a small number of companies who understood what it was worth.

Working an event properly is a six-week process, not a three-day one. Six weeks out, build the target list from the published exhibitor and speaker rosters and request meetings by name against your target map, because the people worth meeting have their calendars full by then. Two weeks out, lock the schedule and prepare one specific technical question for each target, specific enough that answering it requires their engineer rather than their marketing manager. During the event, spend your hours in technical sessions, committees and working groups rather than at your own stand, and take notes on requirements rather than on interest, because interest is not information. Within five days of getting home, log every conversation against a gate.

Then apply the rule that makes all of it accountable: an event that produces no gate deliverable within a week produced nothing. Not a soft event, not a brand investment, not a long-term play. Nothing. Judged that way, roughly half of most companies’ conference calendars disappears, which is the point, because the budget that half consumes is the budget the other half needs.

The argument against. The counter is that brand presence has genuine value, particularly at the qualification gate. A company nobody has heard of struggles in a supplier audit no matter how good its papers are, and there are buyers for whom an absent stand reads as an absent company. The booth is not worthless. It is simply not an access instrument, and most companies fund it out of the access budget and then wonder why access did not improve.

September 10, 2026
Shared commitment beats free engineering

Long design-in programs fail for a reason that never appears in a forecast: neither side is committed, and both sides call the program active.

A design-in program that is going to fail rarely announces it. There is a modelling review in March and a promised test vehicle in April. In June the customer reorganizes the architecture team. In September a new power map arrives and supersedes the old one. Two of your engineers have spent a quarter on it, the opportunity is still in the forecast, and no deliverable exists that either company could point to as evidence of progress.

Nobody lied. The failure has a specific shape, and it is symmetrical. The customer is interested but not budget-committed: an engineer wants the answer, and no cost centre owns getting it. And the supplier is interested but not schedule-committed: applications engineering will get to the test vehicle when the quarter allows. Both sides are genuinely engaged. Neither has put anything at risk. Programs in that state do not fail, they drift, which is worse, because a failure gets removed from the pipeline and a drift gets carried.

The fix is to tie both commitments to the same gates. Agree at the outset what each side funds and staffs at each stage of the design-in, write it down, and revisit it at every gate. Not a contract. A commitment schedule, of the kind both engineering organizations already use internally and neither thinks to use across the boundary.

Where the free line sits matters enormously. The early gates should stay free and joint: architecture access, problem definition, first-pass modelling. Low friction is the only way anyone gets into an architecture conversation at all, and attempting to charge for entry prices you out of the door you need. From the test vehicle onward it changes. A non-recurring engineering fee at that stage is entirely industry-normal — photomask and tooling NRE in semiconductors is exactly this arrangement, and it is routinely creditable against production volume, which disposes of the main objection before the customer raises it.

But the fee is not the point, and treating it as revenue is how this idea gets ruined. The fee is a diagnostic. A customer who cannot find a budget owner for a modest engineering line within a fortnight does not have a program; they have an interested engineer, which is a real asset and a different thing. Learning that in week two instead of month fourteen is worth far more than the fee. It also works internally in the same way: a funded engineering commitment gets scheduled, while an unfunded sales-support request gets deferred, so asking the customer for commitment is often the only reliable route to getting commitment from your own applications team.

What goes in the schedule is unglamorous and takes about a page. For each gate: what the customer supplies, what the supplier staffs, the exit criterion that says the gate is passed, and a date. The exit criterion is the line that does the work, and the best way to get it is to stop proposing one. Ask the customer what they would need to see for this to be worth a test vehicle. Whatever they answer is your exit criterion, stated in their words, owned by them, and defensible inside their own organization in a way that nothing you write ever will be. It is the single most useful question available in a design-in conversation and it converts a pleasant meeting into a definition of done.

Introducing it requires care, because the wrong framing sounds like a payment demand at the exact moment you are asking for trust. The frame that works is predictability, which is what both sides actually want out of a long program. Before proposing anything, ask the question: in their experience, do stalled design-ins stall on physics or on funding? If the answer is funding, you have permission and they have effectively asked you for this. If the answer is physics, do not raise it, and go and solve the physics.

The failure modes are worth naming. Do not put this in the first conversation. Do not use it as a substitute for discovery, because it is a qualification instrument and not a qualification shortcut. And do not let finance attach a target to it, because the moment the fee has a number to hit, the people collecting it stop reading what its absence tells them.

The argument against. The real argument against it is competitive. In a market where a rival will do the same work for nothing, asking for a fee can lose you the evaluation outright, and in an early-stage company fighting for its first reference customer that may be the correct trade. The answer is not to abandon the principle but to move the line: make the free tier genuinely generous and make the paid tier genuinely different, with a co-signed report, a committed turnaround and a named engineer against it. What you cannot do is charge for what everybody else gives away and call it commercial discipline.

September 5, 2026
A part loses to a method

The dangerous competitor to a hardware component is rarely a better component. It is a competitor whose approach lives inside the customer’s design flow.

If you sell a physical component into somebody else’s platform, the competitor who takes your position is unlikely to arrive with better specifications. They are more likely to arrive with a method.

A method is an approach embedded in the customer’s own design process. A tool, a model, an intake procedure, a workflow that converts the customer’s requirement into a manufacturable answer. The defining property is timing: a method is present while the customer is designing, and a part is quoted after the customer has designed. By the time you are asked for a price, a method vendor has already shaped the geometry that price has to fit.

That is a structural advantage, not a marketing one. It owns the modelling gate by construction. It also generates switching cost out of familiarity rather than out of contracts, which is the cheapest kind to build and the hardest to attack. Nobody has to sign anything for a method to become the default; an engineering team simply learns to think in it.

The purest example is electronic design automation. No chip gets designed because one tool is marginally better in isolation. The tools became the flow, the flow became the industry’s shared vehicle for describing a design, and the companies who own the flow have a seat in every decision anybody makes about what goes on a die. The same logic is now visible in facility and thermal design, where computational fluid dynamics and digital-twin platforms have been moving from where thermal decisions get checked to where they get made. When your customer’s design review runs inside somebody else’s model, that somebody is present at every decision you are trying to influence and you are not.

Here is the part that should be uncomfortable for most component vendors: you already do the method work. Your applications engineers take a power map, build a model, produce a recommendation and walk the customer through it. That is the method. And it is given away invisibly, funded out of a sales budget, with no defined intake format, no committed turnaround, no name the customer can use to ask for it again, no deliverable the customer’s own engineer can cite in an internal design review, and no continuity when the engineer who did it gets pulled onto a different deal. All of the cost, none of the position.

The counter does not require building a software product, which is fortunate, because most companies in this market should not try. It requires naming and resourcing the co-design process as something that exists. A defined intake, so the customer knows exactly what to send and in what form. A committed turnaround, stated in days. And an interrogable report: a document the customer’s thermal architect can defend in their own design review without you in the room, which is a much higher bar than a slide deck and the only version that creates a position. Give it a name so it can be requested by name. Put it on the price list even while the early stages are free.

There is a second-order benefit that is arguably larger than the competitive one. The real constraint on most component vendors’ design-in motion is not relationships and not product. It is engineering bandwidth and intake latency. If a test vehicle takes eight weeks to get resourced, no amount of architecture access helps, because every conversation that goes well dies waiting. Productizing the method forces the intake path to be staffed, scheduled and measured. Described as sales support, that work never gets funded. Described as a product with a committed turnaround, it does.

Owning the method also changes the pricing conversation, which is the part most sales organizations would notice first. A part is priced against other parts, and the customer’s job in that negotiation is to make the parts look interchangeable. A method changes the denominator. If your co-design work is what determines whether a package holds its clock under sustained load, the relevant comparison is not your unit price against a competitor’s unit price, it is what a percentage point of sustained performance is worth across the life of the program. That is not a rhetorical trick, it is the actual arithmetic, and it is only available to a vendor who was present while the design was being made. A vendor who arrives at the quote stage has already lost access to that argument regardless of how good the argument is.

The test is easy and slightly humbling. Ask the engineers at your best customer what your company is called in their internal documents. If the answer is a part number, you sell a part. If the answer is a process they run, you sell a method.

The argument against. Methods are slower and more expensive to build than product improvements, and they can lock you out. In an account that has already standardized on somebody else’s flow, arriving with a competing method is asking the customer to change how they work in order to evaluate you, which is a worse proposition than arriving with a part. In those accounts you sell the part, and you win by being the easiest thing in the world to drop into the flow that already exists. Interoperability is the specialist’s version of a method, and it is often the better bet for a company without the engineering headcount to build the other kind.

August 31, 2026
Thermal’s next problem is uniformity, not capacity

Almost all thermal marketing is a capacity argument. As packages become mixed assemblies of logic, memory and optics, the binding requirement becomes the spread rather than the total.

Read any cooling company’s material and you are reading a capacity argument. Watts removed. Thermal resistance in degrees per watt. Heat transfer coefficient. Kilowatts per rack. Capacity is real and it will keep mattering. But the requirement that decides designs is changing shape, and the vocabulary has not caught up.

The change is in the package. An accelerator package used to be a die. It is now an assembly: logic, stacked high-bandwidth memory, increasingly optical engines, all on one substrate, and those parts do not share a temperature tolerance. High-bandwidth memory has a meaningfully tighter ceiling than logic and sits immediately beside it. Photonic devices are more sensitive again, in a different way. Wavelength and coupling efficiency drift with temperature in ways that logic simply does not, so a photonic engine does not merely run slower when it gets warm, it runs wrong.

Co-packaged optics is the forcing event. Moving optics off the faceplate and onto the package takes a component that used to sit in a pluggable module with its own thermal environment and places it next to a kilowatt-class switch die. Broadcom’s Tomahawk 6 at 102.4 terabits per second, and the Davisson co-packaged variant using TSMC’s optical engines, are the public reference points for where this is heading. Whatever else co-packaged optics does to the network, it creates a thermal requirement that did not previously exist: hold a narrow band across parts with very different tolerances, on the same substrate, at the same moment, under a load that moves.

That is a distribution problem. It is not a bigger version of the capacity problem, and a solution optimized for the total can be the wrong solution for the spread.

Which reframes the competitive question in a way that is genuinely open rather than settled. Every cooling architecture has a claim to uniformity, and the claims are different in kind. Impinging-jet approaches argue spatial addressability: an array can be tuned to the package’s actual power map, targeting the hot regions die by die, because the cooling structure is a designed part rather than a uniform surface. Two-phase approaches argue that boiling holds saturation temperature through the phase change, so the plate stays closer to isothermal, where single-phase water rises roughly ten to fifteen degrees between inlet and outlet and the chips at the outlet end simply run hotter. Microfluidic approaches argue that the channel topology itself can be shaped to the thermal map, and that getting the cooling structure into the silicon removes another conduction layer entirely. These are engineering trades with different costs attached, not a ranking with a winner.

The honest state of the field is that uniformity claims are mostly unmeasured in the way that would settle anything. A capacity number is cheap to publish and easy to compare. A spatial temperature distribution under a realistically non-uniform load, with the memory stack instrumented separately from the logic and the optical engine instrumented separately again, is expensive to produce and rarely shown. Anybody advancing this argument commercially needs their own test data behind it and should present it as a hypothesis until they do. The caveats also differ by architecture and a serious buyer will ask about them: critical heat flux margin and vapour quality control for two-phase, pressure drop through small orifices at the customer’s actual operating point for jets, schedule irreversibility and yield exposure for anything etched into silicon.

There is a second dimension to this that gets even less attention, which is uniformity in time rather than in space. AI workloads do not present a steady load. Power swings hard and fast as work moves through a cluster, and a thermal solution with a large temperature excursion under a transient produces junction temperature variance, and junction temperature variance produces throttling events, and throttling events produce exactly the thing an operator is measuring, which is sustained performance rather than peak performance. A cooling architecture that damps transients well is making a performance argument, not a thermal one, and performance arguments are bought by a different person with a larger budget.

It also pushes the question down a layer, into materials and interfaces. If the requirement is a narrow spread across a mixed package, then the thermal interface between die and cooling structure, the substrate, and the mechanical loading across an uneven assembly all become part of the answer rather than assumed constants. Companies that sell interface materials and mechanical components have historically sold into the sourcing layer as commodities. The uniformity requirement is the first thing in years that gives them a reason to be in an architecture conversation, and most of them have no route into one.

For anyone selling into this, the practical change is to stop leading with the total. Three questions get you further than any capacity claim. What are the per-die temperature ceilings on this package? Which part in the assembly has the tightest tolerance? Has anyone measured the spread across the package under a non-uniform load, or only the maximum? Those questions are hard to answer from marketing material, which means they get routed to an engineer, and an engineer answering them produces a power map. A power map is the second gate of any design-in, and it is not obtainable by asking for it.

The argument against. The counterweight is substantial and should be stated plainly. Capacity is still the binding constraint for the overwhelming majority of deployments today. Single-phase direct-to-chip holds roughly fifty-five percent of the direct-to-chip market in 2026, and credible voices in the industry argue it will remain the default for years on cost, serviceability, supply maturity and roadmap alignment, with real engineering effort going into stretching microchannel designs further up the power curve. Uniformity is the argument for the package layer and for the generation after this one. It is not a reason to tell a customer that the architecture they are shipping is wrong, and a seller who uses it that way will be correctly heard as someone who has read a roadmap and not a requirement.

August 26, 2026
The barbell

Value is accruing to vertically integrated players and to open-standard specialists. Everything in between is getting compressed, and it is remarkably easy to end up there by accident.

Download the paper (PDF) Download the infographic

There are two places to stand in AI infrastructure right now, and a large uncomfortable space between them.

At one end is vertical integration. Own the silicon, the system, the interconnect and the software, publish the reference architecture, and you capture the whole margin stack. You also capture something more valuable than margin, which is the authority to decide which suppliers exist. When you set the envelope, every other company in the value chain is designing to your document.

At the other end is the open-standard specialist. You are the best available answer to one physics problem, you are trivially integrable into anybody’s design, and you win by being specified rather than by being sold. Your moat is not scale or relationships. It is that replacing you means accepting a worse answer to a problem the customer cannot avoid.

The middle is where most companies actually are: competent, broad-line, differentiated by coverage and relationships rather than by architecture. It gets compressed from above by integrators who set the specification and from below by specialists who own a physics problem. The symptoms are recognizable long before anyone names the cause. Average selling prices flat or declining while volume grows. More bids, longer bids, more of them won on price. A roadmap that has become a list of customer requests. Engineering capacity consumed by variants rather than by advancing a position.

The cooling market ran this pattern in public over about three years. Nearly every independent direct-liquid-cooling specialist of consequence was acquired, and it is worth reading that two ways at once. The specialists had built positions defensible enough to be worth buying, which is the specialist end working. And the acquirers were broad-line industrials paying large multiples to get out of the middle, which is the middle end failing. Both halves of the barbell were visible in the same transaction.

The same structure shows up on the demand side. A hyperscaler designing its own accelerators, its own racks and its own cooling is vertical integration. A neocloud betting the company on one workload profile is a specialist. A regional colocation operator with a general-purpose story, a diversified tenant base and no structural advantage in power or thermal is in the middle, and is currently discovering what that costs when tenants with gigawatt appetites start asking questions about interconnect queues.

What makes the middle dangerous is that you get there through a sequence of individually defensible decisions. Add a product line adjacent to the core, because the customer asked and the engineering is mostly done. Take the high-volume commodity business, because the factory has capacity and the contribution is positive. Hire more coverage rather than resourcing a co-design capability, because coverage shows up in the forecast this quarter and capability shows up in eighteen months. None of those is a mistake in isolation. Taken together over four years they are a strategy, and it is the one nobody chose.

Picking an end costs something real, which is why so few companies do it. Vertical integration requires capital and the willingness to compete with your own customers. Specialization requires refusing revenue, which is much harder than it sounds in a board meeting: turning down adjacent business that would dilute the one thing you are best at, and accepting a smaller addressable market in exchange for pricing power inside it. A company that says it is a specialist while accepting every order that arrives is in the middle.

The test I would apply is a single sentence. Can you name the one physics problem you are the best available answer to, without using the words solutions, platform, or end-to-end? If not, you are in the middle, whatever the strategy document says. And if you can, the follow-up is whether your compensation plan, your engineering roadmap and your hiring pattern all point at that one problem, or at the broad middle your revenue currently comes from.

Moving from the middle toward the specialist end is a two-year operational exercise and it does not start with positioning. It starts with the engineering roadmap, because the only credible specialist claim is a measured one, which means funding the test data that proves your advantage on the specific problem you have chosen and declining the variant requests that would consume the same engineers. Then the target list narrows, usually by more than anyone is comfortable with: a specialist sells into the layer where its problem is decided, which is frequently a shorter list of accounts than the sales organization currently carries. Then compensation has to stop rewarding the revenue you are trying to exit. Companies routinely do the first step and none of the others, which produces a technically excellent company with a sales force still selling breadth.

The investor read of all this is worth knowing if you ever intend to raise or be acquired. Acquirers in this market are not paying for revenue multiples, they are paying for position at the constraint, which is why specialists with modest revenue have been bought at prices that look absurd against their income statements and why broad-line businesses with more revenue have not. If your plan is to be acquired, the asset you are building is a defensible answer to a named problem, and diversifying revenue to look safer actively reduces what you are worth.

The argument against. Barbells are not permanent, and the middle is not worthless. Scale, service coverage, supply reliability and financial durability all live there, and in a supply-constrained year those are worth a great deal of money. A specialist with superior physics, one factory and no second source will lose to an adequate incumbent who can actually ship and can pass a supplier audit. The barbell describes where margin is accruing, not where revenue is. A company can be profitably in the middle for a long time. What it cannot do is be in the middle and also expect the pricing power that belongs to the ends.

August 21, 2026
The reference design is the first gate now, not the OEM

Component sellers still organize around server OEMs, because that is where the purchase order comes from. The decision moved upstream and most commercial teams have not followed it.

Ask a thermal, power or interconnect company where its opportunities live and you will get a list of server OEMs. That is not irrational. The purchase order does eventually come from an OEM or a rack integrator. But the decision that determines whether you can win has usually been made a layer above, in a document published by a silicon vendor, months before anyone in sourcing has heard your name.

What changed is that silicon vendors stopped shipping chips and started publishing rack-scale architectures. When a vendor releases a rack-scale reference design, it is not a product announcement. It is a specification of the thermal, mechanical, electrical and serviceability envelopes that every OEM and ODM building that platform will design inside. Heat removal per rack, coolant flow rate, connector and quick-disconnect approach, tray geometry, busbar cooling, service access. By the time an OEM is collecting quotes, the architectural questions have been closed for two quarters and the remaining conversation is about price and lead time.

The two models in the market are not equivalent, and confusing them costs new entrants a year. Some vendors maintain a recommended or approved vendor list for their rack-scale platforms. Getting onto that list is a qualification campaign run against the silicon vendor, not a sales campaign run against the OEM, and it is typically a year of validation work before a quote is even possible. Others publish an open specification. AMD’s Helios is the current reference case: built on the Open Compute Project’s Open Rack Wide with DC-MHS, UALink and UEC, seventy-two accelerators per rack across eighteen compute trays, on the order of 245 kW of heat removal at roughly 385 litres per minute, blind-mate quick disconnects, liquid cooling carried through the busbar. HPE came in as first major OEM partner and Schneider announced a validated Helios reference design in July 2026.

The commercial significance of that difference is hard to overstate. An open specification with no closed thermal vendor list attached is the one rack-scale architecture where the thermal decision is genuinely contestable on merit. A closed list is a gate you queue for. If you are a specialist with better physics and no incumbency, the open architecture is where twelve months of effort can actually change an outcome, and the closed one is where twelve months of effort buys you the right to compete later.

Timing is the second thing most plans get wrong. OEMs begin thermal design on a platform roughly twelve to eighteen months before it launches, which means the decisions for platforms shipping in 2028 are being made right now. When someone in this business says a sales cycle is twelve to eighteen months, that is not a hedge or a pessimistic forecast. It is the length of the design cycle, and a pipeline built on shorter assumptions is a pipeline that will be rebuilt from zero every two quarters.

The third thing, and the one that quietly consumes the most time, is geography. Architecture, mechanical execution and supplier qualification frequently sit in three different places, and often on different continents. A platform’s thermal architecture may be set in Texas while the mechanical execution and thermal qualification sit in Taipei, with the supplier audit run by a group that reports somewhere else again. By 2024, something like two-thirds of global AI server design contracts sat with Taipei ODMs. A warm relationship with a US-based OEM account team is not access to the people who lock a thermal envelope, and discovering that after eight months of pleasant meetings is one of the most common ways a design-in effort fails.

There is a diagnostic for all of this that takes an afternoon. Go through every active opportunity and record one field: was it entered at the architecture layer or the sourcing layer? If sourcing dominates, you are not losing on price. You are arriving after the decision, and the loss is being recorded in your own CRM as a price loss, which is precisely why it never gets fixed. Price losses get escalated to finance. Timing losses would get escalated to whoever owns coverage, if anyone ever labelled them correctly.

Buying access at the architecture layer requires the only currency that works there, which is a testable answer to a problem the customer has already written down. A model of their package. A test vehicle report. Published data. A paper in the right technical program. Architects will give time to someone who might reduce their risk, and they will give none at all to someone who wants to introduce a product. Enthusiasm, relationships and executive sponsorship are all useful later, and they buy nothing at this gate.

The argument against. None of which means the sourcing layer is the wrong door. For a mature product line with real volume, the OEM sourcing organization is exactly the right buyer, and a company that treats every opportunity as an architecture campaign will starve a business that needs revenue this year. The distinction worth holding is whether you are selling into a platform decision or a component decision. They sit at different layers, they are made by different people, and they are frequently funded out of different budgets. The mistake is not choosing one. It is running both through the same motion and wondering why the forecast keeps missing.

August 16, 2026
The binding constraint moves every fifteen years, and margin follows it

Whoever solves the scarce resource holds the pricing power. The scarce resource keeps changing, and commercial organizations are slow to follow it.

A data center is a machine for turning a constrained resource into computation. The interesting question in any given decade is which resource is actually constrained, because that is where the profit pool sits. And the answer has changed roughly every fifteen years for as long as there have been data centers.

In the mainframe era the constraint was physical: conditioned floor space, raised floor, machine-room real estate, and the enormous capital cost of the box that sat on it. Through the eighties and nineties it became processor performance, and the margin moved to whoever could put more instructions per second in front of a customer. In the 2000s it became bandwidth and interconnect. That is the era I came up in, and it is worth remembering how completely it dominated the conversation: dense wavelength division multiplexing and intelligent optical switching existed because moving data between places was the wall everything else hit. Then virtualization and utilization had their turn. Now the constraint is power and heat, and it is not close.

Each of those transitions relocated the profit pool, and the companies with pricing power in one era rarely held it in the next. Not because they got worse at what they did. Because the constraint moved out from under a commercial organization that had been carefully optimized for the previous one. Sales coverage, partner programs, engineering investment and compensation plans all get built around the thing that was scarce when they were designed, and they are the slowest part of a company to change.

The clearest evidence that the current constraint is thermal and electrical is not a market forecast. It is what large, diversified industrials have been willing to pay. Eaton acquired Boyd’s thermal business in a deal valued around $9.5 billion, closing in March 2026. Ecolab acquired CoolIT for roughly $4.75 billion. Schneider took Motivair, Trane took LiquidStack, Daikin took Chilldyne, Flex took JetCool. Inside about three years, nearly every independent direct-liquid-cooling specialist of any consequence was bought. Nobody pays those multiples for a component line. They pay them for a position at the constraint, and they pay them when they have concluded the position will not be available later.

Market sizing corroborates without proving. Dell’Oro has the data center liquid cooling market reaching roughly $7 billion in manufacturer revenue by 2029, from something on the order of $2 billion as of early 2026. A market on that trajectory, with no vendor holding a commanding position in it, is a market where position is still purchasable, which is exactly the condition that produces an acquisition wave.

The more useful question is where the constraint goes next, and the direction is consistent: down the stack, toward the package. It has already moved from the room to the row to the rack, and it is now moving from the rack to the board and from the board to the package and the die. Each step down shortens the list of people who can solve it and raises what solving it is worth. It also changes who the buyer is. Room-level problems are bought by facilities and operations. Package-level problems are decided by thermal and package architects, eighteen months before anyone issues a purchase order, and they are not reachable through the channels that worked at the room level.

That gives any company in this market three questions worth asking at every planning cycle, and they are more uncomfortable than they look.

Which layer of the stack are you selling into, and is it where the constraint will be in twenty-four months? Plenty of companies are selling competently into the layer where the constraint used to be, and reporting the resulting margin compression as a pricing problem.

Is your differentiation a property of the current constraint or the previous one? Broad coverage, service footprint and integration breadth were decisive when the problem was the room. They are much less decisive when the problem is a temperature gradient across a substrate.

And who has pricing power in your value chain today? If the answer is the layer above you, you are a supplier to the constraint rather than the holder of it, and no amount of sales effort changes that. Changing it requires owning a different problem.

The argument against. The obvious counter is that constraints get relieved rather than relocated. If eight-hundred-volt DC distribution, better microchannel cold plate design and warm-water operation together buy the industry another five years of headroom at the rack level, then the thermal window stays open longer and the shift to the package slips. That is a real possibility and anyone selling on an inflection should hold an explicit view on what would delay it. The honest version of this thesis is not that the package layer is inevitable next year. It is that the constraint is moving, the direction is legible, and a commercial organization built for the last position will be late to the next one whether it arrives in 2028 or 2033.

The version of this idea that is worth anything is not a slide with four eras on it. It is the habit of asking, every planning cycle, whether the thing you are best at is still the thing your customers cannot get enough of.

August 11, 2026