Modelo de escada de carreira

Modelo de escada de carreira para engenheiros de software

Cinco níveis, de júnior a Principal, em seis competências: da entrega de código ao desenvolvimento da equipa.

Plano gratuito · Sem cartão de crédito

Esta escada de carreira foi escrita para empresas de produto com cerca de 20 a 200 pessoas: os engenheiros desenvolvem funcionalidades de ponta a ponta, as equipas são pequenas e ninguém nos recursos humanos está a desenhar uma arquitetura de funções. Descreve cinco níveis, desde alguém em início de carreira até quem define a direção técnica de toda a empresa. O nível mais alto, Principal Engineer, pertence ao percurso de especialista; a gestão de engenheiros tem uma escada própria, a de Engineering Manager.

Cada nível é definido pelo que a pessoa faz, não pelos anos de experiência. Leia uma linha da matriz de competências da esquerda para a direita para ver como uma expectativa evolui; leia a secção de um nível para ver tudo o que se espera nesse nível. Use-a para explicar o que significa o nível seguinte, para estruturar autoavaliações e check-ins e para tornar comparáveis as propostas de promoção de equipas diferentes.

Encare-a como um ponto de partida. Mude o nome dos níveis para corresponderem aos seus cargos, junte ou retire as competências que não se adequam à sua empresa e reescreva as expectativas por palavras suas antes de publicar a escada para a equipa.

Os níveis num relance

Engenheiro júnior
Aprende a base de código e entrega tarefas bem definidas com orientação.
Âmbito
Tarefas individuais numa área do produto, normalmente divididas por alguém com mais experiência.
Engenheiro
Entrega funcionalidades de forma autónoma e é um membro fiável da equipa.
Âmbito
Funcionalidades pequenas e médias na área de uma equipa, desde uma breve nota de design até à produção.
Engenheiro sénior
Lidera trabalhos de maior dimensão e eleva a fasquia da equipa à sua volta.
Âmbito
Projetos que envolvem vários serviços ou várias pessoas, e as decisões técnicas de uma equipa.
Staff Engineer
Resolve problemas que atravessam as fronteiras entre equipas e orienta decisões técnicas para lá de uma só equipa.
Âmbito
Várias equipas ou toda uma área de produto, incluindo problemas que nenhuma equipa assume sozinha.
Principal Engineer
Define a direção técnica da empresa e responde pela sua saúde técnica a longo prazo.
Âmbito
Toda a organização de engenharia e a estratégia técnica da empresa para os próximos anos.

Matriz de competências

Cada linha é uma competência e cada coluna um nível. Leia uma linha da esquerda para a direita para ver como a expectativa cresce.

O que significa cada competência

Entrega técnica: Transformar requisitos em software funcional e fácil de manter, e fazê-lo chegar aos utilizadores.
Design de sistemas: Escolher estruturas, interfaces e compromissos que aguentem o crescimento do produto.
Qualidade e fiabilidade: Manter o produto correto, observável e disponível, e aprender com as falhas.
Colaboração e comunicação: Trabalhar bem com outros engenheiros, com produto e design e com o resto do negócio.
Responsabilidade e impacto no produto: Perceber porque é que o trabalho importa e assumir a responsabilidade pelos resultados, não só pelas tarefas.
Mentoria e desenvolvimento da equipa: Ajudar os outros a melhorar e tornar a equipa mais forte do que qualquer pessoa que dela faça parte.

Engenheiro de software: expectativas por competência e nível
Competência	Engenheiro júnior	Engenheiro	Engenheiro sénior	Staff Engineer	Principal Engineer
Entrega técnica	Conclui tarefas bem delimitadas com código legível e testes, pede ajuda ao fim de algumas horas bloqueado e não de alguns dias, e trata os comentários da revisão antes do merge.	Leva uma funcionalidade de uma breve nota de design até à produção sem acompanhamento constante, divide-a em pull requests fáceis de rever e dá estimativas realistas para trabalho que conhece.	Entrega projetos que envolvem vários serviços ou várias pessoas, organiza o trabalho para que algo útil chegue cedo à produção e elimina riscos antes de bloquearem a equipa.	Desbloqueia a entrega entre equipas: desfaz dependências partilhadas, cria as ferramentas ou conduz as migrações de que várias equipas precisam e mantém no rumo os projetos que envolvem várias equipas.	Molda a forma como toda a organização entrega — práticas de release, escolhas de plataforma, ferramentas de build e deploy — para que todas as equipas entreguem mais depressa e com mais segurança.
Design de sistemas	Segue os padrões existentes na base de código e consegue explicar porque é que o código que alterou está estruturado dessa forma.	Desenha componentes dentro de um serviço existente, escreve uma breve nota de design para alterações não triviais e compara pelo menos duas opções antes de escolher uma.	Lidera o design de funcionalidades que envolvem vários serviços, documenta os compromissos para que outros os revejam e revê de forma construtiva o design de outros engenheiros.	Define a arquitetura para lá das fronteiras entre equipas — modelos de dados partilhados, contratos entre serviços, decisões de construir ou comprar — e antecipa como o sistema terá de mudar no próximo ano ou dois.	É responsável pela estratégia técnica da empresa: em que tecnologias apostar, quais abandonar e como a arquitetura deve evoluir com o negócio ao longo de vários anos.
Qualidade e fiabilidade	Escreve testes para as próprias alterações, verifica o trabalho antes de o lançar e corrige bugs no código em que mexeu.	Acrescenta monitorização e alertas às funcionalidades que desenvolve, faz parte da escala de piquete e resolve incidentes de rotina seguindo o runbook.	Lidera a resposta a incidentes nos sistemas da equipa, escreve post-mortems sem atribuição de culpas e garante que as ações de seguimento são mesmo concluídas.	Identifica riscos de fiabilidade e segurança que atravessam vários sistemas, define normas como a estratégia de testes e os objetivos de nível de serviço, e impulsiona as correções entre equipas.	Define o que significam fiabilidade, segurança e qualidade para a empresa, equilibra-as com a velocidade junto da equipa de liderança e é o último ponto de escalamento nos incidentes mais difíceis.
Colaboração e comunicação	Partilha abertamente o progresso e os bloqueios, e faz perguntas claras quando um requisito é ambíguo.	Trabalha diretamente com produto e design para clarificar requisitos, explica restrições técnicas em linguagem simples e escreve descrições de pull requests que os revisores conseguem acompanhar.	Representa a equipa no planeamento, negoceia âmbito e compromissos com produto e escreve documentos que pessoas de fora da engenharia percebem.	Alinha várias equipas e áreas em torno de um plano técnico, resolve desacordos entre equipas e explica o risco técnico à liderança.	É uma voz de confiança nas decisões ao nível da empresa, traduz a estratégia de negócio em direção técnica e vice-versa, e representa a engenharia perante clientes, parceiros ou investidores quando necessário.
Responsabilidade e impacto no produto	Percebe o propósito das suas tarefas, verifica se o que lançou funciona para os utilizadores e acompanha o assunto até funcionar.	Assume uma funcionalidade depois do lançamento: acompanha a utilização e os erros, corrige o que corre mal e sugere melhorias com base no que aprende.	É responsável de ponta a ponta por uma área do produto, questiona requisitos que não servem os utilizadores e propõe trabalho que faz avançar os objetivos da equipa.	Encontra os problemas de maior impacto numa área de produto — incluindo os que nenhuma equipa assumiu — e garante que são resolvidos.	Liga o investimento em engenharia aos resultados da empresa e defende ou contesta grandes apostas com base no seu impacto técnico e de negócio.
Mentoria e desenvolvimento da equipa	Pede feedback e põe-no em prática, e regista o que aprendeu para que o próximo recém-chegado tenha um início mais fácil.	Faz revisões de código cuidadosas, ajuda a integrar novos colegas e trabalha em par com engenheiros juniores em partes do código que não conhecem.	Faz mentoria deliberada a um ou dois engenheiros, dá feedback que os ajuda a chegar ao nível seguinte e participa em entrevistas de recrutamento.	Desenvolve engenheiros seniores de várias equipas, molda o processo de entrevistas e as práticas de engenharia, e é procurado pelos outros para pedir conselho.	Constrói a cultura técnica da empresa — como se tomam decisões e como se partilha conhecimento — e desenvolve a próxima geração de Staff Engineers.

Deslize a tabela para o lado para ver todos os níveis.

Descarregar em CSV Abre no Excel, no Google Sheets ou no Numbers.

Engenheiro júnior: o que se espera

Aprende a base de código e entrega tarefas bem definidas com orientação. Tarefas individuais numa área do produto, normalmente divididas por alguém com mais experiência.

Entrega técnica: Conclui tarefas bem delimitadas com código legível e testes, pede ajuda ao fim de algumas horas bloqueado e não de alguns dias, e trata os comentários da revisão antes do merge.
Design de sistemas: Segue os padrões existentes na base de código e consegue explicar porque é que o código que alterou está estruturado dessa forma.
Qualidade e fiabilidade: Escreve testes para as próprias alterações, verifica o trabalho antes de o lançar e corrige bugs no código em que mexeu.
Colaboração e comunicação: Partilha abertamente o progresso e os bloqueios, e faz perguntas claras quando um requisito é ambíguo.
Responsabilidade e impacto no produto: Percebe o propósito das suas tarefas, verifica se o que lançou funciona para os utilizadores e acompanha o assunto até funcionar.
Mentoria e desenvolvimento da equipa: Pede feedback e põe-no em prática, e regista o que aprendeu para que o próximo recém-chegado tenha um início mais fácil.

Engenheiro: o que se espera

Entrega funcionalidades de forma autónoma e é um membro fiável da equipa. Funcionalidades pequenas e médias na área de uma equipa, desde uma breve nota de design até à produção.

Entrega técnica: Leva uma funcionalidade de uma breve nota de design até à produção sem acompanhamento constante, divide-a em pull requests fáceis de rever e dá estimativas realistas para trabalho que conhece.
Design de sistemas: Desenha componentes dentro de um serviço existente, escreve uma breve nota de design para alterações não triviais e compara pelo menos duas opções antes de escolher uma.
Qualidade e fiabilidade: Acrescenta monitorização e alertas às funcionalidades que desenvolve, faz parte da escala de piquete e resolve incidentes de rotina seguindo o runbook.
Colaboração e comunicação: Trabalha diretamente com produto e design para clarificar requisitos, explica restrições técnicas em linguagem simples e escreve descrições de pull requests que os revisores conseguem acompanhar.
Responsabilidade e impacto no produto: Assume uma funcionalidade depois do lançamento: acompanha a utilização e os erros, corrige o que corre mal e sugere melhorias com base no que aprende.
Mentoria e desenvolvimento da equipa: Faz revisões de código cuidadosas, ajuda a integrar novos colegas e trabalha em par com engenheiros juniores em partes do código que não conhecem.

Engenheiro sénior: o que se espera

Lidera trabalhos de maior dimensão e eleva a fasquia da equipa à sua volta. Projetos que envolvem vários serviços ou várias pessoas, e as decisões técnicas de uma equipa.

Entrega técnica: Entrega projetos que envolvem vários serviços ou várias pessoas, organiza o trabalho para que algo útil chegue cedo à produção e elimina riscos antes de bloquearem a equipa.
Design de sistemas: Lidera o design de funcionalidades que envolvem vários serviços, documenta os compromissos para que outros os revejam e revê de forma construtiva o design de outros engenheiros.
Qualidade e fiabilidade: Lidera a resposta a incidentes nos sistemas da equipa, escreve post-mortems sem atribuição de culpas e garante que as ações de seguimento são mesmo concluídas.
Colaboração e comunicação: Representa a equipa no planeamento, negoceia âmbito e compromissos com produto e escreve documentos que pessoas de fora da engenharia percebem.
Responsabilidade e impacto no produto: É responsável de ponta a ponta por uma área do produto, questiona requisitos que não servem os utilizadores e propõe trabalho que faz avançar os objetivos da equipa.
Mentoria e desenvolvimento da equipa: Faz mentoria deliberada a um ou dois engenheiros, dá feedback que os ajuda a chegar ao nível seguinte e participa em entrevistas de recrutamento.

Staff Engineer: o que se espera

Resolve problemas que atravessam as fronteiras entre equipas e orienta decisões técnicas para lá de uma só equipa. Várias equipas ou toda uma área de produto, incluindo problemas que nenhuma equipa assume sozinha.

Entrega técnica: Desbloqueia a entrega entre equipas: desfaz dependências partilhadas, cria as ferramentas ou conduz as migrações de que várias equipas precisam e mantém no rumo os projetos que envolvem várias equipas.
Design de sistemas: Define a arquitetura para lá das fronteiras entre equipas — modelos de dados partilhados, contratos entre serviços, decisões de construir ou comprar — e antecipa como o sistema terá de mudar no próximo ano ou dois.
Qualidade e fiabilidade: Identifica riscos de fiabilidade e segurança que atravessam vários sistemas, define normas como a estratégia de testes e os objetivos de nível de serviço, e impulsiona as correções entre equipas.
Colaboração e comunicação: Alinha várias equipas e áreas em torno de um plano técnico, resolve desacordos entre equipas e explica o risco técnico à liderança.
Responsabilidade e impacto no produto: Encontra os problemas de maior impacto numa área de produto — incluindo os que nenhuma equipa assumiu — e garante que são resolvidos.
Mentoria e desenvolvimento da equipa: Desenvolve engenheiros seniores de várias equipas, molda o processo de entrevistas e as práticas de engenharia, e é procurado pelos outros para pedir conselho.

Principal Engineer: o que se espera

Define a direção técnica da empresa e responde pela sua saúde técnica a longo prazo. Toda a organização de engenharia e a estratégia técnica da empresa para os próximos anos.

Entrega técnica: Molda a forma como toda a organização entrega — práticas de release, escolhas de plataforma, ferramentas de build e deploy — para que todas as equipas entreguem mais depressa e com mais segurança.
Design de sistemas: É responsável pela estratégia técnica da empresa: em que tecnologias apostar, quais abandonar e como a arquitetura deve evoluir com o negócio ao longo de vários anos.
Qualidade e fiabilidade: Define o que significam fiabilidade, segurança e qualidade para a empresa, equilibra-as com a velocidade junto da equipa de liderança e é o último ponto de escalamento nos incidentes mais difíceis.
Colaboração e comunicação: É uma voz de confiança nas decisões ao nível da empresa, traduz a estratégia de negócio em direção técnica e vice-versa, e representa a engenharia perante clientes, parceiros ou investidores quando necessário.
Responsabilidade e impacto no produto: Liga o investimento em engenharia aos resultados da empresa e defende ou contesta grandes apostas com base no seu impacto técnico e de negócio.
Mentoria e desenvolvimento da equipa: Constrói a cultura técnica da empresa — como se tomam decisões e como se partilha conhecimento — e desenvolve a próxima geração de Staff Engineers.

Como adaptar esta escada

Faça corresponder os níveis aos seus cargos
Se os seus cargos forem Developer I, II e III, mude o nome dos níveis, mas mantenha um nível para cada salto real de âmbito. A maioria das empresas com menos de 100 engenheiros ainda não precisa de um nível Principal: deixe-o de fora até alguém estar de facto a fazer esse trabalho.
Fique por cinco a sete competências
Com mais de sete, ninguém as lê; com menos de quatro, pessoas muito diferentes parecem iguais. Junte as competências que avalia sempre em conjunto e só acrescente uma quando isso mudar uma decisão real.
Reescreva as expectativas como comportamentos observáveis
Para cada célula, pergunte se um gestor conseguiria apontar um exemplo dos últimos seis meses. Substitua palavras como «forte» ou «profundo» pelo que a pessoa realmente faz, como «lidera a resposta a incidentes nos serviços da equipa».
Teste-a com pessoas reais antes de a publicar
Peça a dois ou três gestores que posicionem os membros das suas equipas no rascunho. Onde discordarem, a redação é ambígua: corrija-a, publique a escada e combine revê-la daqui a seis meses.

Perguntas frequentes

Perguntas sobre esta escada

Quantos níveis deve ter uma escada de carreira de engenheiro de software?

Quatro a seis é o habitual numa empresa de 20 a 200 pessoas. Com menos, as promoções tornam-se raras e enormes; com mais, a diferença entre dois níveis é demasiado pequena para se descrever. Este modelo usa cinco: Engenheiro júnior, Engenheiro, Sénior, Staff e Principal.

Os engenheiros têm de passar a gestores para crescer na carreira?

Não. Esta é uma escada do percurso de especialista: os Staff e Principal Engineers crescem em âmbito e influência sem gerir pessoas. Use-a em conjunto com a escada de Engineering Manager, para que passar à gestão seja uma mudança de percurso e não uma promoção.

Como usar a escada de engenharia nas decisões de promoção?

Promova quem já trabalha de forma consistente no nível seguinte, não quem talvez o venha a fazer. Peça à pessoa e ao seu gestor que reúnam exemplos concretos para cada competência do nível pretendido e compare todos os casos com a mesma matriz, para que as decisões se mantenham coerentes entre equipas.

Como se encaixa a escada nos check-ins e nas reuniões 1:1?

Use-a como agenda dos check-ins regulares: a pessoa avalia-se face ao seu nível atual, o gestor faz o mesmo, e as diferenças entre as duas avaliações tornam-se algumas ações de desenvolvimento concretas para os meses seguintes.

Com que frequência se deve atualizar a escada de engenharia?

Reveja-a uma ou duas vezes por ano e sempre que a empresa mudar de forma — por exemplo, quando criar uma equipa de plataforma ou começar a contratar Staff Engineers. Reescreva uma célula sempre que as avaliações tropeçarem repetidamente nela.

Construa esta escada de carreira no LadderKit — grátis

Configure os níveis e as competências para a sua equipa, avalie as pessoas face a eles nos check-ins e mantenha as decisões de promoção coerentes.

Comece grátis Ver a demonstração Sem registo