Loading ...
Since 2014, I've spent more than a decade as an engineer across two countries, China and Japan, working my way from junior developer to tech lead. Over those years the tech stack, the product direction, the company stage kept changing. I've built in SaaS, robotics, logistics, e-commerce, and AI, alongside engineers from all kinds of countries and backgrounds.
But the thing that makes me remember a company is never any of that.
It's the small things nobody had to do, that someone chose to do anyway.
It took me twelve years to figure that out.
In 2014 I joined Geetest in Wuhan as employee number 13, the company's only web developer. Frontend, the admin dashboard, the marketing site, internal tools — if it touched the web, it was mine. Four years later I was leading a web team of ten.
Then I moved to Shanghai and joined BITO Robotics, a robotics company founded by a CMU team. That was the first time I really felt what a mature engineering team expects around code quality, communication, and documentation. It was nothing like the environment I'd come from.
After that came Shucheng AI, incubated by SF Express, with founders from Stanford and the University of Michigan. I went from senior engineer to engineering director there, and picked up an international patent along the way.
Eight years, three completely different companies. I thought I already understood what a good work environment looked like.
Then I moved to Japan.
My first job there was at a dispatch company, Gennmu. I knew it probably wasn't my long-term path, but it was how I started over in Japan. It gave me far more than I expected. After that I joined a SaaS company building for creators as a Lead Engineer, which put me back closer to the core of the product.
Now I'm at Lunaris. The team includes people from China, Japan, Vietnam, the US, Belgium, and Australia. It's not the biggest company I've worked at, but it's the one that's genuinely international.
Six companies, two countries. And slowly I noticed something: what makes me remember a company isn't the stack, and isn't the product. It's a handful of small, specific moments.
Geetest held a tech talk every Friday. The topics weren't limited to company products — personal projects, open-source tools, frontier tech, even something someone had just learned that week. All of it was fair game.
I was still a junior developer, and a lot of it went over my head. Someone broke down performance bottlenecks from Python's GIL, someone explained load balancing in a Redis cluster, someone built Super Mario in JavaScript.
None of it was necessarily relevant to my day job. But it was the first time I realized the world of engineering was much bigger than the pages and endpoints I wrote every day.
A team willing to share knowledge has already assumed one thing: that my growth is valuable to the whole team.
The opposite is also true. When knowledge gets treated as a personal bargaining chip, everyone tends to hold back what they know. It feels safe in the short term. Over time it slows the whole team down.
The reason I grew fastest in my junior years wasn't that I was smart. It was that the people around me were willing to hand me what they knew.
At BITO I noticed a small habit: after any meeting, someone would write up the notes and send them to everyone. Not always the same person — they rotated.
The first time I got one of those emails, I was a little surprised. It had been an ordinary product discussion. Not senior leadership, not formal. But the email laid out every decision, every action item, every owner, and every next deadline.
It sounds minor. But underneath it is an important assumption: everyone's time deserves respect, and every decision deserves to be recorded.
A lot of teams don't have a competence problem — they have an information-loss problem. The same question gets discussed once in a meeting, then asked again a few days later. A decision gets made but never written down, and later someone keeps building on the old version of it.
That's how an engineer's time quietly gets spent.
That was when I started caring more and more about documentation and transparent communication.
At Shucheng AI the team was spread across Shanghai, Shenzhen, and Ann Arbor in the US. Different time zones, different cities — by rights it should have drifted apart.
But this stuck with me: whenever people from different locations ended up in the same city, they'd usually get a meal together. It happened in Shanghai, and it happened in Shenzhen. Nobody mandated it, it wasn't a policy. It was more of a habit the team formed on its own. Someone's in town, so you grab dinner and talk. No dressing it up as team building.
I've seen plenty of teams since. Some sit on the same floor, a few desks apart, with almost no real connection between them. Others are separated by cities, countries, even an ocean, and still hold a deep sense of trust.
The difference was never physical distance. It was whether anyone was willing to make the effort to hold things together.
I used to dismiss small rituals. Birthday cakes, company lunches, trips, language classes — I figured none of it was necessary. A product doesn't get better because of one lunch, and code doesn't get cleaner because of one birthday.
The longer I worked, the more I changed my mind.
At Geetest, when someone had a birthday, a cake would appear on the table. Nobody asked for it, but it was always there.
At Gennmu, not long after I'd arrived in Japan, the company organized a trip to the Kinugawa hot springs. I hadn't settled into life in Japan yet, and I didn't expect to stay long. But that trip made me remember a lot of people, and it made me realize the company didn't see me as just someone dispatched out to a client site.
At Lunaris, there's a lunch every two weeks, and a Japanese class every Tuesday to help international staff live and work better in Japan.
Not one of these things was "necessary."
But together they send a very clear message: the people here care about you, not just the code you write.
Every time I landed in a new environment, I assumed the tech stack, the product direction, the company stage would decide how I'd do there.
Those things matter, of course. But looking back, what actually shaped how fast I grew was never just those conditions. It was whether a team took people seriously.
I'm more and more convinced of one thing: a team that bothers with the small, unnecessary things usually takes the truly important things seriously too.
If you asked me now what kind of startup is worth joining, the answer is simpler than it used to be.
It doesn't need to be perfect, but it needs a sense of direction. It doesn't need to be mature from day one, but it needs to want to get better together. It doesn't need to spend lavishly, but someone has to genuinely care about the people in it.
I don't know how common companies like that are. But I know they're real — in Wuhan, in Shanghai, in Tokyo, in the small things I still remember.
Do you have a story like this? A team detail you never forgot, or one small thing a company got right — I'd love to hear it.