Ostatnio zastanawiałem się nad dwoma tematami, które mają podobny temat. Pierwszy temat dotyczy stanu infrastruktury publicznej w Kalifornii i tego, jak nieefektywna stała się na przestrzeni lat. Drugi to niepowodzenie dużych firm technologicznych we wprowadzaniu innowacji i szybszym wykonywaniu zadań niż zasiedziałe start-upy. Pozwólcie, że przedstawię kilka perspektyw, dlaczego te tematy są ze sobą powiązane, podając najpierw dwa przykłady do przemyślenia:

• Infrastruktura : Budowa mostu Golden Gate trwała około czterech lat (1933–1937) i kosztowała nas około 500 milionów dolarów w przeliczeniu na dzisiejsze dolary. Z kolei SDS ( Suicide Deterrent System ), który w zasadzie dodaje siatkę wokół mostu, zajmie nam pięć lat (2017-2023) i ma nas kosztować około 217 mln USD. Jeśli dokonasz przeglądu dużych projektów infrastrukturalnych w Kalifornii, przekonasz się, że w przypadku projektów ukończonych przed 1950 rokiem prace były wykonywane szybciej, taniej i z wyższą jakością niż obecnie, co najmniej pięciokrotnie, mimo że obecnie mamy więcej kapitału, lepszą technologię, lepsze surowce i wyższą bezwzględną liczbę inżynierów budownictwa i architektów.
• Firmy technologiczne : Adobe, pomimo wszystkich swoich zasobów finansowych i ludzkich, musi pozyskać konkurenta za 20 miliardów dolarów. Czy Adobe przepłacił za Figmę, dopiero się okaże, ale bardziej interesujące jest pytanie, dlaczego firma ze 100-krotnie większym personelem, 100-krotnie większym doświadczeniem w zakresie narzędzi projektowych i 100-krotnie większym kapitałem finansowym nie wygrała?

Podobnie, jeśli przyjrzysz się firmom, możesz zauważyć, że w miarę ich rozwoju przetwarzanie i rozdęcie wkradają się do wszystkiego i tłumią prawdziwą pracę i innowacje. W tym środowisku pracownicy, którzy są najbardziej chętni do tworzenia rzeczy, twórcy, uważają, że po prostu bardziej atrakcyjne jest przeskakiwanie statku do mniejszego miejsca, w którym ich praca ma ujście do materializacji. Zarówno awarie infrastruktury, jak i awarie firm w zakresie innowacji są przynajmniej częściowo spowodowane rozrostem i pełzaniem procesów.

Dlaczego dochodzi do pełzania procesu?

Każdy proces zaczyna się od dobrych chęci.

• „Chcemy mieć pewność, że wszyscy interesariusze mają wkład w ostateczną pracę, dlatego wszystkie przesłane propozycje projektów muszą zostać zweryfikowane przez zespoły prawne, projektowe, produktowe i inżynieryjne”.
• „Chcemy mieć pewność, że duże projekty infrastrukturalne nie powodują szkód, dlatego przed rozpoczęciem jakichkolwiek prac musimy przeprowadzić dokładne badania środowiskowe”.
• „Chcemy zminimalizować przypadki naruszeń danych, dlatego wszelkie prośby o dane muszą być kierowane do zespołów IT i ds. bezpieczeństwa”.

Droga do perfekcjonizmu

Pamiętam, jak menedżer o dobrych intencjach kazał swoim bezpośrednim podwładnym pisać oprogramowanie tak, jakby miało to trwać 100 lat. Chociaż uwaga była hiperboliczna, rada przypomina coś, co często słyszałem w branży technologicznej poprzez przysłowia typu „zmierz dwa razy i napisz raz” lub „jeśli nie masz czasu, aby zrobić to dobrze, czy masz czas na to dwa razy?” To nie jest zła rada. W niektórych sytuacjach trzeba pisać kod tak, jakby miał przetrwać 100 lat, a przystąpienie do realizacji bez planowania jest marnotrawstwem. Niemniej jednak skrajny nacisk na planowanie może prowadzić do paraliżu i braku rozpoznania korzyści płynących z uczenia się poprzez iteracje. Wolałbym żyć w świecie, w którym oprogramowanie jest przepisywane co roku, ponieważ istnieje silne przekonanie, że doskonałość nie istnieje i że warunkiem wstępnym ewolucji jest zmiana, zamiast w świecie, w którym wszystko działa na podstawie „ 50-letnich baz kodu ”.

Za dużo kleju

Wiele lat temu przeczytałem post na blogu Tanyi Reilly na temat bycia Klejem (przy okazji, gorąco polecam). W tym momencie mojej kariery treść naprawdę odbiła się echem, ponieważ miałem do czynienia z kilkoma kolegami, którzy chociaż byli technicznie kompetentni, po prostu nie pracowali nad właściwymi rzeczami. Ludzie kleju angażują się w proces przywództwa technicznego i mentoringu, który prowadzi do zwiększenia produktywności innych osób w zespole. Potrzebna jest pewna ilość kleju, niemniej jednak odkryłem, że zbyt duża ilość kleju stwarza szereg innych problemów:

• Ludzie wykonujący klejenie uniemożliwiają innym ludziom doskonalenie swoich umiejętności nietechnicznych. Na przykład lider techniczny, który nie pozwala swojemu zespołowi mówić o swojej pracy lub często działa jako „bufor”, zasadniczo odbiera IC możliwości walki i ostatecznie poprawy umiejętności komunikacyjnych.
• Ekstremalne i toksyczne wersje zachowania kleju czasami przejawiają się w przypisywaniu sobie zasług innych ludzi lub w generowaniu rażąco przesadnej atrybucji („np. beze mnie jako pośrednika projekt by się nie powiódł”). Podczas gdy Tanya mówi o sytuacjach, w których ludzie z Kleju często nie są doceniani, moje doświadczenie jest zupełnie odwrotne. Ponieważ ludzie z Glue są dobrymi komunikatorami, wiedzą, jak reklamować swoją pracę i dobrze uprawiać politykę. W zamian zyskują lepszą widoczność i więcej możliwości promocji, a inżynier, który pracuje nad szczegółami wdrożenia, często otrzymuje symboliczne uznanie lub w ogóle nie otrzymuje uznania.
• Wreszcie, dodanie zbyt wielu ludzi zajmujących się klejem zmniejsza własność i odpowiedzialność poszczególnych inżynierów. Zamiast dodawać ludzi do zarządzania technicznie kompetentnym zespołem, po prostu zwolniłbym inżynierów, którzy wydają się nie mieć intuicji biznesowej, brakuje im umiejętności komunikacyjnych lub nie potrafią ułożyć akapitu opisującego, dlaczego praca, którą wykonują, ma wpływ. Sugerowanie, że potrzeba więcej kleju, aby zarządzać inżynierami, kończy się odrzuceniem ogólnego wzorca, że ​​ludzie, którzy są genialni technicznie, mają również wysoki poziom ogólnej inteligencji, dużo czytają, uczą się przez całe życie i są bardzo dobrzy w biznesie, a nie tylko w programowaniu.

Kiedy pracowałem w firmie Novell, dowiedziałem się, że są ludzie, których nazywam „ludźmi klejącymi”. Ludzie kleju to niesamowicie mili ludzie, którzy siedzą na międzywęzłowych granicach między grupami i pomagają w działaniu. I są bardzo, bardzo lojalni, ludzie ich kochają i wcale ich nie potrzebujesz.

W firmie Novell wciąż próbowałem pozbyć się tych ludzi od kleju, ponieważ przeszkadzali, ponieważ spowalniali wszystko. I za każdym razem, gdy pozbyłem się ich w jednej grupie, pojawiali się w innej grupie, przenosili się, byli ponownie zatrudniani i tak dalej.

Entropia

Wraz z rozwojem organizacji rośnie wiedza instytucjonalna, liczba interesariuszy, bazy kodów i entropia. Zwiększona entropia prowadzi do dużego marnotrawstwa, dużego obciążenia poznawczego, dezorganizacji i chaosu.

Myślę, że jako inżynierowie oprogramowania wykonaliśmy kiepską robotę w zarządzaniu złożonością. Na przykład od lat słyszymy, że monolity są złe, ponieważ generują rozdęte bazy kodu, utrudniają wdrażanie lub stwarzają problemy ze skalowalnością. Jednak z drugiej strony, gdzie musimy działać w świecie mikrousług, stwierdzam, że aby dostarczać podstawowe rzeczy, muszę działać w wielu bazach kodu napisanych w różnych językach, z których każdy ma swoje dziwactwa wdrożeniowe i wzorce architektury, z całym paradygmat zamienia się w lambda spaghetti . Zatrzymanie się i ponowne skupienie się na tym, co ważne, ma duży wpływ na zmniejszenie entropii. Na niskim, zorientowanym na działanie poziomie może przejawiać się w następujący sposób:

• Usuwanie martwego kodu, który nie jest wykonywany w środowisku produkcyjnym. Współpracowałem z wieloma bazami kodu, w których> 50% kodu było martwym kodem i tworzyło obciążenie poznawcze dla współpracowników. Chciałbym, żeby w obszarze produktywności programistów było coś, co generowałoby pokrycie kodu na podstawie linii wykonanych w środowisku produkcyjnym. Co kwartał zatrzymujesz się i przeglądasz te raporty i po prostu usuwasz pliki, które nie miały żadnego wykonania.
• Jako menedżerowie produktu nie zastanawiamy się wystarczająco nad tym, które funkcje powinniśmy usunąć lub przywrócić. Jednak zatrzymanie się i zastanowienie się nad tym, co należy usunąć, może być bardzo znaczące w uproszczeniu i poprawie doświadczenia użytkownika. Uważam się za obeznanego z technologią, ale uważam, że wiele tworzonych obecnie produktów zostało hiper-zoptymalizowanych pod kątem zestawu istniejących użytkowników, co prowadzi do zagraconych i mylących doświadczeń UX dla nowych użytkowników. Pytanie na koniec kwartału „Którą funkcję możemy cofnąć?” może być przydatne w zmniejszaniu bałaganu.

Ego jest wrogiem

Ryan Holiday sugeruje w swojej książce Ego is the Enemy, że istnieje silna „pokusa, która istnieje dla każdego — by rozmowa i szum reklamowy zastąpiły działanie”. Ego jest głównym powodem, dla którego postęp i innowacje mogą być słabe w wielu instytucjach. Oto jak manifestuje się ego:

• Widzieć, jak ci sami ludzie mają ochotę podzielić się swoimi przemyśleniami w rozmowie grupowej, mimo że ich pomysły nie wnoszą żadnej lub bardzo niewielkiej wartości marginalnej.
• Posiadanie ludzi, którzy nigdy nie angażują się w aktywne sponsorowanie swoich kolegów lub którzy próbują gromadzić widoczność. Jeśli jesteś menedżerem lub menedżerem menedżerów, możesz to zauważyć, obserwując, jak często Twój bezpośredni podwładny mówi o sukcesach lub wkładzie innych osób w Twoich ocenach 1:1. Brak uznania lub bezinteresowne sponsorowanie innych ludzi może być oznaką niezdrowego ego.
• Optymalizacja pod kątem zespołu zamiast całej firmy lub organizacji. Pożyczyłem diagram ze ścieżki inżyniera personelu autorstwa Tanyi Reilly i doskonale ilustruje ten problem, w którym zespoły optymalizują lokalne maksimum. Na przykład, czy możesz rozwiązać swój zespół i przenieść pracowników do innych zespołów, jeśli w Twojej domenie przechodzisz w tryb konserwacji? Większość menedżerów nigdy by tego nie zrobiła, ponieważ oznaczałoby to utratę kapitału społecznego i politycznego w firmie.

• W zależności od twojej roli istnieje bardzo silna dychotomia, jeśli chodzi o to, jak postrzegasz wartość spotkań. „ Najpotężniejsi ludzie są w harmonogramie menedżera ”. Niestety, ich postrzeganie wartości spotkań tworzy kulturową nadrzędność, która dotyka ludzi, którzy wolą mieć nieprzerwany czas na przemyślenie problemu i rozwiązania. Nawet w przypadku burzy mózgów dowody sugerują, że grupowa burza mózgów jest stratą czasu . Dlaczego jednak tak wiele rozdętych organizacji spędza połowę czasu IC na spotkaniach?

Wniosek

Siła napędowa innowacji opiera się na zmianach ewolucyjnych. Ostatecznie, jeśli instytucja stanie się sztywna i nie dostosuje się do zmian, umrze powolną śmiercią. Z mojego doświadczenia wynika, że ​​wprowadzenie procesu często wiąże się z niezamierzonymi kosztami, które prowadzą do zmniejszenia prędkości. Zamiast tego skupiłbym się na następujących kwestiach:

• Faworyzowanie iteracji i uczenia się na błędach zamiast dążenia do perfekcjonizmu.
• Ludzie kleju są potrzebni, ale ich liczba musi być ograniczona, aby mogli działać z dużą dźwignią. Samo zatrudnienie ludzi, którzy są zarówno kompetentni technicznie, jak i mają dobrą intuicję biznesową, może rozwiązać problem nadmiernego zatrudniania na stanowiska klejące.
• Na koniec skupiłbym się na zmniejszeniu entropii, nieustannie pytając, co można wyrzucić, i nagradzając ludzi za zachowanie, które zwiększa prostotę.