Total 31 PostsAI SiloThe real debt that arises when AI develops too quickly
2026.01.19PlanFocusing only on the plan resulted in an unwanted product that was just tailored to the schedule.
So What Should We Do Now: How to Switch to “Execution Management” When I worked as a development manager at a startup, the thing I repeated the most was “making plans”. Business schedules came first, development plans were made to fit those schedules, and from then on, it was a structure of struggling every day to reach the goals. But at some point, something strange starts to happen. The team stops building the product and starts becoming optimized for making excuses to keep the plan. “Documents explaining why the schedule was delayed” “Post-mortem reports saying it couldn't be helped due to too many risks” “Re-planning the plan to make up for it next week” In the end, the result is similar. The schedule was met, but a product no one wants comes out. The Problem Is Not the ‘Plan’, But the ‘Absence of Intent’ Plans are necessary. But plans cannot replace execution. Problems that occur during execution cannot all be predicted at the planning stage. But the bigger problem lies elsewhere. When you start running solely based on the schedule, the team's interest shifts from “What should we build” to **“By when must we finish”**. From this moment, the development team and the business team stop running towards the same goal and start colliding with different orientations. Business wants “what the customer needs” Development wants “to meet the schedule” Neither side is wrong. It's just that the standards they look at have changed. And in teams where only the schedule remains, misunderstandings eventually pile up. “The dev team has no business understanding” “The business team just doesn't know development” Actually, both are only partially true, but the core is this. We only agreed on the schedule, we never agreed on the intent. The Development Team Cannot Make a Product That Satisfies the Market “Alone” One thing must be made clear here. It is difficult for the development team to read the market, analyze customer needs, and derive the “correct product” on their own. And the moment you shift that responsibility to the dev team, they choose one of two things. Become a team that doesn't listen (Overturning product planning) Become a team that just does what they are told without thinking (Only meeting the schedule) Both fail. What's important in a startup is not “Let's make the dev team build a product that satisfies the market,” but for the dev team to understand the business intent and become a team that turns that intent into the best implementation. Business takes responsibility for the market, development takes responsibility for implementation, but **a structure where the intent is aligned as one** is needed. So What Should We Do: 5 Steps of Execution Management (Intent-Centric Version) 1) Treat Plans as ‘Hypotheses’, Not ‘Contracts’ Many teams run plans like final versions. But a plan is a hypothesis. A plan is an estimate that “if we do this, it will work” Execution is the process of proving “actually doing it showed it was right/wrong” The moment you operate a plan like a contract, the team starts making distorted decisions to meet the plan. ✅ Practical Application Separate **“Fixed Schedule” and “Variable Scope”** on the timeline Keep the milestones, but leave the implementation scope adjustable 2) Set Goals Based on ‘Intent’, Not ‘Schedule’ Goals in schedule-centric organizations are usually like this. Login feature complete Dashboard 1st draft complete Payment API integration complete This is a task list, not a purpose. Intent-centric goals look like this. “Make sure signup conversion doesn't break” “Make the user move immediately to the next action” “Do not block the flow where payment occurs” In other words, the goal becomes not the feature, but implementing the flow the business wants. ✅ Practical Application Change the sprint goal sentence like this ❌ “Develop Feature A” ✅ “Implement Business Intent A, and verify success criteria” Here, the success criteria doesn't have to be the market, but **the business intent criteria (conversion, flow, data, operational feasibility).** 3) Don't Find Risks in Meetings, Reveal Them Quickly in Execution Execution management is ultimately a battle against risk. The moment you look for risks in a meeting, risk becomes an argument, and the schedule becomes a defense. Risks are only seen when you get your hands dirty. ✅ Practical Application: The 48-Hour Rule If there is a “vaguely difficult” task, do the work to just verify the risk within 48 hours first. API Integration → Try connecting just minimum call/auth Performance Worries → Check bottlenecks with dummy data Screen Ambiguity → Check reaction with prototype Doing this becomes grounds for decision-making, not an “excuse”. 4) Manage “Blocked Points and Decisions”, Not “% Progress” The phrase most used by plan-centric teams: “We are currently 70% done.” The reason this phrase is dangerous is that hell might exist in the remaining 30%. Execution-centric management looks at it like this. Where is the blocked point right now? What decision is needed? Who needs to decide and when? ✅ Practical Application: Daily 10-Minute Checklist What is the one thing blocked today? What decision is needed to break through it? Who is the person to decide today? Sharing just these three drastically reduces misunderstandings between business and dev teams. 5) Keep the Schedule, But Do Not Keep It While “Damaging the Intent” If you rush the schedule, abandon the intent, and just fill in the features, the result is this. An unwanted product fitted to the schedule What's more fatal in a startup is not a product coming out late, but a product that came out fast but is different from the business intent. ✅ Practical Application: Priorities When the Schedule Collapses Scope Adjustment (Maintain Intent) Implementation Simplification (Maintain Intent) Launch Schedule Change In other words, the schedule is adjustable, but the intent must not be broken. Conclusion: Not “Schedule”, But “Intent” Binds the Team Together If we focus on the plan, we can become a “team that keeps the schedule”. But if we focus on execution, we become a “team that implements business intent”. And for business and dev teams to move as one team in a startup, what is ultimately needed is this. Not the schedule, but Execution Management Aligned with Intent If you run only with the schedule, business and development create constant misunderstandings while having different goals. Conversely, if you share the intent, even if the schedule shakes a little, the confidence that you are looking at the same goal remains. That is what keeps the team from collapsing.2026.01.12
TPMHow can a team function without a TPM?
A New Solution Through BCTO and Aline.team When the topic of TPM (Technical Program Manager) arises in early-stage startups, the same question always follows: “Do we need a TPM?” And then, a realistic answer emerges: “We need one, but it’s difficult right now.” This article discusses why the TPM role exists and what changes when their responsibilities are broken down and implemented through systems instead of people. We will also explain where BCTO and Aline.team fit into this process. Why Was a TPM Needed? A TPM is not just a simple schedule manager. While a PM focuses on “What should we build?”, a TPM is responsible for the following questions: How is this work progressing? Who is becoming a bottleneck? How do technical decisions impact schedule and risks? How are the dependencies between multiple teams connected? As organizations grow and systems become more complex, these questions naturally converge on one person. That person is the TPM. This is also why TPMs are crucial in large corporations. A TPM is the person who connects technical and organizational complexity. But Why Is It Difficult for Early-Stage Startups? The challenge lies in the reality of early-stage startups. Experienced TPMs come with a high cost. The smaller the team, the more disproportionate the management burden becomes. Ultimately, many decisions rely on people’s experience and memory. Therefore, in most early-stage teams, the CTO or tech lead takes on the TPM role in addition to development. The problem is that this structure doesn't last long. Developers increasingly become coordinators, and while coordination increases, the basis for decisions becomes unclear. Breaking Down the Role from People to Systems Here lies a crucial shift in perspective: Instead of asking, “Should we hire a TPM?” ask, “What structure can handle the tasks a TPM performs?” If we divide the TPM's responsibilities, there are broadly two categories: Observing and explaining Facilitating coordination and decision-making Do these two areas necessarily require a person to handle them entirely? BCTO: Systematizing the TPM’s ‘Observation and Visibility’ BCTO automates the observation and reporting that TPMs do daily, using data. Based on actual Git commits, PRs, and issues, it shows “What is currently in progress?” and through developer work patterns and flows, it explains “Why did it slow down?” It transforms schedule delays or excessive optimism into evidence for proactive measures, not post-hoc analysis. The important point in this process is that it is about explanation, not evaluation. It doesn't show who did well or poorly, but rather what structures and flows led to certain outcomes. While a TPM would provide explanations through meetings and documents, BCTO offers continuously updated data. Aline.team: Supplementing the TPM’s ‘Coordination and Decision Support’ Aline.team goes a step further. The questions that TPMs often found most challenging are typically: Should a senior or junior developer handle this task? Is the current bottleneck technical or communication-related? Why does team speed vary with the same number of people? Aline.team learns individual developers' development patterns and strengths, analyzes task types and team situations together, and aims to answer questions like: “Who is the most rational choice to take on this task?” “Why was this schedule predicted this way?” “Where should intervention occur to speed up the overall flow?” This is less about making decisions for you and more about supporting decisions to make them explainable. So, Do BCTO and Aline.team Replace TPMs? To be precise, no. These two products are not tools designed to eliminate the TPM role. Instead, they enable the following: Teams to function without a dedicated TPM. Existing TPMs to focus on more critical decision-making. It creates a structure where systems handle 70-80% of the tasks a human TPM would perform, allowing people to concentrate on the remaining 20-30% of true judgment and responsibility. In One Sentence TPM is a role, and BCTO and Aline.team turn that role into a scalable system. What early-stage teams need is not perfect consensus or more coordination. A clear understanding of who makes decisions. The ability to explain why those decisions were made. A structure where accountability for outcomes is not blurred. When that structure is maintained, experience becomes a strength, and the team accelerates.2026.01.08
Code qualityCode quality and technical debt
And when should we clean up
When talking about development with startup CEOs, I often see them using “code quality is low” and “too much technical debt has accumulated” as almost the same meaning. However, these two are not the same. If you don't understand the distinction, it becomes difficult to judge when to sprint and when to clean up. Difference Between Code Quality and Technical Debt Code quality is a story about the current state. Can other developers understand this code? Is it predictable where it will break when modified? Can the current team take responsibility for and operate this code? On the other hand, technical debt is a story about future costs. Because choices were postponed now, a state where more time and resources must be spent later A structure where the burden increases every time a feature is added To summarize, it can be said like this: Code quality is the state of now, and technical debt is the future burden that state will create. When code quality drops, technical debt accumulates easily, and as technical debt accumulates, improving code quality costs more. The two are close to a relationship that feeds each other. So the Question CEOs Ask Most Often When I talk up to here, there is a question that almost always comes up. “Then when should our team clean up technical debt and raise code quality?” Answering “always” doesn't fit reality, and saying “not now” only increases anxiety. So I usually suggest one criterion for judgment. One Practical Criterion Is our development team's development history stable enough in function and operation that there are no problems with the service's business deployment even if there are no major changes in production for at least 6 months? If you can answer “yes” to this question, it is highly likely that now is the time to clean up technical debt and raise code quality. This criterion is not a development perspective but a business perspective criterion. Even without adding more features right away, customer response and operation are possible, and sales or service expansion discussions do not stop Only when there is this much breathing room does the cleanup work have meaning. Why 6 Months? 6 months is not a technically magical number. However, in startup reality, it is quite a realistic unit. 3 months is often too short for problems to surface, and 12 months is often when temporary fixes have already become the structure 6 months is the minimum time to judge “is this code holding back the business right now?” One Important Caveat When using this criterion, there is a sentence that must always be used with it. “6 months is not a fixed rule, but a standard to judge whether our team has a ‘breathing interval’ to clean up technical debt.” Without this sentence, the conversation immediately flows like this: “Why 6 months?” “Our service is 4 months old?” “Is 12 months not okay?” Arguments surrounding the period number solve no problems. What's important is not how many months, but whether we can catch our breath for a moment. Adding One More Thing If you have decided to clean up technical debt, you must be able to answer the following questions. What do you intend to change? Why now? Who is responsible? Cleanup that cannot be explained mostly creates another debt. Improving code quality should not be done “because we want to be neat,” but a choice made to protect future speed. In Conclusion Technical debt is unavoidable in startups. The problem is not the existence of debt, but running without knowing when you are in a state to pay it back. If you have started talking about code quality, the signal might have already arrived sufficiently. What is needed now is not the courage to slow down, but a standard to judge when cleanup is possible. The clearer that standard becomes, the code, the team, and the business will look in the same direction.2026.01.06
Code qualityWhen the term "code quality" comes up in a startup,
Are we really looking at the same problem? When startup CEOs come to me for advice on development team issues, there's one phrase they use more than any other. “I think the code quality is low.” “That's why development speed is so slow.” “Maintenance is almost impossible in this state.” “Further development is difficult in this condition.” At first, we naturally formed this hypothesis: Perhaps they have a developer acquaintance, and that acquaintance used these terms. However, as we repeatedly solved similar problems, a strange feeling began to emerge. Why do the CEOs of such small organizations bring up a rather technical issue like ‘code quality’ to me? A Recurring Pattern Began to Emerge As I continued to consult, I noticed common situations that appeared quite frequently. Initial development completed by an external vendor Subsequently hired junior developers internally Attempting to start operations and further development And then the words appear “This code has such low quality that a senior developer needs to redesign it and rebuild it from scratch.” At first glance, this statement sounds very reasonable. However, upon closer inspection, it often points to a slightly different problem. “Code Quality” Sometimes Becomes a Defense Mechanism When junior developers take over code developed by external vendors for operation, they often feel a much greater burden than expected. Difficulty understanding the overall structure Lack of context on why it was designed that way Side effects occurring even with minor modifications Unclear scope of responsibility In this situation, it's not easy to say, “I don't have enough experience yet, so I need more time.” Instead, a much safer phrase emerges: “It’s because the code quality is low.” This statement shifts the cause from personal capability to an external entity: the code. Even if unintentional, it effectively becomes an excellent defense argument. The problem arises the moment this statement is communicated to the CEO. The Arrow Always Flies in the Same Direction From the CEO's perspective, it sounds like this: “The current team can’t handle it.” “We need to hire a new senior developer.” “The development so far has been flawed.” From that moment on, the focus of the problem shifts from the structure or process to people. Who failed? Who is lacking? Who needs to change? And that arrow usually points towards the same developers. So, I Often Advise This When the topic of code quality arises, I often tell CEOs: “In the current situation, rather than rushing to hire a senior developer, it might be the better choice for the current team to take more time and continue with this code.” This doesn't mean the code is perfect, nor does it mean seniors are unnecessary. However, it rests on the premise that: The current difficulties are less about the quality of the code and more likely due to a lack of context, insufficient understanding, gaps in handover, and the common mismatch of roles and expectations in small organizations. Code Quality is a Result, Not a Cause This is especially true in very small organizations. Code quality is less about individual skill and more a cumulative result of the team's decision-making process, time pressures, and unexplained choices. Yet, we often summarize this complex issue with the single word “code quality.” From that moment on, the conversation stops, and responsibility merely shifts. Concluding This Article This article is not intended to blame junior developers, nor to criticize the CEO's judgment. However, one thing is clear: When the phrase “code quality is low” arises, it's worth taking a moment to re-examine whether it truly refers only to the code itself. Perhaps hidden within it lies an organizational issue that has yet to be articulated.2026.01.05
Development effort3 months vs 5 days
Whose Word Should We Trust? This happened when I was working as a startup CTO. After designing a feature, I called developer A, who had been with the company for a while, and asked for an estimated completion time. The answer was "It will take about 3 months." I was from a development background and had gone through similar projects many times. Honestly, it didn't make sense. So, I called a newly joined developer and asked the same question. The answer was "It will take 5 days." This moment is a disaster for managers or executives without project experience. 3 months vs. 5 days. The difference isn't just a matter of opinion; it's a number that shakes up business schedules, resource allocation, costs, and investment timelines. So, who should we trust? Was Developer A Wrong? Not necessarily. Experienced developers often provide Requirement changes QA and communication costs Technical debt Post-deployment risks as part of a "realistic timeframe." The 3 months might not be "coding time" but rather "time to take responsibility if something goes wrong." Then, Was the Developer Who Said 5 Days Exaggerating? This is also not the case. The new developer might have been stating The requirements are fixed Ideal conditions Based solely on their scope of work the "pure implementation time." This is also true. If it were just about writing code, 5 days might be accurate. The Problem is the Standard, Not the People The real issue in this situation is not who is right. What standard was used for the estimate? What risks were included? How does it compare to similar past tasks? The problem is the complete lack of visible grounds for these questions. From a manager's perspective, there's no way to distinguish between a "slow developer" and an "exaggerating developer." Ultimately, they resort to gut feelings, and those gut feelings almost always ruin the project. What's Needed is Comparable Numbers To reduce this confusion, estimating development timelines requires at least the following: Actual time spent on similar features in the past Average deviation at the individual and team level Ratio of design to implementation, review, and deployment Impact of anticipated risks on the schedule In other words, instead of "This time it's 3 months" or "This time it's 5 days," everyone should be able to understand why that duration is estimated and how it compares to previous projects. Development Timelines are a Matter of Data, Not Gut Feeling Developers don't lie. They simply speak from different perspectives. The problem is the lack of a common language and metrics to explain these differences, and the burden always falls on the managers and the entire organization. It's time to ask "What can we use as a basis for judgment?" rather than "Whom should we trust?"2026.01.03
Development teamAI can accelerate development but also slow down the team
AI has now gone beyond being a tool that makes development easier, and has entered a stage where workforce reduction is being realistically discussed. In my experience, doing more work faster has certainly become possible. From code generation and test supplementation to refactoring suggestions, AI significantly boosts developer productivity. However, if you ask whether a non-developer can perfectly perform development tasks using only vibe coding, my answer is clear. “It is still very difficult.” The problem isn't simply about grammar or technical proficiency. The task of repeatedly making partial modifications without understanding the code is far more dangerous than one might think. Especially when working in a team of two or more, AI might become a tool that rapidly accumulates technical debt rather than increasing productivity. AI generates plausible code by referencing context, but it does not take responsibility for whether that code: Aligns with our team's design philosophy Respects the intent of the existing code Is a structure that is maintainable and scalable in the long term There is an actual case. Our team once hired a junior developer to work on a project. Lacking project and team experience, the developer focused on implementing immediate features rather than fully understanding the existing source code. With AI's help, features were built quickly, but the senior developer had to spend more time organizing the results to fit the team's code style and structure. Ultimately, to meet team standards, the design had to be supplemented, code rewritten, and the intent documented. What I felt during this process was clear. AI gives speed to the individual, but it can leave behind debt in the form of unaligned code for the team. In particular, apps built by junior developers alone with AI assistance might look highly complete initially, but often, the cost of modification skyrockets with even small requirement changes. I realized once again that technical debt arises not from the amount of code, but from unshared intent and context. So when a new developer joins the team, I feel that now, more than tech stack or speed, The ability to understand and accept team culture Experience writing code with collaboration in mind A mindset that considers the “next person” over “immediate implementation” have become much more important. If I were to consider hiring a junior developer again, I would probably ask this: Not “How well do you use AI?” But “How much have you respected others' code while working?” In an era where AI accelerates development, in teams where two or more people work together, human thinking and collaborative ability become the most powerful mechanisms to reduce technical debt. Therefore, I judge future developers not as people who create a lot of code, but as people who know how to create together.2026.01.02
DeveloperIn front of the request to find a "good developer," there are two things I always ask.
When a problem arises in development, I often receive requests like, “Please find me a great developer.” Each time, I almost reflexively ask two questions. First, “What kind of person do you consider a ‘great developer,’ CEO?” Second, “Are you perhaps building an operating system like Windows or macOS?” In most cases, they shake their heads at the second question. And then, a brief silence follows the first question. The True Meaning of a ‘Great Developer’ According to CEOs When startup CEOs say “great developer,” they usually don’t mean a top 1% genius developer. The person they truly want is typically someone like this: Someone who doesn’t escalate problems. Someone who can proceed without lengthy explanations. Not a monster who writes tech blogs all night, but Someone who understands our team’s context and moves forward with us. In other words, rather than “someone who writes code exceptionally well,” it’s “someone who makes work flow smoothly when working together.” Most Startups Aren’t Building ‘Operating Systems’ To be blunt, what most startups are building isn’t groundbreaking algorithms or the world’s first technology. Services centered around CRUD. Products that combine existing technologies. Early-stage projects where speed and direction are more critical. In such situations, what’s needed isn’t extremely outstanding individual technical skill, but rather a developer who operates stably within the team. Therefore, ‘Rhythm’ is More Important Than ‘Skills’ Of course, basic development competency is important. However, in a startup, other aspects are more crucial. An attitude of understanding the incompleteness of planning. An effort to read unspoken intentions. The rhythm with the CEO, designers, and other developers. Ultimately, what the CEO is looking for isn’t “a developer without problems,” but “someone who can handle problems together.” The ‘Great Developer’ I Speak Of Is Someone Like This So, I summarize it this way: A great developer is not someone with a flashy tech stack, but someone who makes work progress within our team. And such a developer is revealed not through a resume, not through GitHub stars, but through their rhythm with people.2025.12.29
MistakeTechnology has always developed on the premise of human error.
When I was a junior developer, I heard an impressive story from a colleague I worked with. He recalled his time developing services at a large telecommunications company in Korea like this. One day, due to a mistake by one developer, an incident occurred where all the source code on the server was deleted entirely. It's hard to imagine by today's standards, but back then, there were no version control tools or proper backup policies. The code on the server was the 'sole original', and its disappearance meant the project itself was gone. The entire team fell into a panic at that moment, and after a moment of silence, the team leader said this: “Well… since it’s happened, let’s go have some makgeolli.” It might sound like a joke, but it was actually closer to resignation, meaning there was nothing more they could do. Unexpected Salvation, and a Fact No One Spoke Of However, just as they were about to leave, a freelance developer on the team cautiously spoke up. “Perhaps I… after finishing work each day, I zip the source code and keep it on my personal PC.” The moment they heard that, the atmosphere in the meeting room completely changed. The ironic part is, that action was actually a clear violation of the company's security policy. Storing source code in a personal repository was not permitted. Nevertheless, no one objected. At that moment, saving the project was more important than the regulations. In the end, they returned to the office without finishing their makgeolli, unzipped the files, and stayed up all night restoring the lost code. It wasn't perfect, but the project survived. A Story That Rarely Happens Now The colleague added, that such an incident would hardly happen now. Because there's Git, there are branching strategies, there's automatic backup, and there are CI/CD pipelines. It's not because people don't make mistakes, but because technology has evolved with the premise of human error, which was impressive. Technology Grows by Acknowledging Human Imperfection People make mistakes. And the history of software is not an attempt to eliminate those mistakes, but a process of designing systems that can withstand them. Version control started from the fact that “people can delete code,” backup is the result of acknowledging the premise that “data will disappear someday,” and automation was created based on the understanding that “people are not always perfect.” Good technology does not demand perfection from people. It creates a structure that doesn't collapse even if people make mistakes. That’s Why This Story Lingers The makgeolli that day was not just a simple anecdote, but felt like a symbol that clearly shows why technology has evolved into its current form. Technology does not deny human mistakes. Technology evolves in a safer direction, based on those mistakes. This is why the story I heard from my colleague still comes to mind often.2025.12.24
01. Getting Started
2025.12.23 
