Greg Neiheisel and the Pivot Beneath the Product

The useful thing about a bad onboarding problem is that it has no respect for the product roadmap. In 2014, Greg Neiheisel and a small Cincinnati crew were working on USERcycle, an analytics product meant to explain how people behaved inside applications. There was only one discourteous detail: before the software could analyze customer data, it had to obtain the data. Customers struggled to get it there. Without it, the charts were handsome furniture in an empty house.

Plenty of startups would label that friction, assign it to onboarding, and commission a friendlier progress bar. Neiheisel and his collaborators kept looking. The troublesome step was not merely standing between the user and the product. It was a product in its own right. Companies needed a dependable way to extract, move, organize, and operate on their data. USERcycle's obstruction became Astronomer's opening.

That pivot is the revealing event in Neiheisel's public story. He is not a founder with a grand autobiography arranged around epiphanies. The available record is more engineerly: jobs, systems, diagrams, revisions. It begins with a University of Kentucky degree in Decision Sciences and Information Systems, continues through software roles at Outlyer Technologies and Great American Insurance, and includes an early mobile venture called Trippo. By 2013 he was a partner at Differential, the Cincinnati product studio from which the USERcycle effort gathered people and momentum.

The prototype was allowed to be ugly

The early Astronomer was not born in a tasteful cloud of abstraction. Neiheisel later described its first customer-facing SaaS interface as an “embarrassingly ugly web application.” The team built it with Meteor and MongoDB while taking part in AngelPad's Fall 2015 class. People were scarce. Demo Day was approaching. An inelegant interface that proved events could enter the system and reach useful destinations was more valuable than a beautiful one that arrived after the runway ended.

Behind that interface, the company assembled an event pipeline from Amazon services. API Gateway and Lambda accepted requests. Kinesis buffered the events. Independent services could then archive data or send it toward warehouses and third-party tools. It was a sensible answer for a small team because managed infrastructure removed chores. It was also the start of the next problem.

Enterprise customers wanted software that could run in different environments. A platform assembled too tightly around one provider's managed services could not easily oblige. Neiheisel's response was not to pretend that the first architecture had been foolish. It had been fast, secure, and useful. Then the requirements changed. Good engineering is not the defense of yesterday's diagram; it is the willingness to redraw it before the diagram begins defending itself.

Portability, with a little Mars

The rebuild drew on open-source components including Apache Airflow, Mesos, Docker, and Marathon. Neiheisel explained the decision in two registers. One was practical: Astronomer wanted a system that was secure, highly available, self-healing, efficient, and capable of handling both long-running and one-off work. It also needed to cross infrastructure boundaries. In a small flash of levity, he wrote that an enterprise version should run anywhere, “even Mars.” The joke was interplanetary; the concern was ordinary vendor lock-in.

His second register was almost civic. Open systems invite inspection. A wider community brings more perspectives to the code. Components can be replaced as better ones arrive. Users are not forced to trust a black box simply because a contract says the box is trustworthy. For Neiheisel, open source was simultaneously a development method, a resilience strategy, and a preference about who should retain control.

Airflow gradually became central to Astronomer's answer. Created at Airbnb, the project lets teams define, schedule, and monitor dependency-driven workflows. The concept is easier to picture than the vocabulary suggests. A report cannot run until a table is updated; a model cannot train until the data is prepared; a downstream task should not proceed if an upstream one fails. Airflow makes those dependencies visible and programmable. Astronomer set about making Airflow easier to deploy and operate as critical infrastructure.

A founder still asking systems questions

Neiheisel's public appearances stayed close to the machinery. On a 2018 podcast he discussed Airflow on Kubernetes and planned work on its Kubernetes executor. At Data Council in San Francisco the following year, his slides moved methodically through the burdens that appear after a scheduler becomes important: continuous delivery, thousands of tasks, access control, metrics, logs, authentication, and workers that scale toward zero when idle.

It was not the sort of talk that treats a Kubernetes diagram as decorative modern art. Each box had an operational consequence. How would new workflow code reach a running environment? Where would task logs survive after a short-lived pod disappeared? How would Prometheus discover and scrape metrics? How could an ingress controller and an authentication service protect the web interface? Reliability, in this telling, is a collection of solved small questions rather than one heroic large answer.

By the 2021 Airflow Summit, his title was Founder and Chief Architect. He and fellow founder Ry Walker previewed the next generation of Astronomer's cloud product. More recent directories describe Neiheisel as Founder and Engineering Fellow. The nouns have shifted, but they preserve the same useful ambiguity: he belongs to the company story and to the engineering work inside it.

The social system behind the software

Infrastructure companies are fond of promising scale, a word that can make human beings vanish behind charts. One of the most specific glimpses of Neiheisel comes from the opposite direction. In a public recommendation, former colleague Becky Steele remembered arriving at a small startup as an apprehensive junior engineer. She credited Neiheisel with reducing that fear, handling knowledge transfer with “grace and ease,” and becoming the kind of mentor sought out by people who wanted to build ambitious things.

The recommendation fits his technical writing. He explains decisions in sequence. The rough first version is admitted. Constraints are named. The later rebuild does not erase the usefulness of what came before. This is a generous way to describe engineering because it leaves room for readers, and junior colleagues, to understand that capable systems are not delivered by people who were never confused. They are delivered by people who make confusion legible.

Astronomer would grow far beyond that early crew. In 2022 the company described a founding team that included Neiheisel alongside Ry Walker, Brad Kirn, Viraj Parekh, Paola Peraza Calderon, Pete DeJoy, Ash Berlin-Taylor, and Kaxil Naik. The same account reported that Airflow 2.0 pushed monthly downloads from roughly 600,000 to more than three million. In 2025 Astronomer announced a $93 million Series D, saying Airflow had been used by more than 80,000 organizations and downloaded more than 324 million times during the previous year.

Those are company and community measures, not solo trophies. That distinction suits Neiheisel's part in the story. Open-source infrastructure is a strange place to look for the romance of individual authorship. Its health depends on contributors, operators, critics, maintainers, and users discovering failure modes that no founding team could anticipate. The achievement is not that one engineer controlled the system. It is that the system became useful to people its builders would never meet.

The value of going one layer lower

There is a neat temptation to read the USERcycle pivot backward, as if Astronomer had been obvious all along. It was not. First came an analytics idea. Then came trouble acquiring data. Then an ingestion system. Then a more portable architecture. Then a deeper commitment to Airflow and the difficult work of running it for enterprises. The line looks straight only after somebody has finished drawing it.

Neiheisel's career offers a quieter founder archetype: the person who notices when the annoying prerequisite is more consequential than the feature it was meant to serve. His public record contains no need to inflate the insight. The team had a customer problem. They traced it downward. They found another market beneath the first one.

The modern economy is full of invisible sequences. Data arrives, tasks wait on other tasks, models train, reports refresh, and alerts wake unfortunate humans when any part misbehaves. Orchestration is the art of making those sequences dependable. Greg Neiheisel reached it by following a product that could not get what it needed. The elegant part came later. First, he paid attention to the blockage.