Druga połowa „Artyści wysyłają”

Listopad 2008

Jedną z różnic między dużymi firmami a startupami jest to, że duże firmy zazwyczaj opracowały procedury chroniące je przed błędami. Startup zachowuje się jak dziecko, ciągle się potyka i przewraca. Duża firma jest bardziej rozważna.

Stopniowe gromadzenie się kontroli w organizacji jest rodzajem nauki, opartej na katastrofach, które ją spotkały lub spotkały podobne organizacje. Na przykład, po przyznaniu kontraktu dostawcy, który zbankrutował i nie dostarczył towaru, firma może wymagać od wszystkich dostawców udowodnienia ich wypłacalności przed złożeniem oferty.

W miarę rozwoju firmy nieuchronnie pojawia się więcej takich kontroli, albo w odpowiedzi na katastrofy, których doświadczyły, albo (prawdopodobnie częściej) poprzez zatrudnianie ludzi z większych firm, którzy przynoszą ze sobą zwyczaje chroniące przed nowymi rodzajami katastrof.

Jest naturalne, że organizacje uczą się na błędach. Problem w tym, że ludzie proponujący nowe kontrole prawie nigdy nie biorą pod uwagę, że sama kontrola ma swoją cenę.

Każda kontrola ma swoją cenę. Na przykład, rozważmy przypadek weryfikacji wypłacalności dostawców. Z pewnością jest to zwykła ostrożność? Ale w rzeczywistości może to wiązać się ze znacznymi kosztami. Oczywiście istnieją bezpośrednie koszty czasu osób po obu stronach, które dostarczają i sprawdzają dowody wypłacalności dostawcy. Ale prawdziwe koszty to te, o których nigdy się nie dowiadujesz: firma, która byłaby najlepszym dostawcą, ale nie składa oferty, ponieważ nie może poświęcić wysiłku na uzyskanie weryfikacji. Albo firma, która byłaby najlepszym dostawcą, ale nieznacznie nie spełnia progu wypłacalności – który oczywiście zostanie ustawiony na wysokim poziomie, ponieważ nie ma żadnego widocznego kosztu jego zwiększenia.

Za każdym razem, gdy ktoś w organizacji proponuje dodanie nowej kontroli, powinien wyjaśnić nie tylko korzyść, ale i koszt. Bez względu na to, jak źle wykonał analizę, ta meta-kontrola przynajmniej przypomniałaby wszystkim, że musi istnieć koszt, i skłoniła ich do jego poszukiwania.

Gdyby firmy zaczęły to robić, odkryłyby kilka niespodzianek. Joel Spolsky niedawno mówił w Y Combinator o sprzedaży oprogramowania klientom korporacyjnym. Powiedział, że w większości firm oprogramowanie kosztujące do około 1000 dolarów mogło być kupowane przez indywidualnych menedżerów bez dodatkowych zgód. Powyżej tego progu zakupy oprogramowania zazwyczaj musiały być zatwierdzane przez komitet. Ale obsługa tego procesu była tak kosztowna dla dostawców oprogramowania, że nie miało sensu pobierać opłat poniżej 50 000 dolarów. Oznacza to, że jeśli tworzysz coś, za co inaczej pobierałbyś 5000 dolarów, musisz sprzedawać to za 50 000 dolarów.

Celem komitetu jest prawdopodobnie zapewnienie, że firma nie marnuje pieniędzy. A jednak wynik jest taki, że firma płaci 10 razy więcej.

Kontrole zakupów zawsze będą kosztowne, ponieważ im trudniej jest coś ci sprzedać, tym więcej to musi kosztować. I to nie tylko liniowo. Jeśli jesteś na tyle trudny w sprzedaży, że ci sprzedają, ci, którzy najlepiej potrafią coś zrobić, nie chcą się tym zajmować. Jedynymi, którzy ci sprzedadzą, są firmy specjalizujące się w sprzedaży do ciebie. Wtedy spadłeś na zupełnie nowy poziom nieefektywności. Mechanizmy rynkowe już cię nie chronią, ponieważ dobrzy dostawcy nie są już na rynku.

Takie rzeczy stale zdarzają się największym organizacjom ze wszystkich, rządom. Ale kontrole wprowadzane przez rządy mogą powodować znacznie gorsze problemy niż tylko przepłacanie. Kontrole wprowadzane przez rządy mogą sparaliżować całą gospodarkę kraju. Do około 1400 roku Chiny były bogatsze i bardziej zaawansowane technologicznie niż Europa. Jednym z powodów, dla których Europa wyprzedziła, były ograniczenia długich rejsów handlowych przez chiński rząd. Tak więc to Europejczycy eksplorowali i ostatecznie zdominowali resztę świata, w tym Chiny.

W czasach nowszych Sarbanes-Oxley praktycznie zniszczył amerykański rynek IPO. Tego nie zamierzali prawodawcy, którzy go napisali. Chcieli tylko dodać kilka dodatkowych kontroli dla spółek publicznych. Ale zapomnieli wziąć pod uwagę koszt. Zapomnieli, że firmy, które miały być publiczne, są zazwyczaj dość napięte, a ciężar kilku dodatkowych kontroli, które mogłyby być łatwe do udźwignięcia przez General Electric, wystarczy, aby młodsze firmy w ogóle nie mogły być publiczne.

Gdy tylko zaczniesz myśleć o koszcie kontroli, możesz zacząć zadawać inne interesujące pytania. Czy koszt rośnie, czy maleje? Czy jest wyższy w niektórych obszarach niż w innych? Gdzie wzrasta skokowo? Gdyby duże organizacje zaczęły zadawać takie pytania, nauczyłyby się przerażających rzeczy.

Myślę, że koszt kontroli faktycznie może rosnąć. Powodem jest to, że oprogramowanie odgrywa coraz ważniejszą rolę w firmach, a ludzie, którzy piszą oprogramowanie, są szczególnie poszkodowani przez kontrole.

Programiści, w przeciwieństwie do wielu innych typów pracowników, faktycznie wolą ciężko pracować. Wydaje się, że w większości rodzajów pracy tak nie jest. Kiedy pracowałem w fast foodzie, nie preferowaliśmy ruchliwych godzin. A kiedy kiedyś kosiłem trawniki, zdecydowanie nie preferowałem tego, gdy trawa była długa po tygodniu deszczu.

Programiści jednak wolą, gdy piszą więcej kodu. A dokładniej, gdy wypuszczają więcej kodu. Programiści lubią mieć wpływ. Ci dobrzy, przynajmniej.

Dla dobrych programistów jedną z najlepszych rzeczy w pracy w startupie jest to, że jest niewiele kontroli nad wydaniami. W prawdziwych startupach nie ma żadnych zewnętrznych kontroli. Jeśli masz pomysł na nową funkcję rano, możesz ją napisać i wypuścić na serwery produkcyjne przed południem. A kiedy możesz to zrobić, masz więcej pomysłów.

W dużych firmach oprogramowanie musi przejść różne zatwierdzenia, zanim zostanie uruchomione. A koszt tego może być ogromny – w rzeczywistości skokowy. Rozmawiałem niedawno z grupą trzech programistów, których startup został przejęty kilka lat wcześniej przez dużą firmę. Kiedy byli niezależni, mogli natychmiast wprowadzać zmiany. Teraz, powiedzieli, najszybszy czas, jaki mogli uzyskać na wypuszczenie kodu na serwery produkcyjne, to dwa tygodnie.

To nie tylko sprawiło, że byli mniej produktywni. Sprawiło, że nienawidzili pracy dla nabywcy.

Oto oznaka tego, jak bardzo programiści lubią mieć możliwość ciężkiej pracy: ci ludzie zapłaciliby, aby móc natychmiast wypuszczać kod, tak jak kiedyś. Zapytałem ich, czy zamieniliby 10% ceny przejęcia na możliwość natychmiastowego wypuszczenia kodu, a cała trójka natychmiast odpowiedziała tak. Potem zapytałem, jaki jest maksymalny procent ceny przejęcia, który by za to oddali. Powiedzieli, że nie chcą o tym myśleć, bo nie chcą wiedzieć, jak wysoko by się posunęli, ale miałem wrażenie, że mogłoby to być nawet połowa.

Poświęciliby setki tysięcy dolarów, być może miliony, tylko po to, by móc dostarczać więcej oprogramowania użytkownikom. I wiesz co? Pozwolenie im na to byłoby całkowicie bezpieczne. W rzeczywistości nabywca byłby w lepszej sytuacji; nie tylko ci ludzie niczego by nie zepsuli, ale wykonali by znacznie więcej pracy. Tak więc nabywca faktycznie uzyskuje gorszą wydajność przy większych kosztach. Tak jak komitet zatwierdzający zakupy oprogramowania.

I tak jak największym niebezpieczeństwem związanym z trudnością sprzedaży nie jest to, że przepłacasz, ale to, że najlepsi dostawcy nawet ci nie sprzedadzą, tak największym niebezpieczeństwem stosowania zbyt wielu kontroli wobec programistów nie jest to, że uczynisz ich nieproduktywnymi, ale to, że dobrzy programiści w ogóle nie będą chcieli u ciebie pracować.

Słynne powiedzenie Steve'a Jobsa „artyści wysyłają” działa w obie strony. Artyści nie tylko są zdolni do wysyłania. Oni tego wymagają. Więc jeśli nie pozwalasz ludziom wysyłać, nie będziesz miał żadnych artystów.