Transitioning from IC to Management

Engineering Manager, Mobile Developer Experience

Slack

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

Plato ELEVATE Summit Keynote: "Synergy: Building Strong Engineering Teams"

Nurturing an inclusive workplace

**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"](https://youtu.be/lNE-Vm-q9Iw)

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

## Accountability

[Accountability](https://community.platohq.com/stories/accountability-or-nothing) 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](https://community.platohq.com/stories/increase-accountability-through-commitments-and-followup) 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?

![Elevate by Plato](https://uploads-ssl.webflow.com/5ba170a39dd35e64ce65494a/5d6ffeaf8fe39813f8a15c29\_Elevate%202019%20by%20Plato%20-%2087.jpg)

**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.

![Elevate by Plato](https://uploads-ssl.webflow.com/5ba170a39dd35e64ce65494a/5d6ffcd3884d46044e6163b5\_1\*21BxXGmbfuKVw8Qur1YOcQ.jpeg)

‍

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](https://community.platohq.com/stories/building-a-team-from-scratch) 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](https://community.platohq.com/stories/how-to-deal-with-unhealthy-team-dynamics-) 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](https://community.platohq.com/stories/building-products-for-people-want), 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.

![Elevate by Plato](https://uploads-ssl.webflow.com/5ba170a39dd35e64ce65494a/5d6ffed3884d46801f616b31\_Elevate%202019%20by%20Plato%20-%2091.jpg)

## 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

![Elevate by Plato](https://uploads-ssl.webflow.com/5ba170a39dd35e64ce65494a/5d6fff63be2ead799cb762bb\_Elevate%202019%20by%20Plato%20-%2094.jpg)

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

![Elevate by Plato](https://uploads-ssl.webflow.com/5ba170a39dd35e64ce65494a/5d6fff097bc62c805a524b4e\_Elevate%202019%20by%20Plato%20-%2096.jpg)

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.

Michael Lopp, aka Rands, is the VP of Product Engineering at Slack. At Elevate 2019, he gave a talk on the Product Triangle - his framework for building a successful organization.

The Product Triangle - Michael Lopp from Slack at Elevate 2019

The Product Triangle

Hear from senior engineering leaders from Slack, Stitch Fix, and more to learn how they have built inclusive engineering cultures.

Building an Inclusive Engineering Culture

Engineering Talks with Plato: Part 2/6 Shivani Sharma keynote - 15th May 2017

Plato Event #3 Part 5/6 How do we support our engineers for their transition to managers?

Slack Technologies, Inc. is an international software company founded in 2009 in Vancouver, British Columbia, Canada.

Manager, Engineering, Mobile Developer Experience

MindTree

Test Specialist

Accenture

Siebel Tester

Devops / infrastructure

Mobile

New Manager of Manager

Scaling Team

Underperformance

Conflict solving

Diversity

Productivity

New Manager

Agile / Scrum

QA team

B2C expertise

Hi everyone! My name is Sridhar Ramakrishnan​ and I am currently Engineering Manager at Slack, where I lead Mobile Developer Experience team. Looking forward to meeting you!

Sridhar Ramakrishnan

Engineering Manager, Mobile Developer Experience at Slack

Seniority

Hierarchy

Management Experience

Stories