Які риси мають найкращі менеджери, з якими ви працювали? [зачинено]

Я слухав подкаста Скотта Хензельмана та Роб Конери, життя цього розробника .

В останньому епізоді вони обговорюють риси особистості:

1.0.4 - Будучи середнім.

Що означає людей у ​​нашій галузі? А що з агресивними? Впевнено? Яка різниця? Ви б хотіли мати старшого сержанта для начальника чи зенського майстра? Ми спілкуємось із Сірою Річардсон та Джайлсом Бокеттом.

Мене змусило задуматися, які риси мають у вас найкращі менеджери , з якими працювали?

EDIT: Просто для уточнення, оскільки було кілька близьких голосів, мене цікавить, чи є риси, загальні для менеджерів розробників, які не обов'язково є тими рисами, яких вимагає менеджер якоїсь іншої професії.

Що стосується програмного забезпечення чи ні, я не хочу ставити це питання на сайті, яке не стосується програмування, бо, чесно кажучи, я не так зацікавлений у тому, що люди роблять консервні супи на життя хочу від своїх менеджерів, як мені цікаво, чого розробники хочуть від своїх менеджерів.

На мій досвід, це поєднання наступного:

1. Заходи за результатами / результатами, а не за результатами.
2. Мотиваційний, натхненний лідер, якого ви можете поважати і дотримуватися.
3. Чутлива до потреб членів команди - підтримка / навчання / кар’єра тощо.
4. Швидко вирішує конфлікт, розсіює складні ситуації.
5. Розуміє свою роботу - вони можуть насправді виконати вашу роботу, але найняли вас це зробити.
6. Обробляє / фільтрує речі, які не є важливими або погіршують продуктивність команд.

Джоел Спольський називає це " шаром абстракції ". Зробіть все, що потрібно, щоб я програмував. Дайте мені знати, що відбувається в компанії, але не відволікайте мене від політики. Попри те, що я все ще маю це зробити, принаймні визнаю, що запит є великим!

Хтось, хто буде боротися за політичні битви за мене та усунути перешкоди, які заважають мені робити справи.

Період.

Бути готовим слухати людей, які працюють на них.

У мене були дуже технічно схильні менеджери, і у мене були такі, хто навіть не знав про багатозадачність ("о, ух! Де ви дізналися про цей трюк Alt-Tab?"), Але річ, що всі Насправді мені сподобалося, що спільно працювали в тому, що вони знали, що вони не знають усе, і готові були слухати, коли ті з нас насправді виконують роботу, якою вони мали керувати представленими ідеями, проблемами чи пропозиціями щодо цієї роботи.

Вона / він захищає свою команду та бере на себе відповідальність

Один у вашій команді вибиває сервер із виробничими даними. Ваш менеджер візьме на себе повну відповідальність. Врешті-решт він відмовиться сказати своєму керівнику, хто допустив помилку, і постане перед своїми людьми.

Вони керуються на основі цілей, а не часу, і в першу чергу стосуються мене досягнення цих цілей

Замість того, щоб перейматися тим, як довго я сиджу за своїм столом, вони переймаються тим, що мені потрібно для виконання певного завдання. Якщо це означає усунення перешкод чи перешкод, або дозволити мені працювати довгі години / вихідні, вони готові відключити час. Якщо я закінчую роботу достроково і мені потрібен певний час для призначення лікарів або сімейних заходів, вони гнучкі та зрозумілі.

Я, безумовно, хочу нести відповідальність на роботі, але це має бути за те, що я досягаю, а не скільки часу я провожу за своїм столом.

Утримуйте мене від зустрічей, на яких мені не потрібно відвідувати. Якби менеджери могли просто зробити це, вони були б нескінченно ціннішими.

Визнання, що мене наймають і платять для прийняття рішень.

Вони підтримують вас, коли ви говорите "НІ"

Однією з найбільш демотивуючих рис у менеджера є відсутність сміливості стояти перед своїми людьми та завжди схилятися перед власним начальником, навіть якщо це означає вплинути на товар чи команду.

не кричати, будь ласка ... просто не треба. (як би ви не підкреслювали великі терміни, дурні тестери тощо)

Хтось, хто просто дозволяє мені робити свою роботу.

Розуміння того, з чого складається програмування. Ви були б здивовані тим, скільки керівників нічого не знають про це.

Визнання, що мене наймають і платять для прийняття рішень.

Я не є працівником служби харчування 7 доларів на годину. Я тут, щоб приймати рішення. Якщо мені будуть розказувати кожну деталь, що робити, я також міг бути друкаркою.

(Глибока) Навичка емпатії

Я маю йти на це з точки зору найгірших начальників, над якими я працював - хороший НЕ матиме таких якостей:

Нездатність прийняти рішення - найгірше, з чим я колись мав справу, - це бос, який міняв свою думку щоразу, коли хтось із ним розмовляв. Ми міняли напрямок 4-5 разів на день на трирічному проекті.

Викрадає кредит на те, що роблять члени команди. Одного разу мій бос отримав величезну нагороду, яку вони видавали публічно. Все, що вони згадували, що він робив, я насправді робив. Зайве говорити, що це вкрай демотивує.

Паніка, коли справи йдуть не так добре. Ще гірше, коли панікування змушує його або її стати неприємним. Це насправді не допомагає зробити це.

Назад влаштовує своїх людей. Він отримує кредит, ми отримуємо провину. ANd не підтримує нас в ланцюзі команд, коли він повинен.

Не має розуміння процесу розробки програмного забезпечення і навіть не піклується вивчити достатньо, щоб знати, що ми використовуємо C # (або іншу мову на ваш вибір). Думає, що все можна зробити за короткий проміжок часу і що проста зміна на зовнішній стороні сторінки User_interface означає, що її впровадження не займе багато часу. Людина, яка сидить на зміні до дня до граничного терміну, а потім каже: "О, так, як нам потрібно зробити ...", і що-небудь він запитує - це те, що змінює фундаментальну архітектуру.

Мікроманажі або взагалі не вдається. Обидва однаково погані. У мене було занадто багато начальників, які не знали, що проблема з одним працівником до занадто пізнього часу, і всі інші повинні були заплатити ціну, щоб виправити безлад. У мене також були боси, що мені довелося сказати їм, щоб вони перестали турбувати мене кожні п’ять хвилин, інакше це ніколи не закінчиться.

Політично наївний. Якщо ваш начальник політично не справляється з людьми над ним, у вас виникнуть проблеми з тим, як вам потрібні люди, у вас будуть найгірші місця і ви в групі, швидше за все, втратите роботу в звільненні або тому, що це простий спосіб позбутися від нього. Боси повинні бути хорошими в офісній політиці.

Той, хто думає, що зможе скоротити години на проект наполовину (тому що клієнту це число не сподобається), і ми зможемо виконати це за той час, без відповідної зміни вимог.

Кредит, де належні кредити та достатньо знань, щоб можна було це призначити

Я б додав, що слухає добре, але замість цього наголосив.

1. Якщо є хтось, хто постійно бере на себе кредити за функції, знайдені в бібліотеках, або розроблені власні, з відкритим кодом або сторонніми сторонами, то це повинно бути збитим, а не винагородженим.
2. Якщо на когось покладені всі обов'язки з помилок, оскільки він насправді пише тести на підрозділи та знаходить їх, то він повинен бути винагороджений, а не покараний. Пошук помилок - це не те саме, що писати їх в першу чергу.
3. Якщо розробник або група розробників кидає дупу, щоб скласти терміни, вони повинні бути похвальними, а не менеджерами за те, що вони придумують терміни в першу чергу.

Вони довіряють своїм людям, щоб виконати роботу і не намагаються "стадо котів".

Дайте людям можливість робити помилки (очевидно, не величезні) та вчитися на них.

Хтось, хто добре слухає

і

Хтось, хто має сенс насправді розмовляти зі мною хоча б щотижня

У мене були хороші менеджери та погані. Ось деякі риси, які я помітив у поганих менеджерів:

Виходьте з дороги, щоб ви могли робити свою роботу

Хороший менеджер переконається, що у вас є потрібне обладнання для написання коду.

Мікро-керує неправильними деталями

Цей менеджер буде жувати вас через те, що вам не вдасться прикріпити підпис до своєї електронної пошти, ігноруючи додаткову роботу, яку ви зробили до цього електронного листа.

Не має інтересу до процесу розробки

Це дійсно поганий знак для менеджера, відповідального за розробників програмного забезпечення. Йому не байдуже досліджувати інші підходи до розробки, не буде знати, яким номером версії повинен бути наступний випуск програмного забезпечення, не буде читати блоги на зразок Joel on Software або що-небудь, що стосується управління розробниками, як Peopleware.

Думає, що він там для мене, щоб повідомити

Такого роду менеджер знімає, коли люди повідомляють йому про все.

Помилковий час

З огляду на місяць для доставки проекту розвитку від початку до завершення, цей менеджер виділить 3/4 місяця команді проектування та вимог для створення 1000 лінійних текстових документів і розраховує, що команда розробників впровадить це все за тиждень. Він також повторюватиме вимоги, поки вони не стануть «ідеальними», додаючи багато деталей, поки документ не стане непридатним. Але згодом у процесі розробки ви знайдете помилки в документації на дизайн та вимоги та зрозумієте, що акцент на спробі написати ідеальний документ був помилкою.

Я думаю, що дві найважливіші характеристики - це базове розуміння принципів управління та бути "одним із нас". На жаль, обидва вони не трапляються занадто часто разом, але коли вони це трапляються, ви знайшли хорошу людину, над якою працюєте.

Де я працюю, наш керівник проекту - колишній розробник. Він добре розставляє пріоритети та керує роботою - те, що менеджер повинен знати, - але він також має досить гарне уявлення про те, що відбувається, коли мені потрібно задати питання про те, як реалізувати щось, що вимагає від нього і бачення на рівні управління. і технічний внесок від мене.

У шефа також є обидва ці набори навичок. Він насправді нинішній розробник, який час від часу працює над кодовою базою даних і робить зобов’язання, коли інші обов'язки не відтягують його від себе. Він переконує, що у нас гарне робоче середовище, тому що він інтуїтивно знає, що таке хороше робоче середовище для нас: це умови, в яких він хотів би працювати!

Бій за мене. Мені не варто було б вступати в нього з ІТ. Дає мені потрібні мені інструменти. Зберігає політику компанії вниз. Приймає рішення, коли їх просять, і залишається поза, коли ні.

Відмова: Я раніше займав управлінські ролі, але зараз ні. З цього можу однозначно сказати, що з іншого боку столу також може бути досить важко.

Хтось, хто зрозумів, що потрібно зробити, дозволяє мені опрацювати технічні деталі, надає контекст, коли це потрібно, і не змінює вимоги, коли я закінчуюсь на півдорозі.

Дві речі:

1) Є (або зовсім недавно був) розробником сам.
2) Керує вгору , а також вниз .

Пункт 1 дасть вам, як розробнику, менеджера, який по-справжньому розуміє, яка ваша робота складається і складається, і розуміє, що вам потрібно (а також не потрібно), щоб виконувати свою роботу якнайкраще. Якщо вони не розробник в даний час (і вони дійсно не повинні бути на самому справі практичний розробник тепер , як вони менеджер - і це повний робочий день сама робота) вони повинні мати попередній досвід розробки, але це повинно бути досить останнім часом (тобто в останні кілька років), щоб вони, принаймні, ознайомилися із сучасними мовами, інструментами, методами та методами розробки.

Пункт 2 надасть вам менеджера, який приймає на себе його обов'язки, захищає свою команду від офісної політики та непотрібних відволікань та бореться за те, щоб його команда забезпечувала необхідними речами (таким чином, дозволяючи Точку 1) та може управляти очікуванням від бізнесу та тих над ним (Це ще важливіше у великій корпорації, де між вами (розробником) та керівниками ділових рішень (вищий менеджмент) існує багато рівнів і рівнів управління).

У двох словах, ознака (1) дає вам менеджера, який розуміє, що вам потрібно, щоб виконати свою роботу, а властивість (2) дає вам менеджера, який забезпечить вам те, що вам потрібно.

Розмова Джоела Спольського на Єлі (та пов’язана зі статтею " Команда і перемагай та стадо кокосів ") дуже швидко містить:

Говорячи про (поганий) менеджмент компанії Juno:

"Існувало припущення, що менеджери існують, щоб сказати людям, що робити".

Говорячи про (в цілому хороше) управління в Microsoft:

"Менеджери існують, щоб вибити меблі з дороги, щоб справжній талант міг зробити блискучу роботу".

Я хочу, щоб хтось, хто здатний (і має мужність) визнати та позбутися від мертвого дерева. Ці люди завдають шкоди продукту і сповільнюють його завершення, відводьте їх від мого шляху! Занадто багато менеджерів або не можуть розпізнати, хто поганий розробник (або вважають, що той, хто з брудним столом, поганий, або хлопець, який, здається, починає багато в космосі, хоча він насправді може бути найрозумнішим або найпродуктивнішим розробником) або не хочуть бути тим, хто скаже комусь, що їх відпускають, і тому нехай мертвий ліс залишається рік за роком, викликаючи шкоду та невдоволення серед компетентних.

Я не хочу, щоб мене бентежив менеджер, який навіть не знає, якими мовами або резервними базами даних чи іншими критичними інструментами ми користуємось. У мене було одне запитання (перед клієнтом), на якій мові ми програмували після участі в проекті протягом 3 років! Я не сподіваюсь, що люди, які тривалий час керували, все ще знають, як усе, але вони повинні принаймні знати, що ми використовуємо. І вони повинні бути досить розумними, щоб не задавати подібні речі перед іншими, якщо вони цього не роблять.

Я хочу менеджера, який має мужність. Не приймайте цей нереальний термін, не відштовхуючись, не дозволяйте людям знущатись над вашими співробітниками і не дозволяйте розробникам розкручуватися шляхом їхнього пустощів, не будучи коротким. Не скажіть, чи я щось роблю не так, бо ви боїтесь, що я можу засмутитися. Менеджери існують частково, щоб впоратися з поганими новинами, я хочу того, хто зможе.

Я хочу, щоб менеджер, який розуміє, що я маю домашнє життя, який розуміє, що виснажені дияволи роблять помилки, і займатися проектом потрібно 60 годин на тиждень, ніж 40.

Найбільше я хочу, щоб менеджер, який визнає хорошу роботу і вдячний як мені особисто, так і ланцюжком для своїх начальників. Хоча я справді ненавиджу це, коли вони думають, що погана робота - це добра робота і винагороджують невірних людей!

Доброзичливість була б чимось, що я б там поставив. Мені не подобається мати страх, якщо мій начальник щоразу вирішує відвідувати мою кабінку . Моя робота може бути трохи кращою, якщо мені здається, що я допомагаю товаришеві, який просить про послугу тут і там часом, наприклад, щоб отримати проект достроково, можливо, мені доведеться залишитися в офісі на деяку кількість годин, які я, можливо, інакше не хочу робити.

Компетентність у керуванні кількома речами була б ще одним аспектом, на який я б хотів звернути увагу, хоча це може бути сприйнято як очевидну ознаку певною мірою. Навички вирішення конфліктів та примирення також будуть чимось, що я хочу знати, що мій менеджер може впоратися, оскільки може бути час, коли це або розробник проти розробника, або розробник проти аналітика з точки зору питань, які вимагають від когось права, який може бути ні в деяких випадках, оскільки деякі аспекти твору можуть мати багато інтерпретацій.

Хтось розуміє, що розвиток - це не фабрична робота. Вклавши більше годин на день, швидше за все, не отримає значно більший урожай. Програмістам потрібно досить часто вибирати ніс із шліфувального каменю і просто не замислюватися над тим, над чим вони працюють, щоб вирішити проблему і домогтися справи.

Хороший менеджер готовий дозволити мені сказати "ні" . Вони усвідомлюють, що розробка програмного забезпечення є злою проблемою . Таким чином, навіть якщо менеджер є більш компетентним, ніж я технічно, вони розуміють, що я можу пізнати проблему краще просто тому, що я той, хто реалізує рішення. У той же час вони дають мені знати, коли мені не вистачає контексту. Багато разів менеджери можуть приймати рішення на основі того, що вони знають, що я цього не роблю. Якщо це так, то вони повинні мені заповнити деталі або принаймні повідомити мені , що вони знають щось, чого я не знаю.

Я працював у кількох місцях, де менеджмент явно не був технічним. Мій нинішній роботодавець має політику, згідно з якою керівник, який приймає технічне рішення, є підставою для усунення. (Це не якась маленька компанія, про яку ви ніколи не чули; приблизно одна третина з вас працює з нашим продуктом). Частково в результаті такої політики, принаймні, на мою думку, керівники тут набагато «сильніші», ніж у інших роботодавців. Оскільки вони не беруть участі у прийнятті технічних рішень, керівництво не має постійних рядів технічних рішень від «трохи до дуже неправильних», і вони приймають лише великі рішення на рівні продуктової лінії.

Кращі менеджери, які у мене були, - це ті, хто «заважає» розробникам. Хороший керівник може сказати різницю між "обов'язковою зустріччю" і обов'язковою зустріччю, і повідомить вам про це.

Основна навичка управління - це змусити розробників відчувати контроль над своїм оточенням, це може бути або нагадуванням, або ілюзією, залежно від компанії, але це життєво важливий навик.