What six years inside a scaling healthtech company actually teaches you

There’s a version of a career story that goes: I worked at some companies, got promoted a few times, learned a lot, and now I do something new.

This is not that version.

I spent six years at Florence Healthcare, recognized by TIME as one of the world’s top healthtech companies and by INC as one of the 500 fastest-growing companies in the US, building products inside a domain where the stakes are real, the constraints are serious, and improvising your way through is not an option.

Clinical trials. Document management. Regulated software in an environment where a bad release doesn’t just cause a bug report. It can affect the integrity of medical research.

That context shaped everything.

Three roles, three different kinds of thinking

I moved through three roles across those six years: engineer, tech lead, staff engineer. Roughly two years each. From the outside that looks like a linear progression. From the inside, each transition required a fundamentally different mode of operating.

As an engineer, I was curious beyond my immediate scope. I wanted to understand why things were being built, not just how. I’d push into product conversations, ask questions that weren’t technically my job to ask, try to see the system beyond my part of it. At the time I thought it was just how I was wired. Later I realized it was preparation.

As a tech lead, that curiosity became essential. You can’t lead a technical roadmap if you don’t understand the commercial reality it’s supposed to serve. Suddenly I was sitting in rooms with stakeholders who had business pressures, timelines, and constraints that had nothing to do with code, and my job was to translate between those two worlds without losing either side. You also have less time to actually build, which is a hard adjustment when building is what you love. I protected that time deliberately, because I knew that losing touch with the technical layer would make me worse at the leadership layer, not better.

As a staff engineer, the frame expanded again. Less time with individual stakeholders, more influence over how the entire engineering organization made decisions. Architectural standards. Cross-team alignment. The kind of work where you’re not solving a problem directly. You’re shaping the environment in which problems get solved. That’s a different muscle entirely.

Each transition stacked on the previous one. The engineer’s curiosity fed the tech lead’s translation ability. The tech lead’s translation ability fed the staff engineer’s organizational influence. None of it would have worked in a different order.

The compliance problem and what feature flags taught me about constraints

Here’s something specific.

In regulated software, particularly in clinical trials, you can’t just ship features the way a typical product team does. The compliance requirements around what gets released to customers are strict, and for good reason. The integrity of the research depends on it.

The standard response to that constraint is to slow down. Release less often. Build bigger batches. Accept the friction as a cost of doing business in a regulated environment.

I didn’t think that was the only option.

What I introduced was a feature flag system: a way to deploy software to production without actually releasing it to customers. The code goes out. The infrastructure is updated. But the feature stays invisible until it’s explicitly switched on, after it has passed the necessary compliance gates.

It sounds simple. In practice it changed how the team operated. We could develop continuously, test in real environments, and release deliberately, without the compliance process becoming a bottleneck that killed momentum.

The lesson wasn’t technical. It was about how to work inside a constraint without being defined by it. Find the gap between what the constraint is actually protecting and what it’s unnecessarily blocking. Build in that gap.

That kind of thinking applies everywhere.

The team I’m most proud of

My first tech lead role came with an unusual setup: a team of five engineers, junior to mid level, with just one senior. No safety net. No experienced engineer I could delegate the hard problems to.

My instinct was to lead from the front. Take the hardest problems myself, set the pace, show the standard by doing. It felt responsible. It also didn’t scale, and I could feel it within weeks.

So I changed the approach entirely.

Instead of pulling work toward myself, I started pushing context toward them. Making sure everyone understood not just their task but why it mattered, how it connected to the broader system, what good looked like and why. I started treating the team as engineers who were capable of more than their experience suggested, because they were, and creating the conditions for that to become true.

They grew fast. And they kept growing after I moved on. The same engineers I brought into a second team later: we won a company hackathon together. The year after, when I’d moved to a different team, they won it again without me.

That’s the outcome I’m most proud of from six years at Florence Healthcare. Not a system I built. A group of people who didn’t need me anymore.

What the outbound integration module taught me about designing for complexity

At some point during my time there, I built an outbound API integration module, an event-driven architecture that allowed Florence Healthcare to connect in real time with external customer systems.

The problem wasn’t just technical. It was about designing something that could be reliable, extensible, and legible to teams who hadn’t built it, in an environment where failures had real downstream consequences.

Event-driven architecture in a regulated environment means thinking carefully about what happens when things go wrong. Not if. When. Every event needs to be traceable. Every failure needs to be recoverable. The system has to be honest about its own state.

What that work reinforced was something I’d started to believe more broadly: that the quality of a system is most visible under pressure. When a deadline hits, when an integration breaks, when a customer calls, that’s when you find out whether what you built was actually solid or just solid-looking.

I started designing for pressure as a default. Building things that tell the truth about their own state, that fail loudly rather than silently, that can be understood by someone who wasn’t in the room when they were built.

The thing that connected all of it

Across six years, three roles, and more projects than I can neatly list, the thing that kept showing up as useful was this:

I could talk to anyone.

Not in a generic “good communicator” way. I mean specifically: I could sit with a frontend engineer and talk about component architecture. Walk into a DevOps conversation and understand what was actually being debated. Sit with a product manager and help translate a vague requirement into something buildable. Get in front of a CEO and make a technical constraint legible in business terms.

That’s not a soft skill. It’s a systems skill. It comes from caring enough about the full picture that you learn the language of every layer, not to perform fluency, but because you genuinely want to understand how everything connects.

That’s what six years inside a serious, scaling, regulated software company actually builds.

Not just technical depth. Operational range. The ability to hold the whole system, technical, human, commercial, without losing your grip on any part of it.

Why this matters now

ISTECH is built on exactly that range.

The work I’m focused on now is with people building brands, platforms, and experiences who need a technical partner who understands not just what to build, but how the whole thing runs.

The environment is different. The stakes feel different. The domain is different.

But the thinking is the same.