Infrastructure is the part of technology that prefers not to introduce itself. It sits in racks, hums behind walls, routes the call, stores the record and keeps the application available. When it works, nobody sends flowers. When it fails, everyone learns its name. Humayun Sohel has spent his career in this mostly invisible territory, first as an engineer close to the circuitry and later as the president of Questivity, a Santa Clara company that helps organizations choose and deploy the systems beneath their work.
His professional path reads like a tour through successive layers of modern computing. He studied electronics at Osmania University from 1985 to 1989, then earned a master's degree in embedded systems design at Wayne State University between 1990 and 1992. From there came engineering work at NASA Ames Research Center, ROLM, Siemens and Trimble Navigation. These were not social-media products. They belonged to a world where computing met machines, telecommunications, navigation and scientific work - places where an error could not be dismissed with a refresh.
The next chapter moved through optical networking. At Cyras, Sohel worked as a senior firmware engineer on OC192 cards, technology built for high-capacity fiber networks. Ciena followed, then Cisco Systems, where he served as a firmware architect from 2003 until 2009. Firmware is software with nowhere to hide. It lives near the hardware, obeys tight constraints and rewards the engineer who understands not only an individual component but also its consequences for the whole system.
A career measured in layers: component, network, organization, customer.
The engineer becomes the operator
In June 2009, Sohel began leading Questivity as president. Public corporate records also identify him as its chief executive, chief financial officer and a director. The shift from firmware architect to company operator looks dramatic on a business card. In practice, the two roles share a preoccupation: dependencies. A board on a network depends on timing, interfaces and clean handoffs. A technology project depends on budgets, vendors, users and the unglamorous facts of an existing environment.
The products rotate. The obligation to make them work together does not.
Questivity describes itself as an IT infrastructure solutions and services company. Its catalogue runs across servers, enterprise networking, virtualization, cloud, security and unified communications. The brand names are familiar - Dell, HPE, Cisco and Lenovo among them - but the more revealing part is the company's stated method. It studies emerging technologies, performs proofs of concept, creates deployment guidance, explains benefits and pitfalls, and can operate as an extension of a customer's laboratory or engineering team during evaluation.
That language carries the fingerprints of an engineering career. A proof of concept is an argument that has agreed to be tested. It replaces the smoothness of a sales deck with an untidy encounter between a product and the environment expected to run it. For customers navigating large capital purchases or disruptive migrations, this is not procedural fussiness. It is a way to discover the expensive surprise while it is still small.
Consider the distance between an OC192 card and a cloud-migration plan. One is a piece of network equipment built to move enormous quantities of data over optical fiber. The other is a program of organizational change, usually rendered as arrows drifting toward a friendly blue cloud. Yet both are governed by throughput, latency, compatibility, failure modes and cost. One makes the constraints visible on a bench. The other spreads them across contracts, applications and teams. Sohel's career crossed that distance without leaving the underlying questions behind.
It also crossed a change in who holds the screwdriver. In embedded engineering, the maker has direct command of a tightly defined problem. In consulting, control is distributed. A customer owns part of the environment, several vendors own other pieces, and yesterday's decisions arrive with undocumented reasons. Progress depends on patient discovery. The job is as much archaeology as architecture: understand why the present system exists before proposing the future one.
Years as a Cisco firmware architect
Year his published Questivity tenure began
Layers: hardware, network, cloud and operations
A company built around the test
Enterprise IT has a vocabulary problem. Every era produces phrases that sound complete before the work begins: digital transformation, hybrid cloud, hyperconvergence, AI readiness. The phrases are useful shorthand. They can also conceal the difficult middle, where old systems must meet new ones and where a clean architecture diagram meets an actual building, team and budget.
The product categories on Questivity's site tell that history in miniature. Servers remain, now described alongside edge computing and workloads for AI. Virtualization still promises better use of physical resources. Networking connects offices, data centers and cloud environments. Security runs through every layer. None has replaced the others. New technology tends to arrive not as a clean page but as another responsibility placed on the same operating team. The future, in enterprise computing, has a surprising amount of backward compatibility.
Sohel's background is unusually suited to that middle. Embedded-systems work teaches respect for limits. Telecommunications teaches that reliability is a property of the path, not merely the endpoint. Infrastructure consulting adds a human constraint: the technically elegant answer is irrelevant if the customer cannot operate, secure or afford it. The work becomes an exercise in translation, with specifications on one side and consequences on the other.
Questivity's published evaluation method, reduced to its practical loop.
There is also a revealing continuity in Questivity's location. Santa Clara is routinely treated as scenery for software mythology, but it remains a place of chips, networking equipment, data centers and the physical substrate of the internet. Questivity's office on Civic Center Drive sits in a region where the cloud has always had a floor plan. For someone who moved from embedded design to network firmware to enterprise systems, the geography makes sense.
The visibility paradox
Visibility falls as foundational importance rises. A stylized view, not measured data.
The next infrastructure cycle
Today the industry's newest pressure is artificial intelligence, and Questivity's recent public material places AI back on physical ground. Strong AI performance, the company argues, begins with integrated infrastructure and the right hardware. Sohel has also shared programming about AI security, while Questivity publishes on the relationship between compute, networks and secure deployment. The subject is new; the underlying questions are not. What must the system do, what does it depend on, how will it fail, and what evidence should a buyer demand?
AI makes the visibility paradox especially sharp. A user sees an answer appear in seconds. Beneath it may sit accelerators, high-speed storage, carefully designed networks, data pipelines and security controls. The interface encourages wonder; the infrastructure requires accounting. Capacity must be planned, data must be governed and the promise of performance must be reconciled with available equipment. For a leader formed by embedded systems, the fashionable layer does not erase the physical one. It gives the physical one more work.
This is where a vendor-neutral posture, which Questivity says it follows, becomes demanding rather than vague. Neutrality is not indifference among products. It requires criteria strong enough to survive a logo change. What workload is being served? Which dependency is critical? What does acceptable failure look like? How much complexity can the customer's team absorb? The answers are rarely glamorous, but they make comparison possible. A specification becomes useful only after it has been connected to a constraint.
That return to first principles is the useful idea in Sohel's story. Technical depth does not need to become obsolete when an engineer moves into leadership. It can become a filter. It can sharpen the questions asked of vendors, help a team distinguish a feature from an outcome and make uncertainty discussable before it becomes an outage.
In enterprise technology, expertise is not knowing every new noun. It is having a method for the next unfamiliar one.
The career also resists the tidy myth that engineers and executives occupy opposite species. Sohel's route suggests a quieter progression. First, learn how components behave. Then learn how systems interact. Eventually, apply the same attention to companies and customers. The scale changes, but the habit survives: examine the interface, test the claim and look for the downstream consequence.
Infrastructure careers rarely produce a single cinematic invention. Their evidence accumulates differently: systems that stayed available, migrations that did not become emergencies, purchases that survived their first renewal and teams that understood what they had inherited. It is work judged by continuity. The better it goes, the less dramatic the story sounds.
Sohel's story makes that lack of drama interesting. He has worked from the embedded layer outward, through the hardware, the network and the organization making the buying decision. Questivity is the business expression of that route: evaluate before committing, document what matters, and treat a customer's constraints as part of the engineering problem. In a market forever announcing that everything has changed, there is wit in building around what has not.
Continue reading