Using a Venn diagram to help define and gain a shared understanding of each cross-functional team lead’s roles, this talk explains the relationship between engineering, product, design and technical product management at different types of tech companies. The overlap areas in the Venn diagram are “dark work”, the glue that keeps the teams working well together, which are areas for managers to keep track of and be accountable for.
You're not supposed to see this slide, which you are. It's actually, that's the joke. This is this is the this is the presentation slide that I built because you don't always get a chance to actually see your slide. So you can see before you get on stage. So sometimes you're walking on stage.
You've never seen it. I've seen it calibrates. Amazing. Thank you for having me. It's been a good run, but here's the thing you can learn from this slide. There's a lot going on here. This has nothing to do with the talk. I can see the colors, how they're showing up. Right. I can see how they've cropped it. A little cropping issue down here.
I can see whether this one of these is the actual typeface. And one is a screenshot. If these two things are not the same, my font's not there and I will be destroyed.
And I like this slide. Also you can see what slides that. So this is a talk that's not called the end. This I've had really the opportunity to speak at every single one of calibrate. Thank you all for having me. And they know that I'm a classic. Oh my God. I have this amazing idea for a talk and I write it up and I sent it to them and they're like, that sounds amazing.
And then I write a different talk. So what your what's your what's your reading in the P in the agenda is not where we're going to talk about. Thank you, calibrate for being understanding, and for having me back every time that I screw you like this, I'm so sorry. We're going to talk about the product triangle.
I I want to talk about the responsibilities of the different humans who are responsible for building products. I I've done. A lot of interesting weight in there. Let's go, bam. Not much better, but still there. I've been working in the Silicon valley, my entire life. I was at Berlin for many years.
Anyone Berlin show of hands real quick. Okay. Yeah. It's less every time Netscape show of hands. Yeah. Maybe. Okay. Good. That startup that you've never heard of. Have you heard of it? Okay. Yeah, that's all right. I was there apple Palentier, Pinterest, and finally slack. Doing a lot of building of different products over the past 20 years and learning less all sorts of things.
Let's get to know each other a little bit better as we can, before we talk about this. So how many engineers are here? Show hands engineers. Okay. That makes sense. How many product management types are here. Okay. And designer types. So you hear designers that's intriguing program managers or project managers.
Okay. Okay, sweet. You're going to load this dog. HR, are you here HR as well? How many of you HR and program manager? Lawyers. Are you here? Any lawyers? Okay. Sweet. All right. Sorry, more questions. How many of you I have been starting managing right the last year in the last year. Okay. About half, three, five years, ish.
Three to five years. Okay. And then five years. Okay, great spread. Awesome. How many of you last question, I swear maybe how many of you, and this is gonna be super easy for you? Are extroverts. Raise your hands. If you're an extrovert. I know it's not hard. Okay, great.
I think I've done this joke every time and it slays extra work to raise your hands again. No problem. Please just raise your hands. No, it's not hard. One more time. I look around everyday. Because I'm going to do a thing. That's gonna blow your mind. Introverts, raise your hands. Is this not totally fascinating.
This is a leadership conference, right. And the majority of us, including myself are introverts. So what's up? Yeah. I don't know. I should have read a book about it. Okay. Here we go. When we talk about products and how to build product here and slack, VP of product engineering I, to I say that it's really obvious to me what it is, but I want to define that super quick.
Just so everyone's clear with product engineering is because I think it's actually something that. Relatively new. Although to me, it's been around for forever. So there's basically two kinds of engineering teams. There's gonna be some vast generalizations here, please bear with me. I'll be here all day.
You can critique me in the hallway there. Number one is there's these teams, whether that's. So service engineering, dev ops, developer, productivity, data, all of these folks, incredibly important folks. There's a whole class of engineers that are part of this. And then on top of that is what I consider to be product engineering.
These two teams work closely together. Infrastructure is building the Legos to allow our product engineering team to get things done. Product engineering is the entire. It's from the front end of JavaScript up your Android iOS to whatever it is, the mid tier, all the way to the back end. And sometimes it actually plays in as well.
That's product engineering, but perhaps the most interesting thing about product engineering that is a differentiator from infrastructure is there's product managers was saying this word a lot recently accountability. And I said there would be more questions and here's one. Just throw it out there.
When you hear this word, when your leader, when someone says, are you accountable for X, Y, Z? What is the definition? What is the word that you hear in your head? Just shout it out. Anybody accountability? Say it again, responsible. Okay. Right. Was that owner of a thing? Absolutely. Trust. What was that? Yeah. So everyone's wrong.
And thank you for those who have seen this slide before and not sounding it out. That's not what it means. Now. All of these words that you just said are incredibly true, and that's what you're hearing. I'm not invalidating that, but it's not what the word means. Accountability. Actually, the best one I heard was from someone on my team.
This person said, it means if I don't do that, you're going to cut my fingers off. And I was like, whoa. And they're joking and we're friends, but like, that's it, that's not a good thing to hear. Right? That's, there's this weaponization that happens with this word and it's literally not what the word means.
I did this talk internally at slack, a couple of months, a version of this talk a couple of months ago. And I looked up the word and I don't know, you know, every bad talk starts with a definition from the dictionary. But we've already started so I can do it now. This is what the word means. And when I read it, it gave my heart joy what it means accountability means.
And the thing I want to talk about, and what I inspire you to do is it's about being required or expected to justify your actions and decisions to give it counts for accounting. Isn't this a healthier version of this? A healthier version of this few unit we have about it. I am accountable for this product, which means if we're going to do something, if we're going to take an action, if we're going to make a decision, I am responsible.
I am accountable for being able to explain that to you and the gap. I don't know to talk with folks, please tell me what you think, but why we do it. It is such a healthier version of the, of then I'm going to chop your fingers off. If it doesn't work at and accountability, this ability, this empowering word that I'm throwing out there is really tricky because there's all of these lovely humans who are building the product and they kind of look like it.
You have the product triangle. Now there's lots of sub-teams inside of this. It's meant to be inclusive of everybody, of all of the teams, engineering, the builders, product managers, and TPM, which is effectively program managers. I know you all know. Oh, sorry. I know you all know this, but I want to be clear about the roles here.
Well, start to be clear about the roles engineering. I know this is all. I've made a career out of state in the obvious engineering, the how building and growing the team, aligning to a product strategy, getting the right engineers on the right job, setting clear, achievable, ambitious goals for the team, building a strong, healthy team, actionable feedback.
It's a lot more than that, but those are some of the things, the product managers, the what in the world. Managing a product strategy, defining a vision and a go to market approach. Our chicks relating the business value. If we do this, this is a likely outcome of what's going to happen to the business voice of the customer.
You are humans that are out there talking to our customers and telling us what they want, synthesizing that, bringing it back to us, the builders as an actual plan and setting clear goals for them. TPMS program managers, plate spinners, the TPMS map, interrelated set of independent of dependencies and projects.
They create a logical progression of work. They identify bridge gaps between teams. They partnered with cross functional teams with minimal escalation. They help defined goals, metrics, priorities, and the roadmap. And by the way, They love all this. They have great joy in spinning all those plates. So the thing about this is you're looking at this.
There's a lot of different models. There's a lot of different ways to construct teams, product teams, if you will. And I want to talk about a couple of them before I give you some homework. So I was at apple for a good long time and learned quite a bit. The model at apple is a little bit different when I just showed you the model.
You'll notice I have replaced product managers with design. There are, as far as I know, I know it's not completely true anymore, but there are mostly no product managers at apple. I saw in eight and a half years, I saw one spec and it was bad. It was horrible. It was for ICAT. And they like, what the hell is this one?
Stack no product, man. Does anyone kind of get a little like, whoa, what about that? Like why, who who's defining the strategy? And that was one of my biggest lessons. At apple was we looked around the table and we said, why are we doing this thing? And it was really quiet and everyone was looking at me because I was accountable for that product.
And I had to explain, I had to have a defensible opinion about why we're building this. And I think that 60% of product managers are amazing 60%. But, and they say the same thing about us. It's probably a little the thing about it is I'd been used to having product managers in my, and I was always waiting for them to tell me kind of what we're going to actually go and do.
And for eight and a half years at apple, it was put into me via drinking, all that Kool-Aid. That it was my responsibility to know why we were building and what we were building along with an incredibly strong design function. And also there is this guy named Steve jobs who was kind of the product manager for the whole thing as well, which helped us.
Anyone at slack has heard this from me before, but when I, when I go in, I talk to one of my directors or someone on the team and I say, Hey, Julia, W why Julia would never do this. This is hypothetical. Hey Julio, why are we doing this? What is, what is the reason that we're doing this feature? And if she said, and she would never say this, and she's going to hate me for even saying this here.
Cause you know, we didn't know, but never do it. She was, she said, cause product told us to do it, the hair on my back and that would go straight up. And it's not to say that product is not a talented group of humans and how have a very clear vision, but what was Julia doing in that. She was not accountable for the product that she was building with her hands.
And I say, that's not like I want, you need to be able to explain it and fine. It's fine. If John was telling you how to build it and this sort of thing and whatever, but it's your responsibility to understand it, put it in your bones, be able to explain it. The other thing that I learned at that apple is this PMO.
How many of you have some sort of program or project manager function in your county, but he's right now. Okay. The program managers at apple run apple, they run the company because at apple, you have a software engineering team of 5,000 people. And there's a lot of interdependencies. There's a lot of different people who need a lot of different things and they show up and there, they have this ability to gather signal and move signal around and they're incredibly detailed.
As I said earlier, they're the plate centers and they love spinning plates. They are great at it. They treat jig joy in it and they are world-class at it as well. These are intensely, reliable, intensely detail oriented humans and are absolutely essential connective tissue at some site at some, or get starts to get going all of this work that happens all this work to happen in the year.
Whether you have design PM or. Is going to happen. It's a question is who is the most capable person to actually go and get it done? Which leads me to my next one. Palentier, huh? Yeah, no, boom. Yay. Okay. All right. I'll just take it to silence.
Does it seem a little strange? They would hate, I put this slide up here. There's designers there. There's not a lot of designers there when I was going there. And I'm truly proud of this company and happy to later tell you I am because probably a lot of opinions about this, but factually the data is the company is founded and run by engineers.
When I left seven, seven years ago. All of the directors and I was one of them, there was four directors all recorded the CEO and we were all engineers. It just gets stranger. My job there was running real estate. Marketing and the cafeteria, if you check out my resume, you will notice none of those things I'm actually capable of doing very well.
I'm making fun of them a little bit, but it was really, I did, it was kind of idyllic to go in there and to see like cool engineers are running the whole thing, but I can tell you, well, number one is all of the work product design. All the other was being done by program management was being done by the engineers and they were doing their best and they're trying real hard, but the best they're going to do, having never done it before is probably a C.
And they probably diversified since then, but this is not a model that I would actually recommend at all. They're they're really good. Four engineers. Okay. The last two have been very familiar and are the kind of the model that we're going to talk mostly going to talk about here. A Pinterest and slack, both pretty classic product engineering or product organizations, where you have a product function PM function.
You have the engineering function and you have the TPM or UPM function. It is a diverse set of perspectives at slack for a while. We had this model. And there was basically for every pillar, there was a director of engineering, a director for PM, and a TPM as well. And their job was to equally represent their different domains to disagree healthily and to when they, to have hard debates, but to represent their different respect, their different remains.
And it, that piece of having different perspectives at the table who are representing different views is incredibly important because. Ideas don't get better when we all agreed. You actually want people in the room, they were saying no, or saying, I have a different perspective. This is the diversity argument from a pure product perspective as well.
We have the folks that understand the constraints of the schedule. We gotta have the folks who understand the constraints of what we can and can't build. And we have the folks on the product side who were saying, this is the business that we actually need to build. And that debate is fascinating, but accountability.
The biggest challenge and where I literally spent most of my last year is these gray areas between program and engineering, product and engineering. These are the confusing gray areas between the teams that are incredibly defining and incredibly difficult and hard to define. And you're going to waste a huge amount of time unless you followed my advice.
As a leader, that gray area is where you're going to spend most of your time,
who is responsible for a feature
who is responsible for building the schedule,
who is responsible for talking about the feature in front of everybody.
See heads, nodding people, people be like, yeah, that's interesting. The gray area
is fast and this has been your learning keynote until the animation is over. You can't click. So we're going to be here a while.
This is, this is pulled from various illicit slack from a while ago. Go. And as I go through this, I was thinking about this this morning as I was driving in how much of that stuff is a scroll by some of it was recognizable. Some of it was like, I don't know what the heck that is, but my question to you.
How much of that work, that's all work. That's all someone doing something and getting it done and getting an outcome. How much of that work you actually account for I'm going to do it again because I can't. How much of this work do you account for when you building out a schedule? I think there's another talk, which I'm going to call dark work because this is a ton of work and we're not actually giving ourselves credit for it.
And not even to the point, not even at a hard part, right. Each of these areas, every single bullet on this list is an opportunity for misunderstanding, for a lack of clarity. For two people working really hard on exactly the same thing. And this list is probably four times longer than I listed right here.
So I normally talk in sort of abstracts and high level stuff. I'm going to do something great different here. I'm going to give you two pieces of it. And here's the first one, and it's really simple. And I'm telling you, I'm going to save you thousands of hours and tears and frustration. If you choose to do this homework, both pieces of homework.
Here's the first one. What I want you to do later, before you sell, I want you to write down your key responsibilities, the things that you're responsible for, what your product design, HR, whatever it is. And this is the important part. Those of your peers, not everybody, but the ones that you are most dependent on to get your job done, my responsibilities.
And there now go to one of your peers and say, this guy named wop or Rams, I don't know what his name is said. I should do this. It seems important. He's in, at high-poverty and this seems like important work. Ask them to do the same thing themselves. Don't show him yours. They do the same thing, my responsibilities and yours.
Now this is the part that is the time-saver. This is the thing that really, really matters is it goes to lists and swap. I guarantee you're willing to be shocked by what they think is theirs and yours. And that is an opportunity to sign a contract to say, by the way, I'm responsible for the sprint planning.
I'm responding to the schedule that. For each of those areas that fall into that sort of confusing gray area, define a protocol to find, sign a contract and just come to an agreement. I w I will be accountable for this. I'll keep you in the loop. I'll tell you everything about it, but I'm accountable. I'll do this.
It seems really trivial. But in this hurried, we got to get things done and it's rapid growth. This work this between the seam work between talented, different teams. Is a huge amount of work. It creates miscommunication, it creates confusion and it decreases accountability. I love this word. I love this word because it reframes something which is used sort of as a, as a threat into this opportunity to care about what you're building.
And I think if he goes through the contract process, if you go figure out what your folks supposed to be, you, depending on, he'll be happier. The other thing I want you to do, this is going to seem a little bit off topic, but it's not.
So
I play this game called destiny. I'm a crank with me. And I play with this guy from Portland, named DJ and sitting back there. And I wasn't gonna add this to this part, but I think it's important that you hear it because I think it's important right now in this country, in this world to say this thing about a video game you can play destiny by yourself, but it's far more fun to play with others.
In fact for certain parts of the game called raids, you got to get six people together. Is it 66? Thanks. Together to actually go and achieve this objective, swear to God. This is a related moreover you there's some challenges. The the internet is full of. Colorful people and personalities and raids are complex affairs.
Someone needs to lead or else everyone dies and dying is bad. I'm not joking when I tell you that this gentleman back here and I've done this talk before he's sitting right there is the nicest, and I'm sorry to put you on the spot, man, but you, you brought this on yourself. Is the nicest calmest, kindest person I have ever met.
It's a restore your faith in humanity person. We with others have been doing battles with digital baddies for years now. And there's a lot going on in a raid and people have to leave. You're gonna raid and you've been at it for two year hours and you got to go be with your family. DJ says no problem.
We'll figure it out. No worries. You're having difficulty in a raid. It's hard. It's a complex task. It's a video game. It's a complex guy and you've never actually done it before. And the team is failing. DJ says, no worries. I remember when I had to learn this, it's a fuck ton of fun to learn. I'd never played before this.
Ray. Forgot to tell us that at the beginning. No worries. We'll practice this together right now. It's it's a leadership model that lends itself to the volunteer situations. But my ask of you, calibrate is why is this not the default situation, the default mentality for all situations. I've been saying this for three years now.
Why not be unfailingly kind on this planet in this country right now? Rage is simple. It's easy. If you want to find a reason your product manager is out to make your life miserable, you can just Google it. You can find a reason and you can find an opinion about why that person is out to get ya. My homework for you today is to lead with unfailing, kindness.
You know, what it feels like, you know exactly what it feels like. And you know what it feels like when someone sends it your way, it's a hardest reaction. To take, it's a hardest mindset to take when the stakes are high and the rage is plentiful. But the way we lead is with understanding with empathy and with kindness.
And if you don't believe me, spend some time with DJ he's sitting right there with the big beer countability and unveiling kindness. That's your job. It's been a lovely, wrong calendar. Thank you very much.
Founded in 2015, Calibrate is a yearly conference for new engineering managers hosted by seasoned engineering managers. The experience level of the speakers ranges from newcomers all the way through senior engineering leaders with over twenty years of experience in the field. Each speaker is greatly concerned about the craft of engineering management. Organized and hosted by Sharethrough, it was conducted yearly in September, from 2015-2019 in San Francisco, California.
Together, we form one of the largest independent ad platforms and marketplaces worldwide.
Learn More →