Episode 64: Answering Questions About Finding a Partnership In Engineering, Moving Backward In Your Career, and Playing It SAFe
In this Dear Melissa segment, Melissa answers subscribers’ questions about working with engineering leadership as a director of product, the idea of moving from a leadership position back to an individual contributor to gain a wider skillset, and whether or not SAFe is the answer for a small product org.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: What should my one-on-one’s with my engineering team look like as director of product? How do I find a partner and not an order-taker? [2:30]
A: Direct the conversations. Engineering leadership might be happy to sit back and let you dictate because they don't know what types of conversations you should be having. They aren't aware that they have the power to dictate any of this, so just by having different conversations and asking them different questions, you can get a partner to the table. You do own the priorities when it comes to looking at feature forward work and figuring out what's going to help increase the revenue, but engineering should be approaching it from a different perspective… Maybe start with… [talking about] tech debt. [3:13]
Q: Should we adopt SAFe? Any tips on what I should study up on and propose as a right solution to process and procedure? [6:56]
A: If you only have five product managers, why SAFe?... Why does a VP of product seem to think that SAFe is going to be better for a company of your size within your context? In a high growth context, what's SAFe going to add that a normal just like Scrum cadence wouldn't?... What I would do is study what companies do in your phase… get a development process and use a very light agile process like Scrum. As long as you're not super dogmatic about it and you make it fit you, it's totally fine. I would also look at bringing yourself in a discovery process; make sure you get your user research in there, make sure you get your tools, prototyping, testing and all that wonderful stuff. [7:27]
Q: What advice would you have for someone who is considering stepping out of leadership and back into an IC role to grow their product skill set? [11:01]
A: I think it's hard for a lot of people to take a perceived step back in their careers and go back to being an IC after being a leader… [but] I think sometimes we have to take a couple steps back to really accelerate. There's also a saying in Silicon Valley that I heard a lot: ‘When you see a rocket ship, don't ask what the seat is; just get on it.’ I've known a lot of people who have done exactly what you've done; to go to a company that they just saw as an amazing opportunity because it was going to take off like crazy… That’s what you should look for. You should look for a company that's going to be either your rocket ship for your career or a rocket ship in its own right… I would really hold out for the right company. If you're going to do this, a high growth company is going to give you opportunities. [11:21]
Resources
Melissa Perri on LinkedIn | Twitter
Transcript:
Melissa:
Hello, and welcome to another episode of dear Melissa. We've got three great questions. One around how to work with engineering leader. If you're a director of product, another one about if SAFe is right for your team. And then the last one about transitioning back into an IC role at a product led company, when you've been working at a not very product led company as a leader for a while. So we're gonna dive into that in just a minute, but I wanna remind you that if you have a question for me to answer on dear Melissa, uh, please submit, go to dear melissa.com. This is how I answer all of the questions. If you do send me anything individually, I'll ask you to bring them here.
So, um, I'm looking forward to seeing what's on your mind and help get us some more ideas for guests on the podcast and what you want to hear. So, any questions that are burning don't feel like any question is around wrong question, go over to dear melissa.com and let us know what you're thinking. Let us know what you need help with. In addition to that, too, I wanna remind everybody that we do have a book on product operations coming out this year. So if you go to product operations.com, uh, you can sign up for the mailing list to know that when that goes live, if you go to product operations at, you can sign up for our mailing list and it will notify you when that's live. But back to dear Melissa, we're ready to dive in. First question, dear Melissa, big fan of the show.
I discovered your work through transitioning our organization to empowered product teams as director of product. I spent the last year really trying to understand what it means to be a leader, empowered team. And I feel pretty good about my direct reports and the product teams, but what should my one on ones with my engineering leadership peers look like there's still this idea in our organization, that product owns all engineering capacity and engineering leaders seem happy to sit back and let product, make the calls. I find this frustrating, but don't know how to approach things differently. How do I find a partner, not an order taker. This is a fantastic question. I'm really excited to answer this and I'm going to do that right after this message.
All right, we're back. And we're talking about how to make engineering leadership, your partner, when you are a strong, empowered product leader. So, uh, you do want engineering to be your partner. And I think one of the things is to direct the conversations. Uh, engineering leadership might be happy to sit back and let you dictate cuz they don't know what types of conversations you should be having. Uh, they aren't aware that they have the power to dictate any of this, um, to set these goals. And in that case, you know, just by having different conversations and by asking them different questions, I think you can get a partner to the table. So what should you be discussing with engineering leadership? Oh, well you do own the priorities when it comes to really looking at, you know, feature forward work and um, figuring out what's gonna help increase the revenue, all those different types of things. but engineering should be approaching it from a different perspective. They should be coming back at you and there should be some good tension about, uh, things like tech debt versus investment in new features, revenue and cost implications as you're scaling and you know, adopting new technologies, capacity, planning, scalability, and security. You should be having some give and take on this. So what I'd say is maybe start with the one of those things. Why don't we talk about tech debt? Everybody loves to talk about tech debt. Your engineering leaders should be saying, Hey, you know, if we don't pay down X, Y, and Z tech debt right now, these are the implications. Um, if we do pay it, pay it down. Now we'll be able to ship features, you know, 10 times faster, whatever those numbers are, you need to be looking at it together.
And the deciding as a team, do we sacrifice a little bit of short term revenue right now to get ahead of this tech debt or is the short term revenue implications more important at the moment? So those types of conversations are what you should be having. You should also be talking to them about the systems and the SaaS products and the tech that you have. So for instance, if you are using Amazon web services, which everybody is doing, you're paying monthly fees into it. And a lot of times people go, oh, that's, you know, tech costs, but that's not. That's like bottom line for the company, right? That's your goes into your EBIDA. It goes into all of that stuff. The more you understand those costs associated with actually running your product, um, the more empowered you can be as a product leader to make more revenue and cost based decisions and look at those financials.
So I talk to them about things like that, understand the implications about if you build new features, what those costs associated with that actually look like, then you can actually look at also scalability and security. You wanna be talking to them constantly about like, Hey, how long, or how far will this feature actually scale for us, right? Like, can we onboard 50,000 new people in a year? Or does it break, uh, ask those questions. That's where you're gonna start to understand better about what your products and your capabilities are as you look at your roadmap and then of course, capacity planning, um, where do we put people around? Uh, how do we make sure teams are gonna work well together? How are we gonna make sure that we've got enough people on the most important things that we need to work on? Those should be conversation you're having to.
So I think if you are finding that the engineering leaders just seem happy to sit back, you know, put them on the spot and ask them questions, like get in a room and start asking them questions where only they know the answers. Um, you may be going in there saying, Hey, I want them to like push back. But the way that you're actually presenting the roadmap or telling them what to do, they don't know how to push back. They don't know, um, what questions they need to be answering that will help you as a product person, uh, empower them a little bit, right? Empower them with these types of conversations, um, ask them their, on those things. Once you show that they do have a seat at the table, when it comes to this, you might find that they're kind of rising to the occasion, but I feel like it all starts with the types of questions that you ask. So I'd really try to concentrate on those different areas that we just talked about.
All right, second question, dear Melissa, our company brought a VP of product about six months ago and we're growing rapidly, currently five product managers with me as director of product and more to come. This new VP of product seems to be advocating for us to adopt safe product. Twitter speaks pretty prominently against it, but I want to come to the table informed and with a viable alternative, I listen to your episodes where you debate safe with Eric Willy and now feel even more unsure of my view. Any tips on what I should study up on and propose as a right solution to process and procedure. I guess my first question for you is, you know, why safe if you only have five product managers, um, if you go back and actually listen to Eric's podcast, he admits that product does not well thought out and safe.
Um, the division of the product owners and the product managers is still being worked through, but he also tells us about like how safe came about. And it was for a really large, large like banks, large, large companies going through digital transformations to have some more context about how to run, you know, software teams basically. Uh, you are not in that position. You got five product managers, safe is a lot safe, is a lot for a company of your size. Uh, so my question is like, why does a VP of product seem to think that safe is gonna be better for a company of your size within your context, right? Like, I'd actually look at your context. If you are growing rapidly and in a high growth context, what's safe going to add that a normal, just like scrum cadence. Wouldn't like, can't you just do basic scrum and not adopt all the overhead that comes with safe.
Um, I find that in rapidly growing companies and in smaller companies like yourselves safe is a lot. So like what usually people adopt is some kind of basic agile cadence. And I'm not saying be very dogmatic about this, but they're usually using scrum. And then they put a discovery process on top of that, um, to help feed in the projects. We put product operations around it to get us the information that we need. We have roadmap reviews like every month or every quarter, depending on how fast you can actually ship. You just need a few things, really at a company that side to bring some, uh, discipline to the team. So you're all working together. But to me, I think safe is just way too much overhead for what you guys are looking at. So what I would do is kind of study what companies do in your phase.
If you go look at the companies who adopt safe, I guarantee you they're all gonna be at a different context than you. They're gonna be at a different stage of agile maturity. They're gonna be at different stage of software maturity. They're gonna be at a different stage of, of growth of scale, right? Like they're gonna have tens of thousands of people out there. Um, but you're tiny. So what are companies doing that are your size? Uh, you can listen to a lot of them on the podcast. I, I talk to any high growth CPOs or anybody in that, in that situation. We've talked about this on the podcast before we've answered questions on it, but I would start by like getting a development process. And I think you'd just use a very lightweight agile process, like scrum or something. Um, you know, and I'm not the biggest fan of scrum or anything, but it works.
It works. And as long as you're not super dogmatic about it and you make it fit, you it's totally fine. Start there. And then I would look at bringing yourself in a discovery process, make sure you got your user research in there, make sure you got your tools, prototype and testing, all that wonderful stuff. That's pretty straightforward. I think you can have a lightweight process for that. You're gonna wanna make a cadence for reviewing your roadmaps and for reviewing new upcoming features and figuring out how to prioritize you create a prioritization system. Um, and then you need some operations around it to help with gathering data, streamlining all this stuff together, all your roadmaps together, talking about it through the company. But I try to roll your own process. And I, I feel like you might be looking for something out of the box. Um, and that's why safe might be interesting to you, but you have to remember that anything that just comes out of a box is fit for purpose for maybe not your context, maybe some other context. So I I'd really dig into why do we think safe is gonna be better than us just doing something lightweight on our own that works. And then we add process as we need it. As we keep scaling and we're scaling rapidly when something breaks, we fix it, right? We add a new process. That's how I think you organically grow into something that works well for you.
All right, last question, dear Melissa, I've been in product and product leadership roles at a company in the middle of a digital transformation for almost 10 years. It feels like I need and want to gain experience at a more product led company. What advice would you have for someone who's considering stepping out of leadership and back into an IC role to grow their product skillset? Well, first of all, thank you for considering this. I think it's hard for a lot of people to take a step back in their careers or perceived step back, let's say, uh, and go back to being an IC after being a leader. But you're looking at this as, Hey, what can I do to make sure that I'm doing product right before I go forward? And I think sometimes we have to take a couple steps back to really accelerate.
So I love that. I love that you're doing this. And I think that's really powerful. There's also a saying in Silicon valley that I heard a lot. It's like when you see a rocket ship, don't ask what the seat is, just get on it. And I've known a lot of people who've done exactly what you've done to go to a company that they just saw as an amazing opportunity, cuz it was gonna take off like crazy. So there's something to be said with that, right. There's something to be said about joining something. That's awesome. And I think that's what you should really look for. Uh, you should look for a company that's gonna be either your rocket ship career or a rocket ship in its own. Right. And what do I mean by rocket ship for your career somewhere where they're doing everything so well and so high functioning that you're gonna learn so much, right.
And you're gonna take that with you everywhere you go in your career. So I would really hold out for the right company, if you're gonna do this. Um, a high growth company is gonna give you opportunities to actually ship product over and over and over again and get so many reps under your belt that you'll be able to see all the growing pains, but also like all the new features that you've shipped. Um, you know, fixing things. You're gonna be dealing with tech debt. It's just like a learning experience and high growth that comes really fast and very rapid. So I probably orient yourself somewhere like that. And then I'd also look for really strong chief product officer to work under so that you can understand how, what good looks like, right? Like how things should work. So I definitely think about that, but then also you need to think about how you're gonna sell yourself to, into this IC role.
Um, I could see people interviewing you and saying things like, well, when was the last time you actually shipped a product? Or when was the last time like you got your hands dirty with this? Uh, how do you talk to them about that? Like how do you talk to them about knowing what to do, making sure that you will be a value add to their company and you'll be able to dive in and get your stuff done. So plan that out. Awesome though, though, on the flip side in high growth companies, a lot of the times people end up in leadership roles because they were promoted out of IC into those roles. Uh, you may be able to help those people gain leadership skills, sometimes larger companies, even in the middle of a digital transformation, have some really great leadership qualities, um, in their leaders.
Sometimes they don't, but sometimes they do, right. And you've seen that you've seen how things function at scale. You've probably had some more policies and some more frameworks, uh, actually built out around you and in higher growth companies. Mm. Sometimes they don't have that and they need it. So you can bring some of those in insights to them. Now you don't wanna shove all of those insights down their throats and you don't wanna come in like guns blazing, but you wanna say like, you know, I can help people who are new leaders. I've been a leader for a very long time. Um, if they need just general leadership skills, I can coach them. We can work together. Um, I can, you know, show, tell you what's worked at this company. I'm not saying adopt all of it, but I can just bring new insights in there.
I think that's very powerful too. So definitely think about selling yourself to these companies as well. Cuz they might be a little bit skeptical if you've been in a leadership role for a while and especially one that hasn't done product really well that you can ship. So how do you show them that you, you can get in there, get your hands dirty and start shipping things immediately really look at that. Um, and then also make sure that you are taking the opportunities that's gonna give you the experience that you want. Um, you leverage that you really look for a company where you think you can grow, surround yourself with people who know what they're doing and then you're gonna learn really fast. And you can probably jump back into a leadership role in product at another company fairly quickly.
All right, that's it for dear Melissa this week. And again, if you have any questions for me, please go to dear melissa.com and drop them off. If you like the product thinking podcast, we'd really appreciate it. If you let people know. So feel free to share this episode, feel free to, um, share any of the episodes that you've really liked. We love hearing feedback too. So leave us a review on anywhere that you're actually listening to this and make sure that you subscribe as well so that we can keep you updated every Wednesday. When we've got a new episode, we'll see you next time.