Built at the
intersection.

Most people introduce themselves with a job title. Engineer. Researcher. Manager. I have held all of those titles, and none of them alone has ever felt complete — because none of them captures the thing that has always driven the work: finding the most interesting problems at the edges of disciplines and building something useful there. Where physics meets biology. Where a research lab's rigour meets a product team's urgency. Where a language barrier hides an engineering opportunity that everyone else missed.

I am, at my core, a builder who thinks like a scientist.

The foundation — engineering and the art of making things

I arrived in Japan at seventeen on a government scholarship, speaking almost no Japanese, enrolled at a technical college in Nara. Within a year I was studying in Japanese. Within five years I had earned an engineering degree in that language. By the time I finished my PhD at SOKENDAI — the Graduate University for Advanced Studies — and a postdoc at Marshall University in West Virginia, every piece of formal education I had ever received had been conducted in Japanese.

That is not a linguistic curiosity. It shaped how I think. Japanese engineering culture has a word — monozukuri — that roughly translates as "the art of making things," but implies something deeper: the patient mastery of fundamentals, the discipline to understand a system completely before changing it, the respect for process as much as outcome. That philosophy became my foundation long before I could have articulated it.

My PhD work was in biosensors and measurement systems at the Institute of Molecular Science in Okazaki. I fabricated supported lipid bilayer biosensors using synchrotron radiation etching, designed microelectrode substrates at nanometre tolerances, and built measurement platforms to study how biological membranes respond to chemical and electrical stimuli. The work lived at the intersection of physics, chemistry, and biology — and that intersection, I came to realise, was exactly where I wanted to spend my career.

That discipline — hypothesis, experiment, measurement, honest failure analysis, iteration — is what I now apply to building engineering teams, AI systems, and product roadmaps. It is not a metaphor. It is the same cognitive process operating at a different scale. Most engineering managers learned to ship software. I learned to build instruments that did not yet exist, in a language that was not my mother tongue, in a country that demanded precision before it rewarded speed.

Innovation under constraint — from GPS trackers to custom neuroscience rigs

One of the most clarifying projects of my early career happened not in a world-class laboratory, but in Bangladesh. Around 2008, working with two of my students, we built a vehicle tracking system at a time when internet infrastructure outside Dhaka was unreliable and expensive. The technically ideal solution — a GPS platform with continuous data connectivity — simply could not work in the real operating environment.

So we designed around the constraint. We built an SMS-based tracking system that functioned wherever cellular text messaging reached, which was almost everywhere, even when mobile data did not. It was not the most sophisticated technology. It was the most effective solution given the actual conditions — and it worked.

I carried that lesson into the next phase of my work, at research institutions in Singapore — A*STAR, Duke-NUS, the National University of Singapore. My role there was unusual: researchers and clinicians needed custom instruments that did not exist commercially. I designed an optogenetic stimulation and ion-channel recording platform for zebrafish neuroscience. I built behavioural assay systems for studying learning and memory circuits in Drosophila. Each project required a different combination of optics, electronics, firmware, software, and biological understanding — often all in the same afternoon.

What I loved about that period was the complete-system thinking it demanded. There was no boundary between the sensing layer and the analysis layer, no handoff between hardware and software teams. One person had to understand all of it. That end-to-end fluency — from the physical world through electronics through software through human insight — is something I have worked hard to preserve in every role since, even as the systems grew larger and the teams grew bigger.

From the laboratory to the platform — building at scale

As cloud platforms matured and healthcare moved digital, I moved with it: remote patient monitoring, mobile health platforms, cloud-native architectures, data pipelines carrying device telemetry across millions of users. The problems changed in scale and in kind. But the instinct was the same — understand the full system, from the data source to the human decision it enables, and build with that end-to-end view in mind.

That path eventually put me in charge of the engineering build‑out for HeartVoice — a digital‑health technology spin‑off inside Omron Healthcare that scaled into a $16M business — inside a 90‑year‑old Japanese manufacturer not historically known for taking those kinds of bets. Leading the team through regulatory clearance, ISO 13485, and commercial launch across Asia‑Pacific was, in many ways, the hardest and most satisfying engineering problem I have worked on. It required the measurement discipline of the research lab, the constraint‑aware thinking of the Bangladesh GPS project, and the cross‑border communication skills that 20 years of Japanese engineering culture had quietly installed.

Artificial intelligence, for me, is not a pivot or a trend to ride. It is the natural next layer of the same work I have always done: building systems that can sense, interpret, and act on information in ways that help people make better decisions. The challenges are familiar. How do you validate that what the system is measuring corresponds to something real? How do you distinguish signal from noise in a domain where the cost of a false positive is a clinical decision? A PhD in physics, it turns out, is unexpectedly useful preparation for that.

Curiosity as a career strategy

The most meaningful part of this journey now is sharing it. My son and I build things together on weekends — circuits, small programs, experiments that neither of us fully understands at the start. I think that is the most honest version of innovation I have found: the willingness to begin something without a guaranteed outcome, because the act of figuring it out is where the actual learning happens.

Every time a new hardware platform appears, I want to test it. Every time an AI framework ships, I run something on it. Every time I see an unsolved problem — in a healthcare workflow, in a data pipeline, in the way a distributed team communicates across cultures and languages — I start thinking about what a better solution might look like.

I have come to think of curiosity not as a personality trait but as a professional method. You stay curious deliberately. You protect time to build things that are not on the roadmap. You hire people who bring questions you cannot yet answer. You treat a failed POC as data, not as failure.

My career has not been linear. It moved across disciplines, languages, countries, and technologies. But there has always been one constant: I was trying to understand a problem deeply and build something that made a genuine difference to the people who had it.

That is what innovation means to me. Not inventing the most advanced technology. Not following trends. Not adding complexity for its own sake. Understanding human pain points — with scientific rigour and genuine empathy — and building something courageous enough to address them.

That journey is still going.