И еще для новичков:

99% of management is doing uncomfortable stuff every day: pushing people to do a little better, pushing yourself to be a bit better, resolving conflict, giving feedback.
As a manager, your literal value add is what you do to make people and teams perform better than they would have without you there.

Your job is to change behavior.

This can’t be a job you do once a quarter. Many managers dream of big inspired moments of super high leverage decisions that make their whole year. Management is simply not that job. Management is the accumulation of daily nudges, assistance, enablement, help, and toil.

Management happens every day.

Отсюда "Management Mantras"

ЗЫ совет №1 менеджеру-новичку

#management

Вопрос из зала:
"как описать в резюме свои результаты, если в основном занят тем, что поддерживаешь все разваливающееся от действий тех, кто любит писать красивые вещи в своих резюме?"

Ответ: 🤝 жму руку. Честно, я не знаю, как именно это описать. Надо искать что-то другое, более позитивное и привлекательное :)
ЗЫ у меня тоже смешное резюме с этой точки зрения.
ЗЫ2 ну и да, обычно такие писатели, еще и в других резюме такое искать любят.

Тут немного с примерами про числа и прочие достижения в резюме

#ваши_вопросы #собеседования #про_резюме

Как сохранять спокойствие...

Иногда работает :)

Во всех стратегических сессиях планирования года: "как нам добавить AI в старый продукт"...

пятничные #it_memes

Как разрушать ответственность
This Is How You're Eroding Accountability
• не проверять, что сделано
• изменчивые приоритеты
• неверные стимулы
• сломанные организационные структуры:
- перехлест зон ответственности ролей
- слишком много уровней иерархии
В решениях собственно делать все наоборот :)
И имхо самое важное - настроить систему поощрений:

reinforce accountability via your company’s reward system.
It’s critical that people who consistently don’t perform are managed out, and people who consistently perform well are rewarded. This sets the foundation for all other elements of accountability and gives the system teeth

(Кстати, есть очень "забавная" история с интерпретацией accountability и responsibility на русском. Перевод вроде один, а смыслы разные. В понедельник напишу свое понимание, заодно проверим)

#management

В английском языке используются 2 разных слова для определения ответственности за выполнение чего-либо (responsibility) и за достижение нужных результатов (accountability).

В разных языках/культурах эта "парочка" определяется и используется по-разному.

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

Чем же все-таки отличаются responsibility и accountability, кроме упрощенного output vs outcome (что на самом деле тоже часто требует пояснения ибо и то, и то типа "результаты", но разные 😃 ).

"Accountability = responsibility to explain" - интересная интерпретация из японского (фактически синтезированная, потому что там тоже нет своего слова для accountability).

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

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

Аccountability растет с осведомленностью, контекстом в рамках которого решается задача - это дает больше шансов достигнуть нужных целей (outcome).

Проактивность - важная отличительная черта accountability. И в том самом злосчастном перфревью часто именно проактивность показывает уровень вовлеченности человека и выход за рамки обозначенных ожиданий.
Другими словами: "Когда непофиг. Просто взял и сделал. Не ныл, а сделал".

Есть нюанс или сложность: можно слиться из проактивности в нытье (см убиваем ответственность).

Вместе аccountability и responsibility формируют владение (ownership).

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

Ну а мне, все так же, очень нравится это определение "ответственность - это «способность быть причиной»". Про что это, аccountability или responsibility? Да все равно, потому что это и есть настоящая ответственность.

#мысли_вслух #management #it_философия

API #testing
А какое покрытие у вас? 🙂

У кого про что болит, тот про то и говорит...

• Steps to build engineering strategy.
• пример стратегии "We're a product engineering company!" Engineering strategy at Calm.

Кстати, интересный вариант, не видел раньше подобных. Но интересно, что дальше из этого получилось. Ведь как бы ни о чем, где конкретика. Да? 🙂

ЗЫ вспоминая прошлую компанию после рассказа стратегии <воспоминания разблокированы> "и че с этим делать? где план? че за философия?" <воспоминания заблокированы>

#стратегия

Поржал ... ))

"Наличие скрам-мастера и продукт-оунера — сладкие признаки. Если при описании вакансии тебе встретились эти слова, то они означают вкусные бабосики за безделье. Из минусов адова куча совещаний, которые надо научиться пропускать, либо прогать во время них. Можно заниматься спортом, я лично строил дачу во время совещаний. Нельзя быть токсичным: называть идиотов идиотами, а жирных жирными, бездельников бездельниками. Бонусом идет ДМС, печеньки, модный офис. Если у конторы есть деньги, чтобы кормить скрам-мастера, бизнес-оунера, продакт-менеджера и ux-дизайнера, почему бы не покормить еще одного?"

Но забавно другое.

Те же программисты считают "разраб должен писать код, а не встречи собирать для обсуждения реализации между N-команд и таски ставить".

Они же не могут сходу ответить на вопрос - "для чего ты сделал заведенную тобой задачу "сервис haron должен настраивать тайм-аут conf.timeout.herpoimichego через доп конф свойство в etcd".
И вроде это не "добавить хероверть, чтобы попердень стала крутой", но ведь звучит так же. Иногда требуется несколько наводящих вопросов, чтобы понять на какой пользовательский сценарий это влияет и как.

Я не про то, что все эти дополнительные люди из статьи всегда нужны и полезны (а некоторые персоналии прям конкретно "доставляют").
Но и переводить это как “всех можно уволить и ничего не поменяется", мягко говоря, плохая идея.

Непонятно, что на самом деле так зацепило в этой "желтой" заметке... Все ведь будучи на удаленке хорошо работают? :)

#байки

Да, были люди в наше время,
не то, что нынешнее племя...

"Обычная" вакансия помощника тестировщика 8 лет назад.

А представляете, какой сеньор был? 😇

исторические #it_memes

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

"Это как яйца дверью прищемить: долгая подготовка, яркие ощущения в процессе и непонятно, зачем оно нужно."

#байки #мысли_вслух

The five essential rules of software project management

1. Больше сил на проекте - больше шансов продолбаться со сроками
2. Способ, который работает в одном случае, не факт что будет работать всегда и везде
3. Всегда критически смотрите на оценки разработки
4. Проектное управление разработкой софта - это всегда работа с рисками
5. Неважно, на что тебе указывают, как источник проблемы. Это всегда проблема людей.

#management

"Take it easy"
По идее, сложные задачи и условия должны закаливать те самые новые хард-экс-софт скилы.
Но, как и в металлообработке, главное не перебдеть - перекалил металл на лезвии и вроде остро, но только помидорки резать, иначе просто раскрошится.

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

PS в заголовке байка 20-летней давности из моей первой заграничной рабочей командировки. Часто рассказываю ее, когда пытаюсь кого-то успокоить.

#мысли_вслух

- неимоверные
- титанические
- сверх

усилия...

и прочие восхваляющие эпитеты с нечто называемым "калибровка" в рамках перформанс ревью (гуглите сами).

У вас есть такая тема?

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

#management

Про ящики в тестировании и не только, в пятничных #it_memes
Картинки из далекого прошлого.

McKinsey Gets Developer Productivity Wrong

I know exactly what happens when you have people focus on their individual output. I’ve measured the outcomes. I can only assume that McKinsey doesn’t understand “systems thinking.” The outcome is what I call a “pandemonium of developers.” You have a group of people all working on the same backlog but not acting as a team. Code review suffers, mentoring sufferers, pairing is impossible, work decomposition suffers, etc. Anything that requires more than one person, including helping someone get unstuck, will be deprioritized. Never measure individual output: ever.

🤝

As for “if a quality assurance tester has enough work to do,” tell me you don’t understand what QA should be doing on a team without telling me. Their job isn’t to test. Their job is to improve how testing is done.

🤝

For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.

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

Как определить компанию, где может работать продуктивность по МакКинзи - картинка в комментах.

#metrics

Leadership isn't just about implementing solutions; it's about steering the team through the discomfort of change - and creating and growing a culture where teams can solve any problem they face.

Why you can't solve every problem with the same hammer

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

К сожалению, не всегда это учитывается...

#management

Про даты в граните...

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

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

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

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

И вы понятия не имеете, почему.
А ответ прямо здесь: вы больше не двигаетесь быстро из-за ВАШЕЙ коммуникации.

Вместо того, чтобы создавать культуру, в которой у команд есть внутренняя мотивация двигаться быстро — потому что они энергичны и вовлечены — вы начали наказывать за те редкие случаи, когда команда не достигает своей амбициозной целевой даты.
И таким образом, сделав это, вы послали всем сообщение: не будьте слишком амбициозными, потому что награда за амбиции — это наказание.
Я знаю, что это не то сообщение, которое вы хотели отправить.
Но сделав то, что вы сделали, вы отправите именно его, все 100 раз из 100.

Что вы могли сделать вместо этого?
Когда команда не уложилась в дату релиза, вы могли бы поддержать ее вместо того, чтобы наказывать лидеров команды.
Можно использовать эту возможность, для создания и поддержки культуры решения амбициозных задач с вызовом.
Вы могли бы сказать:
"Я понимаю, почему вы не попали в обозначенную дату релиза.
Но я бы предпочел, чтобы вы оставались амбициозными и иногда не укладывались в дату, чем были консервативными и всегда попадали.
Я не хочу, чтобы вы перестали быть амбициозными по умолчанию.
И мы хотим, чтобы больше команд были такими, как вы".

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

Тем не менее, давайте объясню:
1. Большинство дат запусков не должны быть зафиксированы внешними обязательствами.
2. Но для каких-то запусков все же требуются внешние обязательства (перед клиентами, или регулирующими органами, или партнерами и тдтп)
3. Для запусков из п2 определите консервативную дату, которую вы почти наверняка достигнете.
4. Но даже для них попросите команду проработать амбициозную внутреннюю дату. Ничего страшного, если они не уложатся в эту дату. Но важно иметь эту цель.

Почему? Потому что помните закон Паркинсона: "Работа заполняет все время, отпущенное на неё..."

Вы когда-нибудь замечали, как команды всегда с трудом укладываются в дату, независимо от того, насколько консервативно они ее установили?
Даты — это простое, но неверное выражение скорости, амбиций и энергии вашей команды.

Хотя, если вы все еще хотите сохранить свою увлеченность достижением всех дат, я не уверен, что смогу (или даже хочу) убедить вас в обратном.

Но тогда я также гарантирую, что вы потратите всю свою карьеру, управляя командами, которые движутся медленнее, чем они могут на самом деле, и/или поставляют продукцию более низкого качества, чем они могут на самом деле, и вы потратите всю свою карьеру, настраивая проверки, процессы, ганты, эксельки и кнуты/пряники, пытаясь и проваливая попытки решить проблему, которую вы создали изначально.
Удачи вам 😉!

PS я уже слишком ленив написать такое сам, поэтому это просто вольный перевод, но подписываюсь под каждым словом
#management

Никогда такого не было и вот опять февральская релизная пятница в #it_memes