Як найкраще тримати метушливих, нетехнічних менеджерів у страху і все-таки приносити добру роботу? [зачинено]

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

Я читав наступне на сторінці "Про" компанії Fog Creek Software , компанії, яку заснував Джоел Спольський та є генеральним директором:

Ще в 2000 році у засновників Fog Creek, Джоела Спольського та Майкла Прайра, виникли проблеми з пошуком місця для роботи, де програмісти мали гідні умови праці та отримали можливість робити чудову роботу, не набридаючи, не технічні менеджери не вступають шлях. Кожна компанія з високих технологій стверджувала, що хотіла чудових програмістів, але вони не поклали б свої гроші туди, де були рот.

Почалося це з фізичного середовища (десятки кабін застрягли в галасливій, темній кімнаті, де продавці, що кричать по телефону, унеможливлюють концентрацію розробників). Але це пішло набагато глибше. Менеджери, жахнувшись змін, ставились до будь-якої нової ідеї як до химерного вірусу, який повинен бути підданий карантину. Молодші менеджери Наполеона наполягали на тому, щоб все було зроблено точно так, як вас звільнять. Поліція корпоративних меблів зажурилася в агонії, коли хтось приклеював плакат на фільм у своїй кабінці. Дезорганізація була настільки розлюченою, що навіть якби ідеї були гарними, неможливо було б зробити продукт із них. Недосвідчені менеджери практикували оперативне управління, видаючи суворі накази про те, як саме робити справи, не тримаючись, щоб побачити далекоглядні результати своїх фіат.

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

Тупі правда про більшість сучасних великих софтверних компаній! На жаль, не кожен розробник настільки ж gutsy(або lucky, можна сказати?) Як Джоел Спольський! Отже, моє питання:

Як найкраще працювати з такими менеджерами, тримати їх у страху та все-таки доставляти велику роботу?

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

Це стільки ж про зміну ставлення. Так, завжди буде гм вперті люди в управлінні. Однак створення відношення "ми з ними" підкріплює це з обох сторін.

Варіант 1: Станьте менеджером самостійно і покажіть всім, як робити все правильно. Ви, мабуть, дізнаєтесь, що це не так просто, як думають багато програмістів.

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

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

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

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

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

тримати їх у страху і все ще доставляти велику роботу

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

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

Але це не завжди працює таким чином. Колись я працював у величезній технічній компанії, де менеджер БУДЬ технічний, і коли розробники скаржилися на безперервні зустрічі з чотирма різними менеджерами проектів день у день, його відповідь була - Добре, так що ви хочете БІЛЬШЕ зустрічей з керівниками проектів.

Я відчуваю, що за останні 10 років технічний "талант", як і фактичний талант, був неймовірно маргіналізований з боку бізнесу програмних організацій, і це проблема для нас у кар'єрному напрямку.

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

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