Pierwsze zatrudnienia tech: kogo brać najpierw, a kto jest za wcześnie

Sekwencja pierwszych zatrudnień tech jest w większości startupów podobna: najpierw 1-2 inżynierów pełnostackowych zdolnych do samodzielności, potem senior/tech lead, który wyznaczy standardy, potem specjalizacje (frontend/backend/data) i pierwszy produktowiec, a role menedżerskie i wąskie specjalizacje dopiero wtedy, gdy zespół i skala ich wymagają. Najdroższe błędy to nie złe CV, tylko złe sekwencje: menedżer przed zespołem, wąski specjalista przed potrzebą, etatowy CTO przed PMF. Budowałem zespoły od pierwszego zatrudnienia do 185 osób i poniżej opisuję kolejność, która minimalizuje koszt pomyłki.

Przed PMF firma potrzebuje ludzi, którzy szybko budują i wyrzucają: generalistów o wysokiej samodzielności, odpornych na chaos i zmiany kierunku. Po PMF zaczyna potrzebować ludzi, którzy budują na lata: specjalistów, standardów, struktury. Większość błędów rekrutacyjnych founderów to zatrudnienie profilu z niewłaściwego etapu: świetny inżynier z korporacji, przyzwyczajony do procesów i stabilnych wymagań, cierpi przed PMF, a hakerski generalista nudzi się i szkodzi w fazie systematyzacji.

Na etapie pre-PMF (0-6 inżynierów) zatrudniasz 1-2 generalistów full-stack na poziomie mid lub senior z wysoką samodzielnością, a unikasz menedżerów, wąskich specjalistów i juniorów. Na etapie wczesnego PMF (4-10 inżynierów) zatrudniasz tech leada lub seniora wyznaczającego standardy oraz pierwszego product managera lub designera, a unikasz drugiego menedżera i roli "head of" bez zespołu. Na etapie skalowania (8-20 inżynierów) zatrudniasz specjalizacje: frontend, backend, data, QA, pierwszego engineering managera i juniorów pod opieką seniorów, a unikasz etatowego CTO z rynku, jeśli wewnątrz rośnie kandydat. Na etapie struktury (20+ inżynierów) zatrudniasz liderów obszarów, role platformowe takie jak infrastruktura i security oraz rekrutera tech, a unikasz centralizacji decyzji, które wcześniej działały rozproszone.

Trzy komentarze do tej tabeli.

Juniorzy wchodzą późno nie z powodu kosztów, tylko czasu seniorów. Junior przed PMF konsumuje godziny mentoringu, których nie ma kto dać, i produkuje kod, którego nie ma kto sprawdzić. Od momentu, gdy na jednego juniora przypada 2-3 seniorów z czasem na review, juniorzy stają się świetną inwestycją.

Pierwszy menedżer pojawia się, gdy founder lub lead przestaje wyrabiać 1-1. Umownie przy 8-10 inżynierach. Menedżer zatrudniony wcześniej nie ma czym zarządzać i zaczyna produkować procesy, żeby uzasadnić rolę.

Etatowy CTO z rynku to ostatnia, nie pierwsza opcja. Do rundy A funkcję strategiczną taniej i bezpieczniej pokrywa techniczny co-founder albo fractional CTO, a docelowego CTO często lepiej wyhodować z tech leada, który zna system i zespół.

Zatrudnianie pod presją rundy. "Mamy pieniądze, plan zakładał 10 osób do grudnia" to najgorszy powód rekrutacji. Zatrudnianie do planu zamiast do wąskiego gardła produkuje zespół, który trzeba czymś zająć, i spadek velocity opisany w tekście o rosnącym zespole i spadającym delivery.

Optymalizacja pod CV zamiast pod etap. Nazwiska firm w CV mówią, w jakim systemie ktoś pracował, nie czy zbuduje twój. Przed PMF jedno pytanie rekrutacyjne bije wszystkie inne: "opowiedz o czymś, co zbudowałeś end-to-end sam, od decyzji po produkcję i utrzymanie".

Brak sekwencji w ogóle. Zatrudnianie reaktywne ("odszedł backendowiec, szukamy backendowca") utrwala strukturę z przeszłości. Raz na kwartał warto spojrzeć na plan zatrudnień jak na architekturę: jakiego zespołu wymaga roadmapa na 12 miesięcy i która rola odblokowuje najwięcej.

Osobny przypadek sekwencji: firma, której produkt buduje software house. Tam pierwszym hire nie jest "programista do pomocy dostawcy", tylko przyszły właściciel systemu, senior zdolny poprowadzić transfer wiedzy. Pełny plan tego przejścia, z fazami i ryzykami, opisałem w tekście o przejściu z software house na własny zespół.

Kogo zatrudnić jako pierwszego, jeśli founder nie jest techniczny? Nie pierwszego inżyniera, tylko najpierw osobę, która oceni, co budować i kim: technicznego advisora albo fractional CTO na 1-2 dni w tygodniu. Nietechniczny founder rekrutujący pierwszego inżyniera samodzielnie nie ma jak zweryfikować ani kandydata, ani później jego pracy, i to najczęstszy początek produktu do przepisania.

Senior drogi czy dwóch midów? Przed PMF jeden samodzielny senior prawie zawsze bije dwóch midów: mniej koordynacji, lepsze decyzje architektoniczne, których koszt odkręcania rośnie z czasem. Dwóch midów zaczyna wygrywać później, gdy istnieją standardy i jest komu robić review, czyli gdy system pracy jest już postawiony.

Kiedy pierwszy product manager? Gdy decyzje produktowe stają się wąskim gardłem: founder nie wyrabia z priorytetyzacją, discovery nie istnieje, zespół buduje rzeczy "bo były w backlogu". Zwykle to okolice 6-10 inżynierów. Wcześniej rolę produktu musi grać founder i to jest zdrowe, bo wymusza kontakt z klientem.

Jak sprawdzić samodzielność kandydata przed zatrudnieniem? Płatne zadanie próbne możliwie bliskie realnej pracy (dzień-dwa) plus pytania o rzeczy zbudowane end-to-end i decyzje podjęte bez szefa. W referencjach jedno pytanie: "w jakim środowisku ta osoba pracowała najlepiej, a w jakim najgorzej". Odpowiedź mapujesz na swój etap, nie na abstrakcyjną skalę talentu.

Plan zatrudnień na 12 miesięcy to dwie godziny pracy, jeśli robi się go od roadmapy, a nie od wakatów. Umów bezpłatny audyt: w 30 minut przejdziemy przez twój zespół i plany, a ja wskażę, która rola odblokowuje najwięcej i w jakiej kolejności rekrutować. Prowadzę to w ramach budowania zespołów tech-product.