(the post is automatically translated by AI)
In early 2026, I left my senior software engineer position at a large tech company to join a startup as a tech lead. Still figuring out both the technical and managerial sides, I’m hoping this series of journal entries will help me look back years later and see how I’ve grown.
In early 2025, a former lab senior — also a co-founder from our first startup attempt — reached out again with an invitation to build something together. At that point, I hadn’t been a senior engineer for very long, and my risk tolerance was fairly low. So I declined.
After that, they reached out multiple times — true “three visits to the thatched cottage” persistence. Having settled into the senior engineer role for a while, I started feeling the itch to try something different. When the next invitation came, I decided to take the leap and join the startup.
To be honest, we had already tried this once before in 2022. Back then, I was still a master’s student, and the founders had just graduated from the lab with limited industry experience. Our lack of clarity on requirements and market direction had us running in circles. Knowing my own limitations and how much I still needed to learn from the industry, I stepped away first. The convenient timing of military service — specifically the R&D alternative service program — gave me a two-year window to work in the industry. I figured I’d come back afterward. Little did I know “afterward” would be three years later. The team composition hasn’t changed much, but the company has.
This time, joining the startup is also a way to test myself against the years that have passed. What can I bring to a company just getting off the ground? Can I have a bigger impact and help more people? Can I gain more experience leading a team? These three questions are the most important reasons driving my decision.
The company’s current state: there’s one relatively mature product, a new domain they want to explore, and some scattered client work. Most team members are each handling their own project. My first task after joining is to assess the stability and architecture of the existing mature product — and determine whether to replace or retain it in preparation for high-traffic scenarios.
Given that everyone is essentially a one-person team, I anticipated that software development processes might not be fully established — things like CI/CD and separate testing environments.
Sure enough, within the first week I discovered that while there is a basic CI/CD pipeline on Jenkins, each environment is configured independently. The configuration differences between environments are significant, which means there’s actually very little confidence in the test-to-production reliability. In other words, the current workflow makes it nearly impossible to catch in staging what might still break in production.
I’ll document that more in the next entry.
For now, the ship has sailed and the plunge has been taken. Let’s see how far I can go.