Исправление - это комплекс мер. Тут надо смотреть, где идет затор, сверху или снизу.
Я обычно делаю так (но я не советую за мной повторять из-за высоких рисков, просто у меня с моим польским характером по другому не получается):
1. На работу выхожу, когда есть минимум два оффера на руках. По второму офферу чистосердечно договариваемся как о резервном. Это важно. Не нужно думать, что если отказаться в последний момент, то удастся сохранить отношения. Если они на вас рассчитывали, то назад уже не примут. Я проверял.
2. На новом месте есть три месяца, чтоб осуществить изменения. Если за три месяца не удалось, то уже вряд ли получится. Нужно менять работу. В РФ это делать болезненно, ибо остается запись в трудовой, поэтому испыталку лучше оформлять по ГПХ. В Европе многие программисты работают как предприниматели, поэтому там проще: не понравилось - ушел, и никому об этом не говоришь просто.
3. На новом месте нужно пустить корни. Провести встречи 1to1 с программистами, понять кто и что из себя представляет. Выбрать костяк, узнать их проблемы, чем-то помочь и заручиться их поддержкой.
На этом этапе многие начинают думать, что нужно выслужиться перед начальством. Бесполезно. Начальство соберет фидбек снизу. Поэтому фундамент должен быть снизу.
4. Важно. В этот момент у многих появляется желание продемонстрировать руководству, что они не ошиблись, наняв вас. И делают это "блеснув своей эрудированностью" на фоне предшественников, мол, система - гавно, и как вам повезло, что меня наняли, чтоб я её оценил и это сказал. Эффект прямо противоположный. Руководство это понимает так, что "ты - лох, тебя все это время разводили на бабло, и теперь благодаря мне все узнают какой ты лох". Один из умнейших спецов, которого я когда-либо знал, продержался всего сутки в компании, куда я его пригласил.
5. Итак, поддержка есть (мы же сформировали костяк, да?). Всегда найдутся недовольные, которые постараются подорвать авторитет неуважительными выходками. Шопенгауэр в помощь. Языком нужно владеть. Деликатно, острослово и пропорционально поставить выскочку на место. Важно не перегнуть и вовремя протянуть руку, когда человек "уже все понял". Обычно после одного-двух прецедентов больше желания ни у кого не возникает - включается внешний конформизм. Но если это сделать до формирования костяка поддержки, то есть риск попасть в опалу. Поэтому всегда нужно взвешивать силы поддержки и силы сопротивления.
6. Внимательно прислушиваемся к среде. Обычно там, где не хватает знаний, возникают конфликты, особенно на Code Review. Разруливаем конфликты путем интервенции знаний, чем зарабатываем авторитет. Пару раз подсказать - потом сами спрашивать начнут.
7. Противоречия между руководителями - это ваш ресурс. Читаем "Дао Лидера" Джона Хейдера, или Дао Де Цзинь в оригинале. Изучаем диалектику во всех её проявлениях. Учимся использовать эти внутренние противоречия для синтеза. Если этого не сделать, то есть риск скатиться в донкихотство. На этом этапе вы из себя силы пока еще не представляете. Поэтому, находим заинтересованные стороны действующих сил. Тонкая политика. Но мы архитекторы, а архитектура - есть суть разрешение противоречий. Если арх умеет их разрешать, ему не важно, это противоречие требований или противоречие между двумя топами.
8. Выявляем проблемы, по принципу Парето определяем с какой проблемы начать. Смело и решительно решаем выбранную проблему. Дерзновенно, твердо, буйно и радостно.
Если решили проблему менее чем за три месяца - ура, кредит доверия оправдан. Если не решили - бывает. Я в госах тоже не смог ничего изменить. Тогда нужно уходить на резервный оффер - дальше будет хуже. Я проверял. Kent Beck изменил индустрию, но не смог ничего изменить в Facebook. А Eric Evans написал свою книгу по DDD в порыве отчаяния, как финальный аккорд.
Если удалось осуществить изменения - тогда в помощь:
https://dckms.github.io/system-architecture/emacsway/soft-skills/change-making.htmlЭто мой собственный алгоритм. У меня это работало. Но это рискованный алгоритм. Я бы сам был бы рад поступать по другому, но не получается.
