• 💪 Do everything you can to empower your engineers so they own problems and not only solutions.
• 💡 Be curious and learn their language.
• ⚛️ Shield your team from the outside noise.
• 👩‍💻 Know your product, even its dark side.
• 📣 Align by communicating.

💪 Empowerment 

Teams of missionaries are engaged, motivated, have a deep understanding of the business context, and tangible empathy for the customer.
Teams of mercenaries feel no real sense of empowerment or accountability, no passion for the problem to be solved, and little real connection with the actual users and customers.

Missionaries vs. Mercenaries

Extracted from the Spotify Engineering Culture

Your goal as a product manager is to make sure everyone in your team gets why they work, and why your company believes in what your team is pursuing.

They need to understand the company's vision, and how your team's vision ties to it.
They need to understand the company objectives, and how your team is contributing to them.
They need to know their users, their wishes & pains, through accessible user feedbacks.

Empowering engineers is far from easy.
If not done right, it can lead to a lot of noise & overhead, and would be counter-productive.
It's a delicate balance.

My goal is to make sure the team is a great understanding of how we take decisions about what problem to focus on while maximizing the time the team has to find and build the best solutions.


Some tips on how I keep my engineers empowered:

• I take bottom-up inputs to revise the company product vision from each team member as part of a recurring event called the Rolling Strategy Process happening every 3 months.
• We shape the team product vision together as a team.
• I try to make sure that our contribution to the company objectives can be easily understood and tracked via accessible dashboards. 
• I make sure user feedback is accessible by everyone in the team. I spend some time reading it weekly, and share a digest with my team.
• Once we know which problem to solve, we always ideate together in order to find potential solutions.
• When I plan to do some user interviews, I usually invite some of my engineers to one of them.
• If I need to talk to a third-party partner (for example we are actively looking for our next payment partner), I either involve some of my engineers or share updates regularly with them if I consider the session will be too high level.

💡 Curiosity 

I believe that you need to be curious and learn what software development really means.



Admittedly, this may be a bit simpler for me: I have a master of engineering, I have a hacker mindset, and try to cultivate it with side projects every time I get a chance.

I cannot give you the scope of what you need to understand, as it vastly depends on how your company operates, and your affinity with learning technical topics.

Try to learn at least the following terms and concepts 

• A front end
• A back end
• An API
• A data model
• A persistency layer
• A pull request
• A repository
• A deployment
• A rollback (or fallback)

• The review & approval process (How engineers are making sure that issues are surfaced and fixed before reaching your customers) 
• The deployment process (How a piece of software code transitions from done to available to your customers)
• The programming languages used by your engineers.
• The high-level architecture of your product

Our checkout application contains 3 pages : a delivery section, a payment section, and a success screen. 
Today most of the code needed to run the 3 pages is loaded when our users reach the first page.
It increases the response time on a very critical flow of our product.
With NextJS, we will automatically load only the right code at the right time, decreasing the response time and optimising the overall user experience of our checkout.
On top of that, migrating to NextJS will reduce the number of dependencies that our front-end engineers have to tediously handle manually.

⚛️ Entropy

It’s your job to shield your teams from stupid shit. Like time-sucking questions, unnecessary drama, and the whims of execs. People outside your team have no idea how much impact their ad hoc asks and “quick” questions have on the team. It’s your job to help them see this, and to protect your team from them. Help your makers (e.g. engineers, designers, etc.) stay focused and in flow. Unfurl your shit umbrella.

See twitter thread

Then, consider the current iteration (sprint, cycle, whatever its name) unbreakable.

If your company has a good understanding and implementation of agile, you should rarely learn things that are going to jeopardize what your team is doing right now (ie, in the current iteration).

🤔 Why?
Because agile teams either build to learn if they are on a discovery phase, or build safe bets that are already validated if they are on a delivery phase.
Plus these safe bets are very small: the size of the iteration (usually short).

If a new piece of information makes your current goals irrelevant then:

• Either you are building something that was not validated in a discovery phase
• Either your iteration is so long that context changed

There is nothing special about bugs that makes them automatically more important than everything else. The mere fact that something is a bug does not give us an excuse to interrupt ourselves or other people. All software has bugs. The question is: how severe are they? If we’re in a real crisis—data is being lost, the app is grinding to a halt, or a huge swath of customers are seeing the wrong thing—then we’ll drop everything to fix it. But crises are rare. The vast majority of bugs can wait six weeks or longer, and many don’t even need to be fixed. If we tried to eliminate every bug, we’d never be done. You can’t ship anything new if you have to fix the whole world first.

Shape-up

👩‍💻 Knowledge

• Your product 
• Its history 
• Its bugs
• Its funky business rules
• Its quirks
• Its edge cases
• Why were certain decisions taken a few years ago
• What was already tested
• What failed 
• etc.

A product is like an onion, and your users only see the outer layer.
A product manager should know the whole onion.

A good product manager should be able to break his own product by pressing exactly where it hurts, and then explain to everyone why the team never worked on this specific edge case.

This is super useful for your engineers. You can point them towards potential pitfalls, dark edge cases that may cause a problem a few iterations down the road, and so on.

A small tip:
I keep a list of onboarding challenges that I use every time a newcomer is joining my team.
It consists of a list of tasks (or jobs) to be done on our product, as a user.
Each job is more complex than the previous one and builds on top of the learnings of the previous jobs.

It's a very fun way to learn your product and its intricacies as an engineer.

Example of an "onboarding challenge"

📣 Communication 

• The assumptions
• The tests you made, and their results
• The business rules
• The design choices
• The wording choices
• The edge cases that are considered out of scope
• What you decided to track, and why.