Извините, но если директор не в состоянии организовать свой собственный рабочий процесс, почему его допустили до организации работы отдела?
попробуйте посмотреть на это предложение в контексте статьи: хороший разработчик и хороший тимлид "растет" в других условиях, условиях определённости и налаженных процессов. Что почти всегда неверно в случае директора. Это может поначалу вводить в стресс. Опять же, неструктурированный поток задач — это факт, он будет, независимо от того, справляется директор с ним или нет. В статье не говорится, что директор собственноручно решает все проблемы, а лишь подчёркивается то, что может "прилететь", откуда не ждали.
Эта статья только подкрепляет распространенное представление, что для работы руководителем не нужно никаких фундаментальных знаний и навыков. Главное быть лояльным, в режиме 24/7 принимать на себя любую задачу, какую спустят сверху.
Отнюдь. В статье как раз говорится: "Я не говорю, что техдир обязан всегда «брать под козырёк» и коммититься на нереальные сроки, я лишь хочу сказать, что человек должен быть готов к такого рода давлению..."
К вопросу ведь можно подойти системно. Сначала в теории разобраться с тем, что организация, руководство и управление - это разные виды деятельности. Изучить устройство человеческих групп и динамику их развития. Осознать роль директора в прикладном смысле. Наконец, тренировать на практике приемы и методики для эффективного исполнения этой деятельности, в зависимости от конкретных обстоятельств.
Что это означает на практике? Вот назначили вас завтра на такую должность. У вас ворох нерешенных проблем. И вы займётесь теорией? Звучит нереалистично
И вы действительно уверены, что сотрудник будет честен на 100%? Это как при расставании двух людей спрашивать «в чём дело» и услышать «дело не в тебе, а во мне». Навряд ли у сотрудника будет желание обсуждать острые углы.
Практика показывает, что как раз в такие моменты сотрудник склонен говорить «без купюр», т.к. терять нечего и сглаживать углы нет смысла.
Как вы отнесётесь к тому, что соискателя уволили на прошлом месте работы? Скорее всего вы не захотите нанимать его. Никто не захочет озвучивать данную тему тем более давать какие-то контакты руководителей с прошлого места работы, учитывая что расстались «на ножах». Не получится ли так, что из-за увольнения у бывшего сотрудника закрывается сама возможность трудоустройства?
Отнюдь, полно компаний, которые не проверяют рекомендации при найме.
Комментарий более, чем странный. Какое отношение он имеет к статье? Технические ошибки случаются всегда, и если вы обратились в поддержку, передав все детали случившегося, вам обязательно помогут. Добра всем!
Действительно, нематериальная мотивация — тема очень широкая, которая заслуживает отдельного цикла статей. Тут я скорее, в формате «поделиться опытом», хотел сказать, что когда у сотрудника утеряна мотивация, не нужно спешить поднимать зарплату. А вместо этого поискать другие способы. И конечно, спросить сотрудника — не единственный способ. Более того, люди часто сами не знают, что их мотивирует. В таких случаях, например, может помочь тест Хогана (MVPI).
Что касается похвалы, думаю, привычка публично давать заслуженную положительную обратную связь сотрудникам — очень важный скилл для тимлида: ничего не стоит, повышает вовлечённость и мотивированность.
Николай, спасибо за комментарий. Книга, на которую я ссылаюсь в статье, говорит: «the server can use this information to prioritize stream processing by controlling the allocation of CPU, memory, and other resources, and once the response data is available, allocation of bandwidth to ensure optimal delivery of high-priority responses to the client.» Тест, описанный статье, также специально ожидает заполнения буферов сервера данными «низкоприоритетных» запросов. Исходя из этого, как я понимаю, местов в буфере также должно быть перераспределено под приоритетные запросы
Спасибо за комментарий и вопрос! Всё же, в статье имелось в виду Cloudfront, а не Cloudflare.
Касательно HTTP/3, судя по драфту, механизм Steam Prioritization будет заменён на более простой и понятный, обсуждение еще идёт
Спасибо за ваш комментарий.
попробуйте посмотреть на это предложение в контексте статьи: хороший разработчик и хороший тимлид "растет" в других условиях, условиях определённости и налаженных процессов. Что почти всегда неверно в случае директора. Это может поначалу вводить в стресс. Опять же, неструктурированный поток задач — это факт, он будет, независимо от того, справляется директор с ним или нет. В статье не говорится, что директор собственноручно решает все проблемы, а лишь подчёркивается то, что может "прилететь", откуда не ждали.
Отнюдь. В статье как раз говорится: "Я не говорю, что техдир обязан всегда «брать под козырёк» и коммититься на нереальные сроки, я лишь хочу сказать, что человек должен быть готов к такого рода давлению..."
Что это означает на практике? Вот назначили вас завтра на такую должность. У вас ворох нерешенных проблем. И вы займётесь теорией? Звучит нереалистично
спасибо, исправлено
Практика показывает, что как раз в такие моменты сотрудник склонен говорить «без купюр», т.к. терять нечего и сглаживать углы нет смысла.
Отнюдь, полно компаний, которые не проверяют рекомендации при найме.
Действительно, нематериальная мотивация — тема очень широкая, которая заслуживает отдельного цикла статей. Тут я скорее, в формате «поделиться опытом», хотел сказать, что когда у сотрудника утеряна мотивация, не нужно спешить поднимать зарплату. А вместо этого поискать другие способы. И конечно, спросить сотрудника — не единственный способ. Более того, люди часто сами не знают, что их мотивирует. В таких случаях, например, может помочь тест Хогана (MVPI).
Что касается похвалы, думаю, привычка публично давать заслуженную положительную обратную связь сотрудникам — очень важный скилл для тимлида: ничего не стоит, повышает вовлечённость и мотивированность.
Касательно HTTP/3, судя по драфту, механизм Steam Prioritization будет заменён на более простой и понятный, обсуждение еще идёт