The Best Technology Advisors Start by Listening

Enterprise customers are not short on information. They have decks, benchmark charts, reference architectures, roadmaps under NDA, and more product briefings than anyone can absorb. What they are short on is someone willing to understand the problem before recommending a platform.

I have spent 25+ years in enterprise technology, including 25 years at Citi. Most of that time I have been the customer. I have also built and sold technology services through my own businesses, which means I have sat on both sides of the table — sometimes in the same week. That combination taught me something that took years to say plainly:

The first question shouldn't be "What can I sell you?" It should be "What can we do to help you?"

That sounds soft. It isn't. It is the most technically demanding question in the conversation, because you cannot answer it without understanding the workload, the constraints, the operating model, and the person whose name is on the outcome.

Twenty-five years in the customer's chair

Sitting on the buying side of enterprise infrastructure decisions teaches you things no vendor training covers.

A technically impressive product can still be operationally wrong. The fastest platform in the benchmark can be the one your team cannot staff, patch, or recover at 3 a.m.

The lowest acquisition price is frequently not the lowest lifecycle cost. Power, cooling, floor space, licensing, migration effort, and the skills you do not yet have all arrive later, whether or not anyone modeled them.

A proof of concept is not production. A PoC runs on curated data, with the vendor's best engineer in the room, on a system nobody else is using. Production is where budgets go to die.

A vendor roadmap is not a customer strategy. Roadmaps describe what a company intends to build. They say nothing about whether you should reorganize your architecture around that intention.

None of this makes vendors adversaries — I have worked with outstanding ones. It makes the point that the workload, the operating model, and the risk profile have to drive the decision, and only the customer can fully describe those.

What I learned from hundreds of vendor presentations

I have sat through more enterprise technology presentations than I can count. Most of them blur together. A handful I still remember years later, and the difference had nothing to do with the product.

The forgettable ones followed a pattern. The team arrived with a fixed deck and worked through it regardless of what happened in the room. Someone would raise a real constraint — a data residency requirement, an existing platform commitment, a team that was already stretched — and the response was a slide. The presentation was the point. We were the audience.

The memorable ones did something different, and it usually happened in the first ten minutes. They stopped presenting.

One session in particular has stayed with me. The team had prepared the standard material. Early on, we described what we were actually trying to accomplish and where the operational pressure was coming from. The lead stopped, closed the laptop, and spent most of the remaining hour asking questions. Not qualifying questions designed to steer us toward a product. Real ones. How did the workload behave at peak? Who owned the recovery path? What had we already tried, and why had it not worked?

They did not propose anything that day. They came back later with something narrower and less expensive than what they had originally planned to pitch, because by then they understood the problem well enough to know the bigger option was wrong. That is the meeting I remembered when the next project came around.

Here is what separated those sessions: the memorable teams were willing to be less impressive in the first meeting in order to be more useful in the third. They treated the discovery conversation as the work rather than as the obstacle standing between them and their demo.

Listening is not passive

We talk about listening as though it were the absence of activity. In a technical sale it is the opposite, and it is the hardest part of the job.

Real listening here means asking better questions and being genuinely willing to hear an answer that invalidates your assumption. It means noticing what has not been said — the platform nobody mentions, the team that was not invited, the deadline that keeps moving. It means clarifying competing priorities, because security, the application owners, and finance frequently want three different things and have not yet said so out loud in the same room.

It means understanding who actually owns the outcome. Not who called the meeting. Who is accountable when it does not work.

And it means confirming the problem before discussing products, which takes the discipline to sit in ambiguity longer than is comfortable when you already have a solution you believe in.

Done well, that is a technical skill and a commercial one at once. It shortens cycles, prevents rework, and produces recommendations that survive contact with production.

Get the workload right before the gear

Enterprise AI infrastructure is where this matters most right now, because the decisions are large, fast, and expensive to reverse.

Customers are being asked to commit on CPU and GPU platforms, accelerators, memory, networking, storage, power density, cooling, on-premises capacity, public cloud, hybrid operating models, framework compatibility, workload placement, and governance — often at once, and often before the workload itself is well understood.

The question I hear most often is "Which vendor has the best AI server?" It is the wrong first question. More useful ones:

What workload are we actually running? Training, fine-tuning, inference, retrieval, analytics, and simulation have genuinely different profiles.
What are the data, latency, security, power, cooling, and resiliency requirements?
How quickly might this workload change? What happens to a three-year commitment if the model architecture shifts in eighteen months?
What should be tested before a capital commitment, and what does a credible test actually look like?
What can be consumed as a service instead of owned?
Where is flexibility worth more than ownership?

Answer those and the platform conversation gets much easier, because the requirements do most of the selecting. Skip them and you are buying hardware to fit a presentation.

Knowing whom to call is the job

There is a persistent and damaging idea that a senior technical advisor should personally be the deepest expert on every processor, accelerator, fabric, storage platform, framework, and application in the room.

Nobody is. The people who pretend to be are the ones who create the most expensive mistakes, because their confidence outruns their knowledge in exactly the areas where the customer cannot check their work.

Executive technical leadership is not about knowing everything. It is about knowing the shape of the problem well enough to recognize which expertise it requires, and then assembling that expertise quickly.

In practice that means having enough depth to ask a silicon specialist a question that is actually useful, and enough humility to say "I don't know — let me bring in the person who does." It means knowing when a question belongs with an Intel, AMD, or NVIDIA specialist, when it belongs with Dell, HPE, Lenovo, or Cisco, when it belongs with a cloud or security architect, and when it belongs with the customer's own application team, who often understand the workload better than anyone selling to them.

I serve as an active contributing member of the Dell, HPE, Lenovo, and Cisco technology advisory councils, and I engage across the Intel, AMD, and NVIDIA ecosystems. The value of those relationships is not that they make me an expert in everyone's silicon. It is that I know who to call, I can translate between what a specialist says and what an executive needs to decide, and I stay accountable for the outcome after the specialist leaves the room.

That is ecosystem leadership, and it is a strength rather than a gap. The advisor's responsibility is to own the customer's outcome — not to be the smartest individual contributor in the meeting.

What selling services taught me

Building and selling technology services through my own businesses changed how I understood the buying side, because for the first time I was accountable for delivering what I had described.

Customers are not primarily buying technical labor. They are buying confidence and accountability — the belief that someone will still be engaged when the work turns out harder than the proposal implied.

Trust gets built before the contract and tested after it. Everything pleasant happens in the first meeting. The relationship is determined by what happens during the first problem.

Listening poorly is expensive in a way that surfaces later. Every requirement I misread became rework, a missed expectation, or a difficult conversation I had earned. Long-term relationships come from solving the correct problem, which you cannot do while composing your recommendation as the customer is still describing the situation.

That is still how I work. MoeCloud is my current proof that I have not stopped building — an AI-native operations platform I architected, built, and govern, where I hit these lessons on my own systems rather than only observing them on someone else's.

What the research reinforces

This is not only a matter of temperament. It shows up in the research on complex sales.

A 2019 meta-analysis in the Journal of Business Research by Itani, Goad, and Jaramillo synthesized roughly two decades of studies on salesperson listening. It found listening associated with both relationship quality and sales performance through direct and indirect paths — notably as an antecedent of adaptive selling, the ability to adjust your approach to what the customer actually needs. (Itani, Goad & Jaramillo, 2019, vol. 102, pp. 120–130)

Neil Rackham reached a related conclusion decades earlier by observation rather than theory. His research at Huthwaite analyzed more than 35,000 sales calls and produced the SPIN framework — situation, problem, implication, and need-payoff questions. A central finding: techniques that work in small transactional sales are actively counterproductive in complex ones, where the real work is understanding the problem deeply enough that its implications become clear to the customer. (Huthwaite International)

And for anyone weighing whether being useful in public is worth the effort — in the 2024 Edelman–LinkedIn B2B Thought Leadership Impact Report, 75% of decision-makers said a piece of thought leadership had led them to research a product or service they were not previously considering. (LinkedIn and Edelman, 2024) Being helpful before there is a transaction is not a detour from the commercial path. It frequently is the path.

The advisor mindset

The work I find most interesting connects things that usually sit apart: business strategy, technical architecture, customer reality, partner capability, governance, and long-term trust. Most organizations have people strong in one or two of those. Fewer have someone who can sit with an executive on Monday and a hardware specialist on Tuesday and represent each accurately to the other.

That translation is where advice becomes valuable. An executive does not need the memory bandwidth specification; they need to know whether this decision constrains their options in two years, what it costs to be wrong, and who owns it if it is. A specialist does not need the business narrative; they need a precise question.

Holding both, and staying accountable across both, is the discipline. It is also why the first question matters so much. "What can we do to help you?" is not a courtesy. It determines whether everything after it is useful.

The part that doesn't change

Technology will keep moving. The accelerators, models, frameworks, and architectures that feel decisive right now will look ordinary soon enough, and some of the platforms currently being defended in meetings will not survive the decade.

What does not change is the thing underneath. Trust is built by people who take the time to understand a problem before recommending a solution, who are honest about what they do not know, who bring in the right expertise instead of improvising, and who are still there after the invoice clears.

I have been the customer long enough to know how rare that is, and how quickly you recognize it when it shows up. The advisors I still call years later are not the ones who had the best product. They are the ones who asked better questions than I did, told me when I was solving the wrong problem, and were willing to recommend less than they could have sold.

That is the standard worth holding. Listen first. Understand the workload. Assemble the right people. Solve the correct problem. The technology recommendation is the last step, not the first — and it is worth far more when it arrives that way.

If you're working through enterprise AI infrastructure, workload placement, or technology strategy — or you just want to compare notes on what actually survives production — I'm always up for the conversation.

Connect with me: mosesacosta.ai · moecloudgroup.com · LinkedIn · moses@mosesacosta.ai

Author: Moses Acosta is Senior Vice President, Global Next Generation Technology Engineering at Citi, where he has worked since March 2001. He has 25+ years in enterprise technology, is an active contributing member of the Dell, HPE, Lenovo, and Cisco technology advisory councils, and builds MoeCloud as an AI-native operations platform with governance at its core.