Na verdade, eu vi o que acontece quando um "gerente técnico" se envolve demais na mecânica do dia-a-dia de um projeto, e isso não é bonito. No nosso caso, o gerente em questão não era o scrum master, mas estava tentando cooptar algumas dessas decisões; se não tivéssemos um scrum master separado para defender, seria muito mais doloroso.
(Aliás, esse não era meu gerente, então me sinto bastante objetivo nesse ponto.)
Analisarei o que via como os principais conflitos de interesse; se você acha que nada disso se aplica à sua situação, talvez você possa fazer as duas coisas. Mas verifique novamente essas suposições regularmente para garantir que você não caia em nenhuma dessas armadilhas:
Os gerentes técnicos geralmente são responsáveis por uma determinada função em várias equipes. Se é apenas uma equipe, é mais uma "liderança" do que um "gerente". Essa disseminação de responsabilidade significa menos tempo com a equipe e menos tempo com o projeto / produto e tende a levar ao gerenciamento de estilo "bater e correr".
Os gerentes técnicos têm muitos outros deveres gerenciais para os negócios. Eles precisam fazer coaching / treinamento, análises de desempenho, entrevistas / contratação, planejamento de infraestrutura / recursos a longo prazo e muito mais. Isso pode facilmente se tornar um trabalho de tempo integral por si só e significa muito pouco para gastar na facilitação.
Uma agenda cheia também pode se impor à equipe; os gerentes técnicos podem precisar (ou querer) levar os membros da equipe para as reuniões no que a equipe considera um momento inoportuno. Normalmente, é tarefa do mestre de scrum gerenciar e tentar eliminar interrupções, mas é impossível ser objetivo quando você tem seu próprio cronograma para se preocupar. Os mestres do Scrum raramente precisam se reunir separadamente com os membros da equipe, porque todas essas reuniões já estão pré-agendadas (levantamentos, retrospectivas etc.)
Os gerentes técnicos devem lidar com as questões transversais do projeto e seu impulso natural será tentar padronizar tudo - bibliotecas, controle de fonte, algoritmos, layouts, cores, o que for. Embora isso possa realmente ser uma coisa boa para a empresa, em última análise, não deixa ninguém ir atrás do que a equipe quer fazer, e eles podem ter boas razões para querer fazer algo diferente. Isso contraria os ideais de "melhoria contínua" subjacentes ao Scrum e metodologias similares.
Os gerentes provenientes de uma experiência especializada no papel que gerenciam terão suas próprias idéias bastante fortes sobre como o trabalho deve ser feito e quanto tempo deve levar. Isso não é uma coisa ruim como gerente , mas como um mestre de scrum geralmente significa influenciar os membros da equipe em projetos ou estimativas com os quais eles não concordariam - e provavelmente sabem mais do que você sobre o problema em questão.
Os membros da equipe sempre terão problemas para diferenciar entre uma solicitação e um pedido. Eles não lhe dirão isso e podem nem perceber. Mesmo se você deixar claro que está apenas perguntando e não dizendo, na mente deles, você ainda é o gerente deles e há riscos no nível de carreira em dizer "não". Este é provavelmente o mais insidioso de todos os problemas, porque não há nada que você possa fazer sobre isso - é a atitude deles e não a sua que importa.
Se você tem certeza de que nunca vai cair em nenhuma dessas armadilhas, então faça isso ... mas repito, certifique-se de validar frequentemente suas suposições conversando com sua equipe (e outras equipes / gerentes!) e verifique se eles não estão acontecendo de maneira sutil ou inconsciente que talvez você não perceba.
Em uma nota positiva, acrescentarei que o fato de você considerar o problema importante o suficiente para realmente fazer a pergunta significa que você provavelmente é muito bom em ambas as funções. Preocupar-se com a equipe e não apenas com suas próprias ambições de carreira provavelmente responde por mais da metade do que é uma boa administração, de qualquer forma, nos meus livros.
... mas ser bom nos dois não significa necessariamente que você pode ser bom nos dois ao mesmo tempo, o tempo todo . Tenha cuidado com isso.