Você mede a maturidade de um profissional de TI por dimensão: sete no total, três universais e quatro específicas da função, cada uma com nota de 1 a 5 pela escala Dreyfus. A dimensão com a nota mais baixa mostra onde a carreira travou, e o tempo de carteira fica fora da conta.
Esse é o método do capítulo 2 do meu livro Maturidade em TI. Boa parte da minha carreira eu medi errado, pelo cargo e pelo número de linguagens no currículo. A régua abaixo é o que sobrou depois de testar em mim, nos times que liderei e nas pessoas que mentorei.
Por que anos de experiência não medem maturidade?
O mercado ainda contrata e promove como em 1998: tempo de carteira, certificação, último cargo no LinkedIn. Essa régua erra para os dois lados.
Eu já tive no mesmo time dois devs com a mesma stack, a mesma faculdade e o mesmo cargo entregando valores muito distantes. Já entrevistei gente com dez anos de casa que ainda esperava alguém dizer o que fazer, e gente com dois anos pronta para virar tech lead. O que separava os dois grupos era simples: um sabia em qual dimensão estava fraco e atacava; o outro esperava a senioridade chegar por antiguidade.
Ela não chega. Ano de carteira registra quanto tempo você ficou sentado. A pergunta que interessa é o que você virou nesse tempo.
Quais são as 7 dimensões da maturidade em TI?
Toda função técnica se decompõe em sete dimensões mensuráveis.
As três universais, iguais para dev, QA, DevOps, PM, designer ou gestor:
- Comunicação e Influência (U1). Adaptar a linguagem para quem ouve, dar visibilidade ao que entrega e mover decisão sem ter cargo.
- Visão de Produto e Negócio (U2). Saber por que a tarefa existe, ler métrica e questionar prioridade com argumento.
- Gestão de Carreira (U3). Ter plano escrito, clareza do próximo nível e assumir a própria evolução.
As quatro específicas mudam com o papel. Para quem desenvolve: domínio técnico, arquitetura e design, entrega e qualidade, liderança técnica. Para DevOps: infraestrutura e automação, confiabilidade e observabilidade, segurança, escalabilidade. Para engineering manager, a quarta é calibração técnica, porque gestor que não lê código nem senta em decisão de arquitetura perde autoridade técnica e fica só com o crachá.
Eu não inventei essas dimensões. Sou autodidata, estudei os frameworks que já tinham prova de campo (T-Shaped de Tim Brown, Jobs to Be Done de Clayton Christensen, Engineering Ladders de Jorge Fioranelli, os arquétipos de Staff de Will Larson, entre outros), apliquei pedaços nos times e mantive o que funcionava. A lista é curadoria testada em operação, com o crédito de cada fonte no livro.
Repare que as três universais aparecem para todo mundo. Na minha leitura de campo, é nelas que a maioria trava, e é por elas que você vai ser avaliado na próxima entrevista, qualquer que seja a stack.
Como dar nota de 1 a 5 em cada dimensão?
A escala vem do modelo de Stuart e Hubert Dreyfus, da Universidade da Califórnia em Berkeley (1980), usado para classificar habilidade em medicina, enfermagem e engenharia. Adaptei para TI assim:
| Nota | Nível | Como você opera |
|---|---|---|
| 1 | Iniciante | Segue regra e precisa de instrução para cada passo |
| 2 | Competente | Junta peças, mas depende de checklist em contexto novo |
| 3 | Proficiente | Resolve sozinho dentro do conhecido, com julgamento |
| 4 | Experiente | Antecipa problema, cria heurística própria, mentora |
| 5 | Especialista | Define o padrão que o time segue |
Para cada dimensão, pense numa situação concreta da última semana. Na U1, por exemplo, lembre a última reunião em que você precisou defender uma decisão. Você seguiu roteiro, improvisou com base em princípio ou previu o que ia acontecer? A resposta classifica.
Uma regra que eu cobro de todo mentorado: ficou entre 2 e 3, marca 2. Todo mundo infla a própria nota. “Maturidade é admitir piso, não pintar teto.”
Como fica um diagnóstico real?
Júlia (nome trocado, números reais, com permissão dela) era dev pleno havia três anos, com React, Node e Postgres em dia e entregas no prazo. Estava parada havia 18 meses no mesmo nível e no mesmo salário. Convencida de que faltava técnica, comprou três cursos de arquitetura e dois de TypeScript avançado. Continuou parada.
O radar dela contou outra história: domínio técnico em 4, arquitetura e entrega em 3. Comunicação, gestão de carreira e liderança técnica, todas em 1. Ela não comunicava o impacto do que entregava, não tinha plano de carreira e nunca tinha mentorado ninguém. Para a empresa, era “uma dev que entrega”, coisa que um pleno faz sem esforço.
Em 90 dias, sem curso novo, ela fez três coisas:
- Passou a mandar, toda sprint, três linhas no canal do time com o resultado para o negócio do que tinha entregado. Em seis sprints virou referência no canal.
- Escreveu num sábado de manhã um plano de uma página (onde estou, onde quero estar em 12 meses, três evidências por trimestre) e levou ao 1:1. O gestor enxergou, pela primeira vez em 18 meses, que ela queria crescer.
- Ofereceu 30 minutos semanais de pair programming a uma júnior recém-chegada e documentou as decisões das sessões.
Foi promovida a sênior no ciclo seguinte, cerca de nove meses depois do diagnóstico. A técnica dela não mudou nada nesse período. Como escrevi no livro, “o radar não mente. O profissional, sim. Pra si mesmo.”
Que padrões aparecem no radar?
Quando você plota as sete notas, três desenhos se repetem:
O técnico isolado. Específicas entre 3 e 4, universais entre 1 e 2. É o caso da Júlia. Ataque a U1 antes de qualquer outra coisa, porque comunicação destrava o resto.
O comunicador raso. Universais altas, específicas baixas. Fala bem em reunião e entrega pouco. Esse perfil vira “aquele que fala muito” e perde a confiança do time rápido. Passe 90 dias focado na primeira dimensão técnica da sua função antes de aceitar mais palco.
O equilibrado mediano. Tudo entre 2 e 3. O mercado não paga sênior para quem é competente em tudo e bom em nada. Escolha uma dimensão e leve até 4 em seis meses, porque escassez é o que o mercado paga.
Se você está em transição de função, de dev para PM por exemplo, diagnostique no papel que ocupa hoje. No papel novo você vai tirar 1 em tudo e travar.
Como medir a evolução sem se enganar?
Diagnóstico que ninguém reabre vira promessa de ano novo. Três regras:
- Reavalie a cada trimestre. Refaça o radar inteiro a cada três meses.
- Mova uma dimensão por vez. A meta é subir uma dimensão um nível inteiro por trimestre. Quem tenta três ao mesmo tempo não sobe nenhuma.
- Anote a evidência. “Acho que melhorei” não vale. “Fiz code review de arquitetura em quatro PRs e o time aceitou as sugestões” vale.
Depois do radar, faça a si mesmo três perguntas duras: qual é a sua dimensão mais baixa, há quantos meses ela está lá, e por que você não está atacando ela agora. Se travou na terceira, o problema é prioridade. Você teve tempo de maratonar série essa semana.
E se eu sou gestor e não sou técnico?
Você não preenche as sete dimensões, e a pergunta continua sendo sua. Responda seis coisas sobre o seu time: quanto ele entrega, como funciona o processo de desenvolvimento, qual é o caminho de uma demanda do pedido até a entrega, quanto você gasta em tecnologia e o que recebe por isso, com base em que a empresa se diz ágil, e qual é a maturidade das pessoas que trabalham para você.
Conte os “não sei”. Cada um é uma decisão tomada sem você, todo mês, com o seu dinheiro.
Onde ir a partir daqui
Separe quinze minutos ainda esta semana, com papel e caneta, e dê as sete notas. Marque na agenda a reavaliação para daqui a 90 dias, no mesmo dia em que fizer a primeira.
O capítulo 2 de Maturidade em TI traz a tabela das quatro dimensões específicas para nove funções, o roteiro do autodiagnóstico e os frameworks com fonte; os capítulos seguintes aprofundam uma dimensão por vez.
Baixe os 22 templates do livro e comece com o material que eu uso com os meus mentorados.