Случайно наткнулся на видео, в котором Александр Покрышкин рассуждает о лидерстве, об инструкциях и менеджменте, о роли теории, об искусстве побеждать. О том, как побеждать в условиях, когда инструкции и менеджмент препятствуют победе.

Когда-то я услышал фразу, что заяц не может научить охотиться. Сегодняшний рынок знаний переполнен всяким хламом о лидерстве от зайцев. Поэтому, я всегда читал в первоисточнике тех людей, лидерские способности которых не вызывают сомнений. Особый интерес вызывает путь тех людей, которые выбились в лидеры не благодаря природным способностям, а вопреки им. Взять, например, Ивана Кожедуба:

"В начале военной карьеры Ивана Никитовича преследовали неудачи, его даже чуть было не перевели на пост оповещения. Только заступничество командира полка майора И. Солдатенко помогло ему остаться в полку. Свою первую победу летчик одержал в ходе 40-го боевого вылета, сбив немецкий пикировщик."
—"Кожедуб Иван Никитович" / Киселев О. Н.

Раз уж затронул тему лидерства, то нелишне было бы в очередной раз упомянуть книгу "Becoming a Technical Leader" by Gerald M. Weinberg.

Кстати, глава о лидерстве в этой книге начинается со слов Лао Цзы:

If you are a good leader,
Who talks little,
They will say,
When your work is done,
And your aim fulfilled,
"We did it ourselves."
- Lao Tse

А так же книгу "Дао Лидера" Джона Хейдера, которая является современной интерпретацией "Дао Де Цзин" Лао Цзы и учит лидерству на основе диалектической философии. Ну и подборку по лидерству от "Harvard Business Review".

В этот день 6 марта 1913г родился советский легендарный лётчик-ас, Александр Покрышкин 🫡

Фильм "Хозяин неба" (1985г)

💬 The more I struggled against becoming a leader, the more I was setting my own direction—and the more I was becoming a leader.

💬 Whenever I want to learn about something, I arrange to teach a course on the subject. After I've taught the course enough to learn something, I write a book.

💬 Leaders are leaders of change – change in other people, change in working groups, and change in organizations. Above all, leaders are leaders of change in themselves. To become a leader, you have to understand how change happens; yet it's difficult to see change in yourself.

-- "Becoming a Technical Leader" by Gerald M. Weinberg.

Z-lib позволяет создавать персонализированный бот.

💬 Bot is a fast and convenient way to download books. And now our users can get and configure their own personal bot. To do this visit our library website > Edit Profile or click on the bot icon at the bottom of the website page.
https://news.1rj.ru/str/zlibrary_official/6

За что отвечает архитектура?

1. За выявление наиболее существенных требований и за разрешение противоречивых (конфликтующих или обратно-коррелирующих требований).

2. За устранение напряжения между требованиями и конструкцией (это когда то, что хотим, - не можем, а то, что можем, - не хотим).

3. За выбор способа разрешения неопределенности требований путем выбора соответствующей SDLC-модели разработки. Т.е. за выбор соотношения предиктивного и адаптивного способов разрешения неопределенности.

4. В случае выбора адаптивного способа обработки неопределенности (итеративная SDLC-модель разработки и её производные) - за достижение Quality Attribute Modifiability. Т.е. за максимизацию количества открытых решений, где открытость определяется стоимостью изменения решения. Т.е. за опеспечение постоянства скорости (стоимости) разработки по мере роста размера системы. На практике график роста стоимости разработки обычно обретает характер роста близкий к логарифмическому, и задача архитектуры - предотвратить экспоненциальный рост. Достигается это путем минимизации когнитивной нагрузки, т.е. путем управления сложностью, и локализацией изменений. Если этого не сделать, то адаптивный способ разрешения неопределенности утратит экономическую целесообразность, поскольку стоимость реализации решения будет существенно зависеть от момента принятия решения.

5. В случае выбора многокомандной инкрементальной SDLC-модели разработки и её производных (Scaled Agile) - за обеспечение постоянства скорости разработки по мере увеличения количества команд разработки, т.е. за решение Проблемы Брукса. Достигается это путем минимизации коммуникативной нагрузки на команды разработки за счет выявления правильных границ Bounded Contexts.

Это те функции, для осуществления которых нанимается архитектор.

Теперь подойдем к часто обсуждаемому в профессиональных сообществах вопросу.

Давайте представим пациента, госпитализированного с острым воспалительным процессом, которому доктор назначил лечение в виде курса антибиотиков. Пока еще можно обойтись консервативным лечением, но если его не осуществить вовремя, то потребуется уже хирургическое вмешательство. А если и его не осуществить, то возможен летальный исход. И тут пациент говорит, что у него сегодня важная бизнес-встреча, и нужно бухнуть вискаря, тем самым нейтрализовав антибиотики. Что делает в таком случае доктор? Он выписывает пациента из стационара за нарушение предписанного режима, и тем самым он снимает с себя ответственность за последствия, которые от него не зависят. Потому что иначе это будет называться преступная халатность. Она не может быть оправдана тем, что доктор получил за халатность деньги (т.е. наличием корыстного умысла). Доктор-убийца никому не нужен. Он получает деньги за исполнение возложенных на него функций.

Размытость в понимании своих функций иногда на практике приводит к тому, что архитектор начинает противодействовать им, оправдываясь тем, что "кто платит, тот и танцует..." Такое, конечно, тоже может быть, только это уже не функции архитектуры. И если человек не осуществляет функций архитектуры, то называть его архитектором уже ошибочно.

Еще одна книга от PostgresPro:

Путеводитель по базам данных. Комаров В. И. — М.: ДМК Пресс, 2024. — 520 с.

ISBN 978-5-93700-287-7

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

Эту книгу следует прочесть всем, кого не устраивает уровень подготовки на трехмесячных курсах типа «войти в айти». Практическим знаниям она даст прочный фундамент в виде понимания общих закономерностей. Книга написана для архитекторов информационных систем и ведущих разработчиков. Иными словами, для элиты и для тех, кто хочет ей стать.

https://postgrespro.ru/education/books/dbguide

Наглядно о том, чем руководство (формальное) отличается от лидерства (неформального):
https://habr.com/ru/articles/536292/

В Nokia разработали собственную мобильную операционную систему MeeGo. Но формальные руководители решили, что будут использовать Windows Phone для смартфонов Nokia.

Далее цитатами:

💬 ситуация в Nokia и в разработке MeeGo была настолько дезорганизована за последние пару лет

💬 Команда MeeGo и другие сотрудники Nokia были задеты за живое, и у них была только одна цель — закончить продукт на основе MeeGo и отправить его на полки магазинов в течение 2011 года.

💬 команда MeeGo была распущена после выпуска N9 и нескольких обновлений прошивки

💬 С 2005 года очень небольшая группа людей с ограниченными ресурсами в Nokia разрабатывала операционную систему Maemo на базе Linux и устройства на ее основе. Команда была известна как OSSO (Open Source Software Operations), и, по словам одного из членов команды, который работал там с самого начала, целью было создание продукта, который изменит мир. Команда OSSO была переименована в команду Maemo в 2007 году. А в результате партнерства Nokia и Intel в 2010 году она была переименована в команду MeeGo. С самого начала группу возглавлял Ари Якси, который ушел из Nokia в октябре 2010 года и перешел в HP для разработки операционной системы WebOS.

Здесь мы видим человека с лидерскими качествами, который силами небольшой группы собрался изменить мир. Но столкнулся с проблемами:

💬 Конечный продукт в основном производился через аутсорсинг без большой помпы и поддержки со стороны топ-менеджмента. Никто не вмешивался в процесс, и это привело к проблемам с качеством готовой продукции. Принимая во внимание небольшие ресурсы и работу с подрядчиками, самая низкая цена всегда была первым приоритетом при выборе компонентов, а остальные требования были на вторых позициях.

Тут отчетливо просматривается недооценка проекта формальным руководством.

💬 Сокращение расходов на разработку программного обеспечения не было особо мотивирующим фактором. Учитывая, что экономия была достигнута за счет менее качественных компонентов...

💬 Трудно было сохранить качество работы субподрядчиков, и контракты не контролировались должным образом. Субподрядчики могли жульничать, заменяя лучших специалистов, которые были в начале, на менее квалифицированных людей потом. Приведенные примеры включали плохой код, написанный в Индии, и проблемы со связью с китайцами и японцами из-за их плохого знания английского языка.

На эту тему была серия постов: https://news.1rj.ru/str/emacsway_log/1096

Которая вылилась в черновик доклада: http://kr.msk.ru/

Далее началась "Проблема Брукса", и очевидно, что формальное руководство с ним не справилось:

💬 В то же время размер команды вырос, а вместе с ней и бюрократия. Это привело к снижению гибкости и к замедлению в разработке программного обеспечения.

Далее мы видим, что разработчики осознавали ответственность за судьбу проекта больше, чем руководство. И начали защищать проект от руководства:

💬 Предложение было сразу же отвергнуто, но разработчик не сдался, поделившись примером функциональности для тестирования другими. В результате во внутренней системе Bugzilla, используемой сотрудниками Nokia для обработки ошибок, появилась цепочка длиной в несколько сотен сообщений, где руководство и разработчики спорили друг с другом по поводу этой функции. Наконец, эта функция была сделана, и в обновлении PR 1.1 она использовалась по умолчанию.

Тут просматриваются проблемы с организацией SDLC в контексте разрешения неопределенности требований:
💬 Постоянно меняющиеся требования к разработке пользовательского интерфейса вызывали внутренние проблемы в команде разработчиков

Дальнейшее развитие ситуации сравнили с историей:
💬 о человеке, работающем на нефтяной вышке, который просыпается ночью от взрыва и понимает, что вся платформа объята пламенем. Человеку удается добраться до края платформы, и ему необходимо принять решение: остаться и умереть или прыгнуть на 30 метров в темные и холодные воды. Это решение надо принять срочно.

Продолжение...

Наглядно о том, чем руководство (формальное) отличается от лидерства (неформального). Продолжение.

Была принята новая стратегия:

💬 ОС Windows Phone 7 от Microsoft, выпущенная осенью 2010 года, и ее последующие версии станут новой основной платформой для смартфонов Nokia.

Но лидеров больше интересовали интересы дела, нежели угодничество руководству - они принимают решение продолжать без руководства, которое в фигуральном смысле превратило компанию в горящую нефтяную вышку. Поэтому:

💬 Финская компания Jolla Ltd. (от фин. jolla — шлюпка), основанная бывшими разработчиками MeeGo из Nokia, вышла в свет через Twitter в июле 2012 года. Компания, в которой на данный момент [на момент публикации] работает около 60 человек, продолжает разработку операционной системы и смартфонов MeeGo, где ранее остановилась Nokia.

Вывод:

💬 Организация, однако, стала ахиллесовой пятой проекта. Под конец отдельные разработчики не имели права голоса или, что еще хуже, не знали о решениях и изменениях, которые произошли за их спиной.

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

Вполне ожидаемый результат - истребление слабоприспособленной формы хозяйствования:

💬 Пока Nokia погружалась в пучину разработки Harmattan и MeeGo, ее злейшие конкуренты Apple и Google успешно создали работающие экосистемы вокруг своих операционных систем и захватили рынок Северной Америки.

Причиной поражения в конкурентной борьбе сдала слишком долгая адаптация продукта к скоротечно изменившимся рыночным условиям. Причиной этому стал "плохой код" и Проблема Брукса.

В конечном итоге, Nokia под руководством руководителей прекратила производить смартфоны. А MeeGo, возглавляемый лидерами, продолжил свое развитие без Nokia. На его базе возникла Sailfish OS.

В 2018 году «Ростелеком» приобрел пакет акций Jolla. В 2019 году Sailfish Mobile OS Rus поменяла название на ОС «Аврора».

Поему я вспомнил об этой истории? Из обсуждений в профессиональных пабликах можно сделать вывод, что описанная в Nokia ситуация является не исключительной, а, скорее, типовой для рынка. У многих специалистов не хватает аргументов для того, чтобы предотвратить неизбежные последствия. Эта статья позволяет снабдить их хорошим аргументом - просто задайтесь вопросом: "запас финансовой прочности вашей компании больше, чем у Nokia?"

Сказ о том, как я трубку загубил, и причем здесь ИТ?

Если кто не знал - я курю трубку с 2010 года (и при этом веду спортивный образ жизни с первого класса). Так вот, была у меня трубочка, и на ней немного сошел лак. Это нормальное и естественное явление, но тогда я об этом не знал. Я ничего не понимал ни в лаках, ни в восках. Я просто хотел вернуть ей прежний блеск. Где-то я прочитал, что нужно натереть трубочку карнаубским воском. Вместо того, чтоб купить чистый карнаубский воск в виде хлопьев, я купил его смесь на основе скипидара (растворителя лака). Потому что я хотел как можно скорее получить результат. Я не мог ждать, пока я изучу что делать с твердыми хлопьями твердого карнаубского воска. Промедление было смерти подобно. Мне достаточно было увидеть в составе неизвестной смеси слово "карнаубский воск", и в условиях недостаточной информированности когнитивные искажения сделали свое дело - я был убежден в том, что это то, что мне нужно. И это освободит меня от долгого изучения правильного пути. Дело подогревалось моей хронической перегруженностью. Удивительно, но чем больше я хотел как можно скорее вернуть ей блеск, тем больше я его уничтожал.

В погоне за функцией (блеск) я пренебрёг конструкцией (которая этот блеск поддерживает). Натерев пару раз восковой смесью на основе скипидара, я обнаружил, что блеска осталось еще меньше. Но я отказывался в это верить, пока, наконец, половина трубки не осталась без лака. Ничего страшного в этом нет, и лак можно было заместить воском (некоторые даже делают так преднамеренно), но я в тот момент думал, что все испортил, и пошел на отчаянный шаг - попытался шлифануть на диске, пока не испортил покрытие окончательно. Удивительно то, что шеллачный лак у меня на тот момент был в наличии, но я не хотел тратить время на изучение способа его применения. Тогда я снял полностью покрытие наждачкой. И, вместо того, чтобы изучить про морилки и набраться недостающих знаний, я намазал трубку маслом с твердым воском графитового цвета, потому что его можно было купить в соседнем хобби-магазине Леонардо прямо сейчас, а не ждать несколько дней доставку нужной морилки. Поверхность трубки пропиталась маслом, но нужный тон цвета так и не обрела. Она настолько пропиталась маслом, что стала резиновой на ощуп, и насенение новых слоёв уже не влияло на её тон. Тогда я в сердцах её выбросил, потому что не знал о том, что бриаровая пыль используется для мелкого ремонта других трубок. Об этом я узнал потом, когда купил превосходную редкую трубку с незначительной каверной внутри мортиза, которая обычно легко шпаклюется смесью бриаровой пыли и обычного канцелярского силикатного клея (обладающего удивительной термостойкостью).

В общем, будучи ослепленным сиюминутным достижением результата, я, опытный архитектор, совершил все возможные конструктивные ошибки. Я действовал как типичный Product Owner, под воздействием системных и хорошо изученных причин. Я пренебрег долгосрочными техническими интересами в угоду краткосрочных бизнесовых интересов, и собственными руками уничтожил продукт. Я совершил все то, о чем так много говорил и предупреждал, стоило лишь мне ступить на ранее неизвестную мне конструктивную область.

Я попал в условия рядового Product Owner и поступил в точности как рядовой Product Owner. Имея доступ ко всей информации о конструкции, обеспечивающей необходимую мне функцию, я не счел нужным мириться с порогом окупаемости решения. Выбирая между "плохо, но сегодня" или "хорошо, но завтра", я ожидаемо выбрал первое. Так устроен мозг человека.

Согласитесь, что потратить несколько часов на узучение воскования и морения намного проще, чем изучать несколько лет ИТ-архитектуру. Но я, опытный архитектор, все-равно пренебрег даже этой технической малостью. Чего тогда ожидать от рядового Product Owner?

Если вы думаете, что причиной загнивания вашего проекта являются личные морально-деловые качества вашего Product Owner, то вы ошибаетесь. Эти причины системны и устраняются организацией процессов разработки таким образом, чтобы взаимокомпенсировать когнитивные искажения сторон разработки.

В продолжение темы. После института я работал в одной небольшой компании, и по объявлению нашли человека, который продавал необходимое нам б/у оборудование. Я с водителем собрался ехать на переговоры, но директор выдал мне наличную сумму новенькими банкнотами на треть меньше запрошенной, что было существенно ниже рыночной стоимости. Я попытался было возразить, но он ответил "просто достань банкноты и покажи их ему". И это сработало. Это всегда работает. Хотя он мог получить больше, если бы владел эмоциями, чем пользуются профессиональные трейдеры.

💬 It’s not about the personalities of Product versus Engineering. It’s not about short-sighted versus visionary thinking. The struggle is economic—do we make some money now or more money later? The answer is always “both”. We have to make some money now to survive. We want to make more money later. Fear versus greed. No wonder it’s so hard to get time to refactor.
-- "Behavior Change = Revenue Versus Structure Change = Option" by Kent Beck

Наткнулся на любопытную статью про ООП, хочу порекомендовать вам ее в контексте недавних обсуждений: https://blog.sigma-star.io/2024/01/people-dont-understand-oop/ и перевод на хабре.

💬 Пример из жизни. На одном из тренингов на этапе сбора ожиданий мы обычно спрашиваем всех участников, чего они ждут от этих двух дней и какие вопросы хотят разобрать. Доходит очередь до инженера лет тридцати с очень уставшим видом:
– Я хотел бы научиться отказываться от проектов.
– ?.. Расскажите нам больше…
– Понимаете, сейчас я работаю над пятью проектами одновременно. И мне очень тяжело. Я хотел бы, когда принесут шестой проект, так ловко от него отказаться, чтобы не взять его и чтобы руководство не обиделось.
– А что было, когда вам давали пятый проект?
– [после паузы] Я работал над четырьмя… Мне было очень тяжело… Я им говорил, что не потяну… А они сказали, что очень надо…
– Ну и как, вы потянули?
– Потянул…
– Тогда руководство знает, как дать вам и шестой проект…

Довольно часто руководство и заказчики приходят к нам со срочными просьбами о совершении подвига. И на слова «это невозможно» всегда находится аргумент «ребята, очень надо». После чего мы обычно беремся за этот воз, не спим ночами и совершаем небольшое чудо (иногда вместе с командой). Выдыхаем и надеемся спокойно поработать дальше. И это не получается.

Как эта ситуация выглядит с точки зрения руководства /заказчика? Приходишь к ребятам, просишь что-то сделать.
Поначалу они сопротивляются, говорят, что это невозможно, но после аргумента «очень надо» берут и делают, большие молодцы!

Или, наоборот, руководство подозревает, что, когда вы говорите «невозможно», то, мягко говоря, лукавите. Значит, и дальше надо грузить.

Ни один реальный подвиг не должен оставаться «непроданным». Любой подвиг – это повод для обсуждения с заказчиком подвига (после совершения, когда тот находится в приятственном расположении духа, хорошо к вам относится и готов вас слушать): «Как там, все нормально? Так вот, я поэтому и пришел. То, что произошло, – это чудо, потому что… Как бы нам сделать так, чтобы это все предусмотреть и в следующий раз вас не подвести?»

Зачастую решение одной проблемы создает следующую, которую мы упускаем из виду. И это тоже распространенноенарушение принципа своевременности.

-- "Джедайские техники конструктивного общения" Александра Орлова

В этой же книге:

💬 Когда два сотрудника друг другу в курилке жалуются на начальство: «Блин, опять переезд в новый офис. Сколько можно? Третий раз за год! Заколебали уже…» – это не вполне конструктивно. Потому что, если есть проблема с переездами, они вряд ли решат ее между собой в курилке.
Вот если кто-то после этого разговора пойдет к начальствувыяснять, что и как с переездами, то произойдет переключение в конструктив.

Тут я с автором второй раз не соглашусь, что, правда, не уменьшает ценность книги. Те, кто знаком с теорией управления изменениями, знают, что иногда бо‌льшего совокупного эффекта можно достигнуть, если позволить кризису назреть, нежели пытаться его компенсировать. Сейчас уже не вспомню, кто автор этого подхода, кажется John P. Kotter (поправьте, пожалуйста, если я ошибаюсь).

С одной стороны, в условиях кризиса меньше сопротивление изменениям, т.к. необходимость изменений становится очевидной для всех.

С другой стороны, кризис может привести к самосвержению руководства, уровень компетентности которого является причиной кризиса. В моей практике такой случай был. И чем скорее кризис назрел, тем быстрее проект освободился от причины кризиса и начал оздоравливаться.

Существуют еще причины в виде политических дивидендов, о которых упоминал Егор Толстой здесь. Я тоже не считаю такие причины допустимыми для профессионала.

Но хочу упомянуть об одном интересном случае, который я наблюдал на практике. Product Owner пытался убедить руководство в проведении дорогостоящего рефакторинга, но эти попытки оказались безуспешны, и они лишь пошатнули его авторитет в глазах команды слабостью своего влияния. Тогда он переключился на формирование общественного мнения команды, т.е. выступил в роли лидера общественного мнения, и вскоре ему удалось осуществить задуманное. Т.е. он сделал в точности наоборот утверждению автора, и это оказалось конструктивно. Если руководство небезнадежное, то оно мониторит общественное мнение. Правда, Product Owner не ныл деструктивно, как в обсуждаемом фрагменте книги, а конструктивно, как подобает настоящему лидеру, излагал каким именно образом можно облегчить деятельность команды.

В общем, не существует абсолютно правильных решений - многое определяется контекстом.

Можно ли назвать деструктивным самоустранение Ивана Грозного от власти и бегство из Москвы? А заявление Сталина с просьбой освободить его от занимаемой должности? В обоих случаях их влияние только увеличилось, хотя, казалось бы, такое поведение эмоционально и деструктивно.

💬 Проблема заключается в том, что советы, если они вообще берутся на вооружение, тотчас же становятся механическими инструментами. Это значит, что необходимо вводить интервалы между похвалами. Открываются «текущие счета похвал». Когда-то сердитые менеджеры превращаются в машины для метания похвал, а сотрудники только покачивают головами, замечая: «Он опять был на семинаре». Новая причуда техники управления уходит в пустоту.

Следует признать: многие люди на рабочем месте болезненно переживают дефицит признания. Но чувствуют ли они дефицит похвалы? Здесь уместен скепсис. Потому что похвала при более точном ее рассмотрении представляет собой весьма противоречивый и коварный стиль поведения, роковое действие которого проявляется не сразу. В известных обстоятельствах она, однако, скорее вредит отношениям между начальником и подчиненными, чем идет им на пользу. И это следует пояснить.

...

Тот, кто пользуется похвалой как мотивом, наказывается рапортами об успехах. - Это было бы приемлемо в том случае, если бы удовлетворялась только индивидуальная страсть к похвале, а в остальном работники побуждались бы к быстрому и эффективному достижению целей. Но велика опасность получения сообщений о мнимых успехах.
Подразумевается разного рода обман на этикетках, в статистике, в сообщениях о том, что работа идет полным ходом, в нецеленаправленной активности, результаты которой невозможно проверить. Если дарящий похвалу шеф докапывается до истины, то он, глубоко оскорбленный, жалуется на эгоизм и увертливость своих работников, т. е. на те черты характера, которыми он хотел сам воспользоваться в качестве рычага для получения своей выгоды. И потерпел неудачу в соревновании хитрецов!

..

Наоборот: похвала умаляет достоинство! Тот, кто зависит от похвалы, старается до тех пор, пока не получит, что хочет. Он прилагает усилия до «барьера похвалы». Тем самым он делает похвалу шефа и, следовательно, его критерии оценки масштабом своего величия.

Подсмотрено здесь:
https://news.1rj.ru/str/ru_arc_chat/23615

P.S.: Что думаете по этому поводу?

Статья о том, почему софтверные компании умирают, когда власть захватывают менеджеры вместо технических профессионалов.

Обращает на себя внимание фраза, которая развивает тему предыдущего поста:

💬  The only person whose praise matters is another programmer.

Именно в этом заключается, как мне кажется, истинный путь к лидерству. Ведь слово "ведущий" (т.е. лидер) имеет смысл только в контексте "ведущий кого"?

Когда специалист действует ради сиюминутной похвалы от руководства, то он тем самым блокирует собственное развитие до топового уровня (или до основания собственной компании) по одной простой причине - у него сформирована потребность в том, чтоб его постоянно "кто-то хвалил сверху". Т.е. он добровольно ограничивает себя ролью второй скрипки.

На практике иногда приходилось наблюдать как специалист уступал профессиональностью своего решения в обмен на благорасположение бизнес-менеджмента, что приводило к утрате авторитета среди коллег, к загниванию системы, и, в конечном итоге, как это ни парадоксально звучит, к утрате того самого доверия менеджмента, ради которого он так действовал, а иногда даже к увольнению под благовидным предлогом, чтоб не задеть ущемленное самолюбие и не спровоцировать негативные отзывы о компании. Специалист думал, что занимая "удобную" для менеджмента позицию он тем самым перекладывает на него всю полноту ответственности за последствия такого решения. Но менеджмент видел это так, что если специалист согласился, то он осознаёт все последствия и считает возможным реализовать "хотелку" без ущерба для системы. Истина в том, что ответственность не перекладывается вместе с полномочиями, но это становится очевидным слишком поздно.

Истинный авторитет обнажается только тогда, когда время отобьет весь шлак дешевого авторитета. На это требуется время и не у всех хватает смелости вытерпеть.

Мудрый специалист мыслит дальше, чем сиюминутная похвала менеджмента, и оценивает свои решения объективными последствиями, от которых зависит то, продолжит ли завтра этот менеджер хвалить его, сохранив свой пост в компании, выстоявшей в конкурентной борьбе.

💬 All successful software companies had, as their dominant personality, a leader who nurtured programmers.

P.S.: Большинство моих бывших коллег-программистов сегодня занимают ответственные руководящие или архитектурные должности в крупных высокотехнологичных компаниях. Я никогда не получил бы поддержку такого количество руководителей ИТ-рынка, если бы пренебрег автортетом перед ними.

А лучшее признание - это признание от своих бывших коллег, с которыми ты уже не работаешь вместе, потому что его бескорыстность не вызывает сомнений.