Opening
I served as CTO from April 2021 to April 2025 — joining a three-engineer team, growing it into a 30-plus-person R&D division, and finally closing out a long campaign. I’m not sure my writing is up to the task of fitting four years into one post, but I want to get it down before too much time passes.
Timeline
April–May 2021. Starting Part-Time
I joined on a short-term, part-time contract. I was building my own service at the time, and to keep cash flow going I spent my days on my own business, then went into the company at night. The engineering team had three engineers total, and two of them and I worked together every night from 7pm to 11pm, sometimes past midnight.
I worked on a few things at the time. The first was a single controller file with over 7,000 lines of code. I tried to clean it up by applying a layered architecture (at least), cutting repeated code, separating raw queries into a repository pattern, removing recursive functions, and applying a functional style. It was a Node.js / Express.js setup, a node server with no framework, running a single instance with PM2. Inside the controller, instead of calling other functions, the code was hitting its own server’s API endpoints, which during peak hours caused repeated network overhead and response delays. Most of my time went into fixing that.
Push notifications and other heavy work weren’t being moved to background jobs either, which was hitting the server hard, so another big task was pulling that into Kafka and handling it as events. Most of the work in this period was on the legacy service, especially the backend: fixing problems, refactoring, performance, server stability. Alongside that I was studying Kafka, applying it to events, studying k8s.
June–December 2021. Six-Month Contract CTO
While I was doing all this, the engineering team’s main projects somehow became directly tied to me, and in May they offered me the CTO role. The previous CTO wanted to move to the service experience innovation team (an operations group), and since I needed cash anyway, I took the offer without much hesitation, thinking six more months, why not?
From June, while continuing to work on the legacy service, the CEO proposed throwing out the legacy operating service entirely and replacing it with a brand new one. Internally we called the project SA service development. Replacing a service from a Series-C company with over 100 people felt like a tall order, honestly. I initially proposed improving the existing legacy as much as possible, but after firm persuasion from the CEO, we committed to building the new SA service from scratch.
Our stack was Node.js-only at the time, so the blueprint was straightforward: TypeScript + NestJS, MySQL, deployed on k8s. For the first three months and change, almost all of the time went into thinking through what was wrong with the legacy and how to design a system extensible enough to hold whatever content we’d want to put in later. We prototyped fast.
In parallel I was working on the CMS, the content editor. The legacy service offered only a bare-bones editor, and the content team had been storing things like multiple-choice option numbers and special characters in macros or notepads on the side. They’d even elevated buggy behavior into what we treated as a workflow feature, as part of how they got things done. I called these people content ninjas.
To solve the content production problem, I started planning and building a new CMS. This was probably the first time at IHFB that we actually listened to users, did the content production work ourselves, empathized with their problems, and kept the customer in the room. I remember testing every single keyboard shortcut, and running rough user tests with intermediate builds as we went. Content is the heart of an education business, but the perception was just hire more people, so this team had been getting zero technical support. I had a strong urge to fix it for them.
Anyway, during this period we were also hiring aggressively to build a real engineering team. The company had successfully closed Series C and was deploying that capital into all the scale-up moves: a record-setting TV ad campaign, large-scale hiring. By December 2021 the engineering team had grown from 3 in April to 13. And my contract was nearing its end.
2022. Toward the SA Service Launch
I’d started it, so I wanted to finish it. We’d come this far, so I wanted to see it through. I signed two more contracts in 2022 and started running toward the SA service launch. The company moved from Mapo to Yeouido Park One (Seoul districts). We hired aggressively across the board, not just our team. The actor Lee Byung-hun was on TV promoting the service, and marketing was firing on all cylinders.
Everything that ran on the legacy had to keep running, and structurally the new service had to be better. The legacy service had years of features layered on top of one another, and somehow each of them was being used somewhere. Missing even the smallest one would break the service, so as the dev timeline kept stretching, we kept checking and re-checking that we hadn’t missed anything from the legacy.
The first cut of the service was done in August. We pre-launched to a low-impact, low-sensitivity user group (1st-year middle schoolers and 3rd-year high schoolers, who don’t take in-school exams). Through September, October, November we kept it in pre-launch. In the last week of December all users were migrated to the new service. January through July, a full seven months of dev. August through December, all the non-dev work (operations team training, content migration) to actually put it into production.
We kept hiring, and the team passed twenty people. Around summer, what people call “Naver/Kakao/Coupang/Line/Baemin”-tier team leads (the Korean big-tech equivalents) joined, and the team finally felt like a real team as we pushed through dev and launch. For the final content migration we were at the office until 4am with the team. I can still vividly remember the hours leading up to that night. The full release took over a year, and honestly there were moments I wondered if it would ever actually end.
By that point we weren’t just an engineering team anymore. We were the R&D Division, with our own organizational culture, moving as one team. Team leads had come in. The service had launched after all the back-and-forth. The wrap-up moment was finally close.
January–August 2023. Going Full-Time, Then Iteration
Ironically, when we finally launched at the end of 2022, the company offered me a full-time role and gave me a short window to think it over. We’d launched, sure, but there was still a mountain of work: stabilizing the service, dealing with the issues that come up in real operations. After putting more than a year into the service, though, I wanted to stay and watch it find its feet and grow.
So in this period I bought a small amount of stock and became a shareholder, and for the first time I started working at the company full-time. I changed my mindset too. Up until then I’d always felt like an outsider, and I’d been working from that posture. Now I was going to commit a little more sincerely. No more excuses. Do my best with what I can do. That was the resolution.
The new build was good, but compared to before, both the architecture and infrastructure had gotten more complex, and incident response and various solutions were genuinely hard. The three-team-lead structure that came together around then (backend, frontend, PM) controlled the feature teams well, and despite all the issues, we were building out work processes in an almost ideal way. QA was set up around then too. By that point we were already over 25 people.
We launched a more premium product on top of the existing one, which came with a lot of additional feature requirements, and the product itself started handling many more content types and packing in many more features.
September–December 2023. B2G? B2B?
Things started getting hard around then. This was probably when I entered a completely new phase. The PM team lead I had real chemistry with left to start her own business, and I took over as acting PM lead. From that point, I was doing more PM work than CTO work. The company was also expanding from B2C (which it had focused on) into B2B and B2G, building on the platform we’d made, and I was barely keeping up with the business requirements.
In September, then again in January 2024, the company planned and ran large external events (expos) it had never done before. To prep demos and features for those, this stretch was almost entirely B2B and B2G product dev rather than B2C. B2B/B2G is genuinely much harder than B2C. I couldn’t tell what to base feature decisions on, what to actually build, and instead of customer voices, feature priorities kept getting shoved around by self-proclaimed experts: internal executives, outside expert groups, departments outside the engineering team.
This was when things got truly hard. Not because the difficulty was high, but because B2B/B2G product-building isn’t a domain I’d built up over ten-plus years, so I honestly felt no joy or interest in it. Every feature implementation felt like homework. Having said in 2023 that I was going to commit fully, though, I kept moving forward.
January–August 2024. B2G
I never thought I’d be making a textbook in this lifetime, but the policy review guidelines for the government textbook certification were handed down, and from the January expo to the August submission deadline I burned everything I had. By the end I was barely going home, working weekends and holidays. It wasn’t only dev. There were training programs, demos, every kind of business requirement coming in along the way, on schedules tighter than what we’d planned. I just kept rebalancing priorities and pulling resources together to get it done.
I was running more like a PMO function or PM than a CTO, and the PMs working with me at the time recognized me as a PM. I learned the hard way that PM isn’t a fit for me. Engineer ego aside, I gave everything to finishing the work. We took the existing service, kept only the skeleton, and built a new platform in a short window. The summer passed without me noticing the heat.
And Up to Now
From September 2024 to now, I’ve covered enough in earlier writing. If you’re curious, see below.
To Sum Up
- Early days: legacy platform refactoring and stabilization (3 → 13 people)
- Phase 1: launching the new SA platform (13 → 20 people)
- Phase 2: platform iteration (~25 people)
- Phase 3: building the B2G platform (~35 people)
If I had to pick the most fun stretch, it was from February 2023 (when the three-team-lead structure clicked into place) through June 2023, when we were just focused on iterating the service. Funny — writing it all out, it doesn’t feel like much got done. And when I really chew over those years, no period was easy. The time when I was still writing code was honestly more fun, and people were closer.
As someone else once said, those memories belong only to me. Everyone else has already forgotten, and only the recent memories stick with them. That long period when we were sometimes happy together and sometimes really tight as people, there’s no way to find traces of it in each other anymore. That’s sad. I’m not saying we should be chained to the past. As someone wrapping up and leaving, I just want to be remembered well. What can you do? Coming this far was my decision. I could have stopped at any of those moments along the way, but I kept going. That was my choice. If I’d wanted to walk out to applause, I shouldn’t have come here in the first place. Anyway, I’ve laid out what I did in rough chronological order, just as it came to me. Now let’s go through it piece by piece.
Outcome (Org and Product)
Data Team
The data team was properly built when the two people currently there joined in August 2022. We started from basic data engineering with Airflow, did a stats study group together (we even rewrote Andy Field’s whole book in Python), built out a data warehouse, set up analytics pipelines, and worked together on the data products that became core to running the service.
Both were juniors when they joined, so for the first year we ran weekly study sessions and did design work together. They both put in their personal time too, and partly because of that, they grew really fast. One of them finished grad school over the past two years on top of the busy work schedule. People joke that she’s a robot, but as someone who’s actually tried doing school and work in parallel, I have nothing but respect for her.
I could have done more focused work on the data team, but unfortunately, from the second half of 2023 when I took over as acting design team lead, I ended up neglecting the team more than I should have. Coming from a data engineering role at my previous company, there’s regret that I didn’t execute more of the roadmap I’d planned. The saving grace is that both of them are people who run themselves well, so at this wrap-up moment they’re the team members I trust most and I’m most grateful to. They’re also (from my side) the easiest people to be around, and the team where I most wish I’d looked after them more. They’re working on the company’s main initiative right now, the AI Agent project. They’ve finally landed on the something AI engineering they’d been wanting, and I really hope they get the result.
Design Team
When I took over the design team, I thought it was a blessing in disguise at the time. The previous lead had left, and while we were hiring a new PM, I stepped in as acting lead. It pulled me back into the planning details. The one thing I regret is not making enough of the opportunity, because we hired a new PM not long after. The new PM was a junior, so I stayed on as acting lead, and the biggest mistake was demanding from this new PM most of what the previous PM lead had been doing. (PM stuff, I’ll save for the PM section.)
The reason an engineer-background lead could land any real hits in the design team was that the planning skills I’d picked up from running my own business held it up. We were also pursuing product design (owning policy details all the way down, not just UX/UI), and that gave me room to play several roles. On the aesthetic and form side, my feedback was close to zero. The best I could do was feeling out the room with I don’t really like this color. I can’t make it, but I can tell good-looking from ugly.
What I liked about leading the design team was the time spent one-on-one with each person, going back and forth on product direction and feedback. Designers and developers are makers, and makers can’t help over-investing in their own solution. Someone has to keep pulling them out of it from the outside, and when leading the project, I think I did that part well. Especially when many initiatives were running in parallel, the product was still one and the customers were still defined, so giving useful feedback wasn’t hard, and the designers took it in well. When something didn’t make sense, we kept trying to convince each other. You could say that’s just how you see it, but when requirements come down so top-down, my position as a middle manager forced me to keep asking why and to keep building motivation just to set priorities. The persuasion may not have been enough for some people, but I can promise I never skipped the persuasion process.
That said, recently (at the end), with so many products, so many squads, so many kinds of customers, the useful range of my feedback shrank to mostly implementation-scope. If I hadn’t quit this year and had kept going, my plan from the start of the year was to delegate the design lead role and return to being CTO.
QA Team
We set up the initial QA staffing with the original PM lead, and built out the QA process together. The QA team, truth is, didn’t grow much after the initial setup. This is the team I have the biggest regret about. While also leading the data team and the design team, I didn’t have the experience or the capacity to give QA proper direction and lead it as a specialized function. Late in the period, I tried giving the QA team more authority and a sense of ownership to push them to do better, but unfortunately, during the time I was there, we put almost no time into proper test-case reviews or building QA automation. My experience there is limited, but the team has people who’ve worked with strong QA orgs. I hope the team itself can push toward becoming a more specialized function that contributes more to the org going forward.
Engineering Team (FE/BE)
For the first year I was almost always with the engineering team, looking at code, writing code myself, spending most of my time on code review. I delegated FE to the FE lead who was there from the start, and concentrated mostly on backend. Legacy, layered, functional, DDD, clean: I came in with all these design agendas. The one thing I regret from that period is that no design methodology is 100%, and I set the criteria too vaguely for the gray areas. We just kept developing. A lot of that is still in production code. Even if my methodology becomes a new kind of legacy by today’s standards, I should have set stricter criteria and done more rigorous code review on the ambiguous parts. I was lacking a lot back then.
When the BE lead came in, I naturally delegated code ownership. For about half a year I spent more time pairing with a junior FE engineer once a week to untangle a heavily coupled component. Most of my actual coding was on the data engineering side. Since this was the company’s core engineering team, I always followed up on key design and decisions and actively joined design reviews on new projects. From that point on, instead of code reviews, it was mostly design reviews and tech doc reviews. From this distance, I should have stayed on top of code reviews more consistently. I wasn’t completely absent from the code, but it was nowhere near enough. Whether the implementation actually matched the design has to be verified through the code itself. Because I was so weighted toward design reviews early in projects, I kept finding out late that the agendas I’d brought in originally and the actual code implementation had drifted apart in important ways.
Even as I’m wrapping up now, I keep asking myself if I could go back to point X in time, what would I pick differently? From tech stack to design direction. The biggest one is that during the B2G phase, when there was a window to partially rebuild the platform, I didn’t go far enough in breaking the existing structure. I compromised to hit a tight schedule, what amounted to honoring the old while building the new, and looking back from here, that was the wrong call. I really hope my successor and the engineers staying behind, plus the strong people coming in, can fix the structural problems at the root and turn it into software that’s resilient to change, a service where you can focus on the core logic.
PM
Honestly, just regret. In 2024 I was a PM, not a CTO, and as a PM I failed badly. I didn’t make use of the strengths and weaknesses of the PMs we’d hired. I didn’t delegate properly. We didn’t communicate or share well. The team and people I spent the most time with. And yet I just couldn’t pull it off. I owe the PMs I worked with an apology, and that failure left me unsettled for a while.
There were a few causes. The biggest one is that I was the PM lead and I was the PM role model. But no matter how much I set down the dev work to be a PM, the ability to review and plan a product based on technical understanding and design is mine alone. That’s something I do well. The big mistake was forcing that role on others early on. The thing is, the moment a PM hears a requirement, they have to step back and check their own thinking: can I make this call or not? If they can, decide fast. If they can’t, get the right stakeholders into a room fast so the work doesn’t stall. The moment a PM thinks they can decide something they can’t and burns time on it, the timing slips and everyone working on it ends up unhappy. And in an in-house product, the PM’s job is to deliver the customer’s voice faster, judge the essence of the problem, and work with the makers to land on customer satisfaction. The timing was bad too: the B2G product I worked on for a year was a project where you basically couldn’t do any of that. The role was mostly take a given task and shrink its scope to the bare minimum that still meets the conditions. Or write business proposal documents.
Still, I think I could have done better. And in spite of everything, they should have been working in a better product environment. At least when it comes to PM, I’m not A-tier, so if I’d met these people in a B2C or B2B in-house product, I might have done better, might have delegated more. In this kind of environment, PMs honestly just get pushed around and bled dry.
I never praised that team properly, only nagged them. I’m sorry. I hope both of you find environments where you can work more like yourselves.
Org Structure Changes
We started with feature teams, and ended up (clumsily) with mission-based teams, a squad system. I think that’s a good thing. I didn’t drive the change proactively, though. Buffeted by changing external business needs, our single big division kept doing wildly different work in feature-team units sprint to sprint, and to get some continuity and focus people, we ended up in what I’d call survival-mode squads. But there weren’t enough PMs, the size of the businesses was wildly imbalanced, the contexts were different (different businesses, different customers), yet we kept the same platform strategy (same codebase, same branch). Every release blew up. To fix it, you’d have to either drop a business, or if you can’t, split codebases by business unit and make everything independent so the squads can move faster. On this one, my view differs from the executive team, so I won’t comment further.
If we’d separated codebases per squad, put a senior engineer on each squad, had a dedicated PM per squad (especially for B2G, where stakeholders are so tangled, I think you need at least two PMs), and split the org structure clean along squad lines, could we have run a more agile system regardless of headcount? Saying we’d have done well if we had more resources we didn’t have is a cheap thing to put in a retro. What I really wanted from the squad model was back to the basics. The way I built culture and led nimbly with three engineers when I first joined, I wanted to recreate that in small squads. But honestly, looking at where things stand, I can’t say that worked out. Was it because we’d gotten too used to feature teams over the years? Or just because last year’s B2G project drained everyone?
Still, the one really important thing I should have done is: more 1-on-1s with people, more often. When I scrambled to talk to people in January, the timing already felt too late. If anyone asks me, I’m a manager and I don’t know what to do, I’ll tell them: do 1-on-1s diligently with your people. That’s the best move.
Also, the absence of a clear reporting structure (both up and down) was one of the biggest problems. Setting aside the squad structure, I should have set up direct, organized reporting from team leads, PMs, and seniors much earlier. In startup organizations where everyone is moving on their own, I’d treated reporting as almost a forbidden word. But in a bigger company, reporting structures and rank structures matter, and so does delegating well to the people you can delegate to. Coming to that realization too late was another problem.
Leadership goes downward, but it also goes upward. Just changing org structure doesn’t make work happen. Org structure functions properly only when the upstream business structure and the downstream team culture both back it up.
Org Culture
Up until the org grew toward the first 20 people was probably when my influence was strongest. Check-in meetings, random lunch-mate matchups, sprint retros, those mechanisms worked. I wrote the onboarding doc myself. The two things I value most in org culture (humor and curiosity about each other) were running through small mechanisms that actually worked.
Then last year, with the B2G project, people lost motivation, the company stopped communicating, and it all collapsed. As I started letting the small details go one by one, even the mechanisms that had been working just fell apart at the end. I decided we couldn’t keep going like this and brought in the company’s EX (employee experience) team. Now that the company has to move forward again, this might be the moment to reset the team’s identity and culture entirely. If the culture I built doesn’t work anymore, I hope they peel it off without hesitation and set up something new.
People Ops
Because the company’s HR and people ops were mostly absorbed in the education and teacher operations side, almost all org-level people ops landed on me. The thing that took the most energy: the comp negotiation season at the start of every year. When I was alone, I had to evaluate all team members myself. When team leads were in place, I delegated to them but did the final evaluation myself. We brought in peer review for people who’d worked together, and used it more for reference than as an evaluation. A month on team evaluations alone, almost two months on comp negotiations with the executive team. For 2023 and 2024, the first quarter of the year was almost entirely poured into people ops. The executive team was reluctant to raise compensation much, and team members wanted bigger raises, so I had to do max-tension tug-of-war within the cap I was given. Negotiating someone else’s salary, not your own, isn’t an easy process. To make evaluations more transparent, I introduced 1-on-1s, quarterly retros, peer reviews, all of it.
The flip side: with that much authority comes that much responsibility, and since every execution went through my hands, the moment I got busy or lost focus, I’d drop something. There was no framework or system to back it up, and the org had no real HR function, so I spent a lot of time fighting alone.
Looking back, when the team was under 10, I had enough capacity even without HR support to give frequent feedback and run growth-oriented conversations. In 1-on-1s we’d set goals together for the next month or three months, look back at what got better and what was missing, and during that time at least, I gave honest feedback (positive or negative, no holding back). I made a point of preparing at least one piece of negative feedback per person, where negative meant something they could turn into an action item.
As the team got bigger, the system was still nothing, and the company had less slack, it got harder to keep evaluations and reviews consistent. Building a system was a stretch when the company still had so much growing to do, and without a system you can’t promise anyone even a baseline of growth. Pay eventually fades into background noise once you’ve been receiving it for a while. There’s a limit to how far you can convince or commit someone with money. It’s just one of many ways to express what you think they’re worth. What matters is whether the leader pulls growth out of people with sincerity while still giving objective evaluations. And on that front, I’d think I was doing fine, then think it was impossibly hard. It was a brutal stretch.
Team members and the company both talk about money in comp conversations, and only money. The company says we paid this much, so deliver this much. The team members say if you want this much, pay this much. A team member who works at a 6 out of 10 doesn’t suddenly become an 8 because you raise their comp by 10 million won. (Truth is, you’d be lucky if they don’t drop below 6.) The company shouldn’t expect that, and the team member’s promise of it isn’t worth much. Comp negotiation is one lever for carrying value and growth forward. Trying to solve everything with it, without context, is just not knowing people.
I always emphasized individual growth, but in the end, you can only talk about individual growth if you keep pulling team growth, and beyond that, team wins. In a startup, team wins have to connect to the company’s business goals. The team has to drive those goals and turn them into wins. In an org where you don’t even know what winning is, no matter how much a leader talks about individual growth, it’s hollow. Individual growth sits on top of team wins. It might be sacrificed for one. But it can’t exist without one.
The executive team wanted us to build the product they had in mind, and they ran the business and engineering as separate orgs. Every metric and every requirement’s backstory came only through the executive team. Right or wrong, that’s a structure where it’s really hard to define what team winning means. The hardest moment was when the B2G project finished and the team had been crunching for three or four months. We hit our final goal (passing the review), but that wasn’t a win. Not users, not revenue. Just earning the right to sell. With no business outcome reached, the team had worked plenty hard, and wanting some additional reward was completely reasonable.
Of course there was no extra reward. From that point on, the company started struggling, and even the things you’d taken for granted started disappearing. We spent enormous amounts on B2G with no clear business goal definition and no return. Forget headcount cost and time, we did everything money could do. But the executive team didn’t explain (and when I asked for an explanation, all I got was we have to save money now). I had to manufacture a company message in the middle, talk about vision… but I wasn’t the final decision-maker, so my words couldn’t carry weight. I myself was deeply skeptical about doing business through B2G product. It was because the company, in the end, didn’t fully respect the CTO. Whatever the intent or reason.
The story of finding out, the day before the holidays, that the Chuseok and Lunar New Year gifts that always go out hadn’t gone out (finding out as Division Head by asking the other directors), and then scrambling to buy the team’s holiday gifts on my own dime: you couldn’t make it up. I’m not bragging about paying out of pocket. With the judgment I have now, I’d never use my own money. But moments like that pushed my leadership in running a 30+ person division beyond its natural range, and probably drained a lot of my patience.
Even so, thanks to all this, I got to experience how to run an org, manage it, hire, all of it. These aren’t lessons I read in a book — they were carved into me the hard way, and they’ll stay. I won’t be running a big team for a while, but I’m not giving up on thinking about it. Because I really do love working as a team.
Product
When we built product, I always planned around structure, design, solutions. Sometimes thinking that way helped (extensibility, structural thinking), but the thing I regret most is the actual ways people would use this, which I didn’t see.
A concrete example: the curriculum part of the current content system was designed on the assumption that a curriculum gets written after it’s complete. But in the actual service, most curricula are written and updated as they go, and that’s exactly the case customers are paying for. In the first year I was so focused on catching up to the legacy and on my (self-proclaimed) structural completeness that, no matter how much extensibility I thought about, we ended up with a structure that’s painfully fragile to change. Because the product design itself was broken from the start, the more use cases and edge cases surfaced, the more dev cost grew exponentially.
It’s like building getters and setters in an OOP class, thinking now we can generalize these everywhere, then watching feature requests pile up and the getters and setters get crusted with if statements, and one wrong touch sends side effects into every other area. Unlike DDD or recent design trends, I held the foundational model design too strict, and that fixed structure became a kind of immutable law. After that, every change had to either avoid touching it or work through it, which inevitably meant ballooning dev cost.
You were CTO, couldn’t you have just done better? Ha, fair. That’s why I wrote I regret this. Early on I should have interviewed the operating teams much more deeply about exactly what they did and how they ran the service, even done the actual work myself, and understood it. But because I had to focus on the new platform that would replace the legacy, and because I was stuck in what I’d convinced myself (that the new platform is obviously better in features and design), I developed in isolation, without looking deeply at the use cases on the customer side. One reason I didn’t quit after the 2022 launch was that I had a strong urge to make up for this, to develop from inside the customer use case.
Honestly, more than the question of which dev stack to pick, this is the part I regret most all the way to the end. For a developer to write good code, they have to know the customer. If you write code based only on what the PM or the designer or someone else tells you, before long you’re looking at your own code and blaming yourself for it. If it’s just a code issue, you can refactor. But once the DB schema, the production data already sitting there, the relational table structures are in place, turning all that around, migrating it, redeveloping, once the service is in motion and chasing the next business requirement, that’s almost impossible. You’re carrying a giant lump forever. The trap engineers with tech, tech, tech ego need to avoid: our value only shines when it connects to delivering value for the customer. If I’m getting paid and what I’m building doesn’t connect to customer value, I think honestly I’m a developer on borrowed time.
Which brings me back to the same point: the customer. In the end, we’re building products people use. Don’t forget that. Don’t ever forget it.
Closing
What I built, in the end, was an org and a product. If I had to pick a single action item from the org side, it’d be: do more 1-on-1s. The things I most regret, the things that stung most in the end, were the if I had just done it back then, it might have been different kind.
On the product side, like I just said: put the customer first. Forget structure, forget design. What actually matters? The customer has to come first. Don’t get confused. I’m absolutely not saying just take what customers say at face value. The real skill is catching the requirements, needs, and opportunities hidden underneath. (And being the kind of developer who can carry that into code.)
Like my other posts, this is a brief (?) look back at four years of work. I wrote (or rather, dumped onto the page) whatever came to mind, so it’s all over the place. Really, a stream of thought transferred straight to the page. While writing it, part of me wanted to clear it all out for a fresh start, and another part of me wanted to bury the past here and not be tied to it. The memories will fade. I’ll read this and think, ah, right, that’s how it was. There’s plenty I’m still unhappy about (the company, other things), but this is a public space, so I focused on my own record and on things I can actually act on. Those frustrations will fade too. Some other version of honest thoughts I might write down, well past now, if I still have the will and the memory.
Most of my twenties I spent building my own business, so for a 13-year career, I’ve never been at a company this long as a regular employee. And not just an employee, a middle manager with the title of CTO. I spent my twenties and into my thirties being called CEO, and only lately have I gotten used to being called Director (a middle-management rank below the CEO title I’d held until then). Time scares me a little.
Watching the company grow rapidly and watching it struggle, I always ran a mental simulation: if I were the operator, what call would I make here? Not I’m better than anyone, but I have my own style, so what’s the best version of my approach? And I tried to understand the operator’s position from the inside while doing it. Going from 3 to 30 in R&D while the company went from 100 to 500 was a high-difficulty problem.
I trash-talked my boss behind their back and ate good food on the company card. I learned what a paycheck means. I learned a lot of things I didn’t know when I was only an operator. I became more of a realist. As a middle manager I tried to live up to the responsibility, but it was harder than I expected. To my team I held two opposing sentences in my chest, I’m in the same boat as you and I’ll take responsibility and decide, and there were moments I disliked everyone, above and below, and moments I felt nothing but gratitude for everyone. Right here at the very end, what’s biggest is regret. But over this time I felt and learned and gained a lot.
At some point work got so heavy and the stress got so bad (I can’t remember what it was about) that I sobbed in my wife’s arms (we weren’t married yet). At some point I had insomnia (I’m someone who falls asleep the moment I lie down, anywhere) and was swearing in my sleep, and there were nights I’d wake up at 3am over work and stay up until morning. I was more stressed than when I ran my own business. I only let it show to people at the very end. For someone who likes to wear his heart on his sleeve, I held a poker face and made it this far. Think too deeply and everything ends up a regret.
Now I’ll bury these four intense years here, hold onto the good memories and the lessons, and start something new.
What we call the beginning is often the end. And to make an end is to make a beginning. The end is where we start from.
― T.S. Eliot
To everyone who stayed with me to the last line, thank you for reading all the way through these messy, scrambled four years. I’ll rest for a while and come back with new stories.
댓글
댓글을 불러오는 중...
댓글 남기기
Legacy comments (Giscus)