.png)
SECTOR VOCABULARY · TRANSLATION & FLUENCY
SPEAKING THE UTILITY'S LANGUAGE, SPEAKING THE DEVELOPER'S LANGUAGE
By David Swank, CEO, i3 Power & Energy
The utility sector and the developer sector are trying to work together more than ever, and they are still speaking past each other more than they should be. Not because either party is being difficult. Because the two sectors have developed distinct vocabularies over decades, and those vocabularies encode assumptions about time, risk, and value that are not fully transferable across the boundary. Bridging the gap requires more than glossaries. It requires actual fluency in both institutional contexts, and the judgment to know when a word means the same thing in both languages and when it does not.
This is one of the least discussed reasons that projects stall. Not because of substantive disagreement between the parties. Because the parties think they have agreed when they have actually agreed to different things, or they think they are disagreeing when they are actually saying compatible things in different terms. The vocabulary gap is quiet, it is pervasive, and it costs the industry more time and money than most participants realize.
THE WORDS THAT MEAN DIFFERENT THINGS
Consider a handful of words that come up in almost every project meeting. Capacity, to a utility planner, is a planning concept anchored in resource adequacy and long-term system needs. Capacity, to a developer, is closer to an accounting concept anchored in contracted megawatts and financial modeling. Reliability, to a utility, is a public obligation defined by regulatory standards and public expectation. Reliability, to a developer, is a performance metric defined by SLAs and customer contracts. Flexibility, to a utility, is a system property that shapes planning and operations. Flexibility, to a developer, is an operating strategy that shapes contracts and revenue. Bankability, to a developer, is a financial threshold the project either clears or does not. Bankability, to a utility, is often an unfamiliar test that describes something the utility does not directly experience.
These are not translation errors. They are legitimate uses of the same word inside two institutional contexts that shaped its meaning differently. Both parties are correct about what the word means in their world. Neither is wrong. What is missing is the acknowledgment that the same word is doing different work on the two sides of the table.
.png)
.png)
The Utility Side of the Vocabulary Gap
RB Sloan and I sat in that seat, and I want to be honest about something the developer community sometimes misreads. Utility vocabulary is not resistant to change. It is optimized for a different problem than the developer is solving. Utility executives are responsible for maintaining service to millions of customers over decades, under regulatory obligation, with cost recovery that depends on public commissions. The vocabulary reflects those responsibilities. When a developer walks into a utility meeting speaking a language that assumes short horizons, private contracts, and financial returns as the primary framing, the utility is not being obstructive when they respond in their own terms. They are trying to do their job.
Understanding this is different from being sympathetic to it. Understanding it is a prerequisite for actually working with the utility. Sympathy is optional. Understanding is not.
“Fluency across sectors is not about speaking two languages. It is about knowing which sentences translate cleanly and which ones need to be reconstructed from scratch.”
What Real Translation Looks Like
The kind of translation that makes projects go faster is not achieved by sending memos across the boundary. It is not achieved by hiring liaisons who report back to their home sector with translation notes. It is achieved by building teams that are genuinely native in both contexts, and by producing analysis, deliverables, and conversations in both vocabularies simultaneously.
This means a project team that can present the same integrated resource plan in utility planning terms and in developer financial terms without having to run two separate analyses. It means a contracting approach where utility standards and developer standards are considered together, not sequentially. It means individual people around the table who have spent enough time in both worlds to know when a sentence will land clearly and when it will not.
.png)
.png)
Why This Matters for Every Project
Every negotiation touches vocabulary. Every contractual term relies on shared understanding of what the words in the contract actually mean. Every project meeting proceeds on the assumption that the participants are talking about the same thing. When they are not, the misunderstanding compounds through the project timeline. Small vocabulary gaps become large operational gaps. Assumptions that were never really shared become disputes that neither party
saw coming.
Firms that operate fluently in both vocabularies compress schedules that halting firms cannot. Not because they are working harder. Because they are not spending time re-explaining decisions that were misunderstood in the first meeting. The translation capability is itself a competitive advantage, and the firms that have built it into their teams tend to close projects faster and operate them more smoothly.
Fluency as Infrastructure
The vocabulary gap between utility and developer worlds is real, and it is not going to close by itself. What closes it is the accumulation of firms and individuals who have genuinely operated in both. That kind of fluency is rare, and it is expensive to develop. It is also structurally decisive over the next decade, because every meaningful project is going to require both languages spoken at the same table by the same people. At i3, that fluency is why the framework works, and it is why projects close on the terms they close on. Language is not the whole story. But it is the part of the story that either enables everything else or quietly prevents it.
.png)