A decade ago, Slash began as a tight-knit engineering team in Cambodia, balancing complex enterprise systems with communal lunches and after-work gaming sessions. Today, as a global AI-first digital studio, our roots remain unchanged.
In this session, our Senior Tech Lead, Kevin, will share 10 hard-won lessons on engineering standards, leading without a title, remote collaboration, and adapting to the AI shift.
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?”
When I first joined, I honestly expected a good culture, flat management, and a place that treats employees as assets rather than just resources, with real work life balance built in. I also pictured us growing into a company of a few hundred people. On the size part, we’re maybe halfway to what I imagined on day one, so that guess was a bit ambitious. But the happy place to work part has gone well past what I expected. This turned out to be somewhere that genuinely empowers people to grow, and people actually love being here, which matters more to me than the headcount ever did.
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?”
The biggest lesson is that global teamwork runs on the basics, not on clever process. You have to actually care about each other and be supportive, because when someone is in a different country with a different first language, small misunderstandings turn into big ones fast if there’s no goodwill underneath. Communication has to be more than feels necessary, and you have to stay reasonable, especially around time zones and how quickly you expect people to respond. And you keep improving as you go, because nobody gets this right on the first try.
Q3: Real Talk on AI
“Now on AI. Where do you land on AI right now? How much has it actually evolved into your daily routine and workflow?”
I’ve been working with AI for almost ten years now, but this past year is when it really shifted, because the capabilities started to genuinely outsmart people rather than just assist them. I never thought it would move this fast. For developers, I think that means moving ourselves into the orchestrator role and staying on top of the agentic tools as they land, rather than trying to compete with them. In my own routine it’s fully embedded at this point. I’m using Claude Code, Cowork, the Claude API, and a few other agentic tools every day.
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 is that speed changes everything about how you build. Back in 2016, an idea went through a long runway before anyone touched code, and that gap was just accepted as part of the process. Now you have an idea in the morning and you can start building it the same day. So the way you work has to be fast and agentic to match that, because the bottleneck isn’t the building anymore. If your process still assumes a long runway, you’re just slow for no reason.
Q5: The Standard Nobody Wrote Down
“As a Senior Tech Lead, a big part of your job is setting the bar for how things get built, like code quality, architecture decisions, engineering practices. But most of those standards aren’t written in any handbook. How did you develop your own sense of what ‘good’ looks like in engineering, and where did that standard actually come from?”
My standard really comes down to three words I repeat constantly: readable, maintainable, testable. That goes into onboarding from day one, because I’d rather quality be plugged into every developer’s mindset than enforced by me later in a review. Beyond the code itself, a lot of “good” for me lives in the workflow. We have a clear path from Todo to Done, and every ticket goes through the same gates: the dev builds it, someone reviews the code, the pipeline runs automated tests, QA tests it, and the PO checks it against what they actually asked for before anything moves to Done. That structure is what keeps the bar consistent when I’m not in the room. In the AI era I’ve had to make more of it explicit, so a lot of it now lives in a Claude md file. But the rule underneath hasn’t changed: the developer owns the code, even the code AI wrote for them. You can’t outsource accountability to a model.
Q6: Leading Without a Title
“Technical leadership is interesting because you’re influencing how people think and build without always having direct authority over them. How have you learned to bring a team along in a technical direction when you can’t just tell people what to do, and what does that teach you about the difference between being the most skilled person in the room and actually leading?”
The main thing I’ve learned is that you get people to follow a technical direction by making it safe to disagree with it first. So I put a lot of effort into psychological safety, and into making sure we’re genuinely on the same page rather than just nodding at the same words. I try to involve the team in the decision instead of announcing it, because I want people to speak up and I want us to land on something we all actually believe is right. When that happens, nobody needs to be told what to do, since it’s already their decision too. What that teaches you is that being the most skilled person in the room and leading the room are two completely different jobs. The most skilled person can produce the best answer. A leader has to produce the best answer that the team will actually carry.
Q7: The Code You’re Most Proud of Isn’t the Most Impressive
“After years of building across different projects, clients, and technologies, what’s the piece of work you’re actually most proud of, and why is the answer probably not what people would expect? What does that reveal about what you’ve come to value most in this craft?”
The work I’m most proud of is an ML abstraction library I built back in 2018 for ML parameter tuning. It isn’t the most impressive thing I’ve built technically, and it wasn’t for a big client. What made it matter was the timing and the audience. AI and ML weren’t common back then, and developers in Cambodia were just starting to get curious about it. So I open sourced something that let people learn with simple Python, for anyone who wanted to see what was actually happening behind the curtain instead of just calling a library and hoping. What that tells me about what I value is that the impact of code isn’t measured by its complexity. It’s measured by how many people it unblocked.
Q8: The Hard Lessons
“Is there a specific moment where something went badly wrong, and what did you learn from picking up the pieces? How do you do that?”
The hardest lessons for me have all been on the client-facing side rather than the technical side. One that stuck was a project where I worked directly with a non-technical CEO. I found it genuinely hard to explain what we were doing in a way that landed, and I had very little time to do it. So I learned to prepare properly, simplify the message, and get to the point fast, because “technically accurate but incomprehensible” is the same as saying nothing. The other lesson came from watching things go sideways when tech teams don’t communicate. A client had a demo lined up for their investors, and the delays and the challenges we were dealing with all stayed inside the tech team. Nothing was hidden on purpose, it just never got said out loud. So the client got hit with a surprise at the worst possible moment, and understandably, they were angry. The way I pick up the pieces now is by front-loading the bad news. If something is at risk, I’d rather say it early and unpolished than late and well-worded. Managing expectations is part of the engineering job, not something that happens after it.
Q9: The Slash Secret
“After all this time, what do you think genuinely sets Slash apart from every other tech company out there?”
The thing you won’t find at other companies is how seriously management cares about people here. It’s employees first and clients second, and that order genuinely holds when it gets tested, which is rare. Work life balance is real rather than a line in a job ad. It’s a place to learn and grow, and it produces both happiness and a healthy kind of pressure, which is a hard balance to strike. Most companies get one or the other. Either it’s comfortable and you stagnate, or it’s demanding and it burns you out. Slash somehow manages both at once.
Q10: The One-Liner
“Ten years in, summarized in a single sentence: What is Slash to you?”
Slash is my second home, the place where I live and grow.
