The Product Triangle - Michael Lopp from Slack at Elevate 2019

Michael Lopp (AKA Rands) has been into engineering leadership for the last 3 decades. He has built products at companies like Netscape, Apple, Palantir, and Pinterest to name a few.

Michael now works at Slack where he takes care of Product Engineering. We had the pleasure having him talk at our Elevate conference, in front of 500 people. Besides his energizing tone, Michael shared an interesting take on the product triangle and how it impacts organizations.

Elevate Conference — Michael Lopp, Slack's VP of Product Engineering — "The Product Triangle"

But before diving deeper into the product triangle, there’s something Michael wanted to talk about: accountability.

Accountability

Accountability is the scary word people never like hearing. It is often understood as a responsibility, which means, in the head of some managers: “I’ll chop off your fingers if something goes wrong.”

Fortunately, this isn’t the actual meaning. Taking a definition from the dictionary, accountability is: Being required or expected to justify actions and decisions.

Giving account is more empowering than just blaming people for bad decisions. It's about having the ability to describe why you did something, what is the reason behind, why you built something, why you proceeded that way. But in any big organization, it starts to become hard as more employees usually mean more confusion in terms of accountability. How should it be articulated?

The Product Triangle: engineering, product management, and TPM

According to Michael, what makes an organization successful is making engineering, product management and technical program management (TPM) work together. This is what he calls the Product Triangle: 3 pillars that have positive interactions to make a project or a product successful. Each department has its own strengths: engineering knows how to build, product management makes the product more human and in line with the business value, and TPM helps create a logical progression of work.

‍

Michael shared with us the main roles of each side of the “product triangle”.

Engineering: the How.

Engineers are the “how” side of the product triangle. They are here because they have the know-how and will take the best technical decisions to build a flawless product. The role of engineering leaders is thus the following:

• Building and growing a team
• Aligning to the product strategy
• Allocating the right engineer to the right job
• Setting clear goals for the team
• Building a strong and healthy team through actionable feedback

Product Management: The What, the Why.

Product Managers are the ones who transform a business requirement into a product. They have in mind the purpose of the product or feature (the “why”) and the vision for what it will look like (the “what”). Their role encompasses the following:

• Managing product strategies, vision and go-to-market approach
• Articulating the business value
• Being the voice of the customer
• Setting clear goals for the team

TPM

Technical Program Managers (TPM) are the ones who…manage technical projects from the ideation phase to the completion. They are here to lead cross-functional teams, report to the executives, assess progress and metrics. They are the “glue” that enables engineers and product-people to work together in the best manner. Their role includes:

• Mapping interrelated sets of dependencies and projects
• Creating a logical progression of each project
• Identifying pitfalls and bridging the gap between groups or teams
• Partnering with cross-functional teams with minimal escalation
• Helping define goals, metrics, priorities, and roadmap

While these main guidelines helped us defined the roles, Michael warned us that the balance between each side of the triangle is fragile, as no role should dominate another in order to get more meaningful results.

Accountability in a growing team

In Michael’s opinion, everything starts to be confusing when you get past Dunbar’s number (120–150 people) in an organization. Grey areas appear between teams, and they are vast and go on forever. As there is some miscommunication, questions start to pop: Who is responsible for this? Who is in charge of that? Who is the decision-maker? Who takes care of this thing? Who builds a schedule? Who is accountable? Who is the “main voice” for that particular feature? And so on.

The biggest challenge is, therefore, to make sure that all responsibilities between the different teams are well-defined, and the list of things to define is usually endless. For a leader to succeed, Michael suggested a few things.

Old Guard vs. New Guard

Michael advises taking advantage of both the old guard and the new guard to make an organization work.

The old guard consists of the people who are responsible for what the company is today. They have more experience inside the organization and have that “magical knowledge” of how the company works and who’s accountable for what. It’s crucial as a leader to go and talk to these people who know (almost) everything and carry the company culture. They have disproportionate power because they have more knowledge of the company’s inner workings, and people usually follow their lead.

The main issue is that they don’t scale after a critical size: this is where the product/engineering leader intervenes to get more insights and share their knowledge. However, they have a tendency to never write things down as they assimilated them bit by bit during the years and the transfer of knowledge can be a bit painful.

On the other hand, the “new guard” shows up to fill the gap. They are usually happy to bring their contribution to the organization but it takes them some time to get a sense of how things work in the org. They try to figure out everything fits together as more people join the team.

To ensure both the old and the new guard can work together in an efficient manner, leaders have to proceed as follows.

Making it work

Here is a 3-step process shared by Michael:

• 1. Solo: write down your key responsibilities, those of your peers, and who is accountable for what in your own opinion.
• 2. Ask a peer: as your own opinions are subjective, you should ask a peer to do the same exercises by themselves and then compare notes to see where the gray areas lie.
• 3. Sign a contract: the “contract” is a protocol where all stakeholders define the key responsibilities for all the gray areas so that it’s clear who does what.

This will help grease the wheels of the whole organization and ensure the work experience is frictionless for each side of the product triangle. The process is iterative as teams grow, new people join, some people leave, projects change, team structure gets modified, etc. This means the process should be repeated any time a leader believes things could run more smoothly.

Life advice

During the day, we asked each and every speaker to give us one piece of advice they believe shaped their life. Michael talked about his daughter Claire, and how he spent his life making a point of not being late. While he acknowledged being late isn’t always an issue, he reminded the audience that being on time during your whole career shows something about commitment, dedication, and leadership.