DEV Community: Johnny Ilmo Koo

Five Warning Signs of Outsourcing to Avoid

Johnny Ilmo Koo — Mon, 28 Oct 2024 01:34:58 +0000

This article was created with development agency outsourcing in mind, but the principles apply to outsourcing in any field.

Choosing the right outsourcing partner is a critical decision for any client. A wrong choice can lead to wasted time and money, or worse, put the entire product at risk. In this article, we’ll look at five key warning signs that indicate an outsourcing company might not be the right fit, illustrated with some real-life examples.

1. Lack of Transparent Communication

Let’s look at a story from a client who faced issues with poor communication from an outsourcing partner. the client found that the communication lines with the development team were virtually non-existent. Every time the client asked for an update, the answer was always, “Everything is going well,” but there were no details. the client often found herself wondering, “What exactly is going well?” When the first release finally came out, it was completely off-track from her expectations, and it was only then that she realized how disconnected the project had been. Poor communication erodes trust and can turn small issues into major ones. Imagine trying to navigate a maze without a map—that’s how Kim felt, and it ultimately led to losing her way.

2. Lack of Understanding of Business Goals

If an outsourcing partner shows no interest in understanding the client's business processes or the goals behind a project, it’s a major red flag. Developing software isn’t just about ticking off a list of requirements—it’s about adapting to the client's goals and context. There are times when developers need to make assumptions or have the freedom to choose a direction in the absence of specific instructions. To do this effectively, they need to understand the bigger picture and the client’s vision. A team that doesn’t take the time to understand these aspects will struggle to deliver meaningful outcomes.

3. Unclear Contracts and Scope

One client, the client, started a project without a clear contract and ended up feeling like they had earned an advanced degree in frustration. The scope was vague, and every time requirements changed, the outsourcing partner added extra charges. For example, the contract only mentioned “user authentication,” but when Lee wanted a complex social login system, the team kept billing it as an “additional feature.” Lee thought, “Wasn’t authentication supposed to cover that?” Without clear agreements, projects are more likely to end in disputes or unnecessary expenses.

Another issue arises when the outsourcing company doesn’t ask for specifics or properly clarify the requirements with the client. Lee thought the team would figure everything out, but it turned out they had misunderstood the requirements completely. Midway through, the deliverable didn’t match Lee’s expectations at all, leading to more rework and expenses. Conversely, if the team doesn’t ask questions and instead makes assumptions, the final result often ends with, “This isn’t what I wanted.” To prevent such situations, it’s crucial to thoroughly discuss and document requirements in the initial stages.

4. Unrealistic Promises

“We can deliver all features in just two weeks!” sounded great to a client named the client. At first, the client was impressed—this company seemed like a magician! However, the reality was quite different. Once development started, there were far more bugs than anticipated, and the timeline kept getting pushed back. Park realized that this was less magic and more illusion. Development always comes with uncertainties, and unrealistic promises are usually a sign of deeper problems. It’s much better to choose a company that provides realistic timelines and is transparent about challenges. Unrealistic promises are often bait, leading to poor quality outcomes later.

Another red flag is when the outsourcing team simply agrees to all requests without offering any pushback or alternative suggestions. Even if a client asks for unreasonable things, a good partner should guide them, highlight pros and cons, and provide realistic directions. For instance, when Park asked, “Can you do all this in a month?” and the developer said, “Sure, no problem!” without hesitation, it ended in delayed timelines and subpar results. If the partner had been honest and set realistic expectations from the start, the outcome could have been far better.

5. Suspiciously Low Estimates

Another client, the client, learned the hard way after choosing an outsourcing company with a suspiciously low estimate. Initially, the price seemed unbeatable, but throughout the project, the team kept saying, “This will require additional costs.” Jung thought, “It would have been better to pay a fair price and get things done properly from the start.” In the end, the final cost was much higher than expected, and the quality of work was subpar. Going for the lowest bid often leads to hidden costs or compromised quality.

Selecting the right outsourcing partner is about more than just cost—it’s a critical decision that can make or break a project. Avoiding these red flags can increase your chances of a successful partnership. The best collaborations are built on mutual trust, transparent communication, clear contracts, realistic expectations, a solid understanding of business goals, and a reasonable pricing structure. By keeping these factors in mind, you can minimize risks and achieve the results you’re aiming for.

If you’re looking for a trusted development agency, we’d love to connect! With expertise in automation projects, admin dashboards, and back-office applications, we’re here to help streamline your operations. Reach out at johnnykoo@kooslab.net to schedule a free 30-minute consultation via video call. Let’s explore how we can bring your vision to real!

A Beginner’s Guide to Writing Software Requirements: User Stories

Johnny Ilmo Koo — Mon, 21 Oct 2024 05:56:19 +0000

One of the most important processes in software development is clearly defining requirements. However, writing requirements can be challenging for someone with little or no experience. Studying software requirements in depth is not always practical either. In such cases, user stories become a highly useful tool. Unlike traditional software requirements documentation, user stories are written in an easy-to-understand language and structure.

In this article, we will explore what user stories are and how to write them. Additionally, we will look at how to effectively use epics and acceptance criteria.

1. What is a User Story?

A user story is a way to express software requirements in a simple and clear manner. It is commonly used in Agile development methodologies, facilitating smooth communication between developers and non-developers. A user story follows this basic structure:

User Story Template:

“As a [user], I can do [action]. (optional) So that I can achieve [value].”

This format explains the user’s goal and the benefit they expect in a concise way. For example:

“As a user, I can change my password so that I can maintain the security of my account.”

This simple format helps convey the requirements clearly, making it easy for non-experts to write and understand.

2. The Difference Between Epics and User Stories

One concept that is often confused with user stories is epics. An epic is a large requirement that is too big to be captured in a single user story. It consists of multiple user stories that can be broken down into smaller, actionable items.

For example, let’s look at an epic:

Epic: “User Account Management”

To complete this epic, several user stories would be needed. Each user story is derived from the epic and represents a small, actionable unit. For example, the epic could be divided into the following user stories:

“As a user, I can change my password.”
"As an admin, I can deactivate individual user accounts.”

The relationship between epics and user stories is hierarchical. The epic represents the big picture, and user stories break that down into more specific, actionable tasks.

3. Principles of Writing Good User Stories

To write a good user story, it’s important to follow certain principles. Here are six key principles for writing effective user stories:

Independent: A user story should be independent of other stories.
Negotiable: A user story should not be fixed; it should be flexible enough for changes.
Valuable: A user story should provide direct value to the customer.
Estimable: A user story should be able to be estimated in terms of time and resources.
Small: A user story should be small enough to be completed in a short time frame.
Testable: A user story should include criteria that allow it to be tested.

By adhering to these principles, you can write clear and detailed user stories.

4. User Story Writing Practice: Good vs Bad Examples

Bad Example:

User Story: “As a user, I can sign up.”

This is too vague. It’s unclear why the user needs to log in, and the goal, acceptance criteria, and value are not clearly defined.

Good Example:

User Story: “As a user, I can sign up using my email and password. The sign-up process requires email confirmation via a link. This prevents the use of fake or invalid email addresses.”

Acceptance Criteria:

Only verified email addresses can be used for login after the user receives the confirmation link.

The password must be at least six characters long and include a combination of letters and numbers.

This example clearly explains what the user wants and the benefits they will gain. It’s important to write user stories that are both specific and clear.

This introduces a new concept: Acceptance Criteria. Acceptance criteria are necessary to determine when a user story is considered complete. They set out the conditions that must be met for the story to be considered successful. These criteria align expectations between the development and business teams and provide a basis for testing whether the developed feature meets user needs.

5. Conclusion

Through user stories, the development team defines the features, breaking them down into smaller tasks and prioritizing them. This incremental approach allows for development to be more flexible, and requirements can be adjusted as needed.

User stories play a crucial role in backlog management, especially when epics are broken down into smaller user stories to be worked on step by step.

By effectively using user stories, epics, and acceptance criteria, even non-experts can define requirements relatively easily, and development teams can proceed with clarity. User stories, in particular, are well-suited for adjusting to changes in business or customer needs, allowing for flexible management. While the level of output and requirement management may differ from that of professionals, even inexperienced decision-makers or CEOs can learn and apply this approach in a short period of time. Now, you can introduce user stories into your projects to enhance communication during development and achieve your business goals.

5 Key Tips for First-Time Software Outsourcing

Johnny Ilmo Koo — Mon, 14 Oct 2024 05:48:20 +0000

Even if you don’t have experience in software development or IT services, there may come a time when you need to outsource development to an external team. It can be overwhelming at first, especially if you don’t know where to begin. Maybe you’ve recently secured funding for a new idea and need to deliver on promises made to investors.

If you don’t have a technical co-founder or internal dev team, you’ll likely find yourself managing the outsourcing process. To help guide you, here are five essential tips to keep your project on track and avoid common pitfalls.

1. You don’t need to be a tech expert, but you should be the expert on your business problem.

You don’t need to become an overnight coding whiz to successfully outsource software development. However, you do need to be an expert on the business problem you’re trying to solve. Whether you’re automating a process or launching a new app, understanding the problem inside out is crucial. You should be able to explain what the issue is, how it’s being handled today, and why a software solution would be better.

The dev team will handle the technical details, but it’s up to you to articulate the problem clearly. If you can’t define the problem in simple terms, there’s a good chance the solution they build won’t meet your expectations. Projects without clear, well-understood problems are far more likely to fail. So before you dive into specs and features, make sure you’re the business problem expert.

2. Communicate the context and expected solution thoroughly.

It’s not enough to tell your development team what features you want; you need to explain the context of the problem and what you expect the solution to achieve. Think of it this way: telling someone to “grab a ladder from the storage room” is one thing, but saying “we need the ladder to reach the top shelf in the warehouse” provides the full picture. If the ladder isn’t available, the person can think of another tool to solve the same problem.

Your developers aren’t mind-readers. Even if you have experience in the industry, if you don’t explain the broader context of what you’re trying to accomplish, they may miss important details. For instance, if you’re building a platform for senior citizens and suggest a standard email/password login, your devs may not realize how unfamiliar that system could be for your target audience. Sharing insights into your users and the challenges they face will lead to better, more thoughtful solutions from your development team.

3. Prioritize features. Not everything needs to be built at once.

When you hand over a list of features to a dev team, one of the first things you should do is prioritize. It’s common to want everything all at once, but unless you have unlimited time and resources, some features are going to have to wait. Often, clients will say every feature is critical, but this can lead to bloated, inefficient projects that miss deadlines and overspend.

A helpful exercise is to categorize features by urgency and importance. What’s truly essential for solving the core problem right now, and what can be added later? One method is to imagine each feature costs a significant amount and takes a long time to develop—then ask yourself, “Would I still prioritize it?” By clearly defining what matters most, you’ll keep your project focused and increase the chances of delivering a product on time and within budget.

4. A fair price gets you a fair result.

There’s a reason the saying “you get what you pay for” exists, and it’s especially true in software development. While it’s tempting to go with the lowest bid, cheap development usually leads to cheap results. I’m not suggesting you need to pay top dollar for everything, but be cautious of deals that seem too good to be true.

In some cases, a junior developer might surprise you with quality work for a low price, but these cases are rare. More often, low-budget projects end up with poor quality deliverables or hidden costs that add up as the project goes on. Even worse, you could be left with something so incomplete that you need to start over with another team. It’s better to find a team that offers a reasonable price and ensures good communication, transparency, and a commitment to delivering value rather than just cutting costs. Think long-term—it’s better to pay for quality once than to deal with cheap mistakes later.

5. Show up to meetings prepared.

Once the project starts, regular meetings with the dev team are essential. These meetings are your chance to review progress, give feedback, and adjust the project’s direction if needed. However, if you show up unprepared, the meeting will likely be unproductive, and key issues might get overlooked.

Before each meeting, take time to review the progress that’s been made and prepare any questions or concerns you have. These are opportunities to keep the project on track and ensure the development aligns with your goals. You don’t want to leave everything in the hands of the developers without oversight. This doesn’t mean micromanaging, but it does mean actively participating in discussions, keeping the priorities clear, and ensuring the project is moving in the right direction.

It’s also important to avoid frequent changes to the scope or requirements. If you constantly shift priorities or add new features without considering the impact on the timeline and budget, it can lead to delays and decreased product quality. Balance flexibility with consistency to get the best results.

By following these five tips, you’ll set your project up for success, even if it’s your first time outsourcing. Focus on being the expert in your business problem, communicate clearly, prioritize effectively, pay for quality, and stay engaged throughout the project. It’s not easy, but these principles will give you the best chance at delivering a successful product.

If you’re looking for a trusted development agency, we’d love to connect! With expertise in automation projects, admin dashboards, and back-office applications, we’re here to help streamline your operations. Reach out at johnnykoo@kooslab.net to schedule a free 30-minute consultation via video call. Let’s explore how we can bring your vision to real!

내가 잘 하는 것은 무엇일까?

Johnny Ilmo Koo — Wed, 21 Feb 2024 01:46:05 +0000

너가 잘 하는 영역과, 하고싶어하는, 재밌어하는 영역의 교집합을 시행착오 끝에 계속 찾아나가야 해. 처음엔 잘 안 만날 수 있어. 잘 하는 것만 열심히 하면서 지칠수도 있고. 재밌어하는 영역만 하다가 결국 아무 수요도 발생시키지 못할 수도 있고. 그런데 하다보면 그 교집합이 보일거야. 아 그리고 흥미로운 건, 보통 잘 하다보면 재밌어지기도 해. 그런데 재밌는 것도 계속 지속하기 어려워진다면 오히려 재미없어지기도 하고.

최근 선배 창업자 대표님과의 커피타임에서, 이미 수년 전부터 알고 있었지만, 가슴으로 받아들이지 않았던 조언을 들었다. 원래 머리로 알고 있다가 가슴으로 받아들이게 되는 상황은, 현재 그 상황을 겪을 때일 뿐이다. 즉 그 상황이 닥치지 않으면 결국 여전히 계속 머리에 정보로만 담고 있게 될 뿐.

지난 몇 달간 내가 좋아하는 영역, 새로운 곳에서 기회를 찾는 영역에만 몰두했다. 내가 무얼 잘하는지에 대한 관심은 전혀 없었다. 지나칠 정도로. 스스로 내가 무얼 잘 한다고 생각을 하지 않는 경향이 있는데, 이건 겸손한 것처럼 보이지만 또 어찌보면 꽤나 게으르거나 오만한 것일지도 모른다. 무엇이든 해보면 다 잘 할 수 있을거란 오만 말이다.

사람은 속도를 내는 상황에서 새로운 곳을 갈 수 있는 것 같다. 내가 B라는 영역을 탐험해 보고 싶은데, 현재 정지해있다면 (stationary) 그 곳을 기웃거릴 수 밖에 없더라. 그런데 원래 내가 달려가고 있던 A라는 영역이 있다고 해 보자. 그러면 나는 A라는 곳은 꾸준히 달려가면서, 속도를 유지한 채, 핸들을 돌리면 B라는 곳을 더 공격적으로 탐험할 수 있게 된다. 내가 축구선수는 아니지만, 듣기로, 선발출전해서 뛰는 것보다, 후반에 교체되어 들어와 뛰는 것이 더 힘들 때가 있다고 한다. 처음부터 우리 팀과 상대팀과의 격려한 호흡의 점진적 빌딩이 된 것이 아니라, 중간에 갑자기 들어와 격렬한 호흡의 사이에 들어와 장단을 맞춰야 하기 때문이 아닐까.

어쨌든 2달간의 헛발질을 통해 배웠고, 일단 속도를 다시 만들어야겠다는 생각. 내가 잘 하는 영역이 바로 이 A라는 익숙한 지점을 향해 달려가는 것이다. B라는 곳을 포기하는 것은 아니고, 속도를 만드는 것이 A로 가거나 B로 가는 것보다 더 중요할 수도 있다는 것을 알게 되었기 때문이다.

조금 더 생각해보니, 지난 몇 년간 일하면서 스스로 좋아하면서도 잘 하는 영역을 어느 정도 찾아놨던 것 같기도 하다. 나는 새로운 도구나 기술을 찾아내 소개하고, 알려주고, 설명하는 것을 좋아한다. 이걸 잘 하려면 (잘 한다는 것은 내 스스로의 생각보다는 내 고객이나 동료가 해 주는 말을 믿어야 한다) 내 주변의 사람들, 기업들, 조직들의 문제를 해결해주거나 해결할 수 있도록 도와주어야겠다.

암튼 나는 이 실수를 지난 2달간 했던 것 같다. 내 제품을 팔기 위해 억지로 상황이나 문제를 만들어보려는 경향이 짙었다. 그러기 보단, 수단과 방법을 가리지 않고 고객 문제에만 집중해 보는 것이 지금 달라진 결이다. 내 제품은 거기서 우선순위가 100위쯤 되어야 한다. 고객 문제를 해결하는 데 있어, 내 제품과 도구가 도움이 되면 쓰는 것이고 아니면 마는 것이다. 그게 분해서, 내 도구를 발전시켜나간다면야 이것이야말로 필요에 의해 제품을 만들고 개선하는 것이니 더할 나위가 없다.

"나의 문제에 관심이 있고, 나를 도와주는 사람, 그런 기업"
으로 고객에게 기억되고 싶다. 나의 2024년 바램

types of React Router

Johnny Ilmo Koo — Tue, 05 Dec 2023 05:24:08 +0000

react-router library, in addition to BrowserRouter, there are several other types of routers that you can use depending on the environment and specific requirements of your React application. Each router type serves a different purpose:

1. BrowserRouter

Usage: This is used for applications where you have a server that responds to requests for different URLs. It leverages the HTML5 history API (pushState, replaceState, and the popstate event) to keep the UI in sync with the URL.
When to Use: Use it when you are building a web application that serves dynamic requests and you have control over the server configuration. It's the most common choice for web applications.

2. HashRouter

Usage: This uses the hash portion of the URL (the part after #) to keep the UI in sync with the URL. It's a fallback for older browsers and a solution for certain server configurations.
When to Use: Use HashRouter if you are building a static website (like a GitHub Pages site) where you don't have control over server-side rendering. It's also useful if you need to support older browsers that don't support the HTML5 history API.

3. MemoryRouter

Usage: This keeps the history of your “URLs” in memory (does not read or write to the address bar). Routes are kept internally.
When to Use: Use this in non-browser environments like tests or React Native. It's also useful in scenarios where you don't want the URL to change or have an address bar, such as in certain types of desktop or mobile apps built with React.

4. StaticRouter

Usage: This is used to render static HTML. It's a stateless router that takes in a URL and routes just once (doesn’t change with user interactions).
When to Use: Use it for server-side rendering in web applications. It's useful in situations where you need to pre-render the pages of your application on the server for SEO purposes or to improve load times.
Conclusion
Choosing the right type of router depends largely on your application’s deployment environment and requirements:

Web Applications: For most web applications, BrowserRouter is the best choice.
Static Websites: Use HashRouter for static websites or when you don’t have control over server configurations.
Testing/Non-Browser Environments: MemoryRouter is suitable for environments like testing or platforms like React Native.
Server-Side Rendering: Use StaticRouter for server-side rendering of your web application.
It's essential to understand these differences to choose the appropriate router for your project's needs.

6년만에 찾아온 불확실성

Johnny Ilmo Koo — Thu, 21 Sep 2023 09:52:48 +0000

불확실성, 내가 좋아하는 이 녀석이 오랜만에 또 찾아왔다. 그 동안 뭐, 스타트업 조직을 운영하고 경영에 참여한다는 것 자체가 불확실성을 안고 사는 것이었지만, 불행인지 다행인지 사업을 운영하면서 오늘도 밥을 먹을 수 있을까에 대한 위협은 많진 않았다.

다시 찾아온 만큼, 약간 불안하기도 하지만, 이젠 익숙한 녀석이라 흥미진진하고 기대가 되기도 한다. 6년 전과 가장 큰 변화는, 이제 내가 무슨 순서로 무엇을 해야할지 알고 있다는 것이다. 과거엔 그걸 몰라서 참 불안함이 컸다. 내가 해야할 것은 되게 단순하다. 고객을 만나 관찰하고 문제를 찾아내고, 고객이 원하는 제품을 만들고, 그걸 고객에게 판매하는 것을 반복하는 것이다. 자꾸 딴 짓을 하고싶은 유혹이 많이 드는데, 유혹에 빠지지 말고 단순한 일을 반복하다보면, 길이 보일 것이다.

5년 반동안 내가 배운 것은, 성공하는 공식이 아니라 망하지 않는 공식이다. 고객의 문제에 집착하고 집중하고 성실히 그 문제 해결을 위해 일하면 망하기 어렵다.

부끄럽지 않게 살자

Johnny Ilmo Koo — Tue, 29 Aug 2023 23:58:56 +0000

우리 가족과, 함께 일했던 동료들에게, 이 사회에 부끄럽지 않게 살고 싶다.
그 동안 가족을 핑계로 나 자신의 원칙, 내가 중요하게 생각하는 가치를 양보해 오거나 타협한 점들이 없지 않았다.

꽤 수 년동안 오래 그래왔지만, 이제 더 이상은 어려울 것 같다. 나의 선택을 존중해 주는 가족과 동료들이 있기에 더더욱 내가 핑계댈 곳은 이제 없다.

사랑하는 나의 두 딸에게 부끄럽지 않고 당당하게 살아달라고 부탁하며 지원할 계획인데, 나 자신이 그렇게 살고 있지 못하다면 이는 아리스토텔레스 수사학 3요소 중 에토스를 지키지 못한 꼴이 된다.

삶의 선택들은, 생각보다 인생 전체를 결정짓는 큰 요소가 아니라고 생각한다. 오히려 선택한 후, 어떤 자세와 노력으로 해당 결정에 책임지느냐의 문제이지.

변화를 위한 필연적인 불안정성과 불확실성

Johnny Ilmo Koo — Sun, 18 Jun 2023 14:49:42 +0000

사람들은 변화를 원하지만 변화에 필연적으로 따라오는 불안정성과 불확실성을 매우 불편해 한다. 불편해하는 것을 넘어서서 이 두 가지 요소가 발견되는 것을 리더나 조직의 잘못으로 생각하기도 한다. 즉, '발견'되는 것만으로도 문제라고 생각한다는 것이다. 하지만 생각해보면, 불안정성과 불확실성을 제거하는 가장 좋은 솔루션은 아무것도 하지 않고 변화를 시도하지 않는 것이다. 바꿔 말하면, 변화, 혹은 특히 '혁신'에 가까운 과감한 변화엔 이 두 가지 요소가 필연적으로 따라온다는 것을 리더나 팔로워 모두 인지하고 있을 필요가 있다. 더 민첩한 기동성을 가지기 위해 조직은 일부러 불안정성을 키우는 것도 조직의 전략이 될 수 있다. 맥락과 배경 없이 불안전과 불확실을 부정적인 상황으로 판단할 필요는 없다. 따라서 '위기는 기회다'라는 문구는 진부한 꼰대들의 문장이 아니라, 정말 상황에 따라 선배들의 지혜로운 조언일 수 있다는 말이다.

물론, 상황과 시기가 달라지면서, 아무것도 하지 않는 솔루션조차 완벽하게 이 두 가지 요소를 제거하기에 불가능할 수도 있다. 그러나 아무것도 하지 않으면서 불안정성과 불확실성을 가지게 되는 것은 최악의 상황이다. 통제권도 없고, 변화의 방향성과 시도도 없으면서 불필요한 불안과 불확실을 떠안아야 하기 때문이다. 목적과 유익의 가능성이 없는 불안정성, 불확실성은 굳이 안고 가야 할 리스크가 아니다.

어려울 때 진짜 모습이 나온다

Johnny Ilmo Koo — Fri, 26 May 2023 15:56:45 +0000

조직 안에서 "어떠세요?"라고 물어보면

"사람들이 너무 좋아요"
"조직 문화가 좋아요"
"수평적이어서 좋아요"
"모두가 다 열심이어서 좋아요" 같은 이야기들이 나온다. 이런 이야기들이 나쁘진 않은데, 이런 말들은 조직 상황이 좋으면 다 좋을 수 밖에 없다. 이 세상에 상황이 나쁘지 않은데 굳이 좋지 않은 모습을 보일 이상한 사람들은 많지 않다.

그런데 조직과 개인의 진짜 모습은 상황이 어려울 때 나온다. 이런 이유에서 좋은 상황에서의 좋은 모습들을 믿으면 안 된다. 굳이 의심해야 한다는 이야기는 아니지만, 적어도 최소한, 확인되지 않은 좋은 모습이 그 조직에 있어야 할 이유가 되어선 안 된다는 것이다.

조직 상황이 좋든 싫든, 조직 전체 목표 달성을 위해 모두가 진심이고 열심을 다 할 땐, 마냥 좋을 수 없는 경우가 많다. 조직 안에서 너무 너무 행복하기만 하다면, 무언가 착각하고 있거나 아니면 진짜 모습들을 보지 않아서일 수 있다.

조직 내 갈등과 이슈 해결 방법

Johnny Ilmo Koo — Wed, 24 May 2023 15:16:12 +0000

조직에 속해 일 하다 보면 다양한 이슈와 갈등을 마주하게 된다. 미성숙했을 때 나는 이 모든 이슈와 갈등을 해결하러 다녀서 '소방수'라는 별명을 얻기도 했다. 그런데 이상했다. 불을 아무리 끄고 다녀도, 계속 다른 곳에서 불이 나기 시작했다. 결국 불만 끄러 다니다보면 시간이 너무도 많이 흐르고, 우리가 목표로 해야 하는 진짜 문제 해결과 목표 달성은 우선순위가 미뤄지기도 했다. 조직 내 불만도 생겼다. "일모님은 이슈 해결해 주시는 것은 고마운데 진짜 해결해야 할 문제와, 필요한 아젠다 추진이 이뤄지지 않아 아쉽다"라는 피드백도 자주 듣기 시작했다.

고민하다보니, 어차피 모든 불을 끌 수 있다는 나의 생각이 오만했었다. 조직 내 갈등과 이슈를 해결하는 궁극적인, 그리고 유일한 방법은 지금 우리가 마주하고 있는 갈등과 이슈가 더 이상 갈등과 이슈가 아니게끔 만들어버리는 것이었다. 더 큰 목표와, 더 ROI가 높은 문제를 들고와서, 공동의 문제로 만들어버리는 방법이다. 그럼 우리끼리의 이슈나 갈등이 아니라, 더 큰 녀석이 앞에 있으니 힘을 합쳐 저 문제를 해결하게 만드는 것이다. 때론 이런 방법이 의도치 않게 일어나기도 한다. 임진왜란과 같이 말이다. 전쟁이 나거나 테러를 당하면 지도자의 지지율이 올라가는 것도 비슷한 배경이다.

그러나 사실 너무 당연하게도, 더 큰 목표와 가치있는 공동의 문제를 정의하고 가져오는 것은 '이슈'와 '갈등'해결을 위함이 주목적은 아니다. 즉, 이슈와 갈등 해결의 처방으로 사용하는게 아니라 리더는 늘상 그런 일을 해야한다는 말이다.

오늘도 나 스스로에게 하는 이야기

말은 참 쉽다 - 2편

Johnny Ilmo Koo — Mon, 22 May 2023 13:14:33 +0000

SNS에서 신문 기사나 특정 소식들을 바탕으로 훈수두는 업계 유명인들이 많다. 특히 드러난 현상과 결과만을 가지고, 엄청나게 많은 내용들을 넘겨짚어 비판하고 비난하는 내용들은 부지기수다. 기업과 조직을 한 번이라도 운영하고 리드해 봤다면, 밖으로 들어나는 현상과 결과 저변에 있는 여러 복잡한 사정이 있음을 알 수 있다. 그럼에도 이렇게 쉽게 넘겨짚고, 확증편향된 생각으로 과장, 축소해서 자신이 말하고자 하는 바를 관철시키려는 행동이 과연 정당한가. 특히 그가 SNS상에서 영향력 있는 사람이면 일수록 더 그 펜의 무게를 알아야 하지 않을까? 남을 비판하긴 너무도 쉽다. 특히 정보가 부족할 때 펜이 무기로 사용될 때가 많다. 자신의 펜이 총과 칼보다 무서운 무기로 사용된다는 점을 인지했을 때, 그 비판의 무기가 정확한 정보 기반으로 사용되어야 한다는 책임의식도 없는 것인가. '아니면 말고'식의 태도가 언론에서 주로 너무 흔하게 사용되니 전염이 된 것인가.

말은 참 쉽다

Johnny Ilmo Koo — Wed, 17 May 2023 15:40:19 +0000

SNS에 난무하는, 자기 회고/반성적인 글 같지만 사실은 자신의 SNS내 명성을 올리고 자기성찰 자랑하는 글에 지친다. 정말 대충 읽으면 정말 겸손해 보이는 자기회고라고 생각할 수 있지만, 조금만 자세히 보면 결국 불특정 다수나 같이 일하는/일했던 동료, 팀원, 상사를 저격하는 뒷다마적인 내용들도 많다. 지나치게 교휸적이고, 인사이트가 풍부하게 담겨있는 자기계발서적 글들이 그러하다. 책에서 봤을 법한 내용들이 많고, 생각보다 중복된 교휸들이 마구 짜집기 되어있다.

이런 글의 특징은, 좋아요와 공유 횟수가 많은 편이다. 또한, 실제 그 사람과 같이 일해본 동료들의 엄지척 보다는, 단 한 번도 같이 일해보지 않았지만, 그의 공감대 높은 글과 말을 통해 추정&추종하는 SNS친구들의 호감도가 높다.

또 공통적인 특징 중 하나는 사용된 용어들이 어렵거나 실제 말하고자 하는 바를 이끌어내기까지 전개가 상당히 길거나 직진하지 않고 돌아간다.

솔직하고 진짜 겸손한 글은, 지나치게 자신을 깎아내리지도, 그렇다고 자신을 지나치게 로켓에 태우지도, 남들에 대한 저격이나 훈수를 돌려하지도 않는다. 솔직하게 단순하게, 유머와 위트를 가지고 쉬운 단어가 사용되기도 한다. 이런 글들의 특징은 한 번에 써내려간듯한 느낌이 있으며, 어려운 문어적 표현보단 구어적으로 실제 오프라인 현장에서 음성으로 들어도 크게 어색하지 않은 글들이다.

개인적으로 좋아하는 글은 SW개발자 임백준 형님의 SNS 포스팅 들이다. 매 번 반말로 짧게 유머러스하게 글을 쓰시지만, 그 안에 진정성과 솔직함, 엄청난 전문성과 때론 어설픔까지 모두 있는 그대로 담겨있다. 남을 의식하지 않는다는 글은 누가 봐도 눈에 띈다. 아, 그리고 또 하나. 그런 글들은 고유하고 개성이 강한 편이다.

SNS에서 이야기하는게 다 별로라는 말이 아니다. 그 글들을 과거 함께 일했던, 지금 함께 일하고 있는 동료들이 보고 있다는 사실을 '인지'하며 작성되고 있는지에 대한 의심일 뿐이다. 무식하면 용감하다고, 뭘 잘 모를 때, 실제 쳐 맞아보기 전까진 순수하고 이상적인 이야기를 전혀 어려움없이 이야기할 때가 있다. 특히, 조직의 맥락과 관계 없이 하는 피반은 매우 쉬운데 나도 그랬고 앞으로도 또 그럴지도 모르겠다.

얼마 전, 리디 배기식 대표님께 조직/인사 관리에서의 어려운 문제들을 나누고 그런 상황에서 어떻게 문제를 해결하시는지 질문하는 기회가 있었다. 대표님은 '정면돌파해야 한다. 그래서 요즘은 그냥 솔직하게, 차분히 그냥 바로 이야기한다'라고 하셨다. 대표님 답변에 요행(workaround), 테크닉는 보이지 않았다. 경험과 연륜이 많을수록 기본적인 내용에 집중한다는 생각이 들었다. 언제나 그렇듯이 문제와 문제 해결의 본질은 수백년이 지나도 크게 달라지지 않는 것 같다.

다시 돌아와서, 말은 참 쉽다. 반면, 행동은 그렇지 않다. 내가 가장 신뢰하는 현재 동료 임원는 이렇게 말했다. '그 사람의 말을 믿지 말고, 그 사람의 결정과 행동을 믿는다'. 매우 맞는 말이다. 내가 무엇을 강하게 이야기하고, 어떤 철학을 가지고 있다 말해도, 그것은 결국 나의 행동에서 증명되는 것이지 말과 글로 증명되는 것이 아니라는 것이다.

그런 면에서 말과 글은 빚이다. 동료들이 기억하는 나와 내가 스스로 생각하는 나 사이의 갭을 정기적으로 점검하고 정진하는 것은 언제나 유효하다. '자기 객관화'라는 단어 역시 다소 어렵거나 직관적이지 않은 것 같아 풀어 쓰는 노력으로 봐 주셨으면 한다.