Management by exception is a style of business management that focuses on identifying and handling cases that deviate from the norm, recommended as best practice by the project management method.
...
Managers only intervene when there are significant deviations from the norm, whether positive or negative. In all other cases, the managers set the standards and employees have autonomy and accountability. This way the managers can focus on higher-impact activities.
...
They intervene only when something big happens, overlooking smaller mishaps and giving frequent, continuous feedback. Good and even excellent behavior is not celebrated, thus employees don’t know what behaviors to do more of.
Manage by exception also promotes reactivity to problems over preventing them.
...
What to do instead of manage by exception
• Set clear goals and standards, clarify the autonomy levels, explain an repeat the “why”
• Have weekly 1:1s to build trust and rapport
• “Catch them doing something good” – give constant positive and negative feedback The recommendation is to give 5 times more positive feedback than negative one
• Coach, prepare individual development plans
• Delegate
• Set psychological safety
• Celebrate wins and recognize both small and meaningful achievements
• Focus on taking advantage of and improving your directs’ strengths rather than improve their weaknesses

Stop “Manage by Exception”

Интересно, но я бы добавил, что требует хорошей прозрачности и полного доверия (в обе стороны).

#management

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

Небольшая напоминалка про DORA

DORA suggested using four key metrics, which predict organizational performance:

Deployment frequency (DF): How often does your organization deploy code to production?
Lead time for changes (LTFC): How long does it take to go from code committed to code running in production?
Change failure rate (CFR): What percentage of changes to production result in degraded service and need remediation?
Time to restore (TTR): How long does it generally take to restore service when a service incident or a defect that impacts users occurs?

How we doubled our team’s delivery performance within a year as measured by DORA metrics.

#metrics

There are four approaches to saying No:
• Direct: Thank, decline, and express interest.
• Redirect: Refer to someone else who is better suited for the ask
• Change Their Perspective: Is this ask phrased correctly? Does it really need me?
• Stonewall: Ignore, and follow up a few days later.

Other relevant tips:
• Communicate boundaries to be clear on expectations
• Involve your manager if needed
• Set up focus blocks so no one can bother you
• Scale yourself through notes and wikis
• Manage your reputation carefully – say “No” often but “Yes” sometimes!

Говори "Нет" правильно.

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

#развитие

Testing in prod is not trolling. It's the only way to confirm that your code is working, and *how* your code is working.

(тутъ)
И снова про мой любимый продакшен... Для адептов "руки прочь от прода".
#testing #quality #тесты_в_проде

Time spent thinking about code to be written is much more important than time spent writing code.

by Nathan Tippy

чужие #мысли_вслух

1997 год
Столько времени прошло, а эти заблуждения и ошибки все так же популярны.

Classic Testing Mistakes

... the testing team is responsible for assuring quality...

... the purpose of testing is to find bugs...

... reporting bug data without putting it into context...

... starting testing too late...

... using testing as a transitional job for new programmers...
... recruiting testers from the ranks of failed programmers...

... programmers can't test their own code...

Эта музыка будет вечной... Ясно и бесповоротно. 😏

#testing #quality

Интересное мнение про реальную пользу метрик из git-a от одного из разработчиков инструментов измерения "процесса" через git.

The Truth About Git Metrics Tools

"pull request metrics provided value in creating awareness around inefficient code review processes. But there were no real benefits beyond that. I was dismayed to find leaders frequently using the metrics for inappropriate purposes like performance reviews, or requesting we add metrics like lines of code to the product which I knew were harmful.
...
We built an initial product and piloted it, but shut it down after we found that teams didn't get much value out of it and most hardly used it at all. Although our product vision for "data-driven engineering" resonated with leaders and made for compelling sales pitches, there wasn't real value to back it up.
...
I’ve personally yet to come across an example of real benefit gained from these metrics other than shining a light on inefficient code review processes, which is a problem that’s easily solveable without dashboards.
...
If you’re a leader looking for insights on how to improve developer productivity, steer clear of these types of solutions and instead focus on developer experience."

#metrics

Качество со стороны разработки можно определить как простоту понимания, изменения и поддержания.

#мысли_вслух про #quality

Когда первый раз прочитал про Team Topologies - первой появившейся мыслью было, что такой способ организационной структуры ведет к риску того, что разъединенные/объединенные (как посмотреть) таким образом команды потеряют из вида конечную цель, то для чего делается итоговый результат всех команд, а не конкретной команды и каким этот результат в принципе должен быть.
И потребуются большие усилия на то, чтобы "срастить" это все воедино.
Как и любая модель Team Topologies требует понимания своей сути и того, как ее "натягивание" на ваши текущие процессы/задачи повлияет в конечном итоге на результаты вашей работы.
Вспомните популярное некоторое время назад "натягивание" spotify-культуры, из той же оперы.

И вот наткнулся на эту статью, которая подпитывает мои сомнения и намекает про необходимость "думать самим".

Stop Team Topologies. Reevaluating Team Topologies: A Critical Perspective on Organizational Strategies

ЗЫ в конце статьи хороший список базвордов/"законов"/"паттернов" по теме процессов организации людей

#процессы

Немного циферок про ЗП на основе вилок из вакансий Getmatch.
Детали про наполнение в комменте

#зп

У кого было?
пятничные #it_memes

Exploring the relationship between Tech Lead and Engineering Manager
...

The simplest way to put it is to consider the Tech Lead an extension of the Engineering Manager's bandwidth rather than as a profile that has complementary skills and responsibilities.

As such, the responsibilities that the Engineering Manager will share — or delegate — with the Tech Lead will vary depending on the team context: its composition, challenges, priorities, gaps, etc.

In turn, the Tech Lead will extend the capacity of the Engineering Manager:
• Propose improvements in the technical platform.
• Lead the delivery of a specific project.
• Operate as the primary technical interface on a project involving multiple teams.

#management

Try replacing "we can't because..." with "we can't until..." and then "we can when..."

(c)KentBeck 2015
чужие #мысли_вслух #классика

Тут блогу на днях исполнилось 13 годиков.
SEO конечно смешная штука, но радует, что действительно полезные заметки тоже фигурируют в верхних строчках статистики (в комментах закину).

#байки

... my testing expertise became less valuable at the end of the cycle and much more valuable at the start.

The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end because less bugs would emerge as a result.
...
I’ve had a lot of discussions this year around the role of the tester. Let’s put that aside from now and start thinking about the role of a software developer.
A software developer needs to be able build a product with confidence that it does what it’s expected to do.
Knowing how to do that at a basic level should be critical to the role of a good software developer.
For that reason, we need more testing in software development. And it needs to be done by the people building the product.

Forget developers in test, we need testers in development (2013)

#testing #quality

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

ЗЫ одно из последний обострений было запротоколировано тут. Вчера после вечернего поста, вспомнив про высоты столбиков, в очередной раз подумал, что отчеты по багам и тестировщики - это неразделяемая история. Одно без другого просто не живет.

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

Понимаю, что далеко не весь контент в канале прям всем полезен и сходу применим (вопросов нет только к #it_memes). Много философии и древних баек.
Но кто вам это еще расскажет...

Че-то недавно вспомнилась тут давнишняя мысль:
"Если вам больше 38 и вы работаете в найме не совсем топом, то в ближайшие годы у вас случится босс много младше вас".

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

У меня это произошло давно, поэтому никакой особой рефлексии уже нет, и даже не помню была ли.

Помню лишь, что "много младше" в какой-то момент "стабилизируется" и дальше младше не становится :)

В общем это не страшно.

Но если че, то подумайте, может пора шевелить извилинами и/или локтями активнее.

#it_философия #байки

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

не совсем #it_memes но #байки и #ваши_вопросы

Когда вы работаете над MVP старайтесь больше думать над "ценным", а не фокусироваться на "минимальном".

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

"Решаем проблему, а не человека".

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

И вот именно это и есть настоящая проблема.

Вот такая вот смысловая загогулина.

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

Наткнулся тут на статью "When engineers become managers: How to be a great technical leader".
Прочитал пару раз, гоняя в голове стада радужных единорожек.
В целом умного-нового-ничего, скорее спорил с самим собой по некоторым моментам.

Но пост не про это :)

С радостью и интересом наткнулся на фразу в конце "Now, it is important to draw a distinction between optimism and Pollyannaism."

Господь, полез гуглить "поллианизм". Оказалось, если совсем просто, это умение находить пользу/радость даже в самой большой куче 💩
Шикарно, теперь знаю новое слово и я - поллианист, нашел пользу в банальной статье 😃

PS кстати, список литературы там посмотрите, действительно хорош.

#management