Я сторонник строить максимально самостоятельные команды. Компетенции, которые часто нужны для достижения целей команды имеются внутри команды. Например: бэкенд, фронт, тестирование, если говорить про разработку программного обеспечения.
Базовый принцип для команд: все вопросы, которые способна эффективно решить сама команда, решаются силами команды.
Этот принцип основан на соображениях:
1) команда обладает большей частью информации для решения своих вопросов;
2) команда свои вопросы решит быстрее и качественнее, т.к. именно она заинтересована в их решении в разумные сроки и в надлежащем качестве.
Примеры
Пример 1.
У сотрудника команды форс-мажорная ситуация, ему завтра необходимо явиться на прием к врачу, он вынужден отсутствовать на работе весь день или частично. Этот вопрос решается внутри команды! Остальное - детали, которые решает сама команда: информирование, адаптация рабочего процесса под сложившуюся ситуацию и т.д. У команды есть компетенции и ответственные люди, способные решать вопросы.
Пример 2.
Команда получила дашборды мониторинга ПРОД-среды. Команда не имеет права занимать ресурсы кого бы то ни было для решения вопросов, связанных с деталями, которые можно получить из имеющегося мониторинга. Команда имеет доступ к дашборду, и может сама проанализировать состояние ПРОД среды.
Пример 3.
Для общения с другими департаментами команде необходимо было получить схемы взаимодействия своих сервисов со внешними. Было два варианта:
1) обратиться к архитекторам;
2) самостоятельно изобразить необходимые схемы.
Был выбран путь 2 - "самостоятельно изобразить необходимые схемы". Профит, который команда получила от этого решения:
1) Максимально быстро получены диаграммы - значит команда сама компетентна судить о том, с чем работает. Если бы был выбран 1й путь - "через архитекторов", то было бы потрачено время на введение в курс архитекторов, а затем были бы бесчисленные созвоны и переписки с исправлениями диаграмм.
2) Команда не тратит время на разъяснение архитектуры сторонним людям.
3) Качество диаграмм - диаграммы соответствуют реальности и их актуальность поддерживается, т.к. сам сотрудник команды ее изображал и способен уловить момент, когда возникают изменения, которые нужно внести на диаграмму.
Это пример, когда вопрос лучше решить силами команды, чем привлекать сторонних лиц.
Все 3 примера - частные случаи. Могут возникнуть исключения. Например, надо изобразить UML диаграмму, которую команда обязана предоставить внешней стороне. В этом случае разумнее обратиться к архитекторам (если в команде нет спеца по UML), т.к. так быстрее и ресурсно-экономнее.
Аналогично вопросы выделения виртуальных машин, замена ноутбука, - все решается силами команды, если процесс отточен и известен. Если процесс неизвестен, то решается через руководителя (руководитель направления - "чаптер-лидер", руководитель отдела разработки, CTO - в соответствии с указанной последовательностью, согласно иерархии управления). Если для какого-то вопроса не достаточно имеющихся данных, компетенций или чего-то еще, тогда привлекаются люди, компетентные в вопросе (все сотрудники компании). Но инициатор и первичное решение, проработка, исключительно на команде.
Если команда не имеет ресурсов для решения конкретного вопроса - это поднимается до руководителя.