
Disponível apenas [em inglês](/en/navigating-the-ic-to-em-transition).

*This article was originally written in May 2022 for one of my favourite publications: Gergely Orosz's [The Pragmatic Engineer](https://newsletter.pragmaticengineer.com/p/navigating-the-individual-contributor). I recommend subscribing for a 30-minute length version of this article and much more.*
_____

When I transitioned to my first formal management role, I remember feeling that I was doing well as an engineer with minimal effort. Work just flowed naturally. I gave folks code pointers sometimes without looking at the codebase. When posed with challenges, I knew how to act and get to the solution. 

The journey from junior engineer to senior engineer feels like a continuum, where your perspective of the work changes with each stage of progression. However, the IC to EM transition means learning an entirely different job. The change starts long before you get the title and takes much longer to complete, afterward.

### Transitioning from IC to EM

In most tech companies, the career progression path in engineering forks at around the senior level into two distinct paths. Once at the senior level, you choose if you'd like to progress in the individual contribution craft, as a staff+ engineer, or the engineering management track. 

There are good reasons why this happens at around the senior level: it becomes ineffective to shift context between solving complex organisational problems and driving deeply technical challenges toward clarity.

It's natural then that senior engineers might feel interested in trying engineering management to progress their careers. But what does it take to make this career transition a success?

Engineering management roles are rarer: you first need enough engineers in a team for a manager to exist. A significant component of being considered for the role once the opportunity arises is showcasing leadership traits as an engineer.

Most of the time, expectations boil down to four dimensions:
- **Technology Strategy:** how this person enables the team to build great technology. How they ensure software being shipped is of high quality, that the team has sound engineering practices, and that there is an underlying tech strategy and vision articulating how the team's systems and architecture will evolve over time.
- **Business Impact:** the impact of the software this team ships, relative to the size of the team. The primary measure is not productivity or throughput, but rather how this team enables the overarching business outcomes and how the EM plays a role in making them happen.
- **Process & Delivery:** how this person organises their team. How well they work and collaborate with external stakeholders, ensure accountability is well defined, risks are flagged in proactive ways, and the team functions sustainably and autonomously.
- **People Management:** how this person empowers the people they support. This is not just what their reports have to say, but how this EM promotes growth, matches people to their strengths and growth paths, hires for gaps in capability, and builds a diverse team that fosters a sense of inclusivity and belonging.

Besides the general expectations, some of the key advice I have to offer are:

**Know how to manage yourself.** While this can sound obvious, it is not an easy task. It's not unusual even for senior leaders to mismanage themselves. Typical examples of mismanaging yourself include: 
- Seeking hard goals, forgetting to pace yourself and burning out as a result.
- Drowning in tactics because of pressure and failing to think longer-term. 
- Focusing on speed of execution, mistaking motion for progress and noise for signal. 
- Learning how to manage yourself is a cornerstone of management and leadership.

**Know how to manage up.** The best reports I ever had made my job easy. Not because they didn't need my guidance and support, but because they held me accountable for what they needed from me.

Managing up is fundamentally doing a part of your boss's work, so it's an excellent way to show aptitude for the role. A good example of managing up is taking ownership of problems in the team and coming up with options and a recommendation, rather than just talking about it. 

**Propose solutions to problems.** When you're a manager, accountability becomes an even higher expectation. As a manager, your accountability spans beyond your direct team; it percolates the overarching organisational culture, hiring, fairness, diversity, belonging and inclusion. Leaving issues aside has a much larger blast radius, impacting other people. Holding yourself and others accountable for resolving problems is another key trait that makes you prepared for the opportunity.

When you spot something that feels wrong, flag it to the accountable party, and beyond that, make a recommendation for a path forward. You may not have the answers, but start the conversation.

**Prioritise hard.** In a high accountability environment, one common trap is trying to solve everything that feels wrong. The issue though is that the more responsibility you are trusted with, the harder it is to get to the bottom of your list of problems. It becomes essential for EMs to prioritize well to avoid hindering the team's ability to focus. These traits are also widely applicable for strong individual contributors; they know what matters most and so focus their energy on that. 

Keep a running list of your priorities and every time something new comes in, add it to the list. This same list can also serve as a way to set expectations with your manager in case you are unsure, plus it gives visibility on what you are not doing – which can sometimes be as important as the things you are doing.

Most importantly, you should ask for what you want. Most of the time, [doing so goes a long way](https://twitter.com/ppyapali/status/1361814049231695878).

The last missing bit is the need for a new EM to step up. It can come through your manager quitting, a restructuring in the organisation, your team growing to a point where your manager has more reports than they can manage, and many other situations. As the stars align – or you align them yourself by convincing your manager you can manage a part of the team – you'll be on your way.

### Stepping up to the role
So the stars align and you are given the opportunity to do the role in the interim. In your first year as an EM, some fundamentals can help you establish yourself.

#### Understand the business
In a company, nothing exists in isolation. Everything serves a broader context. As an engineering leader, to be successful, you and your team need to be aligned with the business. You will not be successful if you jump straight into the tech side without understanding the purpose of the team. A large part of an engineering manager's role is building bridges between the team and the broader context. Only with this context in place can you execute against the goals. 

To build a well-informed opinion, you need two inputs: local context (the team) and global context (the company).

**For local context**, my favourite method is [Boz's career cold start algorithm](https://boz.com/articles/career-cold-start). The method is simple, but works very well: you'll hear stories from different angles that will help you build your own beliefs. You will also begin building the relationships which will enable you to be successful in the role.

**For global context**, spend time reading and catching up on what's happening at the company. This is necessary to understand how the work you and your team does maps to the broader company mission. It also helps you spot opportunities to be impactful. 

The more you understand the business, the better positioned you are to shape its direction. Ways you can shape direction include writing [engineering strategy](https://lethain.com/engineering-strategy/), partnering with product and stakeholders to develop a [consolidated roadmap](https://cutlefish.substack.com/p/tbm-4853-one-roadmap) and defining longer-term [Objectives and Key Results (OKRs)](https://www.whatmatters.com/get-started). 

#### Build strong relationships
Your success in a leadership role largely depends on your ability to build and nurture relationships. This part of the work has to do with how well you can work with others and support and be supported by them:
- **With your manager.** In a healthy environment, your manager is the second most interested party in your success, after only yourself. Asking for help is fundamental to your success. As a new manager, you might assume that now you have to deal with everything yourself. Instead, learn how to use your manager and be okay with being supported by them. 
- **With your peers.** Make your manager's reports your "first team." Do this to avoid the feeling of loneliness that can come with a leadership role. Your manager's reports face similar challenges to yours. They are more likely to have a useful perspective on your challenges.
- **With your cross-functional peers.** Engineering teams are usually part of a broader cross-functional team, with product, data, research, design, operations and other counterparts. As an engineering manager, these partners directly impact the outcomes of your work and your team's work. They are fundamental to your success and your team's success.
- **With your direct reports.** Your team defines the largest portion of your success as a leader. A team is a group of individuals, and your success as a manager comes from building an effective, motivated, and impactful group of people. The way people will get the most from you is by you understanding them as human beings, well beyond their technical skills.

If you don't intentionally invest time in these relationships, they will become strictly transactional. Or worse, the lack of relationships may get in the way of getting work done.

#### Build a well-functioning team

<Quote quote="All happy families are alike; each unhappy family is unhappy in its own way." author="Leo Tolstoy" />

Happy teams share characteristics which are not easy to create but are simple to understand. Here are three qualities that are components of well-functioning teams.

**1. Team composition matches the shape of the work.** Happy teams are staffed with people who do work they like, in the proportions of the shape of the work you have. Some of the dimensions to look into are:
- **Discipline:** % of backend, frontend, data, etc.
- **Seniority:** % of junior, mid-level, senior, staff, etc.
- **Projects’ stage of maturity:** % of projects which are zero-to-one, as in trying something new, vs one-to-hundreds which usually means scaling and optimisation challenges.
- **Type of challenge:** % of time the team is working heavily cross-functionally, with multiple stakeholder teams vs working in isolation and writing code.
- **Desired trajectory:** % of people seeking growth vs people seeking stability in the role.

Second, understand the shape of your team. By shape I mean the strengths, growth areas and development paths of the people you support. How strongly work and team match is a strong predictor of how successful people are in a team, and consequently, how successful you are as their manager.

In an ideal world you want a high-performing team that is motivated 100% of the time by exactly the challenges they're given. In reality, this rarely happens. Learn how to [manage and enable performance](https://www.dballona.com/performance-enablement), even if it means supporting people to find a better fit outside of your team. 

**2. Healthy engineering craft practices.** Engineering managers are functional leaders. You are ultimately accountable for the quality of the software your team builds, even if you might not be writing software yourself.

Periodically running [Likert Scale surveys](https://www.surveymonkey.co.uk/mp/likert-scale/) to take into consideration all team members' opinions about different subjects such as state of on-call, architecture gaps, systems ownership usually works well. The maxima is being grounded in the team's sentiment and serves as an input for prioritising engineering investments.

**3. Strong connections.** What makes a group of people into a team is the strength and quality of the connections between members.
- **Shared sense of mission.** A large part of building this sentiment is being aligned on what success looks like. Ways to achieve it include crafting team vision and mission statements and being clear about [direction rather than destination](https://www.productplan.com/blog/build-shared-understanding/).
- **Social bond.** Especially in a distributed world, where video calls can become transactional, creating situations for social bonding is crucial. Social activities in a cadence and dedicating time for team offsites, are examples of ways to create some degree of connection beyond work.
- **Diversity.** Teams that embrace difference and celebrate diversity tend to be more connected. Diversity is a competitive advantage, and diverse teams make better decisions for their customers and the business. 

As an EM, your primary role is in improving the team's outcomes. Building a well-functioning team consists of understanding your team's problems – as every team has them – and working towards improvement, in collaboration with the team members. Start by being a good listener.

### Growing as an EM
If you enjoy the role, your first year will fly by. You will experience the joys of promoting people you support, defusing situations that seemed unfixable, and executing long-term strategies that felt like improbable moon shots back when you started them. You will also experience some of the not-so-great sides of being an EM, such as letting people go, managing conflicts, and saying “no” to things you would've consented to if it was only your call. After some time, you may wonder: “what else is there for me?”

Owning and driving your development becomes more important the more senior you get. It becomes primarily your responsibility to spot, understand and pursue opportunities for your growth. Similarly to the IC track, there are many growth directions you can take into the engineering management craft.

#### Broaden your canvas
Suppose your team’s mission evolves slowly over time, and you're near the point where further investment doesn't grant considerably better business outcomes. In this case, there's a high chance you will feel stagnant. On the bright side, at this stage you will have much more space for defining what the future should look like. Some ideas to further your scope and give you and your team a broader canvas:
- **Explore collaborations with adjacent teams.** With the network and relationships you build over time, it becomes easier to have the leverage to experiment with something entirely new. If you understand the basics beyond your local context, you might find challenges that can be solved at the intersection of teams.
- **Ask your boss for more.** You could be back at our starting point of being prepared for new opportunities. As mentioned at the beginning, making your manager aware that you could do more and asking for new opportunities can help.
- **Make an investment plan.** Sometimes you could be doing more within your scope, but you need to be resourced accordingly. Your manager might not fully understand how much more you could do if you were funded further.
- **Widen your lens to the problem at hand.** Assuming you achieved your original purpose, it makes sense to ask yourself what's next. Using Spotify as an example: it started as a music app, disrupted the music industry and became much more, with podcasts and new audio formats. It's still everything it ever was and is becoming much more.

One common misconception among EMs is that growth in the role comes from supporting a larger number of people. However, the answer is in the most important problems you should be solving for the business. Rather than going on an empire-building journey, you should seek business impact in order to grow as an EM.

#### Try something new
Sometimes the answer to personal growth is changing your context. Before changing teams or companies, it's essential to understand what you want. The engineering management track is full of challenges, and there are many paths to further your growth.

- **Manage multiple teams:** when you support one team, you have total dedication to one problem space. Learning how to manage more than one team simultaneously comes with its own set of challenges such as time management, delegation and stakeholder management.
- **Manage a team outside of your technical expertise:** when your background as an IC predominantly matches your team's discipline, you have much more specific advice to offer. I had the experience of managing a team heavy on machine learning experience. Having been a web engineer most of my IC career, this taught me more about engineering than any other experience I had.
- **Build teams from the ground up:** if you had the experience as a manager of inheriting a well-established team, building a team from scratch is one thing to try out. It comes with its own set of challenges, such as establishing the team's identity and hiring all or most members.
- **Join a team that is well established:** on the flip side of the above, joining a well-established team is another type of challenge. As a new arrival, you won't share all the context and perspectives that the team may have built up over years of working together. 
- **Manage the managers:** Similarly to the IC to EM transition, line management to group management is a complete job change. It comes with its own intricacies, such as having a wide-reaching impact within the business, learning how to manage managers and nurturing a team of teams.

____

In closing, I hope you find fulfilment in engineering management. I found much more happiness in doing the EM role, even when this meant taking a back seat on the engineering craft. 

You may feel differently and if you do, a sideways move from EM to the IC track is career progression. Remember that [your decision is not a one-way door](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/). Stay curious, loyal to yourself, keep your heart open to change, and everything else will fall into place.


Artigo escrito para The Pragmatic Engineer, em Maio de 2022, sobre como navegar esse movimento lateral de carreira.

Navegando a transição de papéis de pessoa engenheira para gerente de engenharia


Há muita literatura excelente sobre [por que você deve construir uma plataforma](https://kislayverma.com/platform-thinking/why-you-should-build-a-platform/) e [o que é uma platforma](https://martinfowler.com/articles/talk-about-platforms.html), mas não encontrei um recurso que ilustre situações específicas em que você possa querer construir uma. Com isso, comecei a pensar em padrões que poderiam ajudar a identificar a necessidade de uma plataforma e o que fazer quando você se encontra nessa situação como líder de engenharia.

Pretendo escrever alguns artigos sobre diferentes padrões que vi no passado. Se você pensar em outros exemplos, entre em contato e eu escreverei sobre ele e creditarei você como contribuidor.

### O que é uma plataforma?

Para pessoas menos familiarizados com plataformas técnicas, usarei a seguinte terminologia simplificada e um conjunto de princípios que podem ajudar a entender o básico. Se você quiser se aprofundar no assunto, os artigos na introdução lhe darão mais profundidade sobre o assunto.

##### Terminologia

- **Equipe de aplicação** é uma equipe que aproveita a plataforma técnica para um caso de uso específico, por exemplo, uma equipe construindo cobrança recorrente por meio de uma plataforma de pagamentos;
- **Equipe da plataforma** é a equipe que opera e mantém a plataforma técnica alavancada pelas equipes de aplicação, por exemplo, a equipe da plataforma de pagamentos;
- **Capability** é um pedaço de software que fornece à empresa e ao usuário a capacidade de fazer algo, por exemplo, "cobrar um cartão de crédito" é um recurso da plataforma de pagamentos, assim como "reembolsar uma transação com cartão".

##### Princípios

1. **Uma plataforma é self-serve para a maioria dos casos de uso.** Não apenas do ponto de vista técnico – o que significa excelente documentação, experiência do desenvolvedor etc. – mas também do ponto de vista de pessoas e processos. O [modelo de coordenação de self-serve do Jade Rubick](https://www.rubick.com/platform-teams-and-the-self-service-model/) ilustra em detalhes o que quero dizer.
2. **Uma plataforma é extensível para casos de uso aos quais ela não oferece suporte.** As equipes de aplicação podem aproveitar a plataforma como blocos de construção em vez de uma caixa preta para criar e dar suporte às suas próprias necessidades. Por exemplo, estender uma plataforma de pagamentos para suportar cobrança recorrente por uma equipe de aplicação pode ser fácil se ela tiver um recurso de "armazenar cartões" e suportar "cobrar um cartão de crédito".
3. **Uma plataforma opera de forma semelhante a um terceiro para os casos de uso.** Toda a complexidade na manutenção do domínio da plataforma é abstraída da equipe do aplicativo. Prevenção de abuso, segurança, conformidade e fornecedores terceirizados são bons exemplos da complexidade que uma plataforma deve abstrair.

A seguinte citação que tirei [deste artigo](https://martinfowler.com/articles/talk-about-platforms.html) escrita por Evan Bottcher no blog de Martin Fowler ilustra muito bem o conceito:

<Quote quote="Uma plataforma digital é uma base de APIs self-serve, ferramentas, serviços, conhecimento e suporte que são organizados como um produto interno atraente. Equipes de entrega autônomas podem usar a plataforma para fornecer recursos do produto em um ritmo mais rápido, com coordenação reduzida." autor="Evan Bottcher" />

Com esta cartilha rápida sobre plataformas técnicas, aqui está uma história fictícia que exemplifica o que quero dizer com o padrão de "consolidação".

### Uma história e o problema

A Acme corp iniciou seus negócios atendendo apenas clientes empresariais. Além de construir um ótimo produto, eles também tinham uma equipe de engenharia de software cujo objetivo era onboarding de empresas. Além de projetar a experiência, a equipe de onboarding de empresas desenvolveu algumas funcionalidades básicas para:
- Verificações de autenticidade através de um número de identificação fiscal (CNPJ) para garantir que as empresas clientes estão legalmente registradas;
- Verificações de compliance para prevenção de lavagem de dinheiro, por motivos de compliance, segurança e qualidade;
- Verificação de informações de contato para garantir que qualquer empresa cliente possa ser contatada por qualquer motivo;
- E, como parte do fluxo de onboarding, era necessário um cartão de crédito, que seria cobrado após o término do trial do produto.

Product-market fit veio muito rápido para a Acme, devido ao seu produto inovador. Consequentemente, suas ambições se ampliaram e a liderança da Acme anunciou uma nova estratégia para apoiar os consumidores sem um negócio jurídico, com um conjunto diferente de recursos. Para fazer isso, eles contrataram outra equipe para construir o onboarding de consumidores finais. Com a crescente pressão dos investidores para atingir as metas, fazia sentido que a equipe de onboarding de consumidores desenvolvesse seu próprio conjunto de sistemas. Nessa fase, para evitar contas falsas, bastava enviar um e-mail para confirmar o endereço de e-mail do consumidor.

Ao longo de alguns meses, o lado de consumidores finais do negócio também cresceu consideravelmente. A Acme viu outra oportunidade de cobrar um subconjunto de consumidores para um plano de seu produto comercial. A equipe de onboarding de consumidores implementou rapidamente o recurso, que foi uma excelente vitória. No entanto, alguns meses após o lançamento, alguns problemas vieram à tona:
- Trials entre os perfis do consumidor e do negócio eram inconsistentes, e gerenciar diferentes durações de ciclos criava muita sobrecarga para a equipe financeira;
- Dado que a integração do consumidor e da empresa usou fornecedores de pagamento diferentes, o mesmo cartão de crédito que funcionaria em uma conta comercial não funcionaria em uma conta de consumidor;
- Como ambos os produtos foram construídos de forma independente, a linguagem para se referir ao domínio variou entre consumidores e empresas, e às vezes era até conflitante;
- À medida que a Acme se expandiu para novos mercados, as equipes de consumidores e empresas tiveram que adicionar novos tipos de pagamento, novas verificações de conformidade e suporte para novas moedas.

### Sintomas

Normalmente, existem alguns sintomas que antecedem a necessidade de aplicar o padrão de consolidação:
1. **Tecnologia fragmentada para um recurso**. Especialmente quando você está experimentando um novo produto, o excesso de indexação na coesão geralmente é uma má ideia, pois você mal sabe se o produto será bem-sucedido. Na anedota acima, quando a equipe de liderança de engenharia formou a equipe de onboarding de consumidores finais, receber um pagamento estava fora do escopo, então provavelmente foi a decisão certa construir um novo conjunto de sistemas. Embora, à medida que o escopo aumentou, a empresa acabou com sistemas duplicados para muitos recursos, como "receber um pagamento", "executar verificações de conformidade", "gerenciar trials".
2. **Duplicação de trabalho ou dependências indiretas similares**. Na anedota, ao expandir para novos mercados, as equipes de integração de consumidores e empresas dependeriam de uma "equipe de gerenciamento de usuários" para adicionar um campo "país" ao modelo de usuário para selecionar qual moeda usar ao fazer um pagamento. Podemos abstrair isso como mais de uma equipe tendo que fazer uma implementação muito semelhante ou às vezes o mesmo trabalho, ou duas equipes tendo dependências indiretas pelas mesmas razões para as mesmas partes.
3. **Linguagem quebrada em toda a empresa**. No exemplo acima, referir-se a "trial de produto" ou "verificações de conformidade" é muito ambíguo, pois você pode estar se referindo a coisas muito diferentes dependendo de com quem você fala. Para pessoas familiarizadas com o livro Domain-Driven Design, o capítulo [Ubiquitous Language](https://martinfowler.com/bliki/UbiquitousLanguage.html) vem à mente aqui.

### Uma solução para o problema

Um exemplo de um caminho a seguir para equipes em tal situação é usar o modelo ["aplicação/platforma"](/pt/composition-for-teams-platform-and-application-pattern) e dividir a responsabilidade em três áreas:
- Onboarding de consumidores, que foca na experiência do onboarding do consumidor e qualquer coisa específica do lado do consumidor;
- Onboarding de empresas, com foco na experiência do negócio e suas especificidades;
- Plataforma de onboarding, que consolida em uma plataforma os recursos utilizadas por ambas as equipes de onboarding. Bons exemplos de recursos nesta equipe de plataforma podem ser "receber pagamentos", "gerenciar testes", "executar verificações de conformidade", que podem ser configurados ou estendidos a diferentes casos de uso;

E aqui está um detalhamento de um passo a passo para testar a mudança e ver se faz sentido para o seu caso:

1. **Forme uma [equipe virtual](https://www.referenceforbusiness.com/management/Tr-Z/Virtual-Organizations.html) com representação de ambas as equipes**. Este grupo de pessoas será responsável por colocar juntos um plano de ação e testar a hipótese. Além de trabalhar em um roadmap compartilhado, recomendo analisar SLAs por caso de uso, nível de extensibilidade necessário por equipe e priorizar casos futuros na nova plataforma com a contribuição de ambas as equipes. Você pode descobrir que talvez possa viver com a duplicação por mais algum tempo, ou até mesmo concluir que uma plataforma não é o ajuste certo;
2. **Desenvolva capacidade para consolidar recursos** Se esse for o caminho a seguir, em vez de fazer uma migração big bang ou reescrever tudo do zero, puxe um recurso de cada vez dos sistemas anteriores para a nova plataforma. Uma maneira de priorizar são os casos de uso que são os maiores pontos problemáticos tanto para as equipes quanto para o negócio, e também quais são os maiores gargalos para o negócio;
3. **Eventualmente, forme uma nova equipe**, de preferência com alguma representatividade das equipes existentes, e adote o modelo de aplicação/plataforma.

E para encerrar, veja como fazer isso resolve os sintomas mencionados acima:

1. A tecnologia fragmentada não é mais um problema, pois, por design, os recursos compartilhados estão em uma única equipe;
2. Idealmente, a maior parte do trabalho deve ficar com a equipe da plataforma ao adicionar um novo tipo de pagamento, cumprir uma nova regra de compliance ou adicionar um novo tipo de trial;
3. O novo limite organizacional na equipe da plataforma pode ser uma função forçante para a correção da linguagem, mesmo que ainda seja necessario um esforço consciente da equipe da plataforma.

_____

*Agradecimentos especiais a [David Golden](https://xdg.me/) por seus comentários sobre uma versão anterior deste artigo.*


Equipes de engenharia frequentemente duplicam o trabalho umas das outras. Quando não há boas razões e isso se torna um problema, um padrão comumente usado é construir uma equipe de plataforma.

Consolidação em um time de plataforma


O caminho mais comum para o gerenciamento de engenharia é por meio de uma posição de liderança técnica com responsabilidades de pessoas, também conhecido como [tech lead manager (TLM)](https://www.teamblind.com/post/What-does-Tech-Lead-Manager-mean-in-Google-8e4VQDy1). Nessas funções, além de ter responsabilidades de pessoas, o gerente de engenharia também é um especialista técnico dentro da equipe.

À medida que avança em sua carreira de gerenciamento, uma pessoa gerente pode se deparar com situações em que gerencia uma equipe com um conjunto de habilidades diferente do que tinham como engenheira. Embora esse tipo de oportunidade venha com muito aprendizado, também pode vir carregado de dúvidas.

Não há uma resposta absoluta sobre o quão técnica deve ser uma gerente de engenharia, pois a resposta está vinculada ao contexto em que está inserida. Ainda assim, um fato é que os gerentes de engenharia são líderes funcionais. Eles devem apoiar sua equipe na tomada de decisões estrategicamente alinhadas para os negócios, mesmo quando não estiverem tão confiantes em suas habilidades técnicas.

### Proteger o alinhamento estratégico

Como um TLM, você tem uma capacidade maior de introduzir controles granulares. Revisar código, discutir como implementar uma mudança ou um simples mergulho profundo com um engenheiro são exemplos desses controles granulares que informam sua perspectiva para fornecer conselhos e comentários. Um gestor menos técnico que precisa garantir que o investimento de tempo e esforço vá para as oportunidades mais impactantes só pode recorrer exclusivamente a controles um pouco mais abstratos, incluindo:

1. **Uma visão clara de longo prazo.** Isso é particularmente importante, pois "tunnel vision" é ainda mais prejudicial para equipes sem uma líder técnica forte. A forma como os sistemas são construídos pode impactar fortemente sua capacidade de permanecer alinhado à estratégia, portanto, ter uma compreensão clara de qual é a condição-alvo por um período mais longo (por exemplo, 2-3 anos) e comunicá-la bem ajuda a equipe a tomar decisões que são à prova de futuro, na medida mais significativa possível;
2. **Um conjunto de métricas de primeira linha e métricas de proteção.** Ter um conjunto bem definido de indicadores que informam "o que é bom" ajuda a avaliar os resultados do time e desempenha um papel considerável na priorização. Por exemplo, priorizar entre aumentar a disponibilidade em 1% ou reduzir falsos positivos em 10% é mais fácil quando você pode atribuir ambos ao mesmo resultado de negócio, como "Economia de custos operacionais". Também o ajuda a ficar longe dos detalhes de implementação que você não entende;
3. **Um ciclo de planejamento com um conjunto claro de resultados.** Embora você possa não entender os aspectos internos de como algo será alcançado, é essencial entender o que e por que isso precisa ser alcançado, assim como comunicar isso claramente com a equipe . Resultados claros e quantificáveis ​​ou objetivos de envio claros vinculados a um resultado de negócios são essenciais para qualquer contexto, mas é proibitivo para equipes com líderes não tão técnicos, pois tentar alinhar a equipe através dos detalhes será contra-intuitivo na melhor das hipóteses e desastroso no pior cenário.

Embora você possa achar que suas habilidades técnicas podem prejudicar sua capacidade de fazer o que foi dito acima, definir bons controles abstratos requer muito mais compreensão do negócio do que as partes internas dos sistemas que alcançam os resultados.

### Descentralizar as funções de liderança técnica

Por muitas razões, incluindo evitar se tornar um gargalo, gerentes de engenharia devem compartilhar as funções de liderança técnica, mesmo quando são relativamente técnicas. Torna-se imperativo quando você pensa que não é competente para tomar decisões técnicas sólidas. Uma abordagem para resolver a situação, que eu particularmente não sou fã, é o TL + EM [two-in-a-box](https://hbr.org/2012/04/leadership-teams-why-two-are-b), em que o EM transfere a liderança técnica para um engenheiro sênior/staff na equipe, mantendo as responsabilidades de gerenciamento de pessoas. Acredito que isso não resolva o aspecto do gargalo, mas, em vez disso, o fragmenta em dois gargalos diferentes com a sobrecarga de alinhamento adicional.

O que acredito ser uma abordagem melhor é identificar os diferentes desafios na equipe e delegar problemas inteiros aos mais competentes para resolver os desafios. Isso evita a fusão de todos os problemas em um único problema e ajuda a identificar as melhores pessoas em sua equipe para esclarecer cada área problemática. Para poder confiar e delegar diferentes tipos de desafios a diferentes pessoas, você pode acabar com [uma equipe em forma de triângulo invertido](https://twitter.com/GergelyOrosz/status/1480942071179579393) – uma equipe com um maior presença sênior – que vem com seu próprio conjunto de desafios, mas geralmente resolve bem a lacuna de liderança técnica na equipe.

### Reúna informações imparciais para tirar conclusões

Se você tem alinhamento de alto nível e liderança compartilhada para diferentes assuntos, como você constrói uma imagem coesa do estado de toda a equipe? Ao confiar em vários engenheiros seniores ou de equipe com diferentes desafios, você pode resolver bem as áreas de problemas individuais, mas não permite a coesão. É fácil desviar a responsabilidade pensando que o alinhamento virá de pessoas falando umas com as outras, especialmente em uma equipe sênior. A coesão só acontece intencionalmente e, se você deixar que ela seja estabelecida organicamente, pode ser altamente tendenciosa por algumas pessoas mais vocais, com alta propensão a serem aquelas em quem você confia mais responsabilidade.

Com a falta de competência para [verificar e inspecionar](https://lethain.com/inspection/), e não se sentir confortável em apenas confiar, já vi pessoas terem muito sucesso em criar mecanismos onde você reúne informações imparciais para chegar às suas conclusões. Algo tão simples quanto executar uma pesquisa anônima com apenas respostas de escala linear variando de 1 a 5 pode fornecer uma imagem coesa que representa as opiniões de todos e ajudar a iniciar as discussões certas.

### Aprenda o básico ao longo do caminho

Eu me encontrei nessa situação no passado, gerenciando equipes que trabalhavam de perto com machine learning quando, sem dúvida, eu falharia em uma prova de estatística básica. No entanto, mais comumente, as pessoas têm orgulho de seu ofício e terão prazer em ajudá-lo a entender o que fazem. Além de aprender ao longo do caminho, desenvolvi uma boa apreciação por identificar pessoas que poderiam me ajudar com sucesso a entender o básico. Como se vê, isso também é um forte sinal de competência de quem seria capaz de melhorar o nível dos outros na equipe sempre que necessário.


Gerenciar equipes para as quais você não tem conhecimento técnico pode ser um desafio. Neste artigo eu falo um pouco sobre o que já funcionou para mim antes.

Gerenciando times de engenharia fora da sua expertise técnica


A gestão de performance é amplamente utilizada como uma forma de planejar, revisar e recompensar as pessoas por suas contribuições. Para pessoas que não estão familiarizadas com o processo em grandes empresas de tecnologia, ele consiste basicamente em:

1. **Alinhar as expectativas.** As empresas geralmente têm uma estrutura que dita o comportamento esperado e o escopo do impacto para um nível de senioridade específico; e expectativas específicas da função fornecidas pelo gerente direto da pessoa, como expectativas dentro de sua equipe ou organização. O início de cada ciclo de gestão de desempenho geralmente consiste em discutir o estado atual das habilidades da pessoa nessas duas dimensões e entrar em acordo sobre como será o próximo ciclo.

2. **Forneçer suporte e feedback continuamente.** Ao longo do ciclo de avaliação de performance, as pessoas precisam ter os canais de suporte para buscar input, fornecer feedback e realinhar expectativas. Normalmente, o processo consiste em 1:1s em uma base semanal/quinzenal e revisões de plano/metas todos os meses. Algumas empresas também fazem check-ins no meio do ciclo, que são o ponto médio de um ciclo de desempenho, com feedback e reflexões um pouco mais formais.

3. **Reconhecer e recompensar as contribuições.** Ao final de cada ciclo de desempenho, as pessoas são recompensadas e reconhecidas por suas realizações. Diferentes empresas também terão seus meandros, mas geralmente é uma combinação de compensação extra (por exemplo, aumentos de salário, atualizações de ações/equity, bônus) e mais escopo e responsabilidade (promoções, assumir mais responsabilidades e assim por diante). A parte da recompensa geralmente é definida por meio de um comitê criado para reduzir o viés/bias e focar nos fatos, para que o processo seja o mais justo possível. O que sai deste estágio é usado como entrada para o próximo ciclo de desempenho.

A gestão de desempenho implica controle, e os gerentes têm sua parcela justa de responsabilidade pelo sucesso de um relatório em suas funções. Embora, na grande maioria das vezes, **eu acho benéfico abordar minha função como gerente no desempenho de um reporte como uma função de capacitação em vez de uma função de controle**. Para explicar melhor meu ponto, considere [duas metas de desempenho que tirei do Radical Candor](https://www.radicalcandor.com/growth-and-stability/): pessoas que buscam crescimento e pessoas que buscam estabilidade.

### Facilitando uma trajetória de crescimento

Por uma questão de definição, o crescimento pode consistir em pessoas buscando uma promoção de sênior para staff, mas também pessoas que procuram uma oportunidade de aprendizado, como um engenheiro de back-end que deseja fazer mais trabalho com dados ou deseja tente uma nova função, ou uma gerente de engenharia entrar como EM provisória para uma vaga dentro da mesma organização para se expor a diferentes desafios.

Independentemente do cenário, facilitar o crescimento de uma pessoa é fundamentalmente achar oportunidades de match às suas aspirações. Facilitar consiste em identificar em conjunto oportunidades significativas que levarão as pessoas à condição desejada. O primeiro cenário é mais simples - as promoções são "lagging", o que significa que há uma necessidade de desempenho no próximo nível para ser promovida, portanto, o alinhamento das expectativas consiste em estabelecer metas para aquela pessoa em alinhamento com expectativas do proximo nível. No caso focado em aprendizado, as expectativas são geralmente menos vinculadas à empresa e muito mais vinculadas à equipe ou à organização - o que, teoricamente, a pessoa gerente tem ainda mais agência em encontrar oportunidades.

Da mesma forma, fornecer suporte e feedback pode ser feito de várias maneiras. Exemplos são diretamente por meio de canais 1:1 já estabelecidos mencionados anteriormente e indiretamente, ajudando a pessoa a construir uma rede de apoio ao seu redor: bons mentores para fornecer conselhos, um incentivo financeiro para aprendizagem e desenvolvimento utilizando o orçamento da empresa, etc.

Em suma, **embora gerentes possam ser uma força multiplicadora na trajetória de crescimento de alguém, as pessoas devem ter agência e desejo pelo caminho de desenvolvimento.** É por isso que acredito que o papel da pessoa gerente na trajetória de crescimento de um reporte é fundamentalmente sobre facilitação.

### Facilitando uma trajetória de estabilidade

Uma trajetória de estabilidade pressupõe que a pessoa está tendo um bom desempenho em seu nível atual e deseja continuar assim por qualquer motivo. Embora algumas empresas tenham pressão de crescimento para a progressão na carreira até o que chamam de nível "terminal", que uma vez atingido, não há risco de "up-or-out". Em tais circunstâncias, as pessoas geralmente buscam estabilidade em vez de crescimento por vários motivos, que vão desde o foco estar em outra parte da vida ou simplesmente gostar das coisas como são.

Em tais cenários, as pessoas já conhecem bem as expectativas em seu nível. **Na maioria dos meios, especialmente nos níveis "terminais", a função de um gerente para um reporte em uma trajetória de estabilidade é facilitação.**

### Quando controlar o desempenho

Embora a maior parte do trabalho seja facilitação, há grandes razões pelas quais controlar o desempenho é uma abordagem razoável. Em última análise, a pessoa gerente é responsabilizável pelos resultados da equipe e, às vezes, não é possível chegar a um consenso com o reporte. Aqui estão alguns exemplos que vêm à mente:
- **Quando uma trajetória de crescimento individual pode afetar as metas ou compromissos do negócio**. Cenários típicos de algo errado incluem perseguir uma promoção por meio de [desenvolvimento orientado à promoção](https://twitter.com/gergelyorosz/status/1442162670753431559) e resultar em um rating ruim no nível atual e metas perdidas devido à negligência do gerente, ou não definir um período de experimentação e plano de reversão para as pessoas que estão fazendo movimentos laterais de IC para gerente e vice-versa. Bons controles para evitar situações como essa são usar o estágio de alinhamento de expectativas no início do ciclo de desempenho para definir quando intervir e como isso aconteceria.
- **Quando uma ação individual impacta a equipe diretamente**, por exemplo, quando há resistência para desenvolver uma habilidade onde a falta dela afeta o funcionamento da equipe. Um bom exemplo pode ser um gerente que não deseja nenhum envolvimento nas decisões técnicas, mas não consegue delegar a responsabilidade a um IC sênior/staff. As pessoas às vezes podem nadar sem querer contra a corrente da equipe, e uma boa maneira de controlar proativamente isso para não se tornar um problema de desempenho é por meio de 1:1s, revisões de metas, apontando as pessoas para as diretrizes de expectativa de nível da empresa para seu nível, etc.

Existem muitas outras circunstâncias, mas acredito que **o resultado final é duplo: em primeiro lugar, mais do que quando, "como" importa muito** - o controle arbitrário pode parecer microgestão; **e em segundo lugar, normalmente o aspecto de controle da gestão de desempenho torna-se fundamental para ser exercido quando há um impacto além da pessoa em suas ações**, o que é muito comum para gestores, menos para ICs.

### Quando não controlar o desempenho

Da mesma forma, as coisas também podem dar errado ao tentar gerenciar demais o desempenho do ângulo de controle. Um exemplo que vem à mente é quando o gerente e o reporte apresentam incentivos desalinhados. O que quero dizer com isso é que o que é "certo" para a função em questão não é o que é "certo" para a pessoa, por exemplo, necessidade significativa de formato em T em skillset e o desejo do indivíduo ser de seguir a rota de especialização. Em tais circunstâncias, **aplicar controle pode deixar apenas duas opções ruins para escolher: dobrar a função para caber a pessoa ou dobrar a pessoa para caber na função.**

É nessas situações que o enquadramento de capacitação tem me ajudado mais - um indivíduo de alto desempenho em outra equipe é um resultado melhor do que um indivíduo de baixo desempenho nesta equipe específica para o negócio. Já vi pessoas se mudarem internamente e serem promovidas no próximo ciclo porque estavam fundamentalmente prontas, mas não tinham oportunidades de correspondência, e pessoas deixaram as empresas porque não queriam desenvolver seu conjunto de habilidades na direção de que a equipe específica precisava. Sem dúvida, a primeira situação é preferida, por isso, por padrão, **acredito que olhar a gestão de desempenho do ângulo da facilitação tende a funcionar muito bem, pelo menos para mim.**


Gerenciamento de performance é uma forma de planejar, revisar e recompensar as pessoas pelas suas contribuições. Nesse artigo eu explico porque eu acho que o processo é mais sobre facilitação do que controle.

Facilitação de performance


Recentemente, um colega gerente de engenharia me perguntou qual era meu framework para delegação, e isso me fez pensar em como resumir o que acredito ser uma boa delegação em alguns princípios. Há muita literatura por aí sobre delegação. Mesmo assim, nunca investi tempo sintetizando o que acredito ser uma boa delegação em algo tão simples como um conjunto de princípios.

Em essência, os melhores exemplos de delegação que experimentei compartilham algumas características. Como delegador, eu poderia concentrar minha energia em outro lugar; Tive o nível certo de envolvimento quando solicitada a minha orientação e cheguei ao resultado esperado por meio do delegado. Da mesma forma, como delegado, tive oportunidades de trabalhar em problemas desafiadores e descobrir como resolve-los sozinho; Eu tinha o nível certo de suporte sempre que me sentia bloqueado e era responsabilizado pelos resultados esperados.

O padrão é bastante claro: **os melhores exemplos de delegação que posso pensar combinam a movimentação de autonomia e responsabilidade simultaneamente do delegador para o delegado**. Eu reduzi isso a três princípios para me ajudar a reproduzir o padrão que acredito ser uma boa delegação:

### Delegue problemas em vez de pedaços de uma solução

Na maioria das vezes é uma má ideia delegar com muita estrutura. Se você tiver que quebrar todas as etapas para chegar à solução, provavelmente significa que ainda está resolvendo a maior parte do problema sozinho. [Work is like a hill ("o trabalho é uma colina") e muito disso está em descobrir o que fazer](https://basecamp.com/shapeup/3.4-chapter-13#work-is-like-a-hill). Os incentivos não são alinhados se você delegar com muita estrutura: dois dos principais resultados que você obtém ao delegar a outras pessoas é expor as pessoas a uma experiência de aprendizado e liberar-se para concentrar sua atenção em outro lugar.

Ao delegar com muita estrutura, você provavelmente não está cumprindo nenhum dos dois. Em primeiro lugar, o aprendizado é limitado, pois a maior parte vem de descobrir como quebrar o problema em uma solução. Ao propor um conjunto de instruções para chegar à solução sozinho, a transferência de contexto para o delegado pode acabar sendo ainda mais cara do que deixá-lo descobrir o que fazer sozinho.

Por outro lado, definir bem o problema e esclarecer por que ele é importante geralmente leva a uma dinâmica muito mais saudável e a melhores resultados. **Ao delegar um problema bem estruturado, você está muito mais perto de expor o delegado ao aprendizado e chegar a um resultado com menos envolvimento.**

### Defina limites claros para o problema que você está delegando

Além de enquadrar o problema claramente, definindo por que ele é importante, definir as restrições para o problema a ser resolvido e alinhar com o resultado esperado são igualmente importantes.

Por exemplo, não estar alinhado em insumos como prioridade e prazos é uma receita para responsabilidade frouxa e investimento desproporcional de esforço/resultado. Ao definir as entradas de antemão, ambas as partes podem alinhar as expectativas de importância e esforço.

Não estar alinhado com o resultado é uma receita para reduzir a autonomia. O delegador é pressionado a se aprofundar nos detalhes. Toda a complexidade do problema em questão se torna o assunto principal nas conversas, em vez de como maximizar o resultado. O delegado é empurrado a focar majoritariamente em execução e perde autonomia.

**Ao definir insumos e resultados precisos, você define os limites do problema, o que define um contrato mais limpo entre as partes**. Conforme você transfere a responsabilidade e a autonomia para o delegado, o desafio passa a ser prepará-lo para o sucesso.

### Gerencie riscos *com* o delegado, não *para* eles

A gestão de riscos é um aspecto fundamental da delegação. Conforme os riscos surgem, é essencial não pular direto para a intervenção, pois ela tem um custo muito alto de várias maneiras.

Um modo de falha comum para delegação é oferecer conselhos que você foi pedido. Por mais que venha de um lugar de cuidado e proteção, vai tirar autonomia e responsabilidade, especialmente em uma situação de pressão. É muito provável que o delegado leve o conselho do delegador muito mais a sério em tais cenários.

A alternativa que encontrei é gerenciar o risco * com * o delegado. Supondo que você não tenha configurado o delegado para a falha delegando algo muito além de sua [maturidade relevante à tarefa](https://getlighthouse.com/blog/management-concept/), e que você delegou todo o problema, em vez de um parte da caixa preta da solução para o problema, eles estão em uma posição melhor para tomar decisões. Nesses casos, **você pode gerenciar o risco com eles, em vez de por eles, sendo curioso, fazendo perguntas e apoiando-os para que cheguem às suas conclusões.**

___

Este conjunto de princípios é especialmente inclinado para cenários de sucesso. As coisas nem sempre saem como planejado. Quando isso acontece, bons líderes fazem as pessoas sentirem que têm uma rede de segurança e podem intervir se a situação exigir; mas, o mais importante, eles fornecem a combinação certa de aprendizado e suporte de que as pessoas precisam para crescer e ter sucesso na próxima vez.


Delegação é uma das habilidades mais fundamentais em liderança. Tentei sintetizar o que acredito ser uma boa delegação em três simples princípios.

Três simples princípios para delegar


Uma tensão em engenharia de software que sempre me fascinou é saber quando dividir um em muitos. Sempre parece haver esse ponto de inflexão, geralmente desencadeado pela percepção de duplicação, compreensão de complexidade de responsabilidades ou perceber que acoplamento se tornou um problema.

Da mesma forma, as organizações também se beneficiam desse padrão. Os sinais de que pode ser necessário são os mesmos: há duplicação de sistemas, uma fusão de escopo e acoplamento indesejável de objetivos entre times. Uma solução de design organizacional comum é estabelecer uma "equipe de plataforma" responsável por generalizar os casos de uso existentes em uma plataforma e "equipes de aplicação", com foco nas especificidades dos casos de uso.

Apoiar esse tipo de mudança pode ser perturbador para as equipes e, às vezes, a frustração vem da definição de novos limites e propósitos dissociados. Aqui estão algumas idéias de como traçar limites e ajudar equipes de plataforma e aplicação a terem sucesso.

### O que permanece nas equipes de aplicação

Definir responsabilidades claras para equipes de aplicação ajuda a definir o que uma plataforma poderia ser. Uma maneira de entender o que precisa ser uma plataforma é entender o que não deve ser, pois isso geralmente é mais óbvio do que o contrário.

1. **Plataformas têm menos probabilidade de resolver problemas subjetivos ou com muitas nuances.** Considerando que o papel de uma plataforma é atender a vários casos de uso, elas geralmente são excelentes para resolver problemas objetivos. Embora, para a maioria dos problemas que tendem ao lado subjetivo, as equipes de aplicação brilham muito mais. Para uma plataforma de processamento de pagamentos, existem muitos desafios de produto difíceis a serem resolvidos como uma equipe de aplicação: quando e como autorizar um cartão, quando tentar um pagamento novamente, quando e com que frequência liquidar fundos, o melhor dia do mês para repetir um pagamento, para citar alguns.

2. **Otimização relacionada ao contexto deve viver próxima ao contexto.** As plataformas são ótimas para resolver a maior parte dos problemas compartilhados entre aplicações, embora alguns dos trabalhos de otimização mais desafiadores, especialmente em sistemas de grande escala, estejam no contexto. Para uma plataforma de recomendações, o contexto em que uma recomendação é feita é extremamente relevante para que seja eficaz, por ex. uma recomendação em uma página de lista de produtos, com baixa intenção de compra versus uma recomendação de pré-pagamento ou upsell. Embora as plataformas possam fornecer vantagens para a otimização, todo o ajuste, calibração e significado do sucesso tende a viver mais perto do contexto. Em geral, as equipes de aplicação estão em uma posição muito melhor para localizar sinais de alta qualidade que são sensíveis ao contexto para otimização.

3. **A plataforma pode afetar seu usuário.** Equipes podem ser extremamente bem-sucedidas trabalhando em estreita colaboração com pesquisadores de experiência do usuário para entender quais são as necessidades específicas de seus usuários. Às vezes, o insight gerado por meio de pesquisas pode ser contraditório em diferentes superfícies ou contextos, e esse entendimento pode determinar como a plataforma afeta o usuário. Os resultados da pesquisa podem variar de equipes de aplicação influenciando a direção da plataforma se o insight for válido em todos os casos de uso, até também revelar que talvez o limite traçado proposto afete de alguma forma o caso de uso e decidir que é prematuro ter uma plataforma.

### Uma nova plataforma emerge

À medida que você entende o que fica, o que deveria ser generalizado fica muito mais claro. Mais do que mudar sistemas, times de plataforma exigem uma mudança massiva de mentalidade. Para quem não está familiarizado com equipes de plataforma, eles tendem a compartilhar algumas características. Um exemplo notável é trabalhar com vários clientes ou partes interessadas. Dito isso, grande parte da tensão para as equipes de plataforma é encontrar o equilíbrio entre a utilidade e permanecer agnósticos - as plataformas são projetadas para resolver bem um conjunto de problemas, mas não todos. Algumas características que observei que equipes de plataforma bem-sucedidas possuem são:

1. **Pense na infra-estrutura como parte do produto - ou o próprio produto.** Quando uma equipe não consegue controlar todas as consequências downstreams de diferentes modos de falha, ela precisa ter SLAs, processos de gerenciamento de incidentes e práticas de continuidade de negócios muito mais rígidos. Por exemplo, um requisito de disponibilidade de 99% pode ser aceitável para uma plataforma de pagamentos com um ticket médio de $10 @ 500k transações por dia - significando uma perda de ~$3.5k por hora. No entanto, se o ticket médio está na casa dos milhares, isso pode significar diferentes requisitos de disponibilidade. Ser uma equipe de plataforma exige uma mudança no pensamento de que a infraestrutura é uma parte muito mais relevante da oferta do produto.

2. **Tenha cuidado ao presumir equivalências em dados.** Especialmente para plataformas de machine learning ou data, pode ser muito difícil encontrar maneiras de comparar significados, padronizar e compartilhar protocolos para labelling de dados ou gerar insights. Além disso, às vezes pode ser enganoso se você não compreender totalmente os casos de uso antes de compartilhar dados para análise ou treinar modelos. Dito isso, uma boa maneira de evitar cenários como esse é ser conservador sobre onde traçar o limite do domínio da plataforma e começar com o menor valor possível. Por exemplo, uma plataforma de recomendações de produtos pode começar com uma API que retorna scores de probabilidade para vários tipos de recomendação - compre novamente, também comprei etc. - em vez de lidar com a ranking de produtos, que é um problema muito mais complexo e matizado.

3. **Pense na plataforma como recursos, em vez de um pacote único.** Uma das formas pelas quais as plataformas geralmente falham é tentar empacotar todos os recursos em vez de fornecer às equipes de aplicativos um conjunto de recursos interoperáveis ​​que podem ser usados ​​como necessário. Embora possa ser bastante conveniente abstrair toda a complexidade por trás de uma única API, quando as equipes de aplicativos não têm acesso a recursos independentes, elas são incentivadas a "dar a volta" na plataforma. Em vez disso, dividir domínios lógicos em blocos de funcionalidade pode dar aos usuários a capacidade de estender funcionalidades. [Esse post do Kislay Verma sobre como evitar "dar a volta" com platform thinking](https://kislayverma.com/platform-thinking/preventing-go-around-with-platform-thinking/) explica o problema e a solução muito bem.

___

Por mais que a mudança seja positiva quando você pode definir claramente a responsabilidade de cada constituinte, introduzi-la prematuramente pode ser muito prejudicial. Considerando o quão perturbadora uma decisão errada pode ser e quão lento é o ciclo de feedback para definir se uma reorganização foi bem-sucedida ou não, [abordar a mudança por meio de experimentação](https://dballona.com/pt/reorganising-teams-through-experimentation/) pode ajudar a mitigar riscos e tornar a experiência menos frustrante para todos.


Da mesma forma que software, times podem se beneficiar de composição. Um padrão de design organizacional comum é definir uma equipe de plataforma e utilizá-la através de vários times de aplicação.

Composição para times, plataforma e aplicação


Assim como sistemas, conforme equipes de engenharia crescem, você se depara com pontos em que precisa iterar o design e otimizar para características diferentes. Você também não _over-engineer_, pois a otimização para casos futuros pode levar a consequências indesejáveis. Esse é um momento em que você pode querer considerar uma reformulação ou reorganização de times.

Reorganizações raramente são a única maneira de resolver um problema. Na verdade, geralmente são a forma mais cara e custosa. Embora, às vezes, reorganizar ou redesenhar é a decisão certa. Alguns dos sintomas que podem indicar que um reorg deve ser considerado são o gerenciamento recorrente de dependências complexas, uma carga cognitiva esmagadora necessária para manter os sistemas pertencentes a um grupo de pessoas, uma quantidade enorme de processos para compensar a comunicação inefetiva e assim por diante.

Uma forma de reduzir os riscos de uma reorganização para resolver um problema e acabar criando mais alguns é esclarecendo o problema, levantando uma hipótese, abordando a mudança como um experimento e depois compartilhando suas descobertas, o que informa a decisão final.

### Antes de tomar uma decisão

Em primeiro lugar, **esclareça qual é o problema que você está tentando resolver por meio da reorganização de times**. Acredito deve-se existir uma tendência forte a não fazer um reorg. Na maioria das vezes alinhamento em um nível organizacional mais alto, reavaliar o ownership de sistemas ou responsabilidades e introduzir melhores práticas ou processos de comunicação pode ajudar a não se tomar essa decisão.

Se você está convencido de que precisa fazer isso, **esclareça quais grupos de pessoas são afetados pelo problema**. Uma maneira de começar é perguntando às pessoas individualmente e prestando atenção às nuances que cada pessoa traz para a discussão. Essas nuances servirão como entrada para a geração de hipóteses.

Depois de saber quem é afetado pelo problema, de forma colaborativa **gere um conjunto de hipóteses responsáveis pela existência do problema**. Entender as frustrações das pessoas geralmente é um bom ponto de partida e, em seguida, perguntar por que isso as frustra pode levar você a uma boa hipótese. [Liberating Structures](https://reimaginaire.medium.com/what-are-liberating-structures-de6f6d14c2c8) são úteis para obter a opinião de todos, livre de julgamento.

A seguir **desenhe diferentes maneiras de organizar as pessoas para validar sua hipótese** e **entenda as lacunas de capacidade que cada mudança candidata geraria**. Uma reorganização pode apresentar riscos e, para times, um grande fator é a composição da equipe. Uma mudança como essa pode fazer você perder características essenciais em uma equipe, como conhecimento especializado sobre um conjunto de componentes, cobertura on-call para operar a infraestrutura que a equipe é responsavel, throughput diluído do ponto de vista de entrega, e assim por diante.

Então, depois de encontrar de forma colaborativa algumas das melhores opções, **ouça as pessoas que estão mais hesitantes e mais entusiasmadas com cada possível mudança**. Isso o ajudará a avaliar se a divisão seria saudável para as novas equipes e também para as pessoas individualmente. Idealmente, você deseja resolver para todos - a organização, a equipe e também para cada indivíduo. Algumas pessoas podem ficar insatisfeitas com a mudança proposta, e opositores fortes geralmente têm seus motivos que podem ser extremamente relevantes e encobrir pontos cegos do grupo.

### Experimentando com mudança

Enquadrar a mudança como experimentação tira parte da pressão do sucesso e é mais fácil reverter do ponto de vista administrativo, mas também do ponto de vista do moral e de gestão de expectativas. **Comprometa-se com uma hipótese e aborde-a como experimentação**. Como qualquer experimentação, você precisa dar tempo suficiente para obter um feedback preciso, pois haverá um atraso considerável entre a implementação da mudança e a capacidade de avaliar sua eficácia.

No início, você provavelmente terá mais fios cruzados, as pessoas ficarão mais desconfortáveis, a qualidade pode diminuir e o ritmo pode ficar mais lento. **Deixe durar o suficiente para construir um julgamento justo** antes de tomar uma decisão definitiva seja positiva ou negativa. Um bom ponto de partida são seis meses para reavaliar. Esse intervalo de tempo provavelmente corresponderá ao seu cronograma de definição de metas, análises de desempenho e planejamento de pessoal, portanto, dar tempo suficiente o ajudará a compreender as consequências dessa decisão de várias perspectivas.

**Configure um ciclo de feedback com a equipe e partes externas**. Obter feedback da equipe é fundamental, mas geralmente é mais direto, pois você pode ter estabelecido canais de comunicação como 1:1s e pesquisas de saúde do time. Também é essencial entender quais são os impactos externos, portanto, passar tempo com as partes interessadas e equipes adjacentes aos times afetados pode ajudar a avaliar a satisfação interna e externa e agir de acordo com ela.

Pode ser útil **reavaliar se os problemas que você presumiu que a reorganização resolveria estão sendo resolvidos**. Você pode sentir que, de forma anedótica, as equipes estão mais saudáveis ​​e performando mais, mas é essencial entender por quê. Olhar para trás e entender quais foram as motivações para fazer isso pode ajudar a validar se você está resolvendo os problemas a partir da própria hipótese inicial ou de outra coisa.

Considerando que a experiência está sendo bem-sucedida e as novas equipes estão se saindo incrivelmente bem, você ainda precisa estar ciente dos fatores externos. Um deles é a demanda: entender as necessidades futuras e **como a demanda e a oferta evoluem ao longo do experimento** pode ser um forte sinal para justificar o crescimento de uma equipe ainda mais ou estar proativamente preparado para outro plano. A maneira menos arriscada que conheço de fazer isso é observar a oferta e a demanda de perto e ser transparente sobre suas observações com todas pessoas envolvidas.

### Tomando uma decisão

Como você sente que o novo experimento atingiu a maturidade, **compartilhe suas descobertas internamente e abra para discussão**. O [model, document and share](https://lethain.com/model-document-share/) do Will Larson pode funcionar bem para iniciar a conversa com uma perspectiva informada em vez de autoritária, especialmente se você for a pessoa responsável pelo sucesso da equipe, onde pode ser fácil ser top-down desnecessariamente.

Também é importante recapitular o que você estava tentando alcançar coletivamente e o quão bem-sucedido foi ao fazê-lo. **Organize uma reunião retrospectiva para refletir** sobre o que deu certo, o que deu errado, o que deveria mudar e resumir as lições aprendidas. Neste estágio, você tem a oportunidade novamente de construir um entendimento compartilhado e decidir como deseja seguir em frente. Use o resultado desta retrospectiva como entrada para o que você comunicará publicamente.

Em seguida, você provavelmente já tomou uma decisão. Se você tiver alguém preocupado com a mudança, reserve um tempo para **ouvir e entender as necessidades individuais das pessoas**. Às vezes, nem todos ficarão felizes com a mudança. Pessoas insatisfeitas têm todo o direito de querer descobrir como será o futuro para elas, e é sua função e responsabilidade apoiá-las na busca por algo que as agrade, de preferência dentro dos novos times ou da organização.

Na próxima etapa, independentemente do resultado do experimento, **torne suas descobertas públicas**. Volte ao contexto que gerou o experimento, como foi abordado, o que você aprendeu durante o processo e compartilhe a mudança com o público afetado por ela. Se você acha que o experimento deu certo, a Uma Chingunde tem um ótimo post sobre [comunicar mudanças organizacionais](https://umach.medium.com/communicating-organizational-changes-6277e4b47cff), que é excelente para esse propósito.

___

Mudar nunca é fácil, mas geralmente é para tornar as coisas melhores. Acredito que os aspectos mais importantes para reorganizações de equipes bem-sucedidas são encontrar clareza sobre o porquê, ter a opinião das pessoas sobre o processo e ouvir as pessoas com atenção. Novamente, raramente é a única resposta para um problema, mas se você acha que é o seu, experimentar antes de tomar uma decisão final pode ajudá-lo a gerenciar os riscos de forma mais conservadora.


Times de engenharia, como sistemas, podem crescer de maneiras inesperadas. Utilizar conceitos de experimentação pode ajudar em tais cenários.

Reorganizando times através de experimentação


Depois de postar [minhas opiniões sobre postura em entrevistas de system design](/pt/posture-in-system-design-interviews) no [TechWriters](https://lethain.com/techwriters/), [David Golden](https://twitter.com/xdg) me inspirou a escrever sobre calibrações em entrevistas técnicas. O ângulo que estou abordando calibragens neste artigo é intencionalmente estreito, pois escolhi um caminho para falar mais sobre como as calibrações contribuem para um processo de contratação mais justo e equilibrado e, como consequência, mais eficiente. Por causa disso, estou abordando o assunto das calibrações para duas perspectivas:

1. Como um grupo de entrevistadores pode avaliar e chegar a um entendimento comum de quem é a pessoa mais adequada para uma contratação;
2. Como a gerente responsável pela contratação pode aumentar a certeza de que está tomando a melhor decisão para sua equipe e organização.

Mesmo que meu objetivo seja abordar o assunto com a maior transposição e objetividade possível, calibrar entrevistas não é de forma alguma um assunto imutável, transferível ou exato. Semelhante a qualquer sistema ou conceito complexo, esta é uma representação excessivamente simplificada do assunto como uma tentativa de torná-lo mais digerível. Calibragens são um assunto com muitas nuances, mesmo dentro do mesmo contexto de cultura organizacional e ainda mais para diferentes organizações. Diferentes organizações esperarão resultados diferentes de processos de contratação, e para cobrir calibragens no grau de profundidade para fazer justiça ao assunto, seria necessário entender especificações do processo de contratação projetado para sua organização, que está fora do escopo e alcance desse artigo.

### Contexto e pré-requisitos

Para aqueles que não estão familiarizados com o termo: caligragens de entrevistas servem o propósito de encontrar um consenso entre entrevistadores sobre o desempenho geral de um(a) candidato(a) e, em seguida, comparar o desempenho dos candidatos(as) entre si, para que avançar com a pessoa mais adequado para a próxima etapa de entrevista ou a uma oferta de emprego.

Mesmo que as calibragens das entrevistas possam ser desestruturadas, como por exemplo falar de forma informal sobre impressões gerais sobre um aplicante, abordá-la dessa forma tem uma grande propensão a dar errado. Os gerentes de contratação e as pessoas mais seniores no ciclo de entrevistas geralmente estão bem posicionados - mesmo que não intencionalmente - para influenciar as opiniões dos outros, tornando o processo menos justo e mais tendencioso.

Dessa forma, acredito que os pré-requisitos para calibrar razoavelmente candidatos são:

1. **Uma estrutura que define o nivelamento em toda a organização**, delineando funções, expectativas e impacto para cada nível - o que Junior, Pleno, Senior, Staff e outras funções significam na prática;
2. **Um processo de entrevista bem definido por nível ou plano de carreira** que seja usado de forma equitativa para todos os aplicantes, independentemente das circunstâncias, como referências ou retorno de funcionários;
3. Para etapas de entrevista mais estruturadas, como entrevistas técnicas, **um banco de dados de perguntas com orientações claras** à disposição da pessoa entrevistadora;
4. **Um programa de treinamento como pré-requisito para entrevistar candidatos**, cobrindo o que é importante para a organização, abrangendo desde aspectos práticos até D&I e treinamento de preconceito e bias inconsciente.

Esses pré-requisitos ajudarão a estabelecer uma base para comparação objetiva entre o talentos existentes na organização, uma forma padronizada de avaliar os candidatos e que os entrevistadores entendam como avaliar os candidatos de forma justa.

### A função da pessoa entrevistadora

Acredito que um bom ponto de partida da perspectiva dos entrevistadores, independentemente de sua função, é **estudar a estrutura de nivelamento de pessoas**. Entender o nivelamento é, inerentemente, entender as expectativas de uma função - e esse é um ponto de partida para garantir a justiça. Em outras palavras, além de definir que quem faz x, y e z é Engenheira Sênior, definir qual tipo de impacto e efeito você espera que essas pessoas tenham na função ajuda a esclarecer o que você está procurando para as necessidades da vaga aberta. Estudar esta estrutura ajuda a calibragem, pois se você entender as expectativas para uma função, poderá avaliar um candidato de forma mais objetiva.

Em seguida, **ter dados e critérios comparativos entre candidatos sob diferentes óticas** também pode ser útil. Em situações em que há restrições, como menos vagas abertas do que candidatos que passam da barra de entrevistas, pode ser difícil definir qual candidato é mais adequado para a vaga, especialmente se pessoas diferentes entrevistaram candidatos diferentes. Já vi isso ser resolvido de duas maneiras: ter mais de um entrevistador por entrevista (por exemplo, um entrevistador principal e um [entrevistador sombra](https://rework.withgoogle.com/guides/hiring-train-your-interviewers/steps/giving-interviewers-practice/)) ou tendo mais de uma entrevista do mesmo tipo por candidato (por exemplo, duas entrevistas de system design dentro do mesmo ciclo de entrevistas feitas por pessoas diferentes). Ambos podem ajudar a diminuir bias e dar aos entrevistadores mais ângulos para debater, comparar e calibrar os candidatos entre si por meio de mais perspectivas para os mesmos critérios.

Outra tarefa crítica é **definir o que se espera como um bom resultado para uma fase de entrevista antecipadamente**, para que você tenha o que calibrar após a entrevista, caso tenha várias pessoas passando no processo. O que "melhor" significa é, na maioria das vezes, relativo, portanto, discutir nos mesmos termos com outros entrevistadores no caso de vários resultados positivos nas entrevistas ajudará a condução de discussões específicas. Por exemplo, para uma entrevista de projeto de sistema, você provavelmente está procurando por critérios como "conclusão", "priorização", "profundidade de conhecimento", "amplitude de conhecimento", "comunicação", "entendimento de trade-offs" e assim por diante. Observações adicionais fora do escopo podem ajudar na decisão geral, mas para garantir que o processo funcione conforme previsto quando projetado é essencial ater notas de performance aos critérios do estágio de entrevista em questão.

Em consonância com o ponto anterior, **definir como o desempenho por etapa da entrevista é mapeado ao nivelamento de um candidato** pode ajudar a informar o processo. Para fins de contexto, o nivelamento de um candidato geralmente leva em consideração o desempenho geral do candidato durante a entrevista, além de suas realizações e experiências anteriores. Ou seja, o desempenho geral deve ser apoiado pelo desempenho em cada etapa, que então é ser apoiado por critérios de avaliação da etapa. Um exemplo um pouco mais tangível é, por exemplo, em entrevistas de system design, pessoas engenheiras experientes são mais propensas a terem um nível mais profundo de consciência sobre trade-offs sendo feitos em comparação com pessoas menos experientes. Entender o que esperar em termos de desempenho para cada estágio de entrevista para cada nível pode ajudar a tornar a decisão mais justa. Porém, esteja ciente de que transformar a avaliação em um processo exclusivamente objetivo ou mecânico também não é desejável, o que nos leva aos próximos dois pontos.

Provavelmente, você não precisará tomar uma decisão exclusivamente com base nos sinais coletados na fase de entrevista que conduziu. Dito isso, **dar aos candidatos o benefício da dúvida por padrão** pode ser uma maneira generosa de falar sobre as habilidades de alguém que você mal conhece. Entrevistar é uma experiência estressante, principalmente quando o candidato realmente quer a vaga. Em vez de julgar pretensiosamente se alguém é adequado ou não para uma função, entender a entrevista como um snapshot dos comportamentos observados ajuda a se manter aberto(a) para ser convencido a opiniões contrárias - tanto para favorecer a contratação quanto para retirar sua recomendação de contratação.

Por fim, se você chegar a uma situação em que tenha mais de uma ótima candidata por função e a notas entre os entrevistadores para o mesmo tipo de entrevista revelar que provavelmente há um empate, **delegue a decisão a outros estágios de entrevista**. É difícil obter uma imagem precisa da capacidade de alguém em uma entrevista de 45 minutos. Em algum ponto, a precisão para ordenar candidatos fala mais sobre seu próprio viés do que sobre as qualidades do candidato, portanto, deixe outros critérios conduzirem a decisão.

### A função da gerente de engenharia contratante

Um dos principais aprendizados que tive como gerente foi **contratar primeiro para a organização e depois para a equipe**. Independentemente da maturidade da organização que você faz parte, as coisas darão errado com frequência. Ter uma estratégia de contratação estreita demais pode trazer consequencias dramáticas. Bons exemplos disso são um projeto em que uma pessoa foi contratada para tocar ser desincentivado, ou decidir comprar software de um fornecedor em vez de construí-lo internamente. Essas são circunstâncias em que as calibragem é útil - se o nivelamento for padronizado em toda a organização, mover as pessoas para o próximo papel lateralmente é menos prejudicial para todos os envolvidos.

Dito isso, **resista ao impulso de pensar exclusivamente nas lacunas que suas equipes tem** e em suas necessidades específicas. Como gerente, você obviamente deve estar focada nos problemas que estão no seu escopo de trabalho, porém, as pessoas podem acabar precisando de mais do que isso para permanecer ou crescer na organização. Investigar se existem necessidades semelhantes em algum outro lugar da organização pode ajudar a tomar uma decisão mais assertiva. Validar suas suposições com outros gerentes e alinhar uma potencial responsabilidade adicional para uma vaga antes mesmo de contratar uma pessoa pode forçá-lo a pensar em qual é o caminho de progressão desse candidato dentro da empresa e garantir que você possa trazer alguém com um espaço de problema claro para assumir. No lado positivo do exemplo anterior, se as coisas correrem incrivelmente bem, essa pessoa terá opções para escolher seu caminho dentro da empresa, o que é extremamente positivo.

**Antes de decidir por um candidato específico, calibre-o em relação à estrutura de nivelamento** para garantir que você está nivelando as pessoas recém-chegadas de forma justa. A maioria das empresas tem situações em que níveis têm responsabilidades e faixas de remuneração sobrepostas. Para alcançar a promoção para o próximo nível, é preciso ter um desempenho consistente no próximo nível, então, ao trazer novas pessoas, é importante nivelá-las corretamente, mas ainda mais, você quer ter certeza de fazer as coisas certas para o time dessa pessoa também. Nos casos em que você não tem certeza sobre o nível de uma pessoa, fazer uma oferta do nível abaixo é geralmente a coisa certa a fazer, pois promover alguém dentro de 6 a 12 meses é mais simples do que ajustar o nível para baixo depois que a pessoa já estiver na empresa.

Um cenário típico como gerente é direcionar a contratação para seus projetos, equipes e necessidades. [Este artigo do Google](https://ai.googleblog.com/2006/03/hiring-lake-wobegon-strategy.html) descreve como a contratação por projeto/equipe afeta a qualidade geral de talento na empresa. Como gerente de contratação, o que você pode fazer a esse respeito é **calibrar os candidatos em relação aos seus pares em potencial**. Isso pode ajudar a alcançar resultados semelhantes em termos de qualidade de talento à estratégia usada pelo Google. Pense em equipes ou organizações adjacentes que têm pessoas no mesmo nível para o qual você está contratando, dentro da mesma disciplina, e entenda os deveres, impacto e responsabilidades dessas pessoas. Isso provavelmente revelará como essa candidata se encaixaria no quadro geral, garantindo assim a qualidade de talento em toda a organização.

Além disso, **calibre os entrevistadores uns contra os outros, para que você tenha uma média ponderada como medida**. Entrevistadores diferentes têm critérios diferentes para avaliar as pessoas, mesmo com uma estrutura de nivelamento bem definida. Tenho a impressão de que muitas vezes tenho tendência a focar no lado positivo de entrevistas. Outros podem ser muito mais conservadores em relação aos riscos e tendem a recomendar "não contratar" quando faço recomendações de "contratar". A grande maioria dos sistemas de gestão de aplicantes tem [relatórios de calibração](https://help.lever.co/hc/en-us/articles/206403385-How-can-the-Interview-Calibration-report-help-me-identify-bias-in-interview-feedback-) que podem ajudar a entender como os entrevistadores tendem a classificar os entrevistados que receberam ofertas, e isso pode servir como um sinal para avaliar o desempenho geral quantitativamente, sem aprofundar muito em análise.

Então, para decisões divididas, onde entrevistadores têm opiniões diametralmente diferentes ou o nível de incerteza é alto em vários estágios, **aumente o alinhamento e a consistência através de uma reunião de revisão do pacote de entrevistas**. Esse tipo de reunião geralmente consiste em reunir todos os entrevistadores que participaram de cada etapa do processo de entrevista do candidato, chegar em um consenso e, em seguida, tomar uma decisão final. Normalmente, é uma excelente oportunidade para entender onde pode haver ambiguidade para um critério dentro de uma etapa de entrevista, para dar feedback aos entrevistadores e receber feedback sobre o candidato e o processo, e como consequência disso, melhorar o processo e torná-lo mais justo e decisões mais precisas.


___

Como dito anteriormente, esta é apenas a ponta do iceberg - calibrações de entrevistas de pessoas engenheiras de software são um assunto fascinante que provavelmente exigirá esforços interdisciplinares de equipes de pessoas, como aquisição de talentos e recursos humanos, bem como perspectivas técnicas. Para garantir calibrações e contratações mais justas, é fundamental continuamente avaliar, medir e, por meio de sinais quantitativos e qualitativos, evoluir o processo.


Avaliar quem é o melhor candidato para uma vaga não é, de forma alguma, uma tarefa simples. Aqui estão algumas das minhas abordagens sobre este assunto.

Gestão de Engenharia