Как да разберете кога вашият стартиращ бизнес има нужда от инженерни мениджъри
Разберете как се развиват стартиращите компании, защо са необходими мениджъри и как да разберете дали трябва да наемете инженерен мениджър.
Повечето технологични лидери, които са били в ранен етап на стартиране, са се сблъскали с този въпрос: „Имам ли нужда от инженерен мениджър?“
Това е трудно решение. Повечето стартиращи фирми на ранен етап не разполагат с пари. Всеки долар, който харчат за „скъп“ мениджър, е един долар по-малко, който могат да харчат за директен участник в кодовата база.
Освен това, наемането нагрешенмениджър може да бъде невероятно вредно за културата и организацията. Техническите лидери на лидерски позиции за първи път се справят двойно по-лошо – те също трябва да се борят с факта, че никога преди не са наемали мениджър, което увеличава вероятността да наемат лош.
Изправени пред такава несигурност, много технологични лидери на стартиращи фирми отлагат решението, прибягвайки до това, което знаят най-добре: индивидуален принос.
Понякога по-късно е твърде късно
Да, наемането на мениджмънт твърде скоро може да се превърне в ненужен разход за компания с финансови затруднения. Обратната страна обаче също е вярна: твърде късното наемане може да струва скъпо на компанията. Културните, технологичните и процесните проблеми се усложняват с времето и дори най-добрите мениджъри в света не могат да поправят щетите за една нощ. Времето е изключително важно.
Как определяте кога имате нужда от слой за инженерно управление?
Ще разваля финала рано - публикация в блог онлайн не може да ви каже кога вашата компания има нужда от мениджъри.
Това е изключително обстоятелствено решение, което само хората в компанията ще имат контекста да вземат. Най-доброто, което една онлайн статия може да направи, е да ви помогне да се въоръжите със знания – разбиране на фундаменталното „Защо?“ зад мениджърите, така че да бъдете по-добре информирани, за да определите „Кога? ”.
Разбиране на еволюцията на инженерната организация
За да разберете защо човек изобщо има нужда от инженерен мениджър, е важно да разберете жизнения цикъл на една инженерна организация в рамките на стартъп, който може да се осъществи за период от години.
Наченките
Стартиращите фирми обикновено започват живота си с един вътрешен разработчик или изпълнител. В този момент дори не можете да го наречете отбор. Този първоначален разработчик или се отчита директно на основателя, или самият той е технически основател.
Пускане на продукта на пазара
Тъй като компанията продава своята визия и това, което са изградили досега, те трябва да увеличат скоростта си на развитие, за да изградят всички неща, които пазарът изисква. Те стигат до момента, в който изпълнителите не са достатъчни или стават твърде скъпи.
В подкрепа на новите изисквания към екипа за разработка, стратегията за наемане се измества и фокусът започва да бъде върху изграждането на вътрешен екип. Стартирането в крайна сметка ще достигне момент, в който има 6-8 инженери в един екип, всички работещи върху един и същи продукт.
С толкова голям екип, основателят вече не е в позиция да управлява директно тези инженери, ако някога са били на първо място. Те са твърде заети да правят сделки, да измислят финанси, бизнес планове и всички онези неща, които бизнесмените правят и които инженерите често приемат за даденост.
Вместо това, отговорността да се гарантира, че екипът продължава да изпълнява бързо, пада върху първоначалния разработчик или най-старшия разработчик. Този разработчик, чрез придобиване на огромно количество знания в областта в продължение на няколко години, стана де факто ръководител на инженерния отдел, отговарящ за всички останали инженери, които са привлечени.
Тяхното заглавие се различава в зависимост от компанията - някои компании използват директор по инженеринг, други технически директор, трети водещ софтуерен инженер. Техническите характеристики нямат толкова голямо значение, колкото фактът, че те са техническият лидер на организацията.
Бремето на успеха
Тъй като компанията расте и печели сцепление на пазара, технологичните изисквания нарастват. Междуфункционалното сътрудничество е все повече ключов компонент на работата. Работата със заинтересовани страни от бизнеса, потенциални клиенти, регулаторни органи, като същевременно поддържате екипа на продукта да гребе, е много работа и много комуникация.
В един момент на началника на инженеринга му просветва, че тяхното време вече не е тяхно време. Само един поглед към техния календар доказва това:
Някъде по време на линията времето им премина от кодиране 24/7 до срещи 24/7. Трудно е да се определи точно кога е било това, но вероятно е било, когато организационната диаграма е започнала да изглежда така:
Повечето хора изискват повече комуникация. Проектите стават по-сложни, с повече движещи се части. Бизнес изискванията нарастват с ускоряването на растежа на компанията. Ръководството желае ръководителят на инженерния отдел да се фокусира върху най-важното нещо. С толкова много хора ръководителят на инженерния отдел едва може да се съсредоточи върху нищо.
Привличане на старши талант
Ако организацията няма старши инженери в този момент, те често ги привличат, като обосновката е, че старшите инженери изискват по-малко управление и могат да помогнат за поемането на някои от тези отговорности.
Това случайно е правилна обосновка. Тъй като тези старши инженери станат надеждни изпълнители, ръководителят на инженерния отдел може да започне да им делегира отговорност за завършване на определени проекти или потоци от работа.
Разделяне на отбори
В много случаи ръководителят на инженерния отдел имплицитно знае кога достигат своите граници.
Те често се опитват да спестят повече от собственото си време, като синхронизират само със старшия инженер, когото са поставили да отговаря за проекта или работния процес, като избягват да се налага да синхронизират с всеки отделен инженер, който е част от същия проект.
Това има смисъл - част от стимула на делегирането е ръководителят на инженерния отдел да отделя по-малко време за определени неща, което включва надзор на проекта и хората, и тази дейност намалява броя на комуникационните канали, които ръководителят на инженерния отдел трябва да поддържа синхронизирани.
Въпреки че официалните линии за отчитане не се променят, инженерната организационна диаграма започва имплицитно да изглежда по-долу:
Формализиране на разделянето
В крайна сметка разделянето се формализира. Както писах в друга публикация, има различни начини, по които можете да разделите екипи, с плюсове и минуси на всяка структура. Съществуват и скрити опасности квалифицирани ИС внезапно да поемат управленски роли без подходяща подготовка и методи, с които да се противопоставят на недостатъците.
Независимо от това, крайният краен резултат е, че има различни екипи, с различни лица, отговорни за тях:
Нещата под тази структура стават много по-управляеми за ръководителя на инженерния отдел и организациите могат да извървят дълъг път с този подход.
Защо това работи?
В този сценарий има някои основи на организационните структури, които трябва да разберем.
С разрастването на организацията става все по-трудно да се гарантира, че всички са синхронизирани. Това е така, защото изискванията за комуникационни канали нарастват експоненциално с размера на организацията.
В ранните етапи на стартиране, да речем - когато има само трима души - за тези трима души е лесно да говорят помежду си. Има само три комуникационни пътя за постигане на споделено съзнание и привеждане в съответствие. Всеки може да общува с всеки.
Но ако организацията стане по-голяма? Това е друга история.
Това, което имаме тук, е провал в комуникацията
С увеличаването на броя на хората, броят на връзките между тях експлодира драматично. Стратегия за синхронизиране, която е поддържала 5 или 10 души в синхрон, внезапно се разваля при 15. Проблемът става още по-лош с нарастването на организацията:
- 9 души? 36 връзки.
- 15 души? 105 връзки.
- 50 души? 1225 връзки.
- 100 души? 4950 връзки.
Невъзможно е да поддържате толкова много хора синхронизирани и на една и съща страница, като използвате стратегия, която включва директна комуникация 1:1.
Това е голяма причина, поради която съществуват организационни структури: да се създаде поток от комуникация, който може да се управлява ефективно. Преходът към модел, при който комуникацията протича между конкретни индивиди, създава ред.
Има обаче някои дребни недостатъци. Тъй като всеки отделен член сега няма достъп до пълното съзнание на организацията, тя има тенденцията да създава силози. Тези силози могат лесно да се разместят в по-голямата организация.
Тези недостатъци се противопоставят с фокус върху ефективното привеждане в съответствие, генерирано от - познахте - ефективни управленски дейности. Тези управленски дейности гарантират информационните потоци до мястото, където е необходимо, и отделните силози насочват усилията си в посока, която е в съответствие с останалата част от организацията.
Защо ръководителят на инженерния отдел не може да го направи?
Често срещан въпрос, който ми задават, е защо ръководителят на инженерния отдел не може просто да управлява хората?
Те биха могли, ако имат набор от умения (които мнозина нямат), но това само забавя неизбежното. Има твърде много други изисквания към тяхното време, за да могат ефективно да правят всичко, което им се иска в една разрастваща се организация.
Компаниите признават това и повечето в крайна сметка разделят отговорностите на ролята на ръководителя на инженерния отдел.
Разделяне на ролята на началник инженеринг
Ръководителят на инженерния отдел в този момент има (или не притежава) определени умения.
Ако използваме опростен 4-квадрантен модел на набор от умения на CTO, получаваме следното:
- Управление на хора
- Управление на изпълнението
- Кодиране и технология
- Управление и стратегия
Малко, ако има такива, хора са силни във ВСИЧКИ тези области. Повечето инженерни лидери имат една или две от тези области, в които превъзхождат, и имат различни нива на представяне и интерес към останалите.
Като имат някой, който се отличава в областите, в които ръководителят на инженеринга е приемлив само, организациите могат да гарантират, че ключовите аспекти на ролята получават вниманието, което заслужават. Това позволява на ръководителя на инженерния отдел да се съсредоточи върху силните си страни и организацията като цяло става по-силна.
Понякога това е трудно хапче за преглъщане и някои технически лидери се противопоставят на идеята да се откажат от своя авторитет и сила. Те се придържат към всички тези области, независимо от уменията си, отслабвайки организацията в полза на своето его.
Ефективните лидери обаче признават колко е важно да разчитат на своите силни страни и приветстват способността за съсредоточаване, която идва с разделянето на ролята им.
Къде се разделят отговорностите?
Това е силно зависимо от контекста и наистина зависи от участващите хора и организацията.
Ръководител на инженерния отдел с управление на хора и управление на изпълнението вероятно ще иска да бъде в роля, която остава близо до ежедневието, и ще прехвърли стратегията и управлението на встъпващия технически директор. В случаи като този ръководителят на инженерния отдел става вицепрезидент на инженерния отдел.
Ръководител на инженерния отдел, който иска да се съсредоточи повече върху кодирането, технологиите и инфраструктурните аспекти на ролята, може да поеме ролята на главен технолог. В случаи като този те често остават CTO, фокусиран върху IC, като управлението на изпълнението пада върху нов вицепрезидент по инженерството.
Може би ръководителят на инженерния отдел иска да бъде по-ориентиран към външното лице/управление/стратегия. В този случай те остават управленски / стратегически технически директор, като управлението на изпълнението пада върху вицепрезидента по инженерството.
Организацията трябва да работи със своя ръководител на инженерния отдел, за да открие своите силни страни и да гарантира, че разбивката на ролите отговаря на техните интереси.
Какво се случва, ако ръководителят на инженерния отдел изобщо не е готов?
Разбира се, винаги има последна опция: Ръководителят на инженерния отдел просто няма необходимите умения, за да преведе компанията през следващото ниво.
Има много причини, поради които това може да се случи.
Някои инженери започват кариерата си в стартиращ бизнес и растат заедно с него. В ранните етапи, когато изграждането е приоритет, те могат ефективно да изпълняват ролята, но по-късните етапи имат значително различни изисквания за умения, за които може да не са готови.
Някои просто не се интересуват от действителните отговорности, които вървят заедно с ролята, след като организацията стане по-голяма, и просто не беше точно това, което очакваха.
Организационните изисквания се променят, когато стартиращият бизнес преминава от етап на етап и са необходими различни умения за различните фази. Въпреки че мнозина го правят, не всеки успява да се адаптира към тези промени и да запази своите умения уместни. Това не е универсално интересно за всички и хората може да имат предпочитания за конкретни етапи на стартиране.
Решението тук е просто: те или поемат по-ниска роля в организацията, по-подходяща за техните набори от умения, така че да могат да продължат да допринасят максимално, или се разделят с компанията.
Мениджърът на мениджърите
Разбира се, предполагам, че сте щастлива организация, благословена с фантастичен технически лидер.
Каквото и да изглежда разделението на ролите, вицепрезидентът по инженерство в крайна сметка поема управлението на екипите за разработка, управлявайки мениджърите, които управляват екипите. Понякога те докладват на CTO, друг път докладват на CEO.
Управленският слой е инсталиран и с нарастването на екипа той се разширява с течение на времето, включително повече мениджъри. За по-големите организации титлата Директор по инженерство често се завръща в намален, неорганизационен обхват, като управлява мениджъри, които са част от конкретна работна група или отдел.
Какво трябва да се запитате?
И така, след като разгледахме еволюцията на този хипотетичен стартъп, стигаме до истинския въпрос: как да разберете кога е време да получите ниво на управление за ВАШЕТО стартиране?
Честно казано, статия в блог онлайн не може да ви каже това. Зависи от контекста. Въпреки това, като си зададете следните въпроси, ще изградите информираност за това какво конкретно да търсите:
Вашата организационна култура оценява ли управлението?
Някои стартиращи култури са много ориентирани към IC (индивидуален сътрудник) до крайност. Стартиращите фирми в ранен стадий оцеляват благодарение на желанието на членовете си да направят всичко необходимо, да носят колкото се може повече шапки и да се трудят и да работят, за да свършат нещата.
В тези организации концепцията за някой, който седи наоколо и всъщност не прави нищо сам, е анатема за идеята за Heroic Contributor. Разбира се, това е погрешно вярване, но открих, че преобладава в много стартиращи фирми на ранен етап.
Ако вашата организация не цени мениджърите, тя ще постави очакванията на отделен сътрудник върху тях и ще намали оценката за управленските аспекти на ролята, а това е рецепта за провал.
Какво правите, ако вашата култура не оценява мениджърите?
Ако вашата култура не цени мениджърите, вероятно или:
- Има лоши примери от мениджъри
- Всъщност не знам каква е стойността на един мениджър
Мениджърите съществуват с причина и техните действия могат да допринесат значително дори за култури, ориентирани към изпълнение – координация, изпомпване на информация, привеждане в съответствие, са всички дейности, които намаляват триенето при изпълнение в целия екип.
Мениджърите могат също така да осигурят умения и напредък в кариерата, осигурявайки ценен фокус върху обучението и растежа. Те подпомагат изпълнението, а също и задържането на служителите.
И накрая, мениджърите могат да помогнат за осигуряване на емпиризъм и подобряване на процесите в дългосрочен план чрез събиране на показатели и оптимизационни дейности въз основа на тях. Фокусът върху подобряването може да помогне за премахване на неефективността и неефективното поведение - неща, върху които е трудно да се съсредоточите, ако сте заети да се опитвате да участвате в следващия проект.
Управленските дейности (извършени добре) действат като мултипликатори на сила, което води до страховитата бизнес дума за синергия,сумата от частите заедно става по-голяма от това, което биха могли да бъдат поотделно.
И накрая, запомнете: Google веднъж се опита да се отърве от всичките си мениджъри. „Мина доста зле.“
Вашият началник инженерен отдел претоварен ли е?
Претоварен може да бъде претоварен термин, така че нека уточним какво означава това.
Вашият ръководител на инженеринга...
- ... прекарват повече време в неща, които не харесват, отколкото в неща, които обичат и в които се отличават?
- ...изглежда, че сте на срещи по цял ден и имате огромен натрупан код, който трябва да напишат?
- …изглеждате стресирани, тревожни, демотивирани, изгорени, депресирани, безнадеждни?
- ...продължават да искат бюджет за наемане на старши инженери с надеждата, че ще освободят време?
Ако отговорът е „да“, трябва да го разгледате по-подробно.
Проектите често ли пропускат целите за пускане?
Проекти, които се забавят многократно, показват някаква форма на проблем с процес, качество или хора. Фактът, че се случват често, означава, че нещо липсва, независимо дали това е по-добра координация, яснота на целите или време за отчитане на техническия дълг.
Мениджърите могат да се потопят дълбоко в тези проблеми и да помогнат за поддържането на проектите по правилния път.
Получавате ли много грешки?
Ето една тайна: в добре проектирани проекти грешките трябва да се случват ПО-МАЛКО често с течение на времето, не повече. Ако бъгове се случват все по-често, това може да е показателно за сериозни проблеми с качеството, причинени от технически дълг, нереалистични крайни срокове, липса на умения или стандарти за качество, които се понижават.
Лесно е да отхвърлите нарастващия брой грешки като „проектът става все по-сложен“ или „движим се бързо и разбиваме нещата“, но истината е, че ако имате опцията „да се движите бързо и да не разбивате нещата“, , тогава „бързото движение и чупенето на неща“ е безотговорно.
Чувстват ли се инженерите несинхронизирани, липса на яснота или неправилно подравнени?
Една от ключовите управленски и лидерски дейности е осигуряването на яснота на екипа. Добрите мениджъри могат да действат като информационни помпи, като гарантират, че хората разполагат с информацията, от която се нуждаят, за да вземат ефективни решения, съобразени с целите на компанията. Те действат като генератори на подравняване, които карат всички в отбора да гребят в една и съща посока.
Ако вашият екип изглежда не знае какво се случва или изглежда объркан по отношение на целите или текущата ситуация, това е знак, че не получават информацията, от която се нуждаят.
Проучванията на служителите могат да помогнат да разберете това, заедно с 1:1 и други инструменти.
Инженерите оплакват ли се от липса на умения или напредък в кариерата?
Добрият мениджър може да направи чудеса за кариерното развитие на един инженер.
Те имат време да предоставят ресурси, насоки, обучение, обучение и възможности за инженера да расте и да се усъвършенства. Те могат да работят 1:1 с инженера, за да разработят персонализиран план за растеж, който помага на много по-бързо, отколкото те самите биха могли.
Това е масивен инструмент за задържане и повишаване на компетентността в дългосрочен план. Въпреки това изисква фокус и внимание и често е първото нещо, което се изпуска, когато крайните срокове започнат да се пропускат.
Без ниво на управление, посветено на това, често е решено дали нуждата ще бъде изпълнена.
Нямате ли представа за инженерните резултати или тенденциите?
Agile-istas често осъждат използването на показатели за измерване на представянето на екип за разработка, вместо това предпочитат да посочват „работещия софтуер“ като основна мярка за напредък и успех.
В епоха, в която всеки и неговото куче могат да създават работещ софтуер, това наистина ли е добър стандарт за използване?
Въпреки че съм съгласен, че показатели като Story Points и Velocity са злоупотребявани от дезинформирани бизнес лидери, правилното използване на показатели може да бъде мощен сигнал за посочване на проблеми с процеса или растеж на инженерните способности с течение на времето.
Показатели като време на цикъл, процент на отказ на промяна, честота на внедряване могат да ви помогнат да разберете дали вашият екип в дългосрочен план се подобрява или влошава и можете да насочите подобрения, за да се съсредоточите върху области, които ще се възползват най-много от тях.
Чувстват ли се инженерите безсилни?
Можете да разберете кога сте в упълномощен инженерен екип. От момента, в който започнете да работите с тях, усещате това бръмчене на работа и това желание да превъзхождате и подобрявате всичко.
Можете също така да разберете кога сте в лишен от права инженерен екип. Те не комуникират. Те не поемат инициативата. Те правят само това, което им се каже да направят - нито повече, нито по-малко. Те не изпитват удоволствие от работата.
Ефективното инженерно управление може да съживи екипа и да му помогне да го вдъхнови и овласти. Виждал съм десетократни подобрения в ефективността на развитието на екипи, които са били поставени под ефективен мениджър, след като са изнемогвали под лош такъв или изобщо без мениджър.
Наемането на мениджър не е лесно решение, но е критично за един стартиращ бизнес. Тъй като стартиращите фирми растат и се развиват, тежестта на сътрудничеството става твърде голяма, за да може да я поеме изключително ръководителят на инженерния отдел.
Ефективното ниво на управление често се превръща в необходимост, за да се гарантира, че организацията може да продължи да успява и да превъзхожда на следващото ниво.
Джозеф Гефро е инженерен лидер в Сиатъл, Вашингтон. Неговият предишен опит включва като старши директор по инженерството в Snap! Рейз и инженерен директор в Jumpsuit Commerce.
