초기 스타트업에는 별도의 플랫폼 엔지니어링 팀이 필요하지 않을 수 있다. 작은 규모의 조직에서는 애플리케이션 엔지니어들이 플랫폼 엔지니어링 업무를 겸하곤 한다. 공유 코드의 문제점이 증가해 자발적인 기여로 감당하기 어려울 정도가 되면 플랫폼 엔지니어링 팀을 구성할 때다. 최초의 플랫폼 엔지니어링 팀은 다른 엔지니어링 조직과 강한 연결을 유지해야 하며, 과도한 수준의 플랫폼을 구축하지 않도록 주의해야 한다.

이 문제 자체보다 '지나친 시스템 중심 접근', '과도한 개발 중심 접근' 같은 문제가 팀에 해를 입힌다는 것을 모두가 동일한 수준으로 이해하는게 더 어려운 문제처럼 느껴진다. 원글에 "리더십은 권위에 호소하며 표준을 규정해버리곤 한다." 라는 서술이 있는데, 리더십은 실무와 멀어지면서 정말로 팀에 필요한 관심사와 전혀 다른 문제를 고민하는걸 보아왔다.

개인으로서는 리더를 조금씩 해킹하는 것 이외엔 수단이 안보이는데, 이런 짓을 하다보면 현타가 온다. 성실히 임하면 문제를 해결하기 위한 자원을 기대하지 않는 곳에 사용하거나, 같이 일한 동료들을 인정하는 대신 본인의 노고와 보상을 높게 치면서 다른 동료들이 힘들어하고, 코드베이스와 협업문화에 관찰하기 힘든 레버리지들이 쌓이는게 눈에 보이기 때문이다.

보통은 이런 인식자체를 못할 뿐더러, 이런 주장을 인정하려고도 하지 않는다. 단기적으로 본인에게 득이 되는 것 보다 잃는게 많고 현재에 너무 만족스럽거나 고된 스트레스에 시달리기 때문이다. 이런걸 무시할 수 있는 사람은 싸이코패스 내지는 책임 선긋기의 달인 정도이기 때문에, 나한테 신뢰할 수 있는 리더라는 존재는 유니콘에 좀 더 가깝다.

문제를 해결하는 리더란 존재를 만나보고 싶다.