내부 해커톤: 48시간의 통제된 혼돈

피치는 항상 같습니다: "해커톤을 합시다! 순수한 혁신의 이틀, 회의 없이, 그냥 만들기만 하면 됩니다." 그러면 누군가 규칙에 대해 묻고 방이 조용해집니다. 그런 다음 누군가 심사 기준에 대해 묻고 세 명의 VP가 다른 회의를 시작합니다. 그러면 누군가 원격 직원이 참여할 수 있는지 묻고 모두가 자신의 노트북을 바라봅니다.

내부 해커톤은 사람들이 실제로 참석하고 싶어하는 몇 안 되는 기업 행사 중 하나입니다. 개발자들은 Jira 티켓 없이 무언가를 만들고 싶어합니다. 디자이너들은 이해관계자 리뷰 없이 아이디어를 탐색하고 싶어합니다. 제품 관리자들은... 음, 제품 관리자들은 해커톤을 관리하고 싶어하는데, 솔직히 그들이 그렇게 하도록 두는 것이 좋습니다.

문제는 열정을 생성하는 것이 아닙니다. 48시간의 창의적 에너지를 모호함에 무너지지 않는 무언가로 전환하는 것입니다.

사람들이 실제로 따르는 해커톤 규칙

해커톤 규칙은 "아무거나 가능하다"에서 "12페이지 요구 사항 문서가 있다"까지의 스펙트럼에 존재합니다. 두 극단 모두 나쁜 결과를 초래합니다. 완전한 자유는 절반의 팀이 첫날 무엇을 만들지에 대해 논쟁하게 만듭니다. 과도한 명세는 당신이 정규 프로세스 없이 정규 작업을 하고 있다는 것을 의미하며, 이는 정규 작업보다 더 나쁩니다.

적절한 지점은 주제와 제약입니다. 주제는 방향을 제공합니다: "온보딩 경험 개선" 또는 "내부 문제를 해결하는 무언가 만들기." 제약은 구조를 제공합니다: "기존 기술 스택을 사용해야 함," "5분 안에 데모 가능해야 함," "3-5명의 팀." 제약 없는 주제는 혼란입니다. 주제 없는 제약은 명세입니다.

사람들이 실제로 논쟁하는 규칙은 비명백한 것들입니다. 기존 코드를 사용할 수 있나요? (이를 명확히 결정하지 않으면 팀들이 다르게 해석할 것입니다.) 팀이 교차 기능일 수 있나요? (예. 항상 예입니다. 엔지니어 전용 팀은 데모에서 설명할 수 없는 기술적으로 인상적인 것을 만듭니다.) 정규 프로젝트와 관련된 무언가를 작업할 수 있나요? (여기서 정치적이 됩니다. 솔직한 대답은 "예, 하지만 심사는 참신함을 보상해야 합니다."입니다.)

인기 투표가 아닌 해커톤 심사

해커톤 심사는 좋은 이벤트가 죽는 곳입니다. 일반적인 실패 모드: 작업에 참여하지 않은 세 명의 임원이 각 데모를 90초 동안 보고, 아는 사람이 포함된 팀에 투표합니다. 또는 더 나쁜 경우, 그들의 팀의 기존 로드맵과 가장 일치하는 프로젝트에 투표하여 "혁신의 날"을 "제품 조직을 위한 무료 노동"으로 바꿉니다.

해커톤이 시작되기 전에 심사 기준을 수정하세요. 이를 공개하세요. 구체적이고 가중치를 두세요. 예를 들어: 기술적 야망 (25%), 잠재적 영향 (25%), 다듬기 및 발표 (25%), 창의성 (25%). 심사위원은 각 카테고리를 독립적으로 평가합니다. 총점이 우승자를 결정합니다. 완벽하지는 않지만, 기분에 기반한 심의보다 훨씬 낫습니다.

더 나아가, 여러 심사 패널을 사용하세요. 고위 엔지니어로 구성된 기술 패널. PM과 디자이너로 구성된 제품 패널. 모든 참가자로부터의 "대중의 선택" 투표. 서로 다른 패널이 종종 서로 다른 우승자를 선택하며, 이는 괜찮습니다 — 여러 상이 있으면 더 많은 팀이 인정받는 느낌을 받고, 어떤 단일 패널에 대한 정치적 압력이 크게 줄어듭니다.

개발자를 48시간 동안 먹이는 물류

해커톤이 진행 중이고 40명의 개발자가 배고플 때까지 음식 물류에 대해 아무도 이야기하지 않습니다. 음식은 세부 사항이 아닙니다. 음식은 인프라입니다. 배고픈 사람들은 혁신하지 않습니다; 그들은 불평하고 개별적으로 DoorDash를 주문하며, 이는 당신이 만들고자 하는 공동의 에너지를 무너뜨립니다.

최소한의 식사 계획: 좋은 커피가 지속적으로 제공되어야 합니다 (포드 머신이 아닌 — 진짜 커피), 양일 동안의 실질적인 점심, 첫날 저녁, 둘째 날 아침, 그리고 실제 영양가가 있는 것과 의무적인 칩과 사탕이 포함된 지속적인 간식 테이블. 이를 위해 예산을 세우세요. 해커톤 예산에 음식이 포함되지 않았다면, 당신의 해커톤 예산은 잘못된 것입니다.

비명백한 점: 50-300명의 그룹에서의 식이 제한은 경계 사례가 아닙니다. 이는 참가자의 상당한 비율을 차지합니다. 채식, 비건, 글루텐 프리, 코셔, 할랄, 견과류 알레르기 — 이 정보를 등록 중에 수집하고, 음식이 도착할 때가 아니라 수집하세요. (이것은 사려 깊은 이벤트와 부주의한 이벤트를 구분하는 접근성 세부 사항 중 하나입니다.) 셀리악병이 있는 개발자가 피자와 샌드위치 테이블을 바라보고 있는 것은 혁신적인 오후가 아닙니다.

2등 시민 없는 원격 참여

"해커톤은 대면만 가능합니다"라고 말하고 싶은 유혹이 있습니다. 이는 조직하기 더 쉽고, 원격 직원들이 실제로 즐길 수 있는 유일한 이벤트에서 제외하는 좋은 방법입니다. 회사에 원격 근무자가 있다면, 해커톤에 그들을 포함해야 하며, 이는 실제로 하이브리드 참여를 위해 설계해야 함을 의미합니다. 단순히 대면 이벤트에 Zoom 링크를 추가하는 것이 아닙니다.

원격 해커톤 참여는 팀이 모두 원격이거나 모두 대면일 때 잘 작동합니다. 세 명이 방에 있고 두 명이 통화 중인 혼합 팀은 항상 같은 결과를 낳습니다: 원격 사람들은 관중이 됩니다. 혼합 팀을 허용하는 경우, 모든 협업이 공유 디지털 공간에서 이루어지도록 요구하세요 — 채팅, 공유 문서, 화면 공유 — 그래서 원격 참가자들은 회의실 구석의 노트북 마이크에서 희미한 대화를 듣지 않게 됩니다.

데모 날은 원격 포함이 잘 작동하거나 눈에 띄게 실패하는 곳입니다. 원격 팀에게 동일한 데모 시간, 동일한 화면 접근, 동일한 심사 기준을 제공하세요. 이를 주요 흐름에 일정에 포함시키고, 사후 생각으로 다루지 마세요. "이제 원격 팀의 이야기를 들어보겠습니다"는 두 시간 데모 세션의 끝에서, 모든 사람이 피곤하고 체크아웃할 때는 공정한 심사가 아닙니다. 이는 참여 트로피입니다.

데모 날: 다섯 분의 영광

데모 날은 이벤트 내의 이벤트이며, 자체 계획이 필요합니다 — 의견이 있는 청중을 위한 제품 출시와 유사합니다... 모든 팀이 자신의 프로젝트를 설명하는 데 15분이 필요하다고 생각하는 것이 보편적인 실수입니다. 어떤 프로젝트도 15분이 필요하지 않습니다. 데모당 5분, 질문을 위한 2분, 그리고 단호한 시간 제한을 두세요. 사람을 끊는 것을 두려워하지 않는 시간 관리자를 지정하세요. 개발자들은 감사할 것입니다 — 모든 사람은 20개의 긴 데모를 듣는 것을 싫어합니다, 데모를 하는 사람들 제외하고요.

데모 순서는 생각보다 더 중요합니다. 에너지를 설정하기 위해 강력한 데모를 첫 번째로 배치하세요. 점심 후에는 주의력이 떨어지므로 또 다른 강력한 데모를 배치하세요. 모든 원격 데모를 마지막에 배치하지 마세요. 청중이 5개의 연속적인 데이터 파이프라인 개선을 보면서 지루해하지 않도록 다양한 프로젝트 유형을 번갈아 배치하세요.

상은 의미가 있어야 하며, 비싸야 한다는 의미는 아닙니다. 하루 휴가. 우승한 프로젝트는 로드맵에서 엔지니어링 시간을 받습니다. 팀은 다음 전체 회의에서 발표할 기회를 가집니다. 프로토타입을 실제로 배포할 예산을 세우세요. 이러한 상은 해커톤이 참가자뿐만 아니라 조직에도 중요하다는 신호를 보냅니다. 50달러의 상품권은 "참여해 주셔서 감사합니다."라고 말합니다. 보호된 엔지니어링 시간은 "우리는 이를 진지하게 생각합니다."라고 말합니다.

월요일 아침에 일어나는 일

내부 해커톤의 불편한 진실은 90%의 프로젝트가 월요일 아침에 사라진다는 것입니다. 사람들은 다시 스프린트로 돌아가고, 프로토타입은 아무도 방문하지 않는 저장소에 남아 있으며, 다음 해커톤까지 모든 사람은 지난 해커톤에서 무엇이 만들어졌는지 잊어버립니다. 이것은 해커톤 문제 — 조직의 후속 조치 문제입니다.

해커톤을 진행할 계획이라면, 해커톤 후 프로세스에 전념하세요. 일주일 이내: 모든 프로젝트를 문서화하세요(우승하지 않은 프로젝트도 포함). 2주 이내: 리더십이 상위 프로젝트를 검토하고 결정을 내립니다 — 배포할지, 보류할지, 후속 작업을 일정에 추가할지. 한 달 이내: 승인된 프로젝트를 가진 팀은 계속할 시간을 할당받습니다.

이러한 후속 조치는 해커톤을 사기 진작 이벤트에서 실제 혁신 프로그램으로 전환합니다. 그렇지 않으면, 2일간의 팀 빌딩 연습에 상당한 시간과 돈을 쓰고 있는 것입니다. 이는 가치가 없는 것은 아니지만, 리더십에게 "48시간의 순수한 혁신"을 제안할 때 약속한 것과는 다릅니다.