Stories about product, engineering, leadership, business, strategy, work organization, and more.

Featured Posts:

Written with ❤️ by @duponico 🐦️

11 - Earn Trust

You just became the manager of a team of engineers.

I bet you will recognize yourself in one of the following categories:

✅ you’ve just been promoted from senior engineer or team lead, and you’re now managing some teammates who were your peers.

✅ you’ve just been promoted and given the lead of another team you don’t know.

✅ you’ve just been hired as a seasoned engineering manager in a team you don’t know.

✅ you’ve just been hired as a junior engineering manager in a team you don’t know.

The last case is unlikely, it’s very uncommon to hire an engineering manager who never handled this role, or a people management role in a previous company.

Whatever your category, whatever your past experience or achievements, you will be labeled as a newbie. Because you don’t know the team, or you don’t know the activity, or because you’re a junior in your position.

You have to acknowledge and accept it. Especially if you’re starting this new career, you know nothing about the job.

You’ll need to work hard to build trust with your team. Being trustworthy does not happen overnight. So how should you proceed?

Listen more than you speak. Listen a lot, gather as much knowledge as possible, ask genuine questions, and show your sincere interest.

Be fully present when you’re discussing, and never do other things like watching your mobile, your laptop, etc.

Be humble, don’t start to explain X, Y, Z to a team who knows more than you. If you used to be a tech specialist, resist the urge of showing off your tech talent or bragging about how you would build this tech piece.

Your tech knowledge is a great asset. It will help you to mentor your reports, to understand and anticipate problems, to articulate great plans, to build credibility. But you should avoid using it too much at the beginning, you need to first establish trust and master the context.

Be reliable. Say what you do, do what you say. Never lie, never over-promise, never tell things you’re not sure about.

Resist the urge of changing things. You may have the feeling that that’s precisely why you’re here. But don’t try to change things before having a very strong understanding of the context, and the potential impact of a change.

List the pain points raised by the team. Identify among them some low hanging fruits, easy to fix, creating a positive impact and fix them by yourself. It will highlight the fact that you’re here to support the team, that you’re actively engaged in improving their work situation.

It will also help you to train your new muscles. Starting with small things, winning small battles. Like when you started as a software engineer, you didn’t start by revamping a super central or complex part of the system. You fixed small bugs, you made small improvements.

A good way to identify the complexity of an organizational problem is to look at who will be impacted, few mates, one team, several teams, one department, several departments, the company. At first, deploy some local improvements, impacting only your team, and do it by involving your reports.

Communication, both written and oral, is a critical aspect to work on. Use your first improvements as examples to muscle it up. Why do we need to change? What do we change? How do we change? What are the expected benefits? Who should be consulted, involved, informed?

Use these examples and actions to assess the boundaries of your own playground with your manager. Depending on the companies, and contexts, you can get a huge push back when trying to change something a bit out of your scope. If it happens it might also mean you didn’t identify the impacts of this change well.

Don’t try to impress everyone. Reward the team for their successes, take the blame when it happens. Don’t claim the merits. Once again, it’s not about you, it’s about the team.

Accept and acknowledge your mistakes. Don’t try to hide things when you mess up. Teammates know you failed, trying to hide or argue or reject the fault on someone else will destroy the trust. Own your mistake, apologize, take actions to not reproduce it, and move on. The only way to make zero mistakes is to do nothing. Mistakes will happen, it’s ok.

Find the right balance between protecting the team from external pressure and making them aware of the overall context and situation.

Understand that you’re now the representative of the team and they deserve to be well represented. When you talk, you engage them as you engage yourself. We build trust by our actions and our behavior, by being consistent, by being reliable, by helping others. A lot of small and concrete actions will contribute to building the strong grounds, the foundations of the team’s trust.