Трябва ли да ги имаме?

Титлите на инженер грубо представят колко опит има един инженер и тяхната отговорност и роля в екипа. Ето някои често срещани инженерни заглавия:

  • Софтуерен инженер
  • Старши софтуерен инженер
  • Щатен софтуерен инженер
  • Главен софтуерен инженер

Имах възможност да работя в няколко среди, които третираха инженерните титли по различен начин. Днес искам да споделя някои от тези преживявания и моите мисли за тях.

Работа в малък екип

В началото на кариерата си работих в малък стартъп с по-малко от десет инженера. Познавахме се много добре. За нас беше ясно какви са силните страни и експертизата на всеки отделен човек и когато възникнеха проблеми, знаехме към кого да се обърнем за помощ.

Целият инженерен екип може да се побере в една и съща заседателна зала. На обяд всички грабвахме храна около един часа и използвахме Slack канал, #lunchatone, за да координираме времето за обяд. Седяхме около голяма маса за пикник, обядвахме и разговаряхме.

Ние познавахме добре целите и мисията на компанията и вярвахме в тях. Почти нямаше недоразумения в комуникацията.

В такава малка работна среда разграничаването на инженерни титли не би имало смисъл.

От без заглавия до заглавия

Когато компанията се разрасна, ние естествено започнахме да мислим за титли и екипни структури.

Често няколко проекта се изпълняваха едновременно и ставаше все по-трудно и по-трудно да се следи върху какво работи всеки човек. В нашите срещи с всички ръце ставаше все по-трудно и по-трудно да привлечем вниманието на всички. Например, ако имаше разгорещена дискусия относно мобилната MVVM архитектура между няколко инженери, които са работили много върху мобилни устройства, тези, които са работили дълбоко в задните системи, ще се отделят и ще работят на лаптопите си.

Наехме няколко ръководители от успешни стартиращи компании и големи технологични компании и започнахме да копираме това, което правят другите компании. Екипът беше разделен на множество измерения.

Той беше разделен на бизнес единици: екип, фокусиран върху приходите, екип, фокусиран върху растежа, екип за всеки продукт, който продаваме, и т.н. Той също беше разделен въз основа на технически домейни: iOS екип, Android екип, бекенд екип, екип за данни. И накрая, всеки инженер също ще получи титла, която отразява нивото му: младши, старши, директор и т.н.

Например софтуерен инженер сега ще бъде старши софтуерен инженер за Android в екипа по приходи.

Разделянето въз основа на бизнес единица или технически домейн беше лесно, но разделянето въз основа на ниво беше трудно. Как да разберем кой каква титла трябва да получи? Как да разберем колко нива трябва да създадем? И как бихме определили границите на отговорностите и очакванията за всяко ниво?

Преходът може да бъде бурен

В крайна сметка, когато голямата реорганизация беше направена, на всеки беше присвоено ново заглавие, което отразяваше неговия домейн и ниво. Всяко ниво също идва с дълго описание на отговорностите и очакванията.

Пътуването беше болезнено и неравномерно, превръщайки се в един от най-разрушителните и нестабилни периоди, които си спомням. Преди това коефициентът на текучество в компанията беше по същество 0. Някои хора трябваше да се преместят заради семейството, но те останаха с компанията, работеща от разстояние. Но след реорганизацията хората си тръгнаха.

Някои от тях чувстваха, че са малтретирани. Ако смятате, че сте по-голям принос, но сте получили по-ниска титла от вашия връстник, вашето уважение неизбежно ще бъде наранено. Независимо колко харесвате продукта, работата или екипа, би било трудно да останете, ако не смятате, че получавате признанието, което заслужавате.

Някои от тях вече не вярваха в ръководството или визията на компанията. Един страхотен инженер, също и добър приятел, веднъж каза: „Лидерите не се дават, но идват естествено. За тези, които са способни и запознати със системата, другите естествено биха се обърнали към тях за помощ.“ Той си тръгна не след дълго.

След като целият прах се улегна, тези, които си тръгнаха, бяха пропуснати, а тези, които останаха, бяха отнесени на път. Новата структура на екипа и инженерната йерархия направиха мащабирането на работната сила много по-лесно. Докато продължавахме да растем, трябваше да наемем инженери на различни нива и да създадем повече екипи.

Някои проблеми със заглавията

Един от най-големите недостатъци беше, че нашите предварително определени отговорности и очаквания ни вкараха в стереотипи.

На срещите хората от по-високо ниво неизбежно придаваха по-голяма тежест на своите идеи и мнения. В същото време тези с по-ниски нива понякога бяха игнорирани. До известна степен това навреди и на креативността, тъй като вече беше необходима повече смелост, за да се изразят и да се противопоставят на идеите на висшестоящите.

Инженерните титли подхранваха инженерна култура отгоре надолу. Старшите инженери се фокусираха повече върху определянето на обхвата и посоката на проекта и понякога диктуваха изпълнението. От друга страна, младшите инженери се фокусираха повече върху изпълнението на предварително зададени задачи.

Набирането на персонал също стана по-сложно. Преди това въпросите, които трябваше да зададем, бяха: 1) умен ли е този човек? 2) мога ли да работя с този човек? Някои въпроси, които често ни задаваха по време на разбора на интервюто, бяха: 1) ако този кандидат не отговаря на изискванията за старши софтуерен инженер, можем ли да го привлечем като младши? 2) в кой екип трябва да бъде включен този инженер? 3) имаме ли инженер в този екип с по-старша титла, който може да включи този кандидат?

Преди инженерните заглавия се фокусирахме повече върху цялостната визия на компанията. Имаше силно чувство за собственост и споделена цел. С наличието на инженерни нива хората все още бяха мотивирани, но по друга причина. Всеки работи усилено, за да стигне до следващото ниво, което предполага повече пари, признание и власт. Тази промяна в мисленето не се случи за една нощ, но беше неизбежна.

Понякога създаваше ненужно напрежение и конкуренция между колегите. Ако множество инженери от едно и също ниво са свършили еднакво добра работа, не могат всички те да бъдат повишени едновременно, нали? Все още искахме да поддържаме смислено разпределение на инженерите на различни нива, за да може екипът да работи гладко.

Преди това единствената цел на работата беше предоставянето на страхотен проект. Сега беше по-важно да сте сигурни, че другите знаят, че сте изпълнили проекта успешно. Ето как и когато политиката се промъкна. Тези, които знаеха как да показват работата си, бяха повишени по-бързо.

Какво ще кажете за инженерните титли въз основа на функционалността на работата

Веднъж ме наеха като пълен инженер. Хареса ми, че мога да танцувам между предния и задния край. Винаги имаше много за учене и винаги имаше нови предизвикателства ден след ден. С реорганизацията трябваше да изберем технологичен стек, върху който да се съсредоточим.

Ползите бяха ясни. Тъй като всеки индивид се фокусира върху по-малък стек от технологии, бихме могли да придобием повече опит в определени области. Frontend инженерите ще трябва да се справят само с потребителски интерфейси; бекенд инженерите трябваше да работят само върху разпределени системи, а инженерите на данни трябваше да мислят само за тръбопровода за данни.

Но недостатъкът беше, че бяхме създали изкуствени граници.

Това създаде повече зависимости, които изискваха повече координация и комуникация. Това сложно планиране на проекта. Ако един от двамата бекенд инженери беше на почивка, това може сериозно да повлияе на напредъка на проекта.

Освен това за инженерите беше по-трудно да изследват други домейни. На инженер не беше позволено да прекарва време в отстраняване на проблем, който идентифицира; вместо това те създадоха задачи за други инженери, които притежаваха този домейн. Той също така обезсърчи хоризонталното учене и растеж, което е добре за тези, които искаха да станат експерти в една област, но за тези, които искаха да станат системен генералист или пълен инженер, вратата беше затворена.

Работно място, където инженерните титли са скрити

През последната година се присъединих към друга компания, където инженерните титли бяха скрити. Титлата се смяташе за частна, както и компенсацията. Правилото беше, че ако човек желае да сподели своето ниво, това е добре; но ако не, не трябваше да питаме.

В среда като тази беше интересно да се работи. Всеки инженер беше овластен. Културата беше по-скоро отдолу нагоре. Вие, като инженер, трябваше да измислите свои собствени идеи за проекти, да идентифицирате партньори, с които да си сътрудничите, и да ги придвижите напред.

Разбира се, всяка монета има две страни.

За нов член, който се присъедини към екип, това може да бъде много объркващо. Без да питате, не знаете кой е ръководителят на екипа. По същия начин, ако имате нужда от помощ от друг екип, също беше трудно да разберете кой има най-голям контекст.

Тъй като идеите за проекти бяха движени отдолу нагоре, понякога имаше дублирани инициативи. Представете си два екипа, работещи по два подобни проекта. Ако нямат припокривания, тези два проекта могат да продължат известно време, преди да забележат.

Някои интегрални схеми на високо ниво нямаха признанието, което искаха, така че може да променят заглавието си на нещо по-елегантно, вътрешно или външно. В края на краищата да имате титла старши софтуерен инженер, персонален софтуерен инженер или главен софтуерен инженер в автобиографията си изглежда много по-добре от обикновен софтуерен инженер.

Заключение

По-голямата част от компаниите на планетата имат дървовидна организационна схема или някакъв вариант. Чувствах се късметлия, че имах възможността да работя в малък екип, където титлите не бяха толкова важни, и в по-голяма компания, която се опитваше да популяризира индивидуалната креативност, като нарочно криеше инженерни титли.

Вие сте на кръстовището, където се опитвате да решите дали трябва да въведете титли сред инженерите? Има много плюсове и минуси, които трябва да се вземат предвид. Надяваме се, че горното може да послужи като храна за размисъл.

Какво мислите за инженерните нива и титли? Както винаги, ще се радвам да чуя и вас.

Want to Connect?
Follow me on Twitter.