#1 - Product owners effect on tech culture with Mike Gertrudes

About the guest

Mike Gertrudes, VP, Head of Engineering at Billie

Previous roles include Director of Engineering for brands like Priceline.com, tech leader, and entrepreneur.

Coaching and advice for professional development.

Join Mikes's team at Billie.

Notes

We speak with Mike regularly, and recently Mike shared with us that a change in his office dynamics had a significant effect on his engagement at work and quality of life. When we asked him what changed, Mike told us it was about a new product owner that recently joined the company.

We had to book Mike for this chat; we believe that a strong team requires everyone to participate. From this episode, we hope to inspire you to see how powerful a united team can be for the sake of creating excellent products and enjoying professional relationships.

Additional notes

Around the 7:30 mark during our conversation, we couldn't remember Conway's Law.

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." — Melvin E. Conway

Transcript

John 0:13

Welcome to pragmatically podcast, your hosts are Alex Bachuk and John Masse. We have conversations with folks throughout the tech industry to get real world perspective on how people make things happen for their careers and businesses, check out PragmaticLead.com for more content just like this.

Mike, welcome and thank you for hanging out this morning. There's something that you said that I wanted to hear more about. And I think more people can hear more about is the effectiveness of or the impact of product person has on our world, the technical word. So before we get in, why don't you tell us a little bit about yourself, like your role what you've been up to recently?

Mike 0:58

Yeah, sure. So head of engineering over at Billy, we're two and a half year old woman's body brand startup. So when you come direct to consumer startup, and the some of the challenges that we're faced with, you know, I was essentially the first engineering hire, we've done a lot with consultants, a lot of E-commerce startups these days, a lot of startups these days can get up off the ground running really, really quickly with a lot of different like platform providers, the different services that didn't exist at Priceline didn't exist 20 years ago. And so like, it's a different game, so then you kind of have to be like, Alright, we've outgrown these partners that we get off of them. So it's a different game, you can get up really, really quickly with a very small engineering team. And then you slowly start to grow engineering teams, the product teams to start to see like, what do you want to know? Can you stay on the same partners and build upon them and grow the business? Or do you have to start to invest to to get the platforms to the point that you need to be? So it's interesting. And also this arc, I think, like, the challenge that I have coming in is that, you know, the company, I'm with Billy, and going through a public acquisition. And so the challenge there is, you know, everything has to be tight. Like from a security stability perspective, it really has to be tight. So it's interesting. So when we think about product, it's, you know, the technology organization. I'm officially VP of technology. And I consider product to be part of technology, although it's a little bit of a gray area. And I think different companies do it differently. But because we're a physical product, there's essentially physical product and digital product. So the delineation is actually like way clearer, and a space like like ours, then maybe it is in other companies. But so that's the challenge I'm faced with is kind of like, develop a technology org. And so the role of product is incredibly important to me. It's actually one of the one of the reasons I took the opportunity is to help shape and form that.

John 2:46

I didn't even consider that you have a physical product, right ability and the digital product. Curious, is the product team the same? Or do they think the same? Is there a dynamic there?

Mike 2:59

Between the two? No, it's not. And the term like digital product, it's really a complete different world, it's a different country, and they don't really, we're almost an accessory to physical product. So they're one of the inputs that we have so and what's interesting is because it was a physical product first, that was usually the driver of really everything of the company. And so what we're starting to do is, is, look, you got to think about your startup company, like I need some technology. Well, let's hire out these consultants to kind of build this technology for us. Either we're growing a team, it's kind of a little bit different, where it's like, hey, not only can we continue to support here, but we're not just a support organization, we're actually a growth organization. So finding ways to, to actually pitch that, that invest in technology, it's not like can we just get the support better than technology, we actually can grow the business. They're coordinated efforts around product launches, physical product launches, but and I started my career in physical product, I guess you could say mechanical engineering, and I left it because, you know, it takes so long to roll out anything physical, it's not like you know, software, you could start you and I could, could spend a weekend and have a site up and start taking money, right? So you don't do that when you have to like get an ingredients list and get manufacturers to do product packaging and prototyping and actually see if it works, make sure you know it's healthy for everyone like that stuff takes a long time. So, so no, their lead times are way way different than ours. And so some being more of an accessory to physical product development.

John 4:33

You said that the technical team was, that was interesting, it was to support the physical product. So that was there a transformation that you had to go through like maybe tell it tell us about a time the time before it was like what inspired this conversation why I want to talk to you about this is your energy we're so you had so much enthusiasm that seemed kind of I don't say new because you've always been very enthusiastic and motivated and driven, but specifically around the introduction sounded like you had a new colleague kind of joined the team that really had an effect on your work life. And really, for the better.

And that was a product person. It sounds like there was a time before that. And I can draw some parallels between my experience where it was, you have the business team and the and your technology team in the beginning is kind of like an appliance for or a support role for the business. But I'm seeing a parallel with the with how you describe the physical product, because I think that's actually what the business team is trying to represent is the physical product. But at some point, there's your technical presence becomes another product, right, or voice for the product in your, in some ways, looking to improve on that on its own merits. So there's the transition period between when a business's using technology to try to grow an audience and establish itself. And then when the technology comes a product of its own, is that kind of a similar, a similar? Would you describe that kind of in a similar way that you went through recently?

Mike 6:04

Yeah. So that the experience that we both shared, the business team, you know, is essentially the physical product here, right. And so, you know, the difference we have now is that it's hard to kind of explain but like, where we are, it's like Business and Technology. So essentially, physical product, and digital products slash technology. We're at where it's, it's all e-commerce. But it's all essentially digital product, even though it results in a physical product, you've got business products, and technology. Right. That's a tough spot to be. That's a real tough spot to be in. And that was frustrating, I think, for everyone. And that happens, I believe that the time that happens through operations in the new world I'm in is a different operations than than would be in last place. But like, it's organizational stuff, like, you build the org that way. And I think, what is it? What's the famous communication versus organization, some theory. And there's like somebody leaving, the way that you divide up your organization is your defining the walls of communication,

John 7:14

Your somebody, your technical organization is organized by your social one,

Mike 7:20

Some guys named will have to annotate this later. Yeah. But that will look at how to you love to use the Oracle for this. But I find that that that that was really the case there. So here, we don't have that we have like, essentially, you know, here, so. So now we've got physical project. And this is like the digital project. So within this, you've got product and technology. So I really look at it as technology, product engineering. And you might even be able to say data in there. But data's got like a little bit of everything. So with that, you've got a lot easier to drive initiatives. Within here, we're all excited in here about the same things. Whereas in a world that you've had, you've got business, product and technology, you're all excited about your own things, right. And so you've all got your own needs. But I really believe that if you're dealing with technology, it's really, really important to be on the same page product and engineering. And that's really all technology. And once they're not, once you have a product owner who can't talk about engineering, and engineers who can't talk about the business, I think you've got a really big problem, you really all should be talking about the business and how to meet the needs of the business. And that that may mean, hey, we really have to refactor this thing, it's gonna take us three weeks, we have to absolutely replatform it because we're going to be paying for it, we're gonna be grinding to a halt in two years. And that needs to be a conversation about business. And it's an engineering conversation, but it's really a business conversation that needs to be had with, with product and engineering together. So I look at that technology. Yeah, so for the experience, I think the kind of timeline of the company that I'm working with is kind of had three phases, you had the first phase, which was like, let's just kind of be scrappy with some consultants, you know, no kind of formal technology or anything like that, that the next one was like, Alright, let's, you know, bring in a head of engineering, and let's start doing some, like, you know, Product Management and project management, but the kind of like, you know, by the seat of our pants a little bit, like, let's kind of figure it out, and, you know, get it done. However, we can get it done like without a lot of like the formal discipline of product and and like, so through here, I kind of kind of knew it. But at Priceline, like, the discipline was actually really strong about how product management went into some of the culture of the, you know, the needs drove it arrived. Thank I still, I think those still drive it awry. Although I think there's likely a lot of things have changed since since I've been there, and probably for the better, hopefully. So that was kind of like phase two. We're in phase three right now. Hopefully now I've heard some things which is good. And then like phase three is like, bring in a head of product, who's really got the fundamentals of product management, the design, the kind of design, it's on the DNA fundamentals of product management, and when I say the fundamentals of it, like and Kinda like good product hygiene. It's this idea of like, you know, MVP, lean testing, you know, saying no to redesigns first, you know, and being careful, be able to know that like refactor actually like is is a function of a of a healthy engineering and technology org, that sometimes you don't need to do it. And then also like strategy, like, Hey, this is like, let's think about this in terms of quarters. Let's think about this in terms of sprint, let's think about this in terms of, like, of yours, and all this kind of stuff. Within that, in order for that to work, you need this trust. And it's like a relationship, right? You need to trust like eating and there's a Yang, and you need you need trust product needs to be able to trust that when they talk to the engineering leader, the engineering leader isn't like, yeah, let's use insert new technology here, that I want to play around with. And you know, there's really no business value to other than maybe I'll make some engineers excited. But, you know, it may actually tax us a year later, or something like that, which, and there's reasons for that. And certain companies like, that's actually like, more important, but depending on the kind of talent you're trying to do, I think for e commerce sites that are kind of just, you know, doing e commerce, there might not be a ton of benefit for us there. So there have to be a trust that like that you have that like, this person is going to tell it to you like it is and and not try to pull the wool over your eyes. And then this person over here also being like, Hey, I understand that I know that, that investments in engineering in this way are going to affect the business this way. And I know that like engineers love to own, I know that engineers love to be able to do some hackathons here and there and like it's and then be able to kind of shift sometimes the needs of the business. And the technology or may lean more towards like driving revenue, or driving like retention are this kind of stuff for it may be like, Oh, we need to be like more stable, we need to be more secure. Like we can't take the load that we used to be able to take or now that this new application and it and it really needs iterating on it, which is what we're doing right, you know, a lot, we can't do it without refactoring this API. And, and having a great product head, they can play any of those roles. And they're still that kind of eating and Yang partner in all those roles, even though this is probably closer to the comfort zone. So an engineering leader is probably going to stay closer to the platform than they are to like, you know, moving moving dollar signs on conversion and this kind of stuff, you know, but having a strong product lead, they've played that same role, any of those pillars that you're chasing, so, but yeah, once that person came on game change, and I got a lot happier in my role and a lot more engaged in my role, because I was like, Damn, I've got that partner who can kind of go out can be the liaison between all the other departments, they understand strategy, they're actually better at pitching the strategy of business, and breaking it down to the leadership than I am. That's kind of like their strength that wasn't really my strength. And I think like, any good team is comprised of a bunch of people who's, who have varying strengths in different parts, and then they come together. And again, it's like a collective Ying and Yang. And with that, they're able to to make a better team because you've got those differences. I mean, you know, this is this is the idea of diverse teams. And so for me, having that partner who like loved kind of driving strategy and talking to the business was was a game changer, and they can do it responsibly, I didn't have to have the conversations of like, we actually can't rebuild that API in a month. It's actually impossible. We don't have the people and even if we got the people, and now we will ramp them up. So yeah, it was definitely game was changed when that that role came in, and I trust that person a lot. And they've made me better and the company better

John 13:37

Mke, that's a very interesting, so you said, um, there's a couple of areas that I think tell a very powerful story. We kind of started sounded like, like the ticket, there's an evolution in the relationship of parts of an organization. So maybe the it sounds like the way you described it, that it's common, I think it's it's common in many companies to is that the technology is starts out as a service to the to the business. But then at some point, technology comes that kind of gets elevated into a partnership role. And the bridge is almost maybe this product team. And I'm sensing that there's there are a good product relationship is a partnership between technology leadership, and the product people. Is that a fair way to describe it?

Mike 14:27

Yeah, I think you described it Well, yeah, I think you need to eat healthy. They really are like their best buds. Yeah, their product and their best buds. They really have to be in a company that you want to do anything with engineering, with technology. They have to be best buds.

John 14:43

I've had a wonderful opportunity to be in that in that position. I sense what you mean. It's almost said that you're always it's not you're answering each other's question or you're not. You're not finishing each other's sentences. But there's this constant feedback loop right checking in on the Other and caring about each other. So So Mike, what are some things or strategies or signs that you look for in a product organization as a technical leader?

Mike 15:10

Yeah, that's a good question. Yeah, I think back to my interview questions when we were when we were hiring for head of product, maybe like six months ago, some of the questions I had were, you know, some of them are on project management, right, which a lot of people can do doesn't make a great product manager and some Excel project management and some don't, and some don't want to do it, some do want to do, it depends on the type of person you are, I'm kind of the belief that I'd rather distribute it and the product head that we have right now is also like, you know, I can do project management, but not might, not what I really love to do. So let's actually distribute it. So for example, we have retrospective today, and somebody in the team leading it, we roll dice, and people lead the different Scrum ceremonies, simply because we don't want the product owner doing it all the time. Because he doesn't want to do it. And it's our strength. So it's like, do the things you don't love Should we just shouldn't.

So simple, don't do this thing, you know, look. But so I guess one thing that you can do that that's a good way to add that relationship there is we have is to check in. So you know, once a week, we have a standing one on one. And we do it before our our leadership, we touch base with the co founders, we report to the co founders directly. Together, we haven't touched them yet together together. So yeah, the orbs are a form and we'll see how things end up and and and I'm cool with whatever way they end up. Because right now, like whatever we've got going on is successful. So So yeah, we have a technology checkpoint with the co founders once a week, which is really important actually kind of show what you driving, hold all of us accountable. to kind of have this kind of, we've actually done really well with this like to have like, essentially, the CEOs be able to say, ah, we really should build this thing. And we're like, Yeah, that's great. That's really important to you, let's do it. But we agreed to this stuff. So which one of these things are going to go? And they're like, Yeah, well, maybe we shouldn't move that. Because this, this isn't as important as that. So the conversation now is they know that we prioritize heavily. And I will thank agile Scrum, for that, it gives us a real great way to to deliver and guarantee delivery. And once you can guarantee delivery, and you start guaranteeing delivery, I looked at one of my first projects, and the company was like a six or seven month critical reimagining of the website, for e-commerce, and they just hired me to end up I could deliver and we nailed it. And we nail it. And you nail it because of this process people like, Alright, I ain't gonna mess with that process anymore. Okay, these people can deliver until like, you start talking in terms of that stuff. But anyway, so we have these check ins once a week. And so we check in with leadership. And so the product and I, we have check-ins right before that the day before, but honestly, I'm on the I'm on the phone with this person probably once or twice a day, we just have calls or like, we'll get out of meeting or like, let's just talk about that. And so like, really, really best buds at the organization. And that's really what it should be with. And we're not there's overlap, but there's not a ton of overlap. So I think looking for people who are complements to you who do the things? Well, it's like, it's like, we're like mini co founders, right? So it's like, if you're going to coke on a company, you don't want somebody who loves all the things that you love and have the same strengths as you do. You really want people who compliment you. And so I think, you know, that's what we have. So looking for a partner who has strengths are different than yours, and that you'll be complements on and you won't be stepping on his toes, we never step on each other's toes. So these check ins really, really help in those check ins, you just got to you got to talk. So, you know one thing that's great about products, like they're often like, running what, they do a lot of prioritization. And so they know what what is important to the business, more than the team is distributed. But they usually know more of that stuff than that they're kind of figuring out what goes into the sprint and the conversation, of course, but they kind of know what's going to the sprint. And with it, they also know when we slip and they know when something's not getting done as well. And they need to have that conversation to the engineering manager right engineering that they might know that they're working with a dev on something, they might be like, hey, this does kind of slipping up a bit, then a couple Sprint's in a row, like, you know you're doing anything on that. And you know, it's tough to hear it, but you need to know that because sometimes you have blind spots with it. Right? You know how this isn't so, so that's really good to guide the conversation for me, like, you know, there's been times where I'm like, so how are you doing? Like, are you happy with this project management's that you like it? And they're like, No, actually, I've never really done it at my other places. I never really loved it. But I felt like this was what the person was doing here before got here to continue it. So then we're like, oh, well, let's just find a way to distribute. Let's try something different. And so being open to evolving and changing is really good. So I think that's good. Some other questions that I asked. One was really cool one, I said, Have you ever you ever owned a headless product? You ever own a product that was an API or a platform or something like that? I think that's a really important question to ask in the technology or because you don't want just somebody who's like been able to skin a landing page or something like that. You want somebody knows that like that you can do a lot with technology. And a lot of that stuff is, you know, john, you're doing a lot of stuff right now it's like, it doesn't have a head to it, he doesn't have a face, you can't even see it. But by knowing it exists, it powers the user experience or powers, you know, something else, like development, speed, and all this kind of stuff. So security, instability, all this kind of stuff. So So I asked that question. Another question I asked is, have you ever had to kill a product, this one's really kind of important. Because sometimes you have a product that you're running, and you have a vision, and it's it's on the roadmap, and it just ain't working, you're testing it, it's just not working, or the, you know, environment changes, the industry changes in the middle of it. This is why you don't really do these long waterfall projects, but you never know, something happened, like COVID is a great example. You can still be going agile, and really still have to like, change course heavily because things changed. Usually, like going agile protects you against that stuff, you know, and let's be honest, anybody who was going waterfall for a year long two year long project in the middle of COVID, or did it before we started COVID is probably like, oh, it wasn't there. Yeah, exactly. So I think, you know, being flexible there. So I ask those kind of questions. And then you also want people who are who are kind who can relate to developers who want kind culture, you really want like a happy culture, I think it's very easy to go sour on development team. And really, like, I think, great product engineering, technology teams, like they get together really well. And they, it is really, truly cross functional. And there's no like, you need to have empathy for both. So I always say, for engineers, you know, we need to be talking to business and for product people, they always need to be like, know enough about technology to be able to to be in the conversation. But engineers need to be able to talk in terms of the business because the common language that we have, and so so I look for somebody that can do all that kind of stuff. And and then last one that died, at least in this role was that, you know, I wanted to make sure I said when have you ever had to essentially sell an idea and get on board, something that was tough that people originally, you know, disagreed with? And how are you able to sell it through? JOHN, you've done this a million times. So you can probably write a book on it. But trying to get, you know, try to see how they could do that. Because I also knew that like, I'm in a small company, the co founders are very, very close to the metal and their baby. And so like, how do you get to be able to develop that trust, to be able to come up with new ideas and can pitch them and get them and also be able to put those across different departments. So I look for that this isn't a head of product method. But I think product owners would have to do the same thing. Right, they'd either have to sell this, the superiors on it, or they're beside aside, I think like, you know, great leaders will manage up inside decide down. So yeah, those are some of the things I look for, for a product person.

John 22:46

There's so much I can ask questions about you. And we're gonna go and motivate leaders of technology organizations to start getting into it. Because there are some companies you said, you've talked to your product person a couple of times a day. Is that right?

Mike 23:02

Yeah. Yeah, it may, depending on the meetings that we have. We have because we start chatting on slack. And it's like, I'm too excited to talk to you about this.

John 23:03

Do you do the same with the co founders, you talk to them everyday?

Mike 23:16

them daily. No, no, no, no, no, it's honestly not like that. With co founders, I'm saying the same that you would do with a co founder, like you had a product if you're head of engineering or like, or if you're a dev manager, and you've got like a product lead that you're working with, I believe great healthy ones are like those, like, it's like you could chose a co founder or start your own mini startup within a company.

John 23:36

So I know some more technical or at least the technical organizations, I've been a part of the touch points are farther and fewer in between, I think at one point, the closer my product person was, the better our relationship was. And I mean that geospatially. So they were sitting at the same table as me. And we were constantly talking. And what I've noticed is one as that starts to kind of separate, and your touch points are once a week, once every two weeks, you're just writing a report for them once a week, there's the lossiness starts to grow. And the relationships right, and what kind of work we start to focus on becomes a bit more one sided. And when we come to the table with ideas, the motivation to engage in each other's thoughts is blower, it's reduced. So I think that's a really dude, would you say that? Could tech product business culture is one where they're communicating? Maybe not as formally, but more informal communication, more frequent, informal communication between individuals?

Mike 24:40

Yeah, I agree. I think it's like, you need to be more like co founders, but then the political parties, right. So like, when you got like, really like,

John 24:49

you're using the term co founder. I think there's something significant there.

Mike 24:53

Yeah. Because I think so the company I'm in has two co founders and they're both like, you know co-CEOs. They started up. I don't know where they were, but like, I would imagine one table coming up with idea. And they're like, let's do this, you know, like, think about, you know, the kind of incubators, right? So it's something like that. And at that point, you don't choose somebody that you can't work with, right? Like you choose somebody who's like, you can't. Like you can't like that would be terrible. You could get like a match. Okay? Yeah, well, you know, some of us are, but like, no judgment. Okay. So think about, you know, whoever, whatever experience you had, that you were just thinking about where, you know, it was actually like, you know, you were just like, sending reports to them, and the distance grew further. Okay. Think about that person. Would you ever start a company with that person?

John 25:45

No, I don't think I would.

Mike 25:47

Exactly. But But now think about the person that you were closest to that you were sitting right next to that you're casually chatting with, would you start a company with that person?

John 25:55

Yeah, I have. Yeah.

Mike 26:02

Okay. Okay. So that's it exactly, is, like, I think really healthy product, product and tech leaders, and they work together like that, like co founders, I think that's the best way to do it. I, you know, had this theory after, you know, like, I actually, you know, I think if this is recorded, I reported to john, when I started at Priceline. And I think I wanted to get into product for a bit because I wanted to have like more say, in like, what we prioritize and what we built. And I actually came back to that when I left Priceline, because I was thinking, I maybe I'll go into product, because, and I actually, like, looked at a few like VP of product roles. And I was like, thinking about it. And then I realized the happy, happier solution is that actually, you can have a lot of say, of what gets built if you're in a healthy company in a healthy organization, as technology leader. So that's a really cool place. So I actually tell this to anybody who's an engineer who's like us think I'm against the product, and I am thinking, I know why you want to get the product. And then they tell me, it's like, I want to get more into what we do not not just how we do it. And I said, it's a conversation. And in the right order, you can totally find that. There are some words that engineering actually drives that. And product is just like, an FYI, I think even Facebook, I've understood works that way. So it depends. So so that's why I keep going back to co founders and kind of thinking like, Hey, you wouldn't co found a company with somebody don't get along with them that you're not excited to work on the same mission together. And so I think that's a great analogy for like, what a good pairing for the product and technology leaders.

John 27:38

As a founder, there's this obvious sense of control over over what's happening, right? Because it's your business, it's your product. So were you saying or using the term co founder between and with your partnership with product as your position in ownership? And like that mindset?

Mike 27:56

A little bit, I guess, like, yeah, just more like two heads thinking, you know, driving what technology does within it, ideally, like you have. So if you have like leadership, and then you have like, department leadership, and then you have the execution level, ideally, you don't have this happening, right, where you've got like senior leadership coming in and knowing really what's happening execution level, it's not efficient. For anybody, it's like, it's really not a good scene, we don't have that here. I mean, you ideally don't want that. So the interface is really between these two. And so you used to have trust, in order for this not to happen, you have to have trust here. And so, and ideally, this is what the check ins are, this is what we do quarterly planning, all this kind of stuff, you start to get to know what if you have a boss, and a boss could be a literal boss, or it could be a board or it could be investors, the wishes of the investors in the board and your bosses, they should influence what you do, because your expectations are set really by them. And then you can help manage expectations. But they're, you know, what they want you to do is why you are hired and why you will still working there, once you stopped doing what they want you to do. Like you're not you're no use to the company. And so like, yeah, there has to be. So that's why you got to join the organization. Like you're in line with what with what the expectations are. That's a whole nother talk. But, you know, so So I think the idea is that, like, you know, we're essentially co founders of the technology org. And so we want to have autonomy and ownership of that org, but still kind of meeting the expectations of leadership.

John 29:28

That makes sense. And this might be a little bit of a segue, but I just wanted, I want to catch it while you're there. You meant you said autonomy. Why is what makes autonomy significant to technology?

Mike 29:40

oh, no, no, autonomy is different for everybody. For me, I love autonomy. It's just the way I was raised. I rebel against not having autonomy. You know, so it's struggles but it's a struggle, and I've had some years to deal with those struggles and now I'm a little bit better at life. Like, understanding that, that full autonomy is not something you'll ever get if you have a boss. And that's why you choose to. That's why you either choose to be an entrepreneur and self self employed and never have investors never have anything like that. Or you'll get into an organization where you can grow, but you're gonna have bosses like them. And it really just is like, it's really just directional. You just want to make sure that you know what your bosses are wanting you to execute on. And then and then you find your own way to execute. That's the way I like to work. I don't like prescriptive anything. I don't like command and control. I like I like, here's where I need you to go. Find a way to get there right now. And maybe in this time, and then I'm like, Okay, cool. It's like, you don't want to be, you don't want somebody to give you a blank canvas and say, paint me something, you maybe it's better to say, here's a blank canvas, you know, it's eight by 10. use acrylic, and I want it to be something uplifting, and then you still got tons of autonomy in it. But like you've got some kind of constraints and so, so yeah, so I think it's different for everyone. I used to think like everyone needed autonomy. And so I always wanted to run my team because I needed autonomy. And I was like, Okay, well, everyone wants autonomy. So like, you know, let me make sure that the teams I create, I'll have autonomy, but you know, there's tons of places you don't have autonomy, peer programming, like you go to the Pivotal Labs, and everyone's doing pair programming. It's not really necessarily autonomy, it's kind of like, you know, it's the opposite of autonomy. It's but you know, it is like, we trust you, but like you're working together, do it. I don't know, I think ownerships, autonomy and ownership are a little bit different. You know, I think for me, ownership fields were really good. And so it's almost like, but sometimes you have to be able to give enough guidance, to set somebody up for success. If you have like a more junior Dev, who really wants some ownership, you give them a bigger project, right, you give them a little bit more apart, maybe they get into the analytics game, and they start to kind of own that start to add, I just find that ownership is really important for engineers, and not just engineers, because you'll essentially like people will become more engaged, and you'll actually get more out of them. And when you get more out of them, it's like a light bulb shining brighter, they shine brighter, they'll just shine like a light bulb, can you turn it on it and it lights up the room, that's great. But like, you know, you have a really great light bulb, where you put a lot more power into that thing gets brighter, it does a lot more it shines the light on different parts of the room that you couldn't see maybe from outside, now you can see a little bit of stuff. And it changes the whole on the outside of the of the room. And in this case, like the team or the company of the orc. And so I think I like it, because I love the idea of of work smarter, not harder. And I think with great ownership, you can get more, more dense output from people more saturation, and somebody's day, you get better quality work, it'll be infectious to the rest of the team. And, and I think like you might get like dividends down the line where I think of the opposite, without autonomy and without ownership, certainly for me, but I think for a lot of people, if I let's say you would give ownership over some pieces of code, you just kind of came in there sorry, like telling them what to do, which which happens to all of us, sometimes I think it can be a disengaging, and that person's morale might even drop that person's morale drops, the code isn't going to be well tested. And, you know, it might not be written Well, it might be buggy, and and certainly like they're not gonna be excited about it. And then that might be infectious to the team and the wrong way. So that's what I think. But again, every leader has different values, and those, those will be kind of ingrained in the DNA of the team just as a result of the leader. And so for me, autonomy and ownership always been important in my adult life. And so, you know, I can't help but have that kind of flow down to the team that I'm building,

John 33:40

getting kind of connecting that to the to the odd person in their organization, what role does the product, so the product person has an effect on what you experienced as autonomy?

Mike 33:52

I'm not really I mean, I think like if you choose somebody who's got that Ying and Yang, you kind of already know what parts you own, you know, for example, the last product owner I worked with, no, I would say that we were kind of like this more like that. And actually won't say we were even Yang and Yang, I think it was I don't know how to do this with my hands. But there was a lot of overlap. And I think it depends on what you know, my choice to go to a company I'm at right now is a choice of breadth versus depth, a lot more to own and like not a lot of stepping on toes. And so like a lot more to like to grow and no worries. But so I think like, yeah, you want to find somebody who's a really nice compliment to you not a lot of overlap. And I understand this is what you do when you when you choose co founders as well. You just don't want somebody who's got all the strengths you do. Because then when you need that thing, you don't aren't strong and you got nobody to do it both. You have nobody to do it. And so I think you get great ownership just by like, how you define the yin and the yang are and so there's this things that that that a practice doesn't, doesn't have passion for and this thing that I'm really passionate about and they're so there's overlap and there's overlap in a good way, but it's never really about ownership. Like, for example, in this situation, this person loves, kind of like, you know, driving stakeholder meetings they love, you know, putting together presentations and getting everybody on board and driving the ships with other teams. They love thinking strategy and putting numbers to the strategy, they love, kind of like telling that telling that story, they love, like getting their hands dirty, you know, they might not be writing code, but they're doing a lot of like still kind of technical things, integrations and this kind of stuff, what a lot of like systems have, since we're using other systems, a lot of systems have interfaces, that you can draft your own workflows and stuff. So they do a lot of that kind of stuff. So they're, they're doing the stuff that I actually don't want to do, I don't want to really do any of that kind of stuff. And so I don't enter thinking about the business, for example, and they're thinking I think about the business, but I'm not thinking about it on like, let's move conversion from this to that, let's run these A B test theorises kind of stuff. I think if user, you know, analyzing units, user journeys, all kinds of I don't, I'm interested in it. But I have no interest, my biggest thing is like, is it consistent? Are we using a design system? Can we reuse some some pieces? Is it going to be accessible? Can it fast? Is it going to affect our performance? Is there some personalization? We can do? And should we build this API that if we don't build that API, if we do build the API, we're going to need a team. If we get that team, can we actually fund that team for a year, two years on done, we're going to need to maintain this thing and grow it and then to bring a product in or something, you want to buy that kind of stuff, and then think about most strategy. So we very seldom, definitely each other's toes, I actually came to think about a time that we did, whereas on my last opportunity, I think the scope was a lot more narrow, so not a lot of breath. And within that scope, the responsibilities of engineering were not too different from the responsibilities of product and my product lead in that that project was very technical, and you know how to computer background and, and so very technical, I think probably could have done a lot of it, themselves. And I was really just kind of left protecting, you know, sanity of the code and pushing for factor and good development practices. But you know, it just wasn't that interesting, where right now I know, my hands are super full, and they're full of different stuff. That's not just about development, you know, and it's stuff that like, like, you know, like it and security and this kind of stuff, and interesting in and wants to help out and wants to kind of adopt that, you know, right? Again, in the beginning, I said, revenue retention, and it's like stability, all this kind of stuff. They're willing to flex all across that, but they don't have that much interested to get deep into the weeds there. So yeah, I just kind of get ownership just because there's a lot of work to do. And the young and the anger are so well defined.

John 33:56

If I'm struggling with my product person, and what I mean by that what I mean, my struggle is I don't, it seems that the things I'm saying aren't necessarily connecting with value for for my partner, if I'm if I'm working with a product person, if I was in that situation, do you have any advice for me?

Mike 37:57

I'm sure you've never been in that situation.

Yeah, I've been there, of course, I think, you know, as a fetus, part of me, that's like, look up and see what the org looks like and see what the values from above are and how they trickle down. It'll trickle down different if you're, depending on the org that you're in, if you're reporting to a CTO, and they're reporting to CPO, and you look up, and the values are different, and the goals are different, you might not be able to reconcile it might be really hard. I think, depending on the company, that could be a really tough thing. But I think actually our mutual boss, our last placement a couple years ago, the one really great thing that I took away from that person was that they said, you know, there's only one common language that everyone should speak. And that's the business. And so, you know, I would check yourself to make sure that you're talking about the business. And if you really are an engineering stuff is sometimes hard to sell. But there's ways to sell it directly and indirectly. And I think like, you know, keeping that in mind is really important. And having that conversation, also reminding them

John 39:04

I know I'm interrupting you here. But there's, I'm curious, do you have an example of like, what a disconnect would look like and then another one where there's actually a connection between a word technologist is using the business language or the language of the business?

Mike 39:17

Yeah, so I think it just kind of, kind of like alluded to it before. So you know, at our last company, you know, the team I was leading, there was an engineer who was really interested in doing GoLang, Okay, which is cool. It was great. They were all about it. And I was like, This is great. This is like really engaging for the team, they really want to learn it, and, you know, made this opportunity that we can really become innovative here at this company. But the company at that point, had not really been incredibly innovative in this kind of way. It wasn't the real space that they had a lot of strengthen. And so it was really kind of going against the grain and sometimes that's a tall order to fill and so, you know,

John 39:56

going against the grain is, it sounds like interesting Using a language for the sake of technological engagement,

Mike 40:03

yeah. And so you got to think about it. How is that helping the business? Now, I think a clear way to look. So let's think about go GoLang at a company that was JavaScript and Java. Okay, well, so GoLang is going to hopefully engage a bunch of engineers, and hopefully retain a bunch of engineers and attract a bunch. And that's really great and might even make the company more attractive, as a technology might move as a company into like, really being a leader in technology. But you know, I don't think it had really been publicly, that kind of place and even talent wise, like, a lot of great engineers, and we're big name, and we could get people but if it wasn't, we're gonna be, you know, Facebook, Amazon, you know, it was going to be tough to do that. And also like the, you know, cultural issues, there would have been really difficult to introduce. So I think actually looking back, you know, I'm glad I had the experience, but I think it wasn't the right choice for the company to go down that road, because I don't think there's enough business value in there, because it took a while to do it, to actually roll out a new language like that, and was hard. And it had to work with what other teams that were already small and tax, and the company was small and tax, and we had support from leadership, tech. But I think what we found even with that is like, even if you had a CTO who's really passionate about pushing the envelope with technology, it has to be in the DNA of the company. And certainly the current leader of the company, if it's not just a list of things like values do not sounds crappy, but values do not come from the bottom, they might be able to come from the bottom, they only will win if the top agrees with him. You know, if you have values here that are different values here, they're not going to last that long. I this is what my experience has been. So they were close to the top, but maybe not close enough. So I think that was a that was a mistake that I made in the sense that I don't think that was a good business decision. It was hard to sell to the product, and otherwise there because the benefits were hard to see. And even the benefits down the road. were hard to see. And, you know, I think it was tough. But then again, there's been that challenge that I came into I think you had been part of it with with Node.js. And if you hadn't fought that fight with Node.js. I mean, I think it'd be a really tough situation over there. So I think it's choosing the right one, I'm not sure that goLang was the right one, and it didn't buy us too much time. So I think that's that's an example that really, really hard to the business one, the Node JS is an easier one. It's like JavaScript server, a JavaScript on the client, same language, same hires, you know, we can't do any of this kind of stuff right now without it because we have this PHP thing. Well, we can do all these kind of things, it's like really much easier to have that conversation. And even though it probably wasn't that easy, but I think that was like, maybe he should want to sell him to go live on less with that. So that's an example of one I think was not good example of one that I think is good is, you know, I think about my company right now, like one of the biggest ones that I have to sell is we've got this, we got this new API that we launched the consultant to build kind of right after I started. But the API is really like a proxy pass through, it doesn't do too much for us. And one of our parts of our platform, this kind of customer portal is is really like hard to debug, it's scary, a little bit fragile. And not a lot of people understand a lot of there's a lot of complexity. And so the conversation I'm always having is Hey, like one day, we're going to have to really refactor this thing. And I don't like to do full out 100% refactoring, I like to kind of refactor from the inside out, if possible, Sometimes it works, sometimes it doesn't. And you try to gain wins along the way. So I'm like, Okay, well, this is layer that we really have to refactor. And I think that we can do an investment here and still be able to have that power, this new product idea that you've got, and still get us a win here. If we do this, we're going to move fast and seems to be higher morale comes up, it's easier to make those kind of cases. So should we tie them to actual existing problems that the product owner can see like, hey, morale is gonna low COVID. You know, like, hey, like, this parts really buggy, and we're having a hard time with it, or, hey, we get a lot of complaints from customers here and have a hard time tracing down the issues. And it's because of this kind of stuff. Then you also get, you know, if you have a healthy, you know, you have a healthy engineering team, by product team. You have like retrospectives, and this stuff comes up retrospectives, it comes up and in casual conversations from the team. It's not just you saying it, it's there, you start to kind of understand it. And then a really great way to do it the same way that we did it. Whenever I talked about the co founders were like, well, if you want this thing, this one of these things has got to go. Again, when you have a healthy team, you're doing backlog grooming and backlog grooming, they're like, Alright, well, let's, you know, here's this, this new story that we want to do. Everybody was pointed, and everyone's like, an eight, that's a 13. And they're like, Why is that a 13. It's just like changing the fields. And all the engineers like collectively like that sealed lives over here and here. If you change this, this is going to break with the test, all this kind of stuff. So those kind of messages come up and they realize that they pay more to do small incremental work, because this refactor has not happened. And with this refactor these things, instead of being taken a sprint and a half, they're gonna take a day. And so for them, especially if they want to start doing some, a lot of iteration in that, that part of the code base, it's going to be in their best interest to do that. So I think that's a really, really great way. But I always believe that like, you don't want to go six months to a year replatforming something and getting no business value out of it. So whatever you can do to kind of start doing that MVP style skateboard sports car, like getting some stuff out, and getting some business value and customer value out early. That's the best way to do it. But again, in order to have that you have to have trust that product owner, my partner has to be able to be like, I trust Mike, but he wouldn't speak up on this as important. And he didn't speak up about the other thing, because he believes that, like there's another part of the code base that the team actually kind of wants to refactor because it's really gnarly. And I'm like, and the product owner will be like, should we get should we refactor with somebody? No, we shouldn't refactor this gonna take us a month and a half. And that code, hopefully, if this test goes, Well, will will die in three months, I don't want to spend any time on it. So you have to have build trust with with that.

John 46:10

That shows I think that's actually really an interesting conversation, because you're showing as a technologist you're showing constraint, right? You're showing your interest, just as much as them that you have the same values and you're making decisions. It sounds like, the more you align on the on where the source of the decision making, whether you're making a product, like a product forward are kind of user experience for or how long your technology organizations organized, the more of those things are rooted in the same foundational values. Right, then you're both kind of coming to the table, you're both showing constraint on each other on yourselves within the domains that you're engaged in. Yep, we're almost at the hour. I wanted to ask you the same question again. But from the product person's perspective, if I'm a Product person, and I'm struggling to connect with and I feel maybe conflict with my technology organization, what would you recommend to me to do?

Mike 47:06

Yeah, that's great. I mean, any partnership is all about empathy and perspective, right? So especially if there's tension, it's just, you know, I actually, I had a tough conversation last week, it wasn't around product, but like, just having that conversation. We're both like, why didn't we have this conversation before we've been building the tension, because someone's thinking something, someone else is doing something, get it out, talk it out. If you're having weekly check ins, which you really should, I used to like winter, in a world where we could go out and walk out for a coffee, I used to like, pushing for kind of one on ones that way. Because once you're out of the office, and you're walking, you tend to like talk about other stuff, like not even talk about about work, you might you might just talk about what you doing this weekend, or how's the new house or something like that. So I think starting there, but yeah, empathy and perspective, you know, you want to make sure that, that you're really thinking about the business too. And, you know, and making sure that you're not just going for conversion all day at the expense of your code base. Because what I always kind of found is like, it's really important for people to stay longer than a year at a company, because the decisions you make, you don't see how they actually really panned out until you've been there for a couple years. And so I had seen situations, we have a product and you're coming and be like conversion, conversion, conversion, then they leave after a year. And it's like, you don't realize that those choices that that you helped to make, and you know, where you didn't refactor, and you didn't clean up those tests like that two years later that that codebase exploded, and like, the engineers on there are meeting at like, three times slower. So I think that's really, really important. So I think it's like, you know, being self aware, and ensuring that you're the business is, its person that you're having conversation that level, but then also understand what it's like to be an engineer and know, if you're popular, you're like really thinking about KPIs and measuring stuff. There's ways to measure team morale, there's ways to get feedback through retrospectives through one on one with your team, say, hey, like, what's the thing that's bothering you the most in the code base and see how passionate they are? They're like, Ah, you know, we probably could have more tests, then it's like, okay, but they're like, Oh, my God, this part of the code was and never want to touch it. Every time I do it, I'm like, I'm sweating bullets at night. I'm having nightmares about it, which is actually a thing that happens, right? start to get some more empathy, like, Damn, I don't want this person to be waking up in the middle of the night thinking about this codebase because I'm doing something over there. So I think like, understanding the perspective, the empathy of the of the engineers, and you know, I think just mutual perspectives, the greatest thing there, so just, you know, and that's why engineers have to be thinking about product, they have to be like, well, we're sorry, we can't refactor this right now, this isn't a post COVID world like, you know, maybe we're slimmer than when we were in better effect is going to have to wait, you know, and just kind of like in Vienna together. So I think like, yeah, mutual empathy and perspectives. I think.

John 49:48

I love that. That's, I think that's a brilliant piece of feedback. Like if I was going to change something tomorrow, and I was a product person that gives me the conversation I can have a reset So maybe getting involved a little bit in technical requirements gathering, but not too much, but at least just being aware that your engineering staff can be coming into something that they look at as problematic. And you can use that as feedback to know, right, like, where if you were going to invest something you and where you want to iterate, or change, where to invest that or to consult your technology leadership, to understand what kind of benefit or value, you can get out of more long term grooming, and use term hygiene as well, which I think is also appropriate of the products that maintaining

Mike 50:36

Yeah, and I'll say actually our mutual boss, it's another thing to me, like that person should be, should be speaking on your behalf, like that person should be looking for opportunities to help you out to be like, you know, I know, Jimmy really needs a refactor on this thing. Well, this project is coming up, I think it's a really, like, actually offer it like you should be kind of like, and you should be able to be like, the conversation I had about like, well, we're not gonna react to that by the code base, I think we're gonna test out of it, you know, don't wait, the product owners, you know, space capacity, like, they probably don't have as many as much firepower with your engineering team as they'd like to. So empathy, like, you know, throw each other about what to look out for each other there.

John 51:15

That's a great conclusion, Mike. So before we break, the last thing I wanted to ask you is, you know, if you had anything that you wanted to share that you have going on, or if people were gonna reach out to you, how could they do that? And for what reasons, maybe they could reach out to you?

Mike 51:30

Yeah, sure. I mean, nothing, I'm literally looking to promote, at the moment, really happy to have been invited to talk. This is super awesome. And, you know, my biggest thing is I love to make to make impact. And so this helps anybody out there. I'm happy to, I'd love to hear about it. But I'm also happier, happy to do like, you know, coaching one on one, if you need a little bit of mentorship, you know, reach out to me, you know, best bet is probably directly my email Mike Archie that gmail.com? Because Find me on LinkedIn. But you know, I think emails fine. But yeah, I'd love to, you know, I got small team right now, I'd love to grow it. So we're also hiring. So any engineers looking full stack engineers? Looking? Definitely looking to bring a few devs

NodeJS react TypeScript style components. kind of stuff.

John 52:22

Beautiful. You said emails, the best way to reach you with email. Yeah. Cool. So I'll make sure to include relevant links in such as well, Mike, thanks so much, man. This is so cool. Seeing you this morning and talking to you. It's really great way to start my week actually.

Mike 52:38

Cool, thanks again.

John 52:40

Yeah, definitely. Man. I definitely have a lot more questions. But yeah, thanks a lot for hanging out with me this morning. And we'll be in touch.

Mike 52:48

All right, buddy.

John 52:51

Thanks for tuning in to the pragmatically podcast. If you found this conversation interesting or helpful. We would appreciate your feedback. If you want even more content like what you just heard. Check out pragmatic lead calm. If you have a story to tell, send an email to pragmatic lead@gmail.com and someone will be in touch. Thanks again.