Forem: BJ Kim

Between Delegation and Hands-On Leadership

BJ Kim — Thu, 05 Feb 2026 14:55:58 +0000

As I assigned a task to a junior colleague, questions flooded my mind. Should I step back and let them handle it, or should I stay closely involved? This decision turned out to be harder than I expected. After leading various teams for about 10 years, I'd like to share my thoughts on how to choose between delegation and close collaboration.

Delegation Works When You Think Alike

The right time to delegate is when your thinking aligns with the other person's in the big picture. When this alignment exists, you can expect things to run smoothly without much friction.

But can two people really think the same way? I don't think that's possible. We're humans, not machines. We can never think identically—we can only make similar choices and express ourselves in similar ways.

That's why delegation works best when you entrust tasks to someone who makes judgments similar to yours. At least in the organizations I've managed, this has held true. When I delegated to people who shared my perspective, the results fell within expected bounds. When I didn't, both parties ended up struggling.

So how do you find such people?

Love Makes Us Alike

Have you ever heard the saying that people who love each other grow to resemble one another? It actually seems to be true. They become similar not just in personality and speech patterns, but even in appearance. This happens because they spend so much time facing each other, looking at each other, and talking. In fact, our vocal cords respond to the sounds we hear, our facial muscles mirror the expressions we see, and our hearts are moved by the emotions of those beside us.

Why am I bringing this up? Because the person who thinks and expresses themselves similarly to you might not be someone you need to find and recruit—they could become that way through your existing colleagues. Loving your colleagues, inspiring them, and being inspired by them in return. All of these interactions might be the process of cultivating people who share your sensibilities. In a way, this could be the key to helping people grow.

Of course, people's core nature doesn't change easily. But there are certainly aspects that can shift depending on circumstances. Isn't MBTI a good example? How boring would it be to live a 100-year life locked into one of just 16 personality types? There's nothing quite as thrilling as watching people change, grow, and be transformed.

What about the opposite scenario?

When Close Collaboration Is Necessary

With people who are truly different from you, you need more frequent and closer communication. Acknowledging that you and I are different—that's where it starts.

Here's an important point. As a leader, you can't surround yourself only with people similar to you. Rather, you must be able to embrace those who are different. Teams become stronger when people with diverse perspectives and capabilities come together. And embracing different people requires more communication, more attention, and more love. What you can convey to a similar person in one conversation might take ten conversations with someone different. This process might feel tedious, but I believe it's the burden a leader must bear.

If things begin without sufficient groundwork, both parties will struggle tremendously. This is because expectations exist. When baseline standards differ, personal values and perspectives can diverge sharply. Add a lack of communication to that, and expectations start being mistaken for given facts.

"Shouldn't someone at this level just figure it out?" "Shouldn't a team lead at least know what I'm working on?"

Rather than assigning blame, these situations arise because neither party successfully communicated their position to the other.

If a leader hastily delegates in such a relationship, it can lead to uncontrollable outcomes. I've seen cases where it devolved into outright neglect. The line between delegation and neglect is razor-thin. It depends on how much effort you've put into understanding the work.

So what constitutes sufficient effort?

Who Sets the Standard for Effort?

The absolute amount of effort shouldn't be measured by your own standards. The real measure is how much the other person trusts you. Only when your effort reaches and is felt by the other person will they begin to move—and that's when things truly start.

From a leader's perspective, delegating without this process is, in my view, neglect. No matter how well you understand the work, the perspective from the operational level can be entirely different. Even if you think you've communicated enough, if the other person doesn't feel that way, your effort is still insufficient.

This is why leaders who are too skilled at hands-on work can be dangerous in their own way. Because they understand the work so well, they tend to skip explanations, assume too many things are obvious, and that gap can feel frustrating to team members. Understanding the work and conveying that understanding effectively are two separate competencies.

Conversely, the process of effectively communicating what you do is equally important. I'm not saying to create work for work's sake, or to play politics. Instead of dwelling on "Why is my team lead asking me to do this?", try thinking "Why did they come to make this request?" Eventually, the reason will become clear. If it makes sense, do it. If it doesn't, exchange opinions or officially raise the issue. Silence is the worst approach.

In summary, what matters is whether there's an atmosphere where such conversations can happen without silence, and whether there's an environment where issues can be officially raised. Since this too falls under the leader's responsibility, the leader's role is significant throughout the entire process.

In the future, we may see a social culture where people work alone. For hands-on leaders, this could actually be an opportunity. They can fulfill an entire team's role by themselves. Not many people can work this way. Shouldn't companies create cultures and environments where such individuals can operate like special forces?

What, ultimately, is the endpoint of leadership? I believe it's creating a state where you can delegate 100%. People who share your sensibilities, people who are different but whom you've embraced and grown alongside, and people who are better than you. When you can appropriately distribute work among these various individuals and fully entrust it to them, only then can a leader begin to see the bigger picture. There's no right answer in the space between delegation and hands-on involvement. But continuously checking how well you understand the other person, and whether that understanding is being conveyed to them, while moving toward that endpoint—that's the standard I've found for myself.

Coding with AI

BJ Kim — Thu, 05 Feb 2026 14:55:02 +0000

The past year has been the most painful time in my 20 years of professional life. While leading the development team at Flap, I had to accept the decision not to backfill departing employees, and with the remaining resources, I had to cover not just BE and FE, but also SE, QA, and AI—all of it. Because I had never worked this way before, even accepting and adapting to it took all my energy, let alone understanding it.

Looking back at how the company came to make that decision, it ultimately came down to not keeping pace with the startup scene, which is feeling the impact of AI-driven changes across the IT industry first. Just as Stack Overflow's traffic has plummeted, countless business models that provided coding education are now facing a crisis. Because people are using AI to generate code directly.

Yet paradoxically, I myself am enjoying coding more than ever right now.

Rediscovering the Joy of Coding

For the past 10 years, I needed colleagues' help to properly implement the things that required development. There were certainly parts I couldn't handle alone. But now, I'm building and managing all of those things through AI. In the past, I would struggle all day solving difficult bugs and have no energy left to spend time with my wife after work. Now, thanks to AI as a pair programming partner, my mental fatigue has decreased significantly.

Before, when I got stuck on tasks like Stripe webhook integration, I would spend half a day digging through documentation, searching Stack Overflow, and asking colleagues. Now, I explain the context to AI, have a few exchanges, and most problems get solved. That time can now be spent on more important decision-making.

Of course, there's also the opposite experience. Lately, I'm realizing I need to use AI in moderation as I watch myself spending more time on development because of it. I thought better tools would mean less work, but instead, the things I can do have multiplied. Features I used to put off saying "that would take too much effort" are now things I can actually attempt.

Vibe Coding and the Developer's Role

I hear the term "vibe coding" a lot these days. It's the approach of giving AI a rough direction and having it write the code. Even if AI writes code in 20 minutes, I still review and refactor the code for essential core features myself. Of course, I give AI feedback and it makes revisions based on that.

Code written by AI works. But it's often complex or inefficient. Variable names don't fit the context, unnecessary abstractions get added, or error handling becomes overly defensive. I think developers now need to transform from people who write every line themselves to supervisors who manage the overall design and verify AI's output.

If writing code quickly used to be what mattered, now it seems like what matters is how well you can read and judge the code AI writes. And this judgment ultimately comes from the experience and knowledge you've accumulated.

There's one more thing that has become important here: the ability to translate business requirements into technical design. AI will build whatever you tell it to build. But "what should be built" is still a human domain. What does the user really want? What value does this feature bring to the business? What role should this component play in the overall system? These judgments cannot be made by AI. In fact, as implementation speed has increased, I feel the importance of design capabilities—deciding what to implement—has grown even more.

On the Counterarguments

At this point, there are some expected objections.

"Doesn't depending on AI weaken developers' fundamentals?"

Honestly, this is a valid concern. I fully understand the worry that developers who grow up in an environment where AI writes code for them might lack foundational strength. But I think about it a bit differently. When calculators came out, there were concerns that "mental arithmetic abilities will deteriorate." That may have actually happened. But did we give up using calculators because of that? Rather, thanks to calculators, we became able to handle more complex problems.

Similarly, thanks to AI, we can now focus on higher-level problems. The energy we used to spend memorizing syntax or API usage can now be spent on architecture design or understanding business logic. Isn't the very definition of "fundamentals" changing?

"Don't you still need to know how to code yourself to verify AI-generated code?"

Yes. That's why I said past experience and knowledge aren't useless. You need the experience of having written code yourself to spot problems in AI-generated code. However, how developers starting their careers will build that experience is definitely a point that needs consideration. Perhaps the learning approach itself needs to change. Something like coding with AI from the start while training to critically review AI's output.

"Doesn't this mean only people who are good with AI tools will survive?"

To some extent, yes. But this applies to all technological change. When Excel came out, accountants who were good at Excel had an advantage. When the internet came out, people who were good at searching for information had an advantage. The emergence of new tools always redefines existing expertise. What matters isn't resisting change, but how you redefine your strengths within that change.

Accept and Adapt

To be honest, until mid-2025, I felt resistant to AI writing code for me. I thought, "Is this really my code?" and felt somewhat uneasy. But now I've accepted that this is an unstoppable trend, and I routinely dedicate time to actively leveraging it.

Lamenting that you miss the old ways is meaningless. To not fall behind those who are achieving much higher productivity using AI, you must get on board with this change. As someone said, you need to know how to use a day like a month. To do that, moving with intention and making it routine is extremely important.

Let me use Kübler-Ross's five stages as an example. Denying AI, getting angry at AI-generated code, becoming depressed when facing the reality that it's more productive than you, going through the stage of bargaining with "maybe I should use it a little," and then reaching the acceptance stage of actively incorporating it into daily life. I can confidently say that whoever reaches this acceptance stage first will have a different future.

The age of coding hasn't ended—it has merely changed shape. Past education and knowledge aren't useless; they will become the foundation for better utilizing and verifying AI. Just because tractors were invented doesn't mean people stopped farming. The form has simply changed.

It's time to stop grieving and embrace the new era.

What stage are you at right now?

A Workplace with Stories to Tell

BJ Kim — Sat, 24 Jan 2026 10:05:02 +0000

A Workplace with Stories to Tell

A while ago, a colleague of 10 years resigned. When I asked why they were leaving a company they'd been at so long, they answered: "I no longer have anything to say. Every meeting, I found myself just repeating the same things."

On the other hand, there's a senior who's been at one company for over 15 years. They still speak passionately at every meeting, come up with new ideas, and debate with juniors. Even after working at the same company for 15 years, they didn't look worn out.

What's the difference? How can you work at a company for a long time?

I think this: If you can repeatedly talk without getting tired about things you want to say, it's possible.

What Does "Stories You Want to Tell" Mean?

The "stories you want to tell" I'm talking about here aren't routine work reports. Not things like "Here's a progress update" or "No issues" that repeat routinely.

"Wanting to" is an active action. It's a result that comes from values important to you as a person, messages you want to convey to others, or an attitude that goes beyond trying to fulfill your role—something that stems from that.

I have that experience too. When starting a new project, I had things I really wanted to say to the team. "What if we tried it this way?", "Users find this part inconvenient, I think we should improve it", "I wish our team would pursue this value."

When I talked about those things, I wasn't tired. Even if meetings went over 2 hours, I wanted to keep talking. On the other hand, when I was just doing what I was told, even 30-minute meetings exhausted me.

What Makes People Active

So what makes people active?

The first is instinct. When cold, we layer up; when hungry, we make food; when tired, we sleep. We do these without being told. It's the same at work. If there's performance bonus on the line, we work actively; if promotion opportunity appears, we move proactively.

The second is affection for others. Like always yielding to the person you love, we've all experienced being active when we're the one who needs something. If a colleague we like asks for help, we gladly help; if a leader we respect makes a suggestion, we voluntarily participate.

The third is when we discover meaning. When we know what we do helps someone, when we feel our role is essential to the team, when we're certain we're growing through this work—that's when people move actively.

I experienced this third one about 3 years ago. When team members said about a system I built, "This is really convenient, work has become so much easier thanks to you"—in that moment, my work gained meaning. After that, I kept working on system improvements without anyone telling me to.

The Root of Being Active: Love

But there's something more fundamental that runs through all three. I express it as love.

If you can know yourself well, cherish and love yourself, you become active. You move on your own for your growth, for your value.

If you can show interest in and love others, you become active. You gladly spend time helping colleagues grow and helping the team succeed.

If you can discover meaning in your work and love it, you become active. You take initiative to make better products, to build better team culture.

The Difference Between Liking and Loving

But here many people get confused. They can't distinguish between liking and loving.

Can you keep talking without getting tired at the liking stage? With just simple favor, you can try once or twice. But in the process, you become curious about the other's reaction, naturally develop expectations, and as disappointment accumulates, you stop repeating.

I was the same. When I first joined a team, I shared various ideas. But after being ignored a few times, I stopped offering opinions. It was because I only liked the subject. It was impulsive favor, an emotion below that.

If I had loved, I wouldn't have stopped. I'd still be repeating it without getting tired now.

So what is love?

The Definition of Love

Neuroscientist Dr. Dongseon Jang explains love this way: love is when the brain's reward circuit activates while conditional expectations disappear. In other words, it's an emotion that makes you act without transactional thinking like "If I do this, they'll do that for me."

Liking expects rewards. "If I work hard, I'll be recognized." "If I help, they'll be grateful." "If I share my opinion, it'll be accepted." So when expectations aren't met, disappointment follows and you quit.

Love is different. The other person's happiness itself is the reward. "I'm happy just seeing this team succeed." "The growth of my colleague itself brings me joy." "Making users' lives easier is my fulfillment." You can continue even without immediate recognition or reward.

I realized this around my 6th year. It was okay even if a feature I made wasn't immediately praised. When someone said 3 months later, "That feature from back then made work easier"—that alone was enough. In that moment, I realized I love this work.

How to Work at a Company for a Long Time

Ultimately, the method for working at a company for a long time is simple. Love the company, love colleagues, love what you do.

Then stories you want to tell emerge. Stories you can tell repeatedly without getting tired. Even after 10 years, 15 years, you can still speak passionately at meetings.

Finding a Workplace You Can Love

Of course, you can't love every company. Some companies are hard to love. When values don't match, when you don't fit with colleagues, when you can't find meaning in the work.

Then you have two choices.

First, try to find something to love at your current company. Even if not the whole company, look for something to love among your team, colleagues, projects you're responsible for. It might be closer than you think.

Second, leave to find a company you can love. Sometimes it's better to find a place where you can naturally love, rather than forcing yourself to love.

I've been through several companies. And joining Plab, I've led the development team for a year. Not a long time yet, but there's been definite change.

At first, I was busy adapting to the new environment. But as I talked with team members one by one, solved problems together, and watched them grow, I realized: I've come to love these development team members.

And now I'm going further, trying to love the company itself and the role the company expects of me. It's not perfect. The reason I use "trying to" is that I'm still in the process. Like I came to love the team members, I trust I'll gradually come to love the company and my role more.

What about you? Do you have stories you want to tell at your current company? Stories you can tell repeatedly without getting tired?

If you do, congratulations. You're already loving. Please nurture that love well.

If you don't, I recommend looking for one. It doesn't have to be the whole company. Start small, from one colleague, from one project. Look for something you can love.

As that small love accumulates, someday you'll be a senior who's been there 10, 15 years. Still speaking passionately, still not tired, still overflowing with things to say.

The Developer's Role in Agile Organizations

BJ Kim — Sat, 24 Jan 2026 09:57:48 +0000

The Developer's Role in Agile Organizations

It's been quite a while since the word "agile" became everyday vocabulary in the IT industry. Sprint, scrum, kanban, backlog—these terms have become familiar. But when asked what role a developer should play in an agile organization, it's not easy to answer readily.

Writing code. Of course, that's right. But that's what developers do in any organization. What an organization with the name "agile" expects from developers is probably a different dimension.

From Someone Who Receives Requirements to Someone Who Defines Them

In traditional development organizations, there was clear division of roles: planners organized requirements, developers implemented them. When documents came over, you just built accordingly. But in agile, these boundaries blur.

During sprint planning when discussing backlog items together, developers don't just answer "How long will this take?" They're expected to offer opinions like "Do we really need this feature?", "Wouldn't doing it this way achieve the same effect more simply?", "This part is technically uncertain, so I think we should verify it first."

Developers end up participating in what was thought to be the planning domain. It might feel like overstepping, but in agile, this is actually natural.

Prioritizing Learning Over Completion

In waterfall methodology, perfect design was pursued from the start. Predicting and planning everything before starting development was considered virtue. But agile acknowledges uncertainty. Under the premise that you can't know everything, building quickly and learning quickly is valued.

From this perspective, the developer's role changes too. Rather than trying to write perfect code from the start, making working code quickly and getting feedback becomes more valuable. Refactoring becomes not something shameful but a natural process.

An organization where "What did we learn this sprint?" is a more meaningful question than "You should have done it right from the start"—that's the direction agile aims for, I think.

Not My Code, But Our Product

Among developers, we often use the expression "my code." It's an expression of attachment and responsibility for code you've written. But in agile, this boundary becomes a bit uncomfortable.

With pair programming, you can't distinguish whose code it is. When others' opinions are reflected through code review, it's even more so. In teams doing mob programming, all code becomes the team's collective output.

What developers need in this environment is to let go of possessiveness. Not feeling bad when code you wrote is modified by someone else. Rather, being happy together if it became better code. It's not easy, but I think it's a mindset needed for good collaboration in agile organizations.

The Courage to Speak About Technical Debt

Since deploying quickly and getting feedback is important, technical debt sometimes accumulates. Code implemented hastily under schedule pressure, parts postponed saying "we'll refactor later." Sometimes these things are left unattended under the name of agile.

The developer's role becomes important here. Being able to tell the team that technical debt is accumulating, and saying that time is needed to resolve it. Honestly saying in sprint retrospectives "I think we're sacrificing quality for speed"—this is also a role developers should play in agile organizations.

Just quickly processing business requirements isn't everything. Maintaining technical health for sustainable pace—developers' voices are essential for this balance.

Ultimately, It's About Communication

The first value in the Agile Manifesto is "Individuals and interactions over processes and tools." Ultimately, the core of agile is communication between people. Developers are no exception.

The era of speaking only through code has passed. Talking with planners, discussing with designers, sharing opinions with other developers. Clearly sharing your situation in standup meetings, asking for help when you're stuck—all of this is what agile organizations expect from developers.

There are many developers who find communication awkward. I was too, and I'm still not perfect. But if you work in an agile organization, communication skills become as important as coding skills. Perhaps even more.

In Closing

Agile isn't a cure-all. It doesn't fit every organization or every project. But the values agile pursues—fast feedback, continuous improvement, collaboration and communication—I think these are meaningful regardless of what methodology you use.

If I summarize the developer's role in agile organizations in one phrase, it would be the expansion from "someone who writes code" to "someone who builds the product together." That expansion might be burdensome, or it might actually be fun. Either way, thinking about your role in a changing environment is definitely worthwhile.

From Learning to Wisdom

BJ Kim — Sat, 24 Jan 2026 09:56:57 +0000

From Learning to Wisdom

A while ago, I had drinks with former colleagues. After a few drinks and various conversations, a senior developer brought up something like this: "These days I wonder if the system I built is really right. The initial requirements were clearly not this, but as conflicting features and policies kept being added, now users have to use it in ways they never imagined."

Then a junior said cautiously: "Actually, I was always confused when submitting PRs for that system. I wasn't sure if I was using it right, but I'm glad we're talking about it today." After that, we continued talking about how each person prefers to build things, what development approach would have been better for those requirements. Conversations that would never have happened in an actual development meeting room started flowing freely at the bar.

On my way home, I suddenly thought: Why can't we talk like this in the meeting room?

Knowledge Accumulates, But Wisdom Is Different

Learning presumes acquiring knowledge. We accumulate knowledge by reading books, attending lectures, writing code. But having a lot of knowledge doesn't mean wisdom follows.

I had a similar experience. Around my third year as a developer, I thought I knew and could do quite a lot. I knew design patterns, algorithms, and had frameworks I could handle proficiently. When I took on a new project, I mobilized all that knowledge to quickly build a system. Completed it in 4 months and was proud.

But as the service operation started, requirements grew day by day. Operations people were suggesting and presenting requirements in ways I never expected. I managed to implement them somehow, but dependencies between modules broke, causing unexpected errors and constant new issues I'd never seen. Eventually, watching things not work as originally intended, I got angry.

'Why don't they use it as intended, as originally requested?'
'If they use it this way, of course problems will occur. People are so stupid.'

For 6 months—longer than the development time—I blamed users while fixing bugs. Having to test directly to fix bugs, inevitably becoming a user myself, testing feature operations one by one, I suddenly realized:

'With this implementation, of course there's room for misunderstanding and problems.'
'Ah, I've been making garbage.'

Development is the process of creating something from nothing, and I think any developer with sufficient knowledge can create any feature shown in production, given the right conditions. But the seams and craftsmanship differ for each creator. Eventually, the process of making it your own is needed, and that's when wisdom to distinguish right from wrong develops, I think.

Thus, what's essential for knowledge to transfer to wisdom is execution. But simply executing isn't enough.

Starting to Understand Users and Myself

After that realization, my questions changed. "How can people use this without misunderstanding?" "How can I make them use it one more time?"

Technology came after that. Knowledge overflows everywhere in the world, and implementation is no longer a difficult task based on it. With AI help, code can be written anytime. Sometimes it produces results far better than mine. But building a service that people actually use required a slightly different approach.

So I started observing the service and the people using it. How do users use it, where do they get lost, which features do they look for most. Even for the same feature, usage methods differed by organization, policies differed, and attitudes toward people differed. So I tried different approaches and solutions for each changing organization.

I definitely grew through my own problem-solving methods. I started getting a sense of which choices and technologies to use in various situations. But there was a blind spot. I wasn't reflecting on or introspecting about my execution.

I still remember. Around my 8th year, I was doing an ad system renewal project, and during a design review, a junior asked me:

"Our system is memcached-based, why are we using Redis for this project?"
"When building something new, if we don't try it at times like this, when will we?"

In a company, how I'm perceived as a person ultimately comes from my accumulated choices. In that sense, it was a rather immature answer. A naive answer from when I was infatuated with new things, without clear standards or rationale.

From then on, whenever projects big or small reach a conclusion, I do retrospectives as soon as possible. I intentionally exchange questions like "Was this development approach ultimately right?", "Given current requirements, how should we have developed?", "How are users using it?", "If I did it again, what opinions could I offer?" Making it a routine improved my ability to accept both positive and negative feedback.

The Courage to Acknowledge My Ignorance

But there was another trap here. As my judgment criteria built through experience and reflection became more established, it became harder to accept different opinions. Thoughts like 'I've already gone through this case 3 times, and you're doing it for the first time' started appearing.

The decisive moment was when I immediately rejected a method proposed by a junior. "That method won't work. You're using RDB but want to serialize data with null true without normalized table design—do you really think that's right?" But that junior didn't give up and came back with a prototype. In the end, there were no problems. Because it wasn't a service storing large amounts of data.

I didn't show it, but I was angry and embarrassed. The situations where I didn't sufficiently listen to the other person's opinion, trapped in my experience and continuing the conversation, were shameful. I felt then that as experience accumulates, there's actually a risk of falling into narrow thinking.

People who don't fear the collision of knowledge, who acknowledge that their experience not based on the situation could be wrong, who can endure and accept the process that occurs from openly exchanging opinions—they're more likely to become wise.

An Environment Where Opinions Can Be Exchanged

So how do we freely exchange opinions? Actually, exchanging opinions isn't possible in every situation just because I want to. There needs to be another party for opinions to flow.

I feel this in every meeting of 5+ people, wherever I go. There are specific people who dominate the atmosphere and do all the talking in meetings. They say "feel free to share opinions" but usually no one speaks. Why do we repeatedly experience this pattern? How can free communication happen?

Psychological safety. This keyword originating from Harvard Business School Professor Amy Edmondson is cited as a very important factor in operating organizations. It refers to an atmosphere where any talk is okay, where trust, comfort, and naturalness coexist.

Real psychological safety isn't one-sided permission. It's an environment where even if a junior opposes a senior's opinion, that opposing opinion is respected and seriously considered. A place where mistakes aren't criticized but treated as learning opportunities. A place where honestly saying you don't know doesn't get you dismissed.

What Understanding People Means

But the hardest part of all these processes was something else. It was understanding people.

First, you have to invest a lot in getting to know people, and this isn't an area of knowledge that someone can just teach you or guide you through.

Some team members want direct feedback; others need time to realize things themselves. Some people learn through failure; others become more cautious because they fear failure. The same words motivate some while others feel pressured.

I didn't learn this from a manual. Over 10+ years managing dozens of people, I came to understand bit by bit through countless trial and error. Even now, when new team members join, I start learning again from the beginning.

With one team member, it took 2 years. At first, my feedback style didn't suit them and the relationship was awkward. But through continuous conversation and gradually changing approaches, at some point we came to understand each other. That process was definitely not something that could be learned as knowledge.

Still Learning

I still don't know many things. New technologies keep coming out, team situations keep changing, and people each pursue different things. In the past, this would have made me anxious. Thoughts like 'I'm a senior but shouldn't I know this at least.'

But now I know. Wisdom comes not from knowing everything, but from the attitude of acknowledging what you don't know and continuing to learn.

Knowledge accumulates, but wisdom doesn't accumulate. Wisdom gradually grows through the endless process of executing knowledge, reflecting, colliding with different opinions, acknowledging your inadequacies, and trying to understand the subject.

What stage are you at? Accumulating knowledge, executing, or reflecting? Any stage is fine. What matters is not stopping this routine.

Why not try this at your next meeting? Honestly saying "I don't know this part well." That one phrase can create psychological safety in your team and enable better exchange of opinions.

The journey from knowledge to wisdom is hard alone. It becomes possible only when we're with people who share opinions together, acknowledge each other's ignorance, and keep learning. I hope you have such colleagues, and I hope you become such a colleague too.

Whose Job Is It?

BJ Kim — Sat, 24 Jan 2026 09:48:31 +0000

Whose Job Is It?

A while ago, a message appeared in our Slack channel. It was a small bug found in production—it only occurred under specific conditions, so it wasn't having a big impact on the service right away. But the problem was that it wasn't clear which team's territory this bug belonged to. It occurred somewhere on the boundary between frontend and backend, precisely at an ambiguous point in the API spec both teams had agreed on.

After the message was posted, no one responded for about 30 minutes. The "read" count kept increasing though. I also hesitated for a while after seeing that message. 'Is this our team's job? Or the other team's?' Eventually, after about an hour, someone cautiously asked: "Who should look at this?"

Important But Not Important, Yet Someone Has to Do It

In service operations, situations like this happen more often than you'd think. Not an important feature, not urgent, but definitely something someone has to handle. A typo in a customer service response, incorrect information discovered on the internal wiki, old data piling up in the test environment. These things don't immediately stop the service or directly affect revenue.

But when these small things pile up, the service gradually ages. More importantly, how the team handles these things eventually becomes the team's culture.

As a developer, I've experienced this countless times. Especially after becoming a team lead, I encounter it even more frequently. Every time I see team members cautiously asking in Slack, every time someone asks "Is it okay if I do this?", I often feel a bitter emotion.

Whose Job Should It Be?

"Whose job is this?"

It's a very simple question. But it's also a very delicate question to answer. Those who can easily answer this question are probably one of two types: people who genuinely think it's not their job, and people who just do it as if it were their own.

If you're watching others' reactions and can't answer, that's a somewhat bitter situation. It's clearly something that needs to be done, but because it's unclear whose job it is, everyone just watches each other. In this situation, it's easy to say "take initiative." But this phrase becomes relative the moment you say it, precisely because of the word "initiative."

Because everyone has different standards for what initiative means.

The Limits of the Word "Initiative"

Last year, I had a conversation with a team member. In my view, they were someone who worked quite proactively, but they themselves felt they lacked initiative. "Other people work so much more actively than me. I'm still far from that."

In that moment, I realized: "initiative" is a hard concept to measure. For some people, going even slightly beyond their work scope feels proactive. For others, only solving team-wide problems feels proactive.

The bigger problem is that "take initiative" can sound like a demand for unlimited responsibility. Should I do things that aren't my job too? Where does initiative end and where does it become excessive? While pondering these questions, you end up doing nothing.

People Who Just Do It

So what should we do? Should we create clear standards? "This type of work is Team A's, that type is Team B's"—would defining it like this help?

In my experience, even if you create such standards, boundaries eventually emerge. And at those boundaries, the same problems occur. What I've observed across multiple teams over about 6 years is that well-functioning teams have something in common: they have "people who just do it."

"People who just do it" don't ask questions like "Is it okay if I do this?" Instead, they say: "I handled this." Or "Let me take a look at this."

They're not people with especially strong initiative or outstanding abilities. They're just people who, when there's something to be done, do it. Of course, they don't unconditionally do things that really aren't their job. But if it's something someone has to do and the owner is unclear, they handle it without overthinking.

I try to be that kind of person too. Not perfect, but at least I tend to raise my hand first when these things happen in the team. About 3 years ago when I was on the backend team, I discovered a small bug on the frontend side. It wasn't my job at the time, but it looked like 30 minutes would be enough to fix. So I just fixed it. Shared it with the frontend team and opened a PR.

After that, collaboration with the frontend team became much smoother. They also started raising their hands first when they found small problems on the backend side. Without anyone going first, we naturally started working across each other's territories.

But It Shouldn't Become Exploitation

There's an important point here. Saying "be a person who just does it" doesn't mean take on all the work. This shouldn't lead to exploitation.

In some teams, when a specific person keeps handling these things, an implicit expectation forms that "this person does these kinds of things." Then the "person who just does it" takes on more and more work, eventually reaching burnout.

What's needed is for the whole team to create a "culture of just doing it." Not one person handling all boundary work, but whoever has the capacity at the time, or whoever can do that work best, naturally raising their hand. And the team recognizing and appreciating that behavior.

In our team, we share these things during weekly retrospectives. "Someone handled this this week." And we express gratitude to that person. It's a small thing, but when these accumulate, it becomes a "culture of just doing it."

The Attitude That Keeps Services Alive

Ultimately, the attitude needed for service operations is this, I think. The answer to "Whose job is this?" becomes "Someone has to do it, so I'll do it." And people with that attitude gather to create a team that naturally handles necessary work without exploiting each other.

As a development team lead, I try not to tell team members to "take initiative." Instead, I try to show that example first myself. When something with unclear ownership comes up, I raise my hand first. And when a team member handles such a thing, I always recognize and express thanks.

Of course, it's still hard. Sometimes I think "Do I really have to do this?" and sometimes I worry if team members are taking on too much. But in those moments, I think: we're not just making code—we're making a service, and a service is the sum of these small things.

If it's something someone has to do, it doesn't matter who does it. What matters is that the work gets done, and in that process, we respect and appreciate each other. I believe teams built that way ultimately make better services.

That bug that came up in Slack a while ago—I ended up fixing it. It took about 30 minutes. And after that, one team member said this: "Because you do it first, I feel like I can do these things without burden too." Those words felt really good.

We're not a perfect team yet, but I feel like we're getting a little better. As "Whose job is this?" questions decrease and "I'll do it" answers increase.

Start Rather Than Overthink

BJ Kim — Sat, 24 Jan 2026 09:47:18 +0000

Start Rather Than Overthink

There's a saying that "mountains and rivers change in 10 years." But having lived through 10 years, the surrounding environment doesn't change as easily as you'd think. Some things remain the same even after 10 years.

Recently, I had drinks with a junior colleague and we had this conversation. They wanted to get more opportunities at work, be recognized, and grow. But they didn't know how, so I asked:
"What problem are you currently thinking about? Or have you stepped up to solve anything yourself?"
The junior thought for a moment and said:
"There are many things I want to try. But the company doesn't give me work that lets me think about these things. I'm always doing the same work, and I'm so busy with just that that I don't have opportunities to do what I want."

Did the junior realize while speaking? That waiting for work to be given or for the environment to change is like waiting for an apple to fall under an apple tree.

There's a phrase I often quote on this topic: "In work, which comes first—the chicken or the egg?"

The chicken first: "If I'm given that role, responsibility, authority, and mission, I'm confident I can do it."
The egg first: "If I prove what attitude and mindset I work with daily and what kind of person I am, someday I'll receive the work I want, the bigger opportunities."

There's no right answer, but the world has more often been egg first. There were occasional chicken-first situations, but looking at those cases alone, the person was never a chicken to begin with—they were a phoenix.

So in general terms, if I want my work or role to change, if I want to grow, if I want more opportunities, I have to prove myself.

Time is 24 hours for everyone. How efficiently you use and manage that time can either prove yourself or let yourself stagnate.

I dare say this is the difference in action between someone who reads this and thinks "oh, I see" and moves on, versus someone who picks up at least one action item to do starting tomorrow.

Gems Shine When Cut

Taking action means exposing yourself. Exposing yourself means there's a possibility of being struck by arrows or polished by weathering. Your form changes. Your shape changes. Changing is painful.

But gems are valued not as rough stones but when they're cut and polished. People are the same.

There are people who roll themselves around and polish themselves. People who raise their hands for new projects, volunteer to learn unfamiliar technologies, and don't shy away from challenges that might fail. These people have mastered the art of cutting themselves.

On the other hand, some people don't yet know how to roll themselves. In that case, they shouldn't fear the hands of others or the wind and rain. They need to accept feedback, push themselves into uncomfortable situations, and learn through mistakes.

The most unfortunate case is not being able to roll yourself while also fearing the hands of others and the wind and rain. Then the rough stone remains a rough stone forever.

The Safe Zone Called Overthinking

In some ways, overthinking too much might come from a desire not to lose even a little bit—whether it's time, money, or emotion. Under the belief that you're very prudent and wise.

I was the same. When learning new technology, changing departments, or changing jobs, I overthought endlessly. I listed pros and cons, trying to find the best choice. But looking back, the time spent overthinking itself was the biggest loss.

I mistook the time spent constantly worrying as a moment. But the amount of stress accumulated from this repetitive pattern was quite significant. Plus, I lost opportunities for unintended fun experiences. In some sense, that was the real loss.

The world doesn't wait. While I'm overthinking, the world moves forward. Now I think the definition of the "thinking" stage needs to change. Thinking should be a day at most; execution should be right now.

You Only Know By Starting

It's not knowing something and then starting, but having to start to know—I feel this repeatedly throughout life.

I decided to become a developer in my mid-20s. I didn't know if it suited me, if I could do well, if I could do it my whole life. I just thought, since I majored in computer science, this must be right, and started. About 10 years later, I realized "Ah, I like the process of making things," and so I tried woodworking and now brew coffee every day. I think I could continue those routines because I enjoy the process of making. Then one day I became a tech leader, enjoying the process of building together with developers, and 20 years later, I'm grateful I can continue this work.

What if I had just worried in my 20s, "I'm not sure if being a developer suits me"? The current me probably wouldn't exist.

Try anything, even something small, and if you don't get tired of it, keep going. If you keep at it, you'll have the fascinating experience of getting closer to the real you that even you didn't know.

Learning Starts from Discomfort

Sometimes I think about what my role is. Creating a comfortable environment for team members? Of course, psychological safety is important. But from a growth perspective, it's a bit different.

The premise of learning something, of acquiring something, is that the environment needs to be uncomfortable. Learning occurs in situations where you have to do something but can't.

I thought back to my early days as a developer, which now feels like ancient history. When my mentor said "Do this by Friday" and gave me an assignment, I was overwhelmed at first. I didn't know how. But I had to do it. So I searched, dug through code, asked seniors, and somehow got it done. I learned the most during that process. Though it became a problem that it solidified into my way of solving problems.

Learning doesn't happen in a comfortable state. You just repeat what you already know. Sometimes giving discomfort—presenting appropriate challenges—is the biggest help.

Of course, the balance between challenge and frustration is important. In my case, if it was too difficult, I would complete it but not succeed, and the burden from the rough process and failure broke my body. But I dare to suggest that appropriately uncomfortable situations can be catalysts for growth.

Courage Is Starting Even When Not Perfect

Someone having grown doesn't necessarily mean they succeeded. It just means they faced their fear and experienced the process and the end.

Having grown, whether big or small, starts from the courage of stepping forward even knowing it's dark and you can't see. I think this has much greater meaning than any success someone might speak of.

Looking back, my today originated from countless failures. My first project missed its deadline, my first leadership role was hard due to conflicts with team members, my first job change wasn't as satisfying as I'd thought. But if I had been buried in those failures, today's me wouldn't exist.

I'm here now because I acknowledged, endured, and accepted failure. And what I learned in that process made who I am today.

I hope you have the courage to trudge forward despite reasons not to. The time we have to act after realizing something has always already passed, or if it exists, it's too short. So you have to go now, without delay, to where your heart leads.

If you repeat this process, rather than regretting results and failures, you start praising yourself for the courage of that moment when you could go. I think the next decision will find a version of me that's a bit wiser, making choices that aren't too late and therefore quite right.

In Closing

How about filling your daily life with at least one thing you make time for because you like it, not things you do when you have time? What's scary is scary, and taking a step is taking a step.

Living this long, I've come to understand. You don't change as you age—you become more yourself. So these days I'm a bit nervous because the road ahead is both far and near. Maybe I'm excited. Anyway, you have to try to know.

Having someone to push you from behind and getting to do things is a blessing. But if there's no such person? You have to push yourself. Reduce the time spent overthinking and muster the courage to start.

Is there something you really want to look at closely? How many things? What have you started to look at them?

Beauty doesn't exist for anyone—it's the privilege of those who discover it. To discover, you have to move; to move, you have to start.

Just start. A day is enough for thinking. The rest is execution. No one knows where that small start will take you. But one thing is certain: if you don't start, nothing happens.

I support and cheer for all your choices, attempts, successes, and failures. I hope you have a day with the courage to start rather than overthink.

What Matters More Than Experience

BJ Kim — Sat, 24 Jan 2026 09:39:35 +0000

What Matters More Than Experience

Recently, I posted a senior developer job opening. More applicants came in than expected, and as I conducted interviews, I felt a strange sensation. Resumes listed 10 or 15 years of experience, but as I had conversations, the word "experience" suddenly felt unfamiliar.

Colleague: How's the senior hiring going?
Me: It's harder than I thought. Finding someone within the compensation our company can offer, with experience in the tech stack we want, who resonates with our team culture and vision, who isn't cynical about the company direction, and who has good work habits... I didn't know finding someone who satisfies all of this would be this difficult.

As I was speaking, I realized something. What I was looking for wasn't simply "someone with a lot of experience" described by multiple lines on a resume.

What Are We Really Looking For?

While interviewing, I discovered an interesting pattern. There was no real correlation between the numbers on the experience section and the feeling of "I want to work with this person" during actual conversations.

In fact, I was more drawn to a 3-year candidate who honestly acknowledged what they didn't know, saying "I don't have experience in this area yet, but I'd like to learn." On the other hand, when a 10-year candidate kept talking about only one technology and showed defensive attitudes toward other approaches, it was hard to continue the conversation.

"Ambition, character and brains have little to do with experience."

I'd seen this quote somewhere, and it kept coming to mind during interviews. It's really true. Having worked for 10 years doesn't mean you've developed a good attitude. Experience is an accumulation of time, but attitude and communication ability are entirely different dimensions.

The Small Moments We Face Daily

These thoughts didn't come only from hiring. I face similar questions every day working with team members.

During a one-on-one, a junior team member opened up that work felt overwhelming. They were learning a lot, but often didn't know why their work was needed or how it helped the team. They said not finding meaning was harder than technical difficulties.

My one-on-one style varies between formal format and free-flowing conversation on various topics, so exchanges often happen spontaneously. Organizing my thoughts from then, I realized that for some people, these values are very important and worth sharing. As a tech lead, giving problem-solving methods and proper technical guidance is important. But what might be more important is helping this person find meaning in their work—as a colleague who works with them, before being a tech lead.

That's why I try to make time, not just use spare time, to have many conversations with team members. I do one-on-ones, have coffee while asking how they're doing, listen to what they like and what's hard for them. Everyone has their own strengths, and finding those strengths sometimes creates much bigger changes than technical guidance.

This approach might not match current trends. But since the processes that make most organizations work aren't that cutting-edge, I think you need blurry eyes and appropriate adaptation.

That said, there's also a sad truth. No matter how hard colleagues try, if they can't find that person's strengths, they'll eventually be pushed out of the organization. The leader is the first to notice such moments. That's probably why I care more. And leaders themselves aren't exempt from this case. Leaders must be most aware that they're in a position where they need to check themselves and work harder so they don't run out of value or mission to contribute to the organization.

A Place to Safely Make Mistakes

Recently, a junior team member accidentally brought down the dev server. They reported to me with a pale face, and I asked:

Me: What were you thinking when you ran that command?
Team member: I was trying to improve deployment speed... but I misunderstood an option.
Me: So what do you think you should do next time?
Team member: Test thoroughly in local first, and if I'm uncertain, ask someone.

That team member became the most meticulous person on the team when it comes to deployment processes 3 months later. What if I had interrogated them with "Why on earth did you do that?" They probably would have shrunk back and never tried anything new again.

The feeling of being safe to say anything within an organization—they call this "psychological safety." Organizations that respond to a junior cautiously sharing an opinion with "That's an interesting idea, how specifically would we do it?" versus organizations that start with "That won't work, because..." look completely different 6 months later.

In the former, juniors start actively sharing opinions. In the latter, only silence fills meetings. Ultimately, those small reactions one by one are what create organizational culture, aren't they?

People Before Process

I was confused when the team grew from 5 to 20 people. It became hard for me to talk with every team member directly, and difficult to understand in detail who was doing what.

'The team should run well even without me...'

So I created code review processes, built deployment automation, and organized documentation systems. These were definitely necessary and actually helpful. But about 6 months in, I received unexpected feedback from team members. They said code reviews felt formalistic. It felt like just checking a checklist and getting approval. Before, they used to learn things and have conversations during reviews, but now it just felt like a procedure.

I realized then: processes and systems are just tools. No matter how good a process you create, if the people using it don't feel meaning, it's just a checklist.

So I changed the code review process. Not "seniors check junior code" but "we learn from each other's code." Seniors can learn new approaches from junior code, and juniors grow from senior feedback. More importantly, conversations happen in that process. The "1 emoji per day" campaign also came from that process.

The Question That Keeps Coming Back

The concerns that started with posting a job opening have now become daily questions.

'How can this person grow in our team?'
'How can this person discover and demonstrate their strengths?'
'Is our team psychologically safe for this person?'

When you look at people, what do you consider most important? The numbers on the resume's experience section, or their attitude and potential?

I now know this: a 2-year person with a good attitude can create much bigger change in a team than a 10-year veteran. And recognizing such people and creating an environment where they can safely grow—that's what leaders should do.

Of course, it's not easy. Looking past the numbers on the experience section to see attitude sometimes feels like a risky choice. But teams built from those accumulated choices are definitely different. They become teams that respect each other, view mistakes as learning opportunities, and respect good ideas regardless of experience level.

In your next interview or team member evaluation, why not try this once? Before looking at the experience section, look first at their attitude and communication style. Imagine how much they could grow in a psychologically safe environment.

That small change might completely transform your team and organization. I'm still learning every day too, but of this I'm certain: the eye for seeing people starts not from the numbers on the experience section, but from their attitude and potential.

I hope relationships where we believe in each other's potential grow, one person at a time. Why not look for potential that's not on the resume in someone you meet today?

Developer Motivation in the AI Era

BJ Kim — Sat, 24 Jan 2026 09:38:10 +0000

Developer Motivation in the AI Era

Recently, I paid $100 for Claude. In that moment, I felt a strange sensation. It was like everything I'd built over 20 years as a developer was suddenly being unlocked all at once. It was fascinating, and at the same time, a bit bitter.

Having lunch with team members, this conversation came up:

Colleague A: "These days when I ask AI about code, it writes cleaner code than me. Honestly, it feels a bit deflating."
Colleague B: "Right, sometimes I wonder if I'll really become unnecessary."
Me: "But think about it—tractors were invented in the 18th century, 300 years have passed, and farmers still exist."

Just because tractors appeared doesn't mean humans stopped farming. Just because there was a dot-com bubble doesn't mean the internet disappeared. The numbers decreased and the forms changed, that's all. If AI is playing the role of a tractor in the development ecosystem right now, wouldn't developers still need to exist? The question is whether I can be one of those remaining developers.

There's something called Kübler-Ross's five stages of grief: denial, anger, depression, bargaining, acceptance. It describes the emotional stages someone goes through when given a terminal diagnosis, and I thought the way developers are responding to AI these days is similar.

From "AI-written code? I can't trust it" (denial), to "I have to review code written by AI?" (anger), to looking around and seeing AI talk everywhere (depression), to "Maybe I should at least try ChatGPT..." (bargaining), eventually reaching acceptance.

I was the same. You have to try it to know. After trying it, supplementing what's lacking, and discussing better ways to use it with colleagues, at some point you realize: "Ah, I need to use this." And for a developer to realize that means there's no going back.

In this time of change, reflecting on myself, I thought about motivation.

Motivation can be broadly divided into extrinsic and intrinsic motivation. Extrinsic motivation includes things like rewards, honor, and praise. They might seem materialistic at first glance, but these are actually values that have been inscribed in our DNA over millions of years as advantageous for survival. Better housing, more popularity, power that prevents others from treating you carelessly—these are perfectly natural desires.

However, extrinsic motivation is highly impulsive and temporary. As a simple example, when you receive a Chuseok bonus—an extra month's salary—how long does the feeling of "Wow, this is a great company, I should work hard" last? In my experience, exactly 3 months. My conclusion from years of company life is that extrinsic motivation can be kindling, but it can't be the firewood.

What we ultimately need is intrinsic motivation. What moves me, and why does it move me? A time comes when knowing yourself becomes important.

If you don't know what you like or why you like it, I recommend just starting with what people around you tell you to do.

Did Kim Yuna really start figure skating because she loved it? As shown in famous interviews, sometimes not assigning meaning or reason and just doing it is very important.

I think that's one of thousands of reasons why Kim Yuna could become the best. Talent was the next necessary element. Wouldn't that talent have gone undiscovered if she hadn't done what her parents told her to try?

What moves you, and why does it move you?

Honestly, few people have clear answers to this question. I'm the same.

I started drinking Americanos about 10 years ago when I began drinking Kanu instant coffee. I've been brewing coffee myself for about 6 years. I'm someone who spends most of my leisure time in laziness, and looking back now, I don't even know why I started this bothersome habit.

I happened to taste filter coffee, happened to have an opportunity to brew coffee, and it tasted pretty good for a first attempt. That coincidence became routine, and one morning after being led along like that, when the coffee brewed exactly according to the flavor notes—that feeling that bursts forth... it was similar to the feeling of playing a soccer game where the passes were insanely good, I wasn't tired, and I was just having fun.

That routine continued and continued, and now my humble end-of-life goal that I tell people about is eventually opening a café. Actually, there's a high chance I won't. Since people around me often ask in small talk, it might have become a habit from deflecting answers. Who knows what life will bring?

But yesterday and today, I brewed and drank coffee every morning, and I'll do it again tomorrow. Now that time has become my most enjoyable and precious time. That's how meaning was assigned.

So what I want to repeatedly say is: if you don't know what you like or why you like it, just try it first.

Don't think "Ugh, why do they keep making me do these things?"—just try it. If you really can't do it after trying, say you can't. They'll tell you to try something else. But saying you can't without even trying—that's a different problem.

If you absolutely don't understand why they're asking you to do something, try it first. The meaning and interpretation can come later. Like me.

Of course, if despite all that you lack motivation and can't do it, I say take a rest. That's probably being in the depression stage.

If you connect Kübler-Ross's graphs, they become life graphs. Ultimately, it's no exaggeration to say our lives depend on how healthily we spend our time at the bottom, our depressed time. Sometimes during this time, we meet ourselves within. What do I need, what do I want, what story do I want to tell? We need to treat ourselves slowly, carefully, and kindly.

You must be able to love and cherish yourself before you can love and cherish others. I'm not just saying something from a book somewhere. It's really true.

Last weekend, my wife asked to take the dog for a walk. Lying on the couch watching TV, I was too lazy and pretended not to hear, but when my wife started to go out alone, I reluctantly followed. I really don't like walking.

But as soon as I stepped outside, I encountered the tail end of beautifully colored autumn leaves. Before I knew it, time was flying by as I collected fallen leaves. While happily gathering leaves, my wife said:

"Are you the same person who was too lazy to go out just a moment ago?"

That's when I realized. Ah, I don't like drinking alcohol but I like collecting it, and I don't like walking but I like picking up beautifully colored autumn leaves. When I got home, I noticed the thick books on my bookshelf were full of leaves I'd collected and tucked in over the years.

It was a "me" I hadn't been aware of until then. And it was fascinating that all of this came from following my wife out reluctantly for a dog walk. It was a "me" I wouldn't have known if I'd stayed oblivious and just watched TV without following.

Looking back, more memorable than the moments when I chose the best option close to the right answer after endless deliberation to avoid failure, were the moments when I just tried things and encountered and explored various "whys."

"Why" wasn't a clear answer or definition. It was a direction that gradually revealed itself, and that was "me" itself. Not knowing something and then starting, but having to start to know—I feel this repeatedly throughout life.

Lastly, I'd like to add one more thing: please don't define yourself as "I'm this kind of person." I mean, don't box yourself in. Talking in terms of MBTI is just icebreaking and small talk at best.

Rolling yourself around and around, and through the various perspectives gained that way, calibrating the zero point of who you are—finding goals comes after that, I think.

I support and cheer for all your choices, attempts, successes, and failures.

Master Your Time

BJ Kim — Sat, 24 Jan 2026 09:29:52 +0000

I watched that Running Man episode so enjoyably that it suddenly came to mind and made me write. Nothing more.

I'm just going to write about how I tried this and it worked for me.

By nature, I've never been early anywhere. School, academy, appointments, even the military! But there's one life pattern I picked up through a superior I met at my previous company who taught me many things.

Arriving at work earlier than the scheduled time!

That's the medicine I'm selling today.

'Why does that person come in an hour early?' 'No way, they only sleep 3-4 hours a day?'

We only worked together for a year, so it's more regrettable but perhaps that's why it struck me so intensely.

Since then, I try to come at least an hour early, or at minimum 30 minutes early, almost every day.

You Gain Margin

This is the biggest reason. Obvious, but not obvious.

If you come early and start working, it loses its meaning.

For example, if I come an hour early, I spend about 10 minutes preparing coffee and snacks, about 30 minutes reading a chapter of a book or studying English, about 10 minutes spacing out, and the remaining 10 minutes checking emails that came overnight while scheduling my day's work before joining the standup meeting.

There's a famous quote from Baemin's CEO Bongjin Kim: "9:01 is not 9:00." It's a phrase that contains many things depending on how you think about it.

Your Expression Brightens

Interestingly, when you have margin, your expression brightens as a positive cycle. Because your day is organized in your head, you're confident and assured when anyone asks. That stance naturally affects interpersonal relationships.

Think about it. How good can the expression be of someone who was just crammed in the subway from hell, ran in breathlessly to avoid being late, and joined the standup catching their breath?

Considering that half of most company work is relationships and communication with people, by coming in a bit early, you've already crossed the threshold, haven't you?

Higher Probability of High Daily Satisfaction

Same context. As troubles in relationships with people decrease, so do chances of getting red-faced or stressed.

Not only that, by grasping the day's work intensity efficiently before starting, you know in advance when you'll catch your breath, enabling appropriate energy distribution and time management.

The conclusion is that time is equally given to everyone, but how you greet it can completely change the feeling.

Just try it for one week.

Arriving at work earlier than the scheduled time!

Try this medicine once, and become someone who leads your precious time. In that process, new routines, communication, and processes will emerge.

What Is Love?

BJ Kim — Sat, 24 Jan 2026 09:29:48 +0000

On my way home from work recently, a thought suddenly came to me. What did I do for someone today? I did code reviews, listened to a junior's concerns, and bought the bread my wife likes on the way home. And I came to think that each of those things was ultimately love.

When people hear the word love, most think of the feelings between lovers. But having worked for nearly 20 years and been married for over 10, I've come to think that love isn't something so grand.

I want to define love like this: willingly spending time for someone else.

Think about it—there's no resource as equal yet finite as time. Everyone has 24 hours in a day, and that time doesn't come back. Spending such precious time on someone—isn't that the most honest expression of love?

When a junior at work comes to me stuck on something, honestly, sometimes it's bothersome. I have my own work to do. But going beyond that annoyance to think together for 30 minutes or an hour—that's love for colleagues, I think. I'm not just saying something from a book somewhere. It's really true.

It's the same with my wife. Early in our marriage, I thought I needed to do grand events for every anniversary. But 10 years later, what my wife really appreciates isn't that. Going for walks together even when tired after work, making a cup of coffee on weekend mornings, listening to her talk until the end. Ultimately, it was spending time together.

Of course, just spending time doesn't automatically become love. If you're reluctantly sitting next to someone while looking at your phone, that's not spending time. I think real love is being completely present with the other person during that time.

But there's something important here: love means giving before receiving.

When I was young, I wanted to be loved. But as I age, I realize: it's much more comfortable to give love first than to wait to be loved.

Looking back, my happiest moments were mostly when I gave something to someone. When a junior solved a problem with my help, when my wife smiles at something small I did for her, when my child hugs me saying it was fun playing together.

So love is ultimately the time invested in relationships, being completely present with the other person during that time, and starting by giving rather than receiving.

It doesn't need to be grand. Offering a cup of coffee to a colleague next to you today, making a phone call to check on family—those small things gather to become love. I hope your day today is filled with such small loves.

On Consistency

BJ Kim — Sat, 24 Jan 2026 09:23:14 +0000

On my way home from work recently, I passed by the gym and suddenly thought: that 3-month membership I signed up for at the beginning of last year—how many days did I actually go? Twenty times? No, honestly it was probably less than fifteen.

But strangely, the English study I started around the same time has continued for 6 months. 15 minutes a day, on the subway during my commute. It doesn't seem like much, but it's accumulated to over 90 hours. The gym and English study—what was the difference?

The answer was surprisingly simple. For the gym, I had to debate "Should I go today or not?" every time. For English, I just automatically started when I got on the subway. Consistency turned out to be not a matter of willpower but a matter of systems.

The Importance of Routines

It's easy to think of consistency as "a characteristic of people with strong willpower." But in my experience, consistent people often have well-designed systems rather than strong willpower.

People pay a decision-making cost every time they have to form a new resolve. Psychology calls this decision fatigue. Conversely, routines automate behavior. When a trigger occurs, you execute without thinking. The power of routines is making it so you don't ask "Should I or shouldn't I?"

How to Form Routines

The biggest mistake when creating routines is "starting grandiose."

Fix the trigger - Concrete triggers attached to actions are better. Things like "after brushing teeth," "before brewing coffee."

Start with 2-5 minutes - Not an hour of exercise but 10 squats, not a whole book but 3 pages. If you do a 2-minute routine for 30 days, your body remembers.

Define by action, not result - "Read one book" is a goal, but a routine should be a unit you can execute today, like "read 3 pages daily."

Stack routines - I linked "brew coffee → 3 minutes stretching → start work." Each one is small, but when connected like a chain, it's hard to break.

Managing Routine Sustainability

Set an SLO - Rather than 100% achievement, set a service level objective like "success if 5 times per week." If you aim for 80-90% from the start, it's okay to take a day off.

Keep only 1 observable metric - I just mark O on Google Calendar. If recording becomes annoying, routines collapse.

Create a failure response plan - Not "if I missed it, double tomorrow" but fallback routines like "on days I can't, the 1-minute version."

Consistency is structure, not emotion. If you make routines small to fit yourself and operate them so they can be reattached even when broken, at some point consistency becomes not "effort" but "default." Like brushing teeth daily, you just do it.

Why not start just one thing? 2 minutes is enough. Just repeat those 2 minutes for 30 days. At some point, you'll find your default has changed.