I was recently fortunate to hear Marty Cagan talk at Berlin about creating empowered teams. Empowerment is a super power, and is often abused and beaten around during conversations, leading to its cliched status. Marty acknowledged this rightly, when he started the talk by saying that this is not his favourite topic to talk about. In this article, I will attempt to cover as much ground as possible with insights and key learning from Marty’s talk, that will hopefully leave you with inspiration to go make this happen at work.
We start with the basics. What are the techniques of Product discovery :- Value (Will the customer buy it ?), Usability (Can they figure out how to use it ?), Feasibility (How to build it ?) and Viability (Does it actually work for our business ?). There are qualitative and quantitative techniques to perform product discovery. We keep this basics in our mind as we try to understand the needs of creating an empowered team around it.
What are truly empowered teams ?
In most organisations, teams exist to serve the business, or as it is stated when asked to an executive. In such organisations, teams are given a roadmap to work on, and hence taking away the empowerment from them.
In good organisations, teams exist to serve the real customers, in ways that meets the needs of business. In order to do that, they need to be empowered.
Why do not companies empower their teams ?
In short, Leaders do not Trust their teams. And teams have to have the competence necessary before being trusted.
Marty called out the three giants of Tech industry : Apple, Google and Amazon. These three organisations have different cultures, sometimes diagrammatically opposite to each other. Yet, they are pinnacles when it comes to doing “product” well. How can it be ?
The secret it seems could be one man.
Bill showed the leaders of these tech giants how tech leadership really works.
Leadership is about recognising that there is greatness in everyone, and your job as a leader is to create an environment where that greatness can emerge.
This is what is missing from organisations that are not Amazon, Google or Apple. They do not empower there teams. And to change this, the answer lies in leadership and management.
Leadership vs Management
Leadership serves to inspire people to greater accomplishments, and management exists to motivate them to the objective. Unfortunately, not all managers are leaders. And hence they need to be called out separately.
What is the role of Leadership in a product organisation ?
According to Marty, there are 5 key aspects that define the role of a Leader in a product org.
a. Setting up the Product Vision : A Product vision describes the context for the empowered teams to make decisions
b. Setting up Product strategy : This is needed to make the vision a reality. It provides the path to the team to accomplish the vision.
c. Having Product Principles : This helps teams decide how to solve the problem that they want to solve.
d. Having Product priorities : The alternate to a roadmap is OKR. Some organisations are doing both — OKR and Roadmap. But OKR is really the alternative to roadmap. Think about it ? The job of a leader is to set the objective and have the teams empowered to deliver on these objectives. Leaders must set “What is important this year” and then get away from the teams to let them deliver.
e. Evangelising Product : A leader needs to preach to the missionary teams, showing them “why it” matters. The larger an organisation gets, more critical is product evangelism. A leader needs to evangelise the product to the stakeholders, investors and even customers. It is a daily thing, and not a one time activity.
The combination of curiosity, respect, and kindness combined with a crazy work ethic will take you anywhere you want to go.
Good product people need to know what they need to know and they need to admit that they do not know. Good product people must avoid arrogance, and have a sense of curiosity to learn. This lack of arrogance is demonstrated by admitting that they lack information, and they have the will and capacity to learn it.
It doesn’t make sense to hire smart people and then tell them what to do. We hire smart people so they can tell us what to do -Steve Jobs
What is the role of Management in a product organisation ?
By Management, Marty refers to People manager who are responsible for hiring and managing key product roles — engineering, design, product manager. The manager is responsible for building the trust, that we saw earlier is the reason teams are not empowered.
According to Marty, there are 5 key aspects that define the role of a Manager in a product org.
a. Staffing : A manager is responsible for sourcing and networking to find the right people for the team. They cannot just outsource that to the Staffing team. They need to interview, onboard, evaluate and administer the people in their team.
b. Coaching : A manager is responsible to create a confident team by coaching them for the next level. Marty gave an example of HP’s (Hewlett Packard) engineering management program which ensured high quality managers within their organisation. In a typical product org, Product managers usually do not get coaching. And this is a key area of concern. A manager must figure this out to enable coaching for their Product people.
c. Objectives : A team should not be told what features to built, but instead what problems to solve. Managers must provide the objectives and let the team propose “Key Results”.
For an empowered team, the role of leadership and management is more important and critical to the team’s success.
The advise from Marty to the managers is to cultivate the skill to “create” people by getting good at coaching.
How do we build trust for empowering teams ?
Trust is a function of two things : competence and character. Competence includes your capabilities, your skills, and your track record. Character includes your integrity, your motive and your intent with people. Both are vital.
To hire for competence, Hiring managers should know what GOOD should look like. Most Hiring managers lack this understanding and they do not know what to hire fore. Hiring 10x people does not translate to 10x team.
When mentioning about Character, Marty gave the example of “New Zealand All Blacks”, the infamous Rugby team that has a significant success record amongst all teams in the world. This team has performance and a culture. The culture is “No Dickheads Rule”. A team must have the right personalities. Marty called out the study from Google around teams and their composition under Project Aristotle that defines Psychological safety as a key need for Teams. Putting an All stars team does not work in real world. Therefore look for the right people with right mindset, not the ones who bring pain and humiliation in a team. Marty also called out “Culture fitness” as a fad and too vague to be of any merit. Being “culture fit” is a parlance for hiring people that look the same, behave the same and think the same as others. Instead, from the pool of people you have for hiring, filter for competence, and then weed out assholes.
Best Teams are composed of ordinary people doing extraordinary things.
Marty also touched upon the role of a senior engineer. According to him, senior engineers build when they are convinced. A Senior engineer needs to be fearless. When hiring for senior engineers, ask if you would love working with them ? Are they competent, and not an asshole ? Can you work with them to solve hard problems ?
What is the true test of empowered teams ?
- Is your team staffed with competent people with necessary range of skills ? Avoid pretend-to-be’s.
- Is your team assigned problems to solve, and are they able to decide the best way to solve these problems ?
- Is your team accountable for solving the customer or business problem (outcomes)
The questions from audience were also insightful and sparked interesting response from Marty.
1. How do we hire for competence for a Product management role ?
This is a problem not just for Product managers but also for Design roles. From Marty’s observations, the average competency of a product manager goes down with time thanks to Agile. This is not about Agile bashing, but how it is interpreted, especially the role of a Product owner. A CSPO certification does not make a Product owner.
CSPO is basically a competence for JIRA administrators
This is what Marty looks for in a Product manager :-
a. An expert on their customers (actual users)
b. Having deep knowledge of data generated from their customer
c. Understanding how their company really works — marketing, sales strategy, legal concerns, constraints of their organisation. This is the reason a PO is called the CEO of their product.
d. Being humble
e. Deep knowledge of Trends in their industry and emerging technologies like AR, VR, ML / AI.
A Product manager is not a boss of anybody, and yet has skills that are relevant for a CEO.
According to Marty, you may hire for Potential as well, if the person does not have deep experience with product management. But for such a person, there needs to be right support for coaching, that sets the person to become competent.
2. How do you keep your teams accountable ?
In good organisations, if a team misses their OKR, they should have a post mortem. This post mortem must involve peers, and especially dependent teams if there were commitment key results. This is a great opportunity to learn and be humble, and prepare for the next quarter / year.
Lastly, there were questions about finding the right person for your team (avoiding assholes) and the need for Product managers to remain ethical.
Marty ended the talk by stating that there was an additional point in the Product discovery: Asking if the team should really build it ? — this should trigger the questions around the impact of your product’s feature on society and overall ethics.
It was an amazing talk by Marty Cagan, one that had dollops of humour, but packed with insights that you could take back home and introspect. I hope this article continues to remain useful for all readers and act as a ready reference to come back to whenever you need words of wisdom.