본문 바로가기

스타트업/IT경영15

CTO를 고용할 때 준비해야 할 것 이건 CTO를 처음으로 뽑는 CEO를 위한 이야기다. 물론 예비창업자에게도 해당이 된다. CTO 나 CIO 등... C 레벨... 임원을 뽑으려고 한다. 그런데 정말 CTO만 덜렁 뽑는 사람이 있다. 직장경력이 있다면 대부분 눈치는 있다. 그렇지 않다면 아예 감이 안잡힌다. 혹은 직장생활을 해도 이런 고민을 안해본 사람이 많다. 정말 모르나? 싶은데 정말 모른다. 고민이 된다. 나이가 차면 그런 분도 사장이 된다. 그런 분들을 위해 정리해본다. 00.임원 CTO나 임원을 뽑는 건, 사장 일을 떼어주려는 거다. 다른 이유도 꽤 많은데 ... 여기선 이 이유에만 집중하자. 사장의 일을 떼어줄 땐 두 가지를 바란다. (1) 현재의 문제 해결하기. (2) 새로운 기회 만들기. 문제해결은 방어이고, 기회창출은 공.. 2022. 10. 26.
조직을 만들어야 하는 이유 개인역량이 뛰어난 사장님들이 아이러니컬 하게도 조직에 대해 무지하다. 조직만들기가 단순히 부하직원 늘리기라고 생각한다. 그거 아니다. (1) 고객의 유형이 다양해질 때 고객사가 임원, 실무진으로 나뉘어져 있다. 그럼 우리도 나뉘어서 대응해야 한다. 내가 임원대응도 하고, 실무대응도 한다? 상대방이 불편해한다. 상대방은 임원, 실무가 동시에 뛰는데, 나는 임원대응이 끝나야 실무대응을 할 수 있다? 고객사가 매우 불편해한다. 다음 계약은 다른 회사랑 한다. 그런 회사가 3개 이상 늘어난다? 더욱 더 혼자 할 수 없어진다. 사장의 능력이 아무리 출중해도, 혼자서 두 명을 상대할 순 없다. (2) 할 수 있는 일의 성격이 다를 때 "조용하면서 시끄러워야 한다?" 이런 일은 두 개의 인격이 필요하다. 두 개의 인.. 2022. 8. 7.
느린 경영이 필요할 때 애자일이 유행이다 보니 빠른 움직임만 정답인 것 같다. 물론 빠른 움직임은 장점이 많다. 하지만, 그렇다고 느린 움직임이 나쁜 게 아니다. 아무것도 하고 있지 않은 것과 느리게 움직이는 것은 다르다. 다만 종종 같아 보여서 헷갈릴 뿐. 빠른 움직임은 창작모드에선 유용하다. 느린 움직임은 이해관계자가 많은 상황에서 유리하다. 느리게 걸어야 한다면 느리게 걷는게 좋다. 속도 내가 느리게 걷는 이유는, 누구나 다 나를 볼 수 있게 하려는거다. 누구나 볼 수 있게 하는 것은 모두가 함께 가기 위해서다. 모두가 함께 가기 위해서는 서로를 보면서 기준을 잡아야 한다. 나도 누군가의 기준이 되어야 한다. 일 일을 잘게 쪼개는 건 작게 롤백하기 위해서다. 작게 롤백하는 건 큰 일을 실패하지 않으려는거다. 실패해서 안되.. 2021. 8. 11.
길을 잃었다고 느낄 때, 던질 질문 4가지 이건 처음 CTO를 하는 사람에게 드리는 글이다. 사실 사장님은 이런 생각할 틈이 없다. 앗 하면 빚더미 위에 올라 앉기 때문이다. 이런 현상은 종종 동업자, 코파운더에게서 나타난다. 나도 그랬다. 아마 앞으로도 그럴 거다. 하지만, 계속 물을 거다. 중심을 잡아야 전진할 수 있다. 세상에 없는 걸 만들다 보면 종종 길을 잃는다. 참고할 이정표도 없고 판단할 기준도 없기 때문이다. 자존심 때문에, 치밀한 계산놀이 때문에 내가 모든 상황을 장악하고 있다고 착각한다. 그래서 이 상황이 되면 혼란스러워 한다. 하지만 처음부터 판단을 잘못한 거다. "세상일은 여러 이해당사자들이 하나의 시간흐름 속에서 자기 욕구와 생각을 실현하고자 서로에게 관여하는 갈등의 과정이다." 한동안 잘 되는 듯 보여도 곧 잘 되지 않는.. 2021. 8. 2.
시스템 안정화와 개발자 채용에 대한 고민 시장을 돌아다니면서 "자주 관찰되는 현상"이다. 안 그런 기업도 있지만, 그런 기업들도 아주 많다. 옳고 그름을 가리려는게 아니라, 현상을 기록하기 위해 정리한다. 01.시스템의 딜레마 Dilemma of System 법칙1 : "모든 시스템은 시간이 지날수록 더러워진다." 개발자는 시스템을 깨끗하게 유지하려고 한다. 당연하다. 깨끗한 시스템이 문제파악하기도 좋고, 장애처리하기에도 빠르다. 물론 이럴 때도 있다. "더 이상 안됩니다. 이건 완전히 갈아엎어야 해요." "이건 이제 수명을 다했어요." 음, CEO는 고민이 된다. 새로 만들것인가, 고쳐서 쓸 것인가? 새로 만들면 돈이 많이 들것 같고, 고쳐서 쓰면 돈이 적게 들것 같다. 그런데 궁금하다. 시스템을 새로 만들면 진짜 괜찮은걸까? 돈이 한두푼 들.. 2020. 2. 27.
소프트웨어 개발자의 딜레마 시장을 돌아다니면서 자주 보게 되는 현상이다. 현상을 기록하기 위해 정리한다. "개발자의 딜레마" Dilemma of Software Developer 법칙 : "대부분의 개발자는 의사결정권자에게 시스템의 문제를 이해시키는 데 실패한다." * 의사결정권자 Stakeholder = CEO, 담당이사 등 대부분의 개발자는 자신이 처한 문제를 보고하기 위해, 그 문제가 회사의 큰 부담이 될거라고 예상하기 때문에, 또는 미래에 새로운 문제가 될 거라고 믿기 때문에 경영진에게 매우 심각하다고 보고하려한다. 그러나 그 심각성에도 불구하고, 보고는 매우 자주 실패하고 만다. 오히려 상황이 악화되기도 한다. 그래서, 개발자는 문제가 생겼을 때 보고할 것인가 말것인가를 놓고 고민하게 된다. 관찰되는 현상 개발자는 의견을.. 2020. 2. 25.
스타트업 팀개발, 협업능력의 중요성 프로젝트를 수습하러 들어간다. 초보자는 남의 소스코드 까기에 여념이 없다. "나는 잘못을 많이 알아." "나는 그 문제를 풀만큼 훌륭한 사람이야." 이 두가지를 어필하고 싶어한다. 팀장이나 고용주에게 말이다. 프로는 그렇지 않다. 거지꼴이 된 소스를 보고 깊은 생각에 잠긴다. "이놈이 바보가 아니라면 해답을 이렇게 쓰진 않았겠지." "이런 답을 만든 범인은 아직 이 안에 있겠지?" 이렇게 생각한다. '아, 나는 여기에 있을건가 말것인가?' 쓰레기 개발자가 없는 건 아니다. 피치 못하게 그 역할을 하는 사람도 있다. 그런 사람들이 쓰레기 소스를 만들기도 한다. 하지만 오늘주제는 아니니까 여기선 제껴두자. 존중, 왜 하는가? "왜 다른 사람을 존중해야 하는가?" 몸에 베여있는 사람에게 던지는 질문은 아니다... 2019. 11. 13.
대안을 이야기해줘. 내가 어떻게 할까? "이렇게 하면 안됩니다." 팀장을 치받았다. 나에게 질문이 던져졌다. 팀 : "그래서 하고 싶은 이야기가 뭐야?" 나 : "그렇게 하면 안되고, ... 주절주절..." 팀 : "알았어, 그래서 넌 어떤 선택을 할거야?" 나 : " !!! " 멈칫했다. 나보고 결정하라니. 나는 결정을 해본 적이 없다. 책임을 져본 일이 없다. 책임을 지는게 무섭기도 했지만, 내 이야기대로 했을 때 문제가 클리어 된다고 확신하긴 어려웠다. 나는 그냥 그게 옳다고 생각한거다. 한발 물러섰다. "그건 팀장님이 알아서..." 에이~ 쪼다발언. 팀장은 내 발언을 무시했다. 하고 싶은대로 했다. 졌다. "이렇게 하시죠." 자꾸 치받다 보니 요령이 생겼다. 다행히 팀장은 내 제안을 받아줬다. 많이 받아줄 때도 있었고, 적게 받아줄 때.. 2019. 7. 28.
좋아하는 일을 해야 할까, 잘하는 일을 해야 할까? 창업하기 위해 필요한 것을 이야기해보자. 돈? 너무 쉬운 이야기다. 당연히 있어야 한다. 그 다음 이야기를 해보자. 사람? 그것도 당연히 있어야 한다. 하지만 그 두가지보다 더 중요한 것이 있다. 뭘까? 바로 당신이다. 내가 준비되지 않으면 아무리 멋진 일도 시작할 수 없다. 그럼 무엇이 준비되어 있어야 할까? 이 두가지는 체크해봐야 한다. 첫째, 내가 잘하는 일이어야 한다. “좋아하는 일을 해야 할까, 잘하는 일을 해야 할까?” 바보 같은 질문이다. 둘 다 잘해야 된다. 그래야 100점이다. 물론 세상을 반드시 100점으로만 살 필요는 없다. 60점으로 살아도 된다. 단지 보상이 조금 적을 뿐이다. 단, 60점이어도 "좋아하는 일" and "잘하는 일"이어야 한다. 미치도록 좋아할 필요는 없다. 싫어하.. 2019. 4. 1.
반응형