Ролевая блокада
Чтение очередной главы учебника пролило свет на грубейшую ошибку в карьере.
В Южной Корее работал на должности называлась Technical Consultant. Ее так же часто называют Technical Account Manager или Technical Sales. В компании эта должность подразумевала выраженную предпринимательскую роль с оглядкой на инженерную и менеджерскую. Необходимо обслуживать и понимать технические запросы клиента и иногда руководить отдельными распределенными командами для запуска проектов соответственно.
Клиентом занимался, но крайне мало. Большую часть времени занимали инженерные задачи, которыми не занимались разработчики. Даже не так. Которые не попадали в backlog к разработчикам. То есть по факту исполнял инженерную роль. Естественно, перекос моей роли и должности сказывался и на окружении - у них тоже был перекос.
Такое положение дел не устраивало, требовал внимания коллег и просил изменить ситуацию. Коллеги кивали головой, но ничего не происходило по той причине, что они прекрасно себя чувствовали в своих ролях. Иными словами, их ролевые интересы были удовлетворены, пусть даже при несоответствии ролей и должностей.
Проблема заключалась в том, что я охотно принимал на себя задачи инженерной роли. Люблю программировать и делать новое, чем и занимался. Эти задачи приносили ощущения удовлетворения и выполненной работы.
Также не умел различать себя и мою роль с должностью. Отсутствовало понимание, наличие навыка не обязывает применять его в ролях на работе. Например, умею делать презентации, но роли этого не требовали.
Следовало как минимум отказаться выполнять работу, не соответствующую ролям должности. Удовлетворение программированием вынести в другие проекты - в личные или фриланс, чтобы не фонило на работе. В качестве радикального решения - перейти в разработчики.
Рад, что появилось не только понимание произошедшего, но и язык, чтобы произошедшее описать. А значит и возможность увидеть такое в будущем.