A decade ago, Slash began as a tight-knit engineering team with a dream of building great things together. Henry joined expecting a classic office: desks side by side, lunch runs, code reviews in person. What he got instead was something rarer: a genuinely global, remote team that figured out how to feel close anyway.
In this session, Henry, Lead Engineer at Slash and one of the team’s foremost frontend craftspeople, will share 10 hard-won lessons on invisible architecture, the shift from contributor to leader, and why the best engineering is the kind nobody notices.
Q1: The Flashback
“When you first joined Slash, what did you honestly think this place was going to be, and how far off was your initial guess?”
Honestly, I pictured the classic office dream:Â a team of 20-plus people all in one room, coding side by side, grabbing lunch together, cracking jokes between builds. That kind of in-person energy was what I imagined a software company was supposed to be.
How far off was I? Pretty far but in a good way. The “together” part came true; the “same room” part didn’t. We grew into a genuinely global, remote team instead. What I learned is that the closeness I was after doesn’t actually depend on a shared office. It comes from how you work together, not where you sit.
Q2: The Global & Remote Reality
“After years of working remotely across different cultures, languages, and time zones, what’s the biggest lesson you’ve learned about making global teamwork actually work?”
Communication is everything, and I mean clear communication, not just frequent communication. When you can’t tap someone on the shoulder, ambiguity gets expensive fast.
The biggest lesson is to over-communicate context in writing, and then be willing to jump on a quick 1-on-1 the moment something isn’t clear, instead of letting it sit for a day across time zones. A five-minute call today saves a five-day misunderstanding later. Respect everyone’s hours, and never assume people read a message the same way you meant it.
Q3: Real Talk on AI
“Where do you land on AI right now? How much has it actually evolved into your daily routine and workflow?”
I’m firmly in the AI-assisted camp, it’s a tool I reach for every day, not something I’m afraid of or worshipping. It’s taken over a big chunk of the repetitive work: scaffolding, boilerplate, the tedious stuff. So it’s made debugging much faster, I can get to the root of a problem in a fraction of the time it used to take.
But I still own the decisions. AI speeds up the judgment about what to build and why is still mine. It’s woven all the way into my routine now as a force multiplier, not autopilot.
Q4: Product Evolution
“What’s the single biggest insight you’ve gained about building products over the years, and how does building something today in 2026 compare to back in 2016?”
The single biggest insight: the hard part of building products was never writing the code, it’s deciding what to build and keeping it simple.
Back in 2016, so much time went into just getting things to work: setup, plumbing, fighting the tooling. In 2026, a complex task that used to take a week can be done in about two days, because AI removes a lot of that friction. But that just moves the bottleneck. When building gets cheap, taste and judgment matter more, not less. The teams that win aren’t the ones who build fastest, they’re the ones who know what’s actually worth building.
Q5: The Frontend Craft Nobody Talks About
“You’ve been deep in frontend development, most recently on FileAI. Frontend is often treated as the ‘easy’ part of the stack, but anyone who’s actually built complex interfaces knows that’s not true. What’s the most underestimated challenge in frontend work, and what has years of doing it taught you that people who’ve never touched it would genuinely be surprised to hear?”
The most underestimated challenge in frontend isn’t making one screen look good, it’s the invisible architecture underneath that keeps a whole product consistent as it grows. On FileAI, like most complex frontends, the hard part was never the single component; it was the decisions that quietly shape everything after them.
Two of those decisions matter far more than people expect. First, picking the right UI library. Get it right and it becomes the shared language between design and engineering, your components line up with Figma, so designers and developers are describing the same thing instead of constantly reconciling two versions of reality. Get it wrong and you fight that mismatch on every single feature. Second, project structure. A well-set-up monorepo and a proper Storybook aren’t “nice to have”, they’re what let a team build in parallel without stepping on each other, reuse components instead of rebuilding them, and see the whole design system in one place.
What would surprise people who’ve never done it: most of the real work in the front end is invisible when it’s done well. Nobody notices the good decisions, they only notice when the UI is inconsistent, slow, or breaks in an edge case. Frontend gets called the “easy” part precisely because when it’s built right, it looks effortless. The years taught me that the craft isn’t in the pixels you see; it’s in the structure you don’t.
Q6: From Writing Code to Owning Outcomes
“What was the hardest part of that shift, and what did you have to let go of to actually become a leader?”
The hardest part was accepting that it’s not enough for me to just do the work myself anymore. As a strong individual contributor, my instinct was always to grab the hardest problem and solve it, and for a while that felt like the fastest path. But that instinct doesn’t scale. One person can only ship so much.
What I had to let go of was the idea that the code has to be written the way I would write it. Delegating means trusting other people to solve a problem their own way, and being okay when the solution isn’t identical to mine as long as it’s the right outcome. My job now is to make sure the right things get built the right way, to unblock people, and to grow the engineers around me. Success stopped being “how much did I ship” and became “how much did the team ship.”
Q7: The System That Looked Fine Until It Wasn’t
“In engineering, some of the most dangerous problems are the ones that don’t announce themselves. Have you ever inherited or built something that seemed solid, only to discover a much deeper issue underneath? What did that experience change about how you design or review systems today?”
I once inherited a client codebase that looked great on the surface: clean folder structure, everything ran, the app did what it was supposed to. On day one it gave every signal of being a solid, well-maintained project. So we started building new features on top of it, trusting that foundation.
The problem showed up once we pushed on it. There were almost no tests, so nothing warned us when a change broke something elsewhere, that was small edits caused problems in places that seemed completely unrelated. And it leaned on a fragile dependency that quietly broke when we moved past the narrow path the original author had used. What looked stable was really just untested and untouched; it appeared fine only because no one had stressed it yet.
That experience changed how I approach any system I inherit. Now I don’t trust “it runs” as evidence that it’s healthy. Before building on top of something, I look for what isn’t there, like the missing tests, the undocumented assumptions, the dependencies no one wants to touch. I’ll add tests around the risky paths first, and I treat anything that “just works” without a clear reason as a question to investigate, not a thing to build on. A clean-looking codebase and a genuinely solid one aren’t the same thing.
Q8: The Hard Lessons
“Is there a specific moment where something went badly wrong, and what did you learn from picking up the pieces?”
Yes, there was a feature where I committed to a tool early, built most of the way through it, and then hit a wall. The library couldn’t do what we needed at the point it mattered most, and it turned into a real blocker. We had to rip it out and switch to a different tool, which meant reworking a big chunk of what was already close to done. Painful, and avoidable.
The lesson stuck: never let excitement about shipping skip the evaluation step. Now, before I commit to any tool, library, or plugin, I research it properly first: check the edge cases, the limitations, the community and maintenance signals, and where possible run a small proof-of-concept against the hardest requirement before writing the real feature. Picking up the pieces taught me that an hour of research up front saves a week of rework later.
Q9: The Slash Secret
“What do you think genuinely sets Slash apart from every other tech company out there?”
The culture. A lot of companies say the words, but at Slash the values actually show up in how we work day to day, being kind, caring about the impact of what we build, taking ownership as leaders of our own work, and rising together as a team.
What makes it real for me is “remote, together.” We’re a genuinely global, remote-first company, but it never feels cold or transactional. The hub, I’m part of the Phnom Penh one, gives us the human side: getting out from behind the screen, having fun, building real relationships with the people we work with. That combination of high autonomy and real human connection, in a low-hierarchy environment where you can grow into whatever role fits you, is the thing I haven’t found anywhere else.
Q10: The One-Liner
“Ten years in, summarized in a single sentence: What is Slash to you?”
Slash is where a global, remote team of kind, ambitious people builds the future: AI-first, automation-driven, and human at the core.
