Проработав пять лет в различных командах в Майкрософт я вынес несколько вещей, о которых я даже не подозревал, когда оканчивал колледж. Основные ценности, чему я научился, вынесенные уроки, причина моего крика на друзей, как ни называй, они сослужили мне хорошую службу.
Некоторые из этих вещей специфичны для Майкрософт, но большая часть найдет применение в любой командной/корпоративной среде. Некоторые из них сложны – из-за них тебя могут уволить (а может и хуже), если ты не знаешь, что делаешь.
Любому достаточно большому учреждению есть чего терять. Кредитоспособность, деньги, власть, что угодно. Поэтому любой запрос на что-либо новое и рисковое встречается с осторожностью. Будь то новое предложение или проект, безопасней сказать «Нет». Корпорации оптимизированы говорить «Нет». Поддерживая статус-кво. Нет риска провала и эффектного крушения.
По этой самой причине лучше идти и делать что-то не спрашивая разрешения. Ведь если не спрашивать, никто не запретит. Появилась интересная идея для побочного проекта? Иди, закодируй её. Если ты спросишь кого-то сначала, возможно тебе скажут «Проконсультируйся с командой X, Y и вице-президентом Z», и тогда ты наткнешься на нескончаемую спираль. Хочешь написать в блоге о том, что тебя беспокоит? Иди, пиши.
Однако ты должен понимать, чего делаешь. Не делай чего-то явно глупого. Хочешь написать о неанонсированной фиче X? Плохая идея. Коммитишь код никого не предупредив? Очень плохая идея. Пишешь гневное письмо не тому вице-президенту? Возможно (но обычно не такая уж плохая идея). Как и с любыми рисками, есть и обратная сторона.
Это не срабатывает постоянно. Ты будешь терпеть неудачу, иногда позорно. Но это нормально (смотри следующий заголовок, объясняющий почему). На самом деле, если ты не косячишь время от времени, вероятно что-то ты делаешь не так.
Вывод: Если твоя неудача может повлиять на других, лучше предупредить их заранее.
Итак, ты обломался и выставил себя дураком. Возможно на тебя наорал исполнительный директор. Твоя демонстрация драматично провалилась на глазах у тысяч людей. После твоей правки кода лег сайт.
Оказывается, что это нормально. Хотя в тот момент может так и не казаться, но на самом деле, это ожидаемо. Если ты не обламываешься, ты не стараешься достаточно. Меня очень раздражает, когда кто-то работает только над мелочами. Каковы шансы того, что это будет полезно через пять лет? Обычно никаких.
Еще бóльшая опасность работы с мелкими косяками? Это делает людей опасливыми. Если твои сотрудники боятся что-то поломать, они застрянут на месте, и не будут узнавать ничего нового. Никто от этого не выиграет – они не «вырастут», а ты не получишь от них максимума.
Трудно достичь Дзэн избежав публичных ошибок. Попробуй поговорить со мной, если моё выступление прошло плохо – обычно я хочу провалиться под землю. Но спустя некоторое время ты учишься различать вещи, которые не должны волновать тебя и вещи, о которых в самом деле стоит беспокоиться.
Вывод №1: Если тебе приходится работать в среде/команде, где каждый боится совершить малейшую ошибку и ходит на цыпочках вокруг – лучше уйди! То же самое стоит сделать и если твой менеджер заносит твои мелкие проступки в личную характеристику.
Вывод №2: Если ты совершил проступок, признай это открыто. Разошли письмо «Я тут накосячил». Прими обвинения и иди дальше вместо того, чтобы пытаться скрыть это.
Я украл идею у Джея. Когда работаешь в команде, уважение и доверие твоих подчиненных обязательно. Простой способ измерить это – взглянуть на ищущих тебя людей. Если люди не ищут тебя постоянно – будь то проблемы, идеи или что-то, что им нужно от тебя, значит здесь что-то не так.
Обратная сторона – ты должен быть вовлечен постоянно. Будь ты разработчик или нет, ты должен присутствовать во всех списках оповещения о коммитах и списках рассылки в команде. Ты должен пробовать все свежайшие дневные билды. Ты должен быть вовлечен.
Если ты не включился или поворачиваешься спиной к людям, которые ищут тебя, не ожидай, что тебя пригласят, когда будут приниматься ключевые решения.
Если у тебя техническая работа, ты обязан смотреть в код. Ты не должен уметь писать или отлаживать его, но у тебя должны быть основные навыки программиста. Синхронизируй исходники и запусти компиляцию. Если ты не можешь понять как, поспрашивай (и в процессе узнай о команде разработчиков). Посмотри дневные коммиты. В хорошие времена коммиты будут идти постоянно. В тяжелые времена коммиты будут редкими и тощими.
Я наблюдал несметное количество переговоров и совещаний, которых можно было избежать заглянув в код на 30 секунд. Нет абсолютно никакой замены знанию того, как продукт работает (и диаграмы архитектуры здесь не помогут). Если ты знаешь, как работает отладчик, поставь пару брейкпоинтов и пойми, как различные части стыкуются вместе.
Если не будет других проблем, твои разработчики будут относиться к тебе намного серьезнее.
Каждый раз, когда я слышу термин «командный игрок», я вспоминаю этот пост. Выражение «командная игра» часто неверно трактуется как означающее повиновение, предсказуемость и в общем, безынициативность. Другими словами, всё то, что ты не делаешь, если ты хакер.
Звучит заманчиво, запереться и закодить что-то а потом показать готовый продукт. Игнорировать летучки, письма и волокиту обычной скучной работы.
Не делай этого. Пожалуй, не делай этого постоянно.
Хакерство – это креативный процесс. Обязательно будут выходные, проведенные за кодом. Хотя, если это твой обычный режим работы, ты причинишь много страданий своей команде. Если они не узнают, насколько далеко ты от «сделано», они не смогут понять, насколько им стоит беспокоиться или сколько времени им необходимо оставить в планах на непредвиденные обстоятельства.
Выдели немного времени на то, чтобы пройтись по офисам. Зайди и выясни о чем говорят люди. Поговори о том, чем занимаешься ты. В конце концов это дает им комфортное ощущение того, что ты делаешь что-то вместо того, чтобы бесконечно читать Хабрахабр (в оригинале «Hacker News» — прим. пер.). Спустя некоторое время (приемлемое время), ты получишь достаточно доверия, чтобы люди могли положиться на то, что ты сделаешь вовремя.
Мне часто приходилось видеть застой у многих хороших людей. Ты начинаешь замечать это, когда они начинают говорить «Эта новая штука X такая-же как Y двадцатилетней давности, поэтому я даже и пробовать не буду». Наша индустрия такова, что она капитально меняется каждые несколько лет. Худшая вещь, которую можно допустить – это не быть в курсе и дать себе увянуть.
Это не значит, что ты должен присутствовать в каждой новой социальной сети и иметь десятки установленных программ для айфона. Но ты должен «играться» с тем, что популярно. Поставить новый популярный язык программирования, веб-фреймворк, плагин для браузера, что угодно.
«Нет времени» – это не оправдание. То, что всегда впечатляло меня в Билле Гейтсе и Рее Оззи, так это то, как много они играют с техникой как своей собственной компании так и других. Если они могут найти время, ты можешь тем более.
Помимо простых забав с техникой, понаблюдай как другие ею пользуются. Ты можешь многому научиться просто зависая в отделе ноутбуков в Эльдорадо (в оригинале «Costco» — прим. пер.) или наблюдая за общением людей в магазинах сотовых телефонов (в оригинале «AT&T store» — прим. пер.). Рэй Оззи рассказывает о том, что каждый раз попадая в новый город или страну проезжается в общественном транспорте, чтобы понаблюдать, как люди используют вещи. Попробуй понять то, чего нормальные люди пытаются получить от технологии.
Команды, которые загибаются в Майкрософт – это те, которые не пытаются быть в курсе. Сигнал этого – все члены команды работали над чем-то одним в течение десятилетия. Это почти всегда верный признак того, что вам нужна новая кровь чтобы встряхнуть мышление. Конечно, как и для любого правила, здесь есть исключения.
Каждый раз, когда я решаю переключиться на что-то другое, сначала я ищу людей, с которыми мне бы хотелось работать (именно так я набрал свою текущую команду). Это очень отличается от того, как я начинал, имея привычку брать команду самого крутого продукта, о котором я мог подумать.
Быстро учишься тому, что в долгосрочной перспективе то, как ты уживаешься с людьми в своей команде значительно больше влияет на то, насколько ты счастлив. Крутые технологии угасают, меняются и становятся старыми. При этом отношения, которые тебе удалось построить с отличными членами команды длятся долгие долгие годы.
Какой тип людей набирать? Я склоняюсь брать в команды людей следующих типов – непочтительных, мятежников, создающих проблемы. Что подходит тебе, решай сам.
Я сильно верю, что единственный способ развиваться – это делать вещи вне своей зоны комфорта. Будь то люди, места, языки программирования или твоя работа – попробуй и сделай то, чего не делал раньше.
Например, я всегда чувствовал себя некомфортно в барах и клубах. Я искал всяческие оправдания лишь бы избежать вылазки с коллегами. Наконец-то я решил, что единственный способ чувствовать себя комфортно в такой ситуации – это взять и пойти. Я заставлял себя несколько лет выходить в свет и теперь я нормален как и все остальные.
То же самое происходит и с технологиями. Пиши код на новом языке, пробуй новый поисковик или переключайся на новый браузер. Попробуй ненадолго заняться другой работой. В Майкрософт достаточно просто стать программным менеджером или разработчиком на полставки – люди обожают ту помощь, которую ты можешь им оказать. Получай от этого пользу.
Каждый из нас бывал на совещаниях/презентациях, где ты был смущен, имел вопросы или просто не понимал темы разговора. Иной раз ты видишь что все в комнате обходят щекотливую тему.
Это происходит из-за желания быть подходящим, не выглядеть глупым перед своими коллегами и боссами. Знаешь что? Чаще всего они в той же лодке что и ты. Принцип большего пальца, который мне кажется надежным в данной ситуации заключается в том, что самый умный в комнате первым скажет «Я не знаю».
Неудобные вопросы каверзны. Некоторые вопросы – это табу не без причины (хороший пример — правовые вопросы). Признай их и двигайся дальше. Чаще всего ты добьешься более продуктивных переговоров ставя обычный вопрос, который все обходят стороной.
В каждой большой организации есть немало интересных людей. Это статистически очевидно. Люди, создавшие интересные вещи, люди, пробывшие здесь достаточное время чтобы стать мудрыми, люди, которые интересны своим эксентричным поведением, список можно продолжать.
Иди и познакомься с каждым из них. Выясни над чем они работают. Попроси их рассказать тебе историю о «старых добрых деньках». Позволь им поворчать о вещах, которые они теперь ненавидят. Научись у них.
Никто не откажется от встречи за обедом или за чашечкой кофе. Они могут сопротивляться, но большинство поддадутся. Если это не помогает, загляни в их офис и скажи «Привет». Если ты работаешь в Майкрософт или Гугл, познакомься с суперзвездами – знакомься с Дейвами Катлерами, Патриками Дассадами, Дейвами Кэмпбеллами, Робами Пайками, Кенами Томпсонами.
Покритиковать чью-то идею на публике никогда не мешает. Этого ожидают. Однако то, чего не следует делать – это критиковать на публике самого человека. Недоволен чьим-то подходом или производительностью? Проведи беседу за закрытыми дверями. Это особенно важно, если человек стоит ниже тебя на корпоративной лестнице. Приемущества во власти не позволят им ответить тебе.
С другой стороне похвала – это всегда то, что должно быть сделано на публике. К сожалению, люди часто недооценивают эффект признания человека за то, что он сделал. Коротенькое письмо проделает большой путь делая всех счастливыми.
Очень много людей ждут, что «система» позаботится о них. Особенно если ты провел всю свою жизнь в школе и университете, где твоя оценка обоснована и рациональна.
В командах/компаниях это очень часто не так. Какую маленьку фичу ты добавишь в следующий релиз? Ты должен пойти и рассказать всем, какая она крутая. Хочешь благодарности за свою работу по массовому повышению производительности продукта? Сделай так, чтобы нужные люди знали о том, что именно ты сделал.
Это удивляет многих хакеров. Разве не «система» должна автоматически заботиться о таких мирских вещах как объявление благодарностей или оценка того, насколько что-то хорошо? Проблема в том, что «система», как правило – это кучка умных, благонамеренных, перегруженных работой людей, у которых обычно не достаточно данных обо всем происходящем в команде. Если ты не приложишь усилий для того, чтобы они получили нужные входные данные (а это может быть так-же просто как постучаться в их дверь и сказать «Гляньте, что я сделал»), не удивляйся, если дела пойдут не в твою пользу.
Самый главный урок из этих всех – не будь засранцем. Много умных людей склоняются к развитию грубой, антагонистической модели поведения. Иногда они придурки по натуре. А иногда они видят такое поведение проявляющимся у людей с которыми они работают и которыми восхищаются (это часто происходило в Майкрософт 10-15 лет назад).
Некоторые хакеры мешают невоспитаность с прямотой и грубостью. Не делай так – существует целый мир различий между этими двумя вещами. Ты можешь быть грубым, называть кого-то сукой и не быть непристойным. Фактически, некоторые люди которыми я восторгаюсь достаточно часто могут обозвать кого-то не повышая при этом голоса или даже не заставляя другого человека чувствовать себя плохо.
Если ты будешь придурком, это не только заставит людей ненавидеть тебя, это так же возымеет социальный эффект. Достаточно одного человека, демонстрирующего плохое поведение, чтобы оно распространилось.
Будь тактичным.
Заключение: Не путай «быть тактичным» и «быть политически корректным» или «быть пассивно-агрессивным». Быть пассивно-агрессивным и чрезмерно политически корректным одинаково плохо. Главное – это критиковать чью-то работу или идеи без того, чтобы критиковать человека лично.
Это, однако, достаточно тяжело сделать.
UPD: Поправил некоторые стилистические и грамматические ошибки в тексте.
Некоторые из этих вещей специфичны для Майкрософт, но большая часть найдет применение в любой командной/корпоративной среде. Некоторые из них сложны – из-за них тебя могут уволить (а может и хуже), если ты не знаешь, что делаешь.
Проси прощения, а не разрешения
Любому достаточно большому учреждению есть чего терять. Кредитоспособность, деньги, власть, что угодно. Поэтому любой запрос на что-либо новое и рисковое встречается с осторожностью. Будь то новое предложение или проект, безопасней сказать «Нет». Корпорации оптимизированы говорить «Нет». Поддерживая статус-кво. Нет риска провала и эффектного крушения.
По этой самой причине лучше идти и делать что-то не спрашивая разрешения. Ведь если не спрашивать, никто не запретит. Появилась интересная идея для побочного проекта? Иди, закодируй её. Если ты спросишь кого-то сначала, возможно тебе скажут «Проконсультируйся с командой X, Y и вице-президентом Z», и тогда ты наткнешься на нескончаемую спираль. Хочешь написать в блоге о том, что тебя беспокоит? Иди, пиши.
Однако ты должен понимать, чего делаешь. Не делай чего-то явно глупого. Хочешь написать о неанонсированной фиче X? Плохая идея. Коммитишь код никого не предупредив? Очень плохая идея. Пишешь гневное письмо не тому вице-президенту? Возможно (но обычно не такая уж плохая идея). Как и с любыми рисками, есть и обратная сторона.
Это не срабатывает постоянно. Ты будешь терпеть неудачу, иногда позорно. Но это нормально (смотри следующий заголовок, объясняющий почему). На самом деле, если ты не косячишь время от времени, вероятно что-то ты делаешь не так.
Вывод: Если твоя неудача может повлиять на других, лучше предупредить их заранее.
(Обычно) Косяки — это нормально
Итак, ты обломался и выставил себя дураком. Возможно на тебя наорал исполнительный директор. Твоя демонстрация драматично провалилась на глазах у тысяч людей. После твоей правки кода лег сайт.
Оказывается, что это нормально. Хотя в тот момент может так и не казаться, но на самом деле, это ожидаемо. Если ты не обламываешься, ты не стараешься достаточно. Меня очень раздражает, когда кто-то работает только над мелочами. Каковы шансы того, что это будет полезно через пять лет? Обычно никаких.
Еще бóльшая опасность работы с мелкими косяками? Это делает людей опасливыми. Если твои сотрудники боятся что-то поломать, они застрянут на месте, и не будут узнавать ничего нового. Никто от этого не выиграет – они не «вырастут», а ты не получишь от них максимума.
Трудно достичь Дзэн избежав публичных ошибок. Попробуй поговорить со мной, если моё выступление прошло плохо – обычно я хочу провалиться под землю. Но спустя некоторое время ты учишься различать вещи, которые не должны волновать тебя и вещи, о которых в самом деле стоит беспокоиться.
Вывод №1: Если тебе приходится работать в среде/команде, где каждый боится совершить малейшую ошибку и ходит на цыпочках вокруг – лучше уйди! То же самое стоит сделать и если твой менеджер заносит твои мелкие проступки в личную характеристику.
Вывод №2: Если ты совершил проступок, признай это открыто. Разошли письмо «Я тут накосячил». Прими обвинения и иди дальше вместо того, чтобы пытаться скрыть это.
Поглядывай на очередь перед своей дверью
Я украл идею у Джея. Когда работаешь в команде, уважение и доверие твоих подчиненных обязательно. Простой способ измерить это – взглянуть на ищущих тебя людей. Если люди не ищут тебя постоянно – будь то проблемы, идеи или что-то, что им нужно от тебя, значит здесь что-то не так.
Обратная сторона – ты должен быть вовлечен постоянно. Будь ты разработчик или нет, ты должен присутствовать во всех списках оповещения о коммитах и списках рассылки в команде. Ты должен пробовать все свежайшие дневные билды. Ты должен быть вовлечен.
Если ты не включился или поворачиваешься спиной к людям, которые ищут тебя, не ожидай, что тебя пригласят, когда будут приниматься ключевые решения.
Код во главе
Если у тебя техническая работа, ты обязан смотреть в код. Ты не должен уметь писать или отлаживать его, но у тебя должны быть основные навыки программиста. Синхронизируй исходники и запусти компиляцию. Если ты не можешь понять как, поспрашивай (и в процессе узнай о команде разработчиков). Посмотри дневные коммиты. В хорошие времена коммиты будут идти постоянно. В тяжелые времена коммиты будут редкими и тощими.
Я наблюдал несметное количество переговоров и совещаний, которых можно было избежать заглянув в код на 30 секунд. Нет абсолютно никакой замены знанию того, как продукт работает (и диаграмы архитектуры здесь не помогут). Если ты знаешь, как работает отладчик, поставь пару брейкпоинтов и пойми, как различные части стыкуются вместе.
Если не будет других проблем, твои разработчики будут относиться к тебе намного серьезнее.
Синдром одинокого волка
Каждый раз, когда я слышу термин «командный игрок», я вспоминаю этот пост. Выражение «командная игра» часто неверно трактуется как означающее повиновение, предсказуемость и в общем, безынициативность. Другими словами, всё то, что ты не делаешь, если ты хакер.
Звучит заманчиво, запереться и закодить что-то а потом показать готовый продукт. Игнорировать летучки, письма и волокиту обычной скучной работы.
Не делай этого. Пожалуй, не делай этого постоянно.
Хакерство – это креативный процесс. Обязательно будут выходные, проведенные за кодом. Хотя, если это твой обычный режим работы, ты причинишь много страданий своей команде. Если они не узнают, насколько далеко ты от «сделано», они не смогут понять, насколько им стоит беспокоиться или сколько времени им необходимо оставить в планах на непредвиденные обстоятельства.
Выдели немного времени на то, чтобы пройтись по офисам. Зайди и выясни о чем говорят люди. Поговори о том, чем занимаешься ты. В конце концов это дает им комфортное ощущение того, что ты делаешь что-то вместо того, чтобы бесконечно читать Хабрахабр (в оригинале «Hacker News» — прим. пер.). Спустя некоторое время (приемлемое время), ты получишь достаточно доверия, чтобы люди могли положиться на то, что ты сделаешь вовремя.
Пробуй новое
Мне часто приходилось видеть застой у многих хороших людей. Ты начинаешь замечать это, когда они начинают говорить «Эта новая штука X такая-же как Y двадцатилетней давности, поэтому я даже и пробовать не буду». Наша индустрия такова, что она капитально меняется каждые несколько лет. Худшая вещь, которую можно допустить – это не быть в курсе и дать себе увянуть.
Это не значит, что ты должен присутствовать в каждой новой социальной сети и иметь десятки установленных программ для айфона. Но ты должен «играться» с тем, что популярно. Поставить новый популярный язык программирования, веб-фреймворк, плагин для браузера, что угодно.
«Нет времени» – это не оправдание. То, что всегда впечатляло меня в Билле Гейтсе и Рее Оззи, так это то, как много они играют с техникой как своей собственной компании так и других. Если они могут найти время, ты можешь тем более.
Помимо простых забав с техникой, понаблюдай как другие ею пользуются. Ты можешь многому научиться просто зависая в отделе ноутбуков в Эльдорадо (в оригинале «Costco» — прим. пер.) или наблюдая за общением людей в магазинах сотовых телефонов (в оригинале «AT&T store» — прим. пер.). Рэй Оззи рассказывает о том, что каждый раз попадая в новый город или страну проезжается в общественном транспорте, чтобы понаблюдать, как люди используют вещи. Попробуй понять то, чего нормальные люди пытаются получить от технологии.
Команды, которые загибаются в Майкрософт – это те, которые не пытаются быть в курсе. Сигнал этого – все члены команды работали над чем-то одним в течение десятилетия. Это почти всегда верный признак того, что вам нужна новая кровь чтобы встряхнуть мышление. Конечно, как и для любого правила, здесь есть исключения.
Новая команда? Набирай людей а не продукты
Каждый раз, когда я решаю переключиться на что-то другое, сначала я ищу людей, с которыми мне бы хотелось работать (именно так я набрал свою текущую команду). Это очень отличается от того, как я начинал, имея привычку брать команду самого крутого продукта, о котором я мог подумать.
Быстро учишься тому, что в долгосрочной перспективе то, как ты уживаешься с людьми в своей команде значительно больше влияет на то, насколько ты счастлив. Крутые технологии угасают, меняются и становятся старыми. При этом отношения, которые тебе удалось построить с отличными членами команды длятся долгие долгие годы.
Какой тип людей набирать? Я склоняюсь брать в команды людей следующих типов – непочтительных, мятежников, создающих проблемы. Что подходит тебе, решай сам.
Покинь зону комфорта
Я сильно верю, что единственный способ развиваться – это делать вещи вне своей зоны комфорта. Будь то люди, места, языки программирования или твоя работа – попробуй и сделай то, чего не делал раньше.
Например, я всегда чувствовал себя некомфортно в барах и клубах. Я искал всяческие оправдания лишь бы избежать вылазки с коллегами. Наконец-то я решил, что единственный способ чувствовать себя комфортно в такой ситуации – это взять и пойти. Я заставлял себя несколько лет выходить в свет и теперь я нормален как и все остальные.
То же самое происходит и с технологиями. Пиши код на новом языке, пробуй новый поисковик или переключайся на новый браузер. Попробуй ненадолго заняться другой работой. В Майкрософт достаточно просто стать программным менеджером или разработчиком на полставки – люди обожают ту помощь, которую ты можешь им оказать. Получай от этого пользу.
Задавай неудобные вопросы
Каждый из нас бывал на совещаниях/презентациях, где ты был смущен, имел вопросы или просто не понимал темы разговора. Иной раз ты видишь что все в комнате обходят щекотливую тему.
Это происходит из-за желания быть подходящим, не выглядеть глупым перед своими коллегами и боссами. Знаешь что? Чаще всего они в той же лодке что и ты. Принцип большего пальца, который мне кажется надежным в данной ситуации заключается в том, что самый умный в комнате первым скажет «Я не знаю».
Неудобные вопросы каверзны. Некоторые вопросы – это табу не без причины (хороший пример — правовые вопросы). Признай их и двигайся дальше. Чаще всего ты добьешься более продуктивных переговоров ставя обычный вопрос, который все обходят стороной.
Иди, скажи «Привет!»
В каждой большой организации есть немало интересных людей. Это статистически очевидно. Люди, создавшие интересные вещи, люди, пробывшие здесь достаточное время чтобы стать мудрыми, люди, которые интересны своим эксентричным поведением, список можно продолжать.
Иди и познакомься с каждым из них. Выясни над чем они работают. Попроси их рассказать тебе историю о «старых добрых деньках». Позволь им поворчать о вещах, которые они теперь ненавидят. Научись у них.
Никто не откажется от встречи за обедом или за чашечкой кофе. Они могут сопротивляться, но большинство поддадутся. Если это не помогает, загляни в их офис и скажи «Привет». Если ты работаешь в Майкрософт или Гугл, познакомься с суперзвездами – знакомься с Дейвами Катлерами, Патриками Дассадами, Дейвами Кэмпбеллами, Робами Пайками, Кенами Томпсонами.
Хвали на публике, наказывай за закрытыми дверями
Покритиковать чью-то идею на публике никогда не мешает. Этого ожидают. Однако то, чего не следует делать – это критиковать на публике самого человека. Недоволен чьим-то подходом или производительностью? Проведи беседу за закрытыми дверями. Это особенно важно, если человек стоит ниже тебя на корпоративной лестнице. Приемущества во власти не позволят им ответить тебе.
С другой стороне похвала – это всегда то, что должно быть сделано на публике. К сожалению, люди часто недооценивают эффект признания человека за то, что он сделал. Коротенькое письмо проделает большой путь делая всех счастливыми.
Лучшие вещи берутся, не даются
Очень много людей ждут, что «система» позаботится о них. Особенно если ты провел всю свою жизнь в школе и университете, где твоя оценка обоснована и рациональна.
В командах/компаниях это очень часто не так. Какую маленьку фичу ты добавишь в следующий релиз? Ты должен пойти и рассказать всем, какая она крутая. Хочешь благодарности за свою работу по массовому повышению производительности продукта? Сделай так, чтобы нужные люди знали о том, что именно ты сделал.
Это удивляет многих хакеров. Разве не «система» должна автоматически заботиться о таких мирских вещах как объявление благодарностей или оценка того, насколько что-то хорошо? Проблема в том, что «система», как правило – это кучка умных, благонамеренных, перегруженных работой людей, у которых обычно не достаточно данных обо всем происходящем в команде. Если ты не приложишь усилий для того, чтобы они получили нужные входные данные (а это может быть так-же просто как постучаться в их дверь и сказать «Гляньте, что я сделал»), не удивляйся, если дела пойдут не в твою пользу.
Не будь засранцем
Самый главный урок из этих всех – не будь засранцем. Много умных людей склоняются к развитию грубой, антагонистической модели поведения. Иногда они придурки по натуре. А иногда они видят такое поведение проявляющимся у людей с которыми они работают и которыми восхищаются (это часто происходило в Майкрософт 10-15 лет назад).
Некоторые хакеры мешают невоспитаность с прямотой и грубостью. Не делай так – существует целый мир различий между этими двумя вещами. Ты можешь быть грубым, называть кого-то сукой и не быть непристойным. Фактически, некоторые люди которыми я восторгаюсь достаточно часто могут обозвать кого-то не повышая при этом голоса или даже не заставляя другого человека чувствовать себя плохо.
Если ты будешь придурком, это не только заставит людей ненавидеть тебя, это так же возымеет социальный эффект. Достаточно одного человека, демонстрирующего плохое поведение, чтобы оно распространилось.
Будь тактичным.
Заключение: Не путай «быть тактичным» и «быть политически корректным» или «быть пассивно-агрессивным». Быть пассивно-агрессивным и чрезмерно политически корректным одинаково плохо. Главное – это критиковать чью-то работу или идеи без того, чтобы критиковать человека лично.
Это, однако, достаточно тяжело сделать.
UPD: Поправил некоторые стилистические и грамматические ошибки в тексте.
