Watch the Episode
Listen to the Episode
Transcript
Welcome to another episode of The Pair Program. The show that brings together two technologists from the startup world to tackle topics at the intersection of technology and career growth. I’m your host, Tim Winkler. Along with my co-host Mike Gruen. Let’s get into it. Becca, Johnny, thanks for joining us.
Thanks for having me.
Of course. So as this is The Pair Program. We like to have everything here, so let’s just kick things off with a few pairing hot takes. I’ll begin. Yeah, something that I, takes me back to my childhood. Used to love, always putting together macaroni and cheese.
Not your normal mixing, but at the same time as a little bit extra flavor to that or hot sauce, but catch up tends to be something that I’ve always thrown in just to add flavor. Has anybody tried or taken in this before?
Sounds terrible.
Absolutely not.
Ketchup feels lazy.
Yeah, I can’t go wrong. Mike, let me get us. What are you going to go? So in honor, of the t-shirt, I’m wearing my Joan Jett and the Blackhearts t-shirt for those watching the video I’m going with female vocalists and punk or metal music I’m a big riot girl fan and I think it’s an underrated genre and there’s just something to it.
Respect. Thanks Johnny. What you got, I’m going to go safe, peanut butter and jelly. And the only reason is because I have a really dark sense of humor, and I really want this to be able to beat played out loud at someone’s office. So I’m just going to stick there. I liked it. I like it. Crunchy or creamy.
Definitely creamy. Creamy is really the only option. That’s the only option I like yourself. Mine feels a little random, although maybe less random after what Mike shared mine is actually Miley Cyrus and cover songs. So I’m a huge Miley Cyrus fan, original sun Whiting could could use some work, but I think she does some amazing covers especially some rock covers.
So yeah, big fan of that. Yeah. I would say recently the one that’s been getting a lot of air time is her cover with Metallica of nothing else matters. It’s really good. She’s got this deeper voice now, which is I think, a perfect fit for that. But also really earlier this year she did a zombie, which is.
Phenomenal. And going back a bit further, a version of a summertime sadness by Lana Del Ray, which again, she just nails it. So that’s classic. Does she ever do a cover? She, I think she actually featured Joan Jett on her last album. Okay. Don’t hold me that he’s a critic podcast. We’re going to need our producers to fact check that, but yeah, good stuff.
All right. Deja VU,
we’re going to stream right into the the actual meat of the episode years. On today’s episode, we’re going to be dissecting the unique relationship between product teams and engineering teams within startup environments. A lot to unwrap here. And to be honest with you, it’s such a broad topic that we’ll like.
We have several followup episodes on this subject alone. Given we only have about 40 minutes here. I thought it made sense to keep it a little more higher level. We can start by just defining some of the roles here and Johnny. Yeah, there are engineering perspective. Becca take our product perspective.
Johnny, let’s start with you, how do you define the role of the engineering team, where they plays, but then. Yeah. So as you might imagine, not all startups are equal, you have everything from, pre series, a just, maybe 20 people to, like series D quote, unquote startups.
But I think that, if you take till, for example, we’re still pretty early in our life cycle. I think that engineers are probably best thinking about, the, how not to say that there’s a, a border and a hard line between product and engineering in terms of what versus how.
But I think that if hire the right folks then there’ll be very focused on. How to solve your problem. Bringing problems to the table is probably going to be best suited for engineering teams and just giving them the autonomy and the latitude to solve those problems.
Given whatever constraints you have, we’re never doing anything in a vacuum, but I think that’s probably, the best way to think about it. Moving forward.
Becca, how do you feel? I guess the product team where that plays in. Yeah, I would say it’s similar in terms of it varies a lot depending on the type of organization. And I think Johnny’s, point’s a good one around stage. I also think it really depends on just your leadership and in some cases your founding team.
And I think the thing with product that’s really challenging is you have some leaders that bring in product teams and really empower them to figure out. What you know what to build. And then I think you have a lot of leadership out there that has a very strong idea of that themselves. And so I think that can really influence what role the product team plays and how much they spend time on discovery work and really.
Talking to users and understanding what to build and not just what, but sometimes like why I think that’s an important part of it too. Versus getting pulled more into the, how, like Johnny said, and really just working a lot more with the engineering team on the specifics of the solution. And so I think sometimes that can create, if you have leadership, that’s spending too much time in that area that can like condense everybody in the how.
And I think that’s where things can get a little bit tricky. Because then I think you sometimes get product teams that function a little bit more in that like project management space versus what I would call like real product doing more of that discovery works. Yeah, it can be very fluid. Yeah. I think when I think about it and both teams are working together collaboratively to solve, basically, we’re trying to produce the product, we’re building the thing.
That’s. Yeah, drive revenue. And so they work together and then right where that, where those lines are, who’s responsible for design, like UI design or graphic design or whatever, maybe not graphic, but and then who is responsible for like user experience and flow and then. What the why and the how and all that.
And then right, yet in sort of leadership, like executive level, there’s, visionary leaders who they know what they want built. And now it’s really product’s job to take that vision. And it’s more of an execution mindset of how to take that vision out of the founders had, or the leaders had, and communicate that effectively to the engineering team in a way that is not.
Specific or whatever. And I think right, depending on the stage, depending on the people that you have in the organization, there’s just a lot of flow. And I think that’s where there’s the most conflict is when, like you have a visionary leader and a visionary product person. And now they’re just bumping heads all the time, rather than maybe pairing things up or similarly, a really technical product manager who really does understand that.
Like how. Working with an engineer who is stop telling me how to do my job. I know what I’m doing. Just tell me what problem I need to solve. And then that’s usually where the conflicts arise is when there’s two people with very similar skill sets, trying to solve the same problem in different ways or not, and it can be collaborative that it doesn’t have to be a hostile conflict.
It can be a collaborative conflict if you will, but healthy tension and friction. But I think that’s how I think about it. I’m curious, you guys, I just preach there for a little bit, but I’m curious about your thoughts are. No, that’s a, I think that’s really spot on. Especially when you start to drill down and thinking about the individual, I’ve worked with some product managers who were like, so technical, if you didn’t know, they were a product manager and just listen to them, talk about certain aspects of the product. Like they sound like they could be an engineer, and vice versa. Some engineers are so product minded, it’s not until they actually start talking about code that you realize, oh, they’re a software engineer.
They not actually. Like the product team. And so sometimes there’s a mismatch there, right? Where you have more of a product minded software engineer who is expecting certain things from the product person who has maybe just more on the technical side and maybe doing more of a project management, a job.
And so neither one of them are really getting what they want. And so there could be a little bit of tension there, but they’re both really good at their jobs. Just not quite a good alignment of skillsets. As far as engineers go, it’s easier to find, front end engineers that are going to be more product minded than like backend engineers that are more behind the scenes, not as product savvy or, I hesitate to say that only because in, and this is just based on my experience.
I could see why, that would be something that a lot of people would think, but I don’t know. Maybe I’m just like really fortunate to just know some of the engineers that I know, but I know like back in engineers who like, wrangled data all the time, who are very. In tune with the product and what it’s doing, who it’s what problems it’s trying to solve, who are the personas?
Like these are like very good conversations to have with these particular folks, but also some front engineers, particularly if they’re like more on the junior side, they may not have a strong grasp on the product problem to be solved, but they know the specific tasks in the project that they’re working on.
I could see a correlation as people get more, maybe senior in their career, but I don’t see that play out. Maybe nearly as acutely as other people do. I know I a hundred percent agree. I don’t think it has to do with where you are in the stack, as much as where you are in your career. I’m curious about. I agree with that or feel free to fight me.
That’s fine. No, I would agree with that. In my experience, procure rated right now. We have a team of full stack engineers and I would say that they’re like willingness and enthusiasm to be involved in the product development process and working so closely with the product team is more about Personality and also who we hire for.
We’re very intentional to find. We don’t really want to hire an engineer. That’s oh I’m good. Just kinda tell me what to do and I’ll go do it. Like we want a team that will think really critically about what we’re building and is it the right thing for us to be building. And so I think, yeah, it really depends on whether or not you’re intentional about that when you’re having.
I think that’s actually a great point. I think that’s something that is pretty common in the growth. When you’re looking at startups and growth stage companies is that’s the type of people you’re looking for, especially early on is who can bridge that. And I think I’m curious, Becca what’s your experience like?
So with this sort of conflict that sort of inherently comes from that because now you have a product person saying, Hey, this is the problem. I think that we should be solving. Here’s the, and then you have engineers who may be. Don’t agree with that and think that, and so now you can see where this can get a little attention and I’m curious, especially at a growth stage, what your experience with that is.
Yeah. I would say my like hot take on all of that. If I can brand it that way is that I think the thing that people don’t acknowledge that often is like, That friction is actually a really good thing. And it is so much easier. If you have these perfectly defined roles and it’s you do this and you do that.
And we all just like hand things off, build what somebody tells us to build. That’s easier, like a hundred percent I think, but I don’t think you can actually build innovative products that way. And so I think like where. The good stuff happens is where there’s that overlap where you do have product and engineering, thinking about the problem and like really challenging one another on it.
And I think that’s uncomfortable for a lot of people and that’s why people sometimes shy away from it because it is easier to just not do that. But I think that’s not how you get to the right answer. And I think. Is, and I agree at, cause I, when I think of I’ve drawn this diagram, almost every company I’ve worked at to describe like engineering and products, relationship and products, relationship with the rest of the company, which is product and engineering are like two cogs that have to like.
Intermesh for those who are just listening and can’t see my hands, I apologize. But then you have and then product also has all these rubber bands, if you will, or whatever you wanna call them to, to the belts, to the rest of the organization. Cause there also has to be tension with sales and marketing and that’s, what’s going to make the engine flow, right?
It’s that friction that that healthy friction between engineering and product that really make everything work. And I think I totally agree with the you can’t build any. Really meaningful if in a way if nobody’s being challenged and there no challenge, I think part of that, and it’s something I hire for is open-mindedness and the idea that like, we’re just trying to solve a problem.
We’re just pitching ideas. That’s not my idea. It’s not your idea. We’re just trying to build better ideas on top of what each other’s doing. And I think that’s an important part. Yeah. I feel like personality traits are something that you got dial in on, right? If you higher up maybe engineers that are looking for that power struggle and less inclined to collaborate or get direction from product at times, it could be that bad friction that you want
for context, I’m curious back what is the size of procure rated and the size of the engineering teams and the product teams from a head. Yeah. So right now we’re around 25 people total. And we have four engineers, two product managers and a UX designer that are working. We’re all working together pretty closely.
And is there like a chief technology officer or it was the founder technical in nature, or I guess how did that, it’s actually a great question. The short answer is no. We our founder is more, his experience has in our industry in the world of public procurement. And when he hired me, I was actually the first person brought on board.
And that was very meaningful to me to know that the first hire at the organization would be someone product focused. And so initially when we got started, we were actually working with a team of engineers that we were contracting with which worked out really well because we were co located in a WeWork space.
And it wasn’t maybe that typical relationship where we were like throwing things over the fence to them. Like it was probably more collaboratives in most contractor relationships might be. And then we just hired and built our own team out of that. One of our engineers she moved over from that contract team to join our team and then have just hired our kind of full stack, mid to senior level engineers to round out that team.
We actually don’t really have anyone at the leadership level of the company that is has an engineering background. So I think it’s a bit of a unique setup, but has worked for us. We’re in the process right now of starting to recruit for a director of engineering. Because I do think that it’s important to.
One have that technical voice at the leadership level. And just someone that can be a great manager for our current team. That’s happening now, but yeah, I think we’re unique in, in how our, how we evolved in staffing out that. So you were the first hire on the technical team was a pro product hire Johnny, what about your situation?
At till, yeah. Let’s see. We’re about 34, 35 ish people today. And by the time people listen to this engineering team will be at 12 people. I think product deal. For folks, I think at that point let’s see. When I first came on board, there were a few people there. We hadn’t hired anyone on the product side yet.
And so we grew engineering first kind of, a little bit of the opposite actually took us a long time to find a really good product manager, like a long time, way longer than we want it to. And so we started. Engineers who are like very product focused, then want it to have a voice at that table.
And so that’s where we grew our strength there. So we have pretty product strong product line engineers. And then we eventually did find our current VP of product Karen Ellenberger and was able grow a product organization based on her leadership. And so we eventually did get there, but it was by way of growing the technical site first and then bring it on product.
As we were able to do. Yeah, I think it’s interesting how hard it is to find a really good product person. I think that’s especially how to product. I think that’s a theme throughout my career. Not to say that I’ve, I’ve worked with great ones. I’ve worked with, some others that haven’t maybe been as great.
It’s definitely a challenge. I think it’s a challenging role. I’m curious, beca like, How do you define success? What, like how do you know if you’re being successful in product? Like in engineering, it’s a little bit easier in sales. It’s a little easier. I feel like product, that’s harder role.
I’m curious what your. What’s interesting is you described that. I started to think a little bit about almost this like chicken and egg problem of, I think part of the reason it’s hard to find good product people is that sometimes the people hiring for that role don’t actually know what that means, or like what kind of product person would be a good fit for their role. And it’s there within the product function. I think. Product leaders have lots of different strengths. You do have those product leaders. I think that have really great fundamentals when it comes to the discovery work and, user research and testing and that kind of thing.
And then you have product leaders that maybe have been closer on kind of the build side of things and are a little bit more. Just used to working very closely with engineering teams. And so yeah, I think there’s just, there’s so much variance that and I think that’s part of, if you’re interviewing as a product person, looking for a leadership role having a level of self-awareness to know where you fall on that spectrum and therefore what a good fit would be for you.
And then like really asking smart questions about that during an interview process. And even if there’s a company that you’re super excited about and really want to work for just being honest with yourself of are you the right kind of product person for that company based on your assessment of what that organization really needs.
But yeah, I think there’s, there is a lot of. Self-awareness that is required on all parts to really find that right fit. I think that’s an excellent point. I actually, as you were talking, I was even thinking back over like the product managers who maybe I thought were not as, as good, but it really is that they were just not as good a fit.
We had a visionary CEO who wanted to find a visionary product person because he wanted. Defer the vision, but it was like, no, that’s not right. What we need is a different type of product manager, a different type of head of product. And I think so yeah, I’d like to retract my earlier statement.
Maybe it was just more about mismatch as opposed to how good or bad they were at their job. It’s more about how good or bad they were fitting the organization and the organizational needs. I think that’s a excellent point about self-aware. Yeah, I think that’s spot on. I think Becca hit the nail on the head.
One of the things we talked about super early on until when we were thinking about this. Sure. It was a matter of what makes a good product manager, product managers have been different at every company I’ve been at. And so the thing that we really honed on was, what makes a good product manager at till, right?
What does it till product manager look like? What does success look like for that person? And it’s so different. All the different organizations, depending on, how technical you need folks to be, to tobacco’s point or visionary or strategic and companies with multiple different products, you need like different types of product managers to build out those products.
Sometimes if it’s a more established product, maybe you just need someone just keep the ship going, or if it’s. Who’s like literally building out a new market, right? You need that more visionary, strategic hire to be able to go out and building that Greenfield.
So it really it’s highly use case dependent. We’ve spoken to a guest on the podcast previously, who’s a product leader and he’s very dialed in from the seed to series a stage. That’s his sweet spot and he knows that a good product person isn’t. Isn’t to is very aware of knowing when to fire themselves almost of going to the leadership and saying, look, we’ve already found product market fit.
I was really dialed in here. We’re doing user research. You need somebody different at this next stage. And it’s no hard feelings. It’s not oh, I couldn’t maybe do the job, but there’s somebody that really knows how to do it at that stage. That’s going to be better than me. And that was an interesting spot because I feel like that is a very unique.
Use case.
Yeah. I think that the same applies in engineering as well. I think there’s engineers who really hit a sweet spot, like at an early stage company who have the sort of capability of doing everything. And they really enjoy that sort of full coverage type stuff and get it done. And then, as the organization grows your needs change.
And I think that’s an important part, whether you’re in engineering or product or wherever you are in a small company, as it grows that at some point. The role that you most enjoy might not really be there, or the role that you’re best suited for might not really be at the company anymore because there’s been there’s just new needs now.
You don’t need that. But I think that self-awareness super important. Yeah. So as far as like roles being defined, it’s safe to say, I guess product managers equal the why and the what your engineering team kind of the house. The product team serving as a way to empower like the engineering team to understand why they’re building, what they’re building and who they’re helping.
Oh, how about, how that all comes together? Collaboration tips on, what works, what doesn’t work, any specific examples that come to mind that have worked really well for you all in terms of getting the two teams to mesh if it be, certain, daily stand-ups or whatever it is, tools that you’ve seen.
One thing I would throw out there is we do OKR is as an organization. That’s what we use quarterly to set our goals. And I think it’s really important to make sure everyone is involved in that process. Because the way I think about it as the longer you wait to. Create that collaboration, the harder it is because there’s just certain decisions that can get made very early.
When thinking about how we prioritize and what we focus on that just carry out. So I think the more that you can bring a broader group into that like the OKR conversation and say, Hey, as a team, What are the big picture objectives that we want to focus on this quarter? How do we want to tackle that?
What are the big customer problems that really matter to us and making sure that yeah, product and engineering are really a part of that? I think that’s really helped us with more of that, like alignment and collaboration.
Yeah. I was thinking of, with the the OKR is an important part. I think goals are great. Provided that we all agree, like these are the goals and we don’t have too many of them and they’re not at odds with each other. Cause I think sometimes goals can also create things going in different directions and not Not getting that shared alignment.
I think that’s one of the, we skipped over this, but I think that’s one of the most important parts of product’s job is, and Beckett feel free to correct me. I was only a product manager for a short period of time is communicating. These are the company’s objectives. This is what we’re trying to accomplish.
This is the line in the sand. If you’re, if the. The things that you think are important, aren’t above this line, they’re not going to get done and there’s nothing wrong with that. We’ve all agreed as a company. This is what our objectives are. And I think that’s one of the most important roles of product is being able to effectively communicate why something is being done or why something maybe isn’t being done.
And goals is like the best medium for being able to communicate that, like, how does this thing that you want to get done align with the goal that we saw all set at the being in the quarter, if we were going to work. So I’m curious if that sort of, because I think we skipped that in terms of one of the major roles of product was really communicating.
I would agree. And I would add to that and say two other things. One, I think an important skill for anyone in product is the ability to say no in like a. Palladian diplomatic way,
And it’s so hard. Like we’re, everybody is, we’re all people pleasers. And you, no one wants to say no, but it’s a huge part of the job. And I think, but along with that, I think an important part of it is. Frame it in the context of what the goals are like, does this really align and help us advance towards that goal and to just putting it in context?
I think it’s very easy when you’re evaluating an individual idea to be like, oh yeah, this is a good idea or not, but there’s lots of good ideas. And so you have. That’s the basics of prioritization is let’s put all the good ideas together and then see like what’s actually best. And I think sometimes a lot of people throughout the organization, whether it’s like your engineering team or stakeholders or whoever just don’t have that context on what is the whole.
Realm of things that we could do. And then think about the thing I want to do. And realistically, where does that fall? So I think that’s a big part of what product has to do is actually give that context on what else is up for consideration and therefore how high of a priority is that request reminds me of a Steve jobs.
Quote, one of my favorites of I think it’s something along the lines of looking back. I’m more proud of the things we decided not to. Then the things we did do just because it is easy, there’s lots of good ideas. And it’s really easy to let that stuff get to, get you distracted. Yeah.
Johnny, how it, how have your teams collaborated between the product engineering? Yeah, we can talk about tools and stuff, but I did want to hammer home. I think Rebecca was saying about context is super important. When you’re setting goals, right? In addition to setting really good goals, you have to agree on the things that around which you want to set goals.
So metrics are really important. What are you actually measuring right. For? You can actually create goals around those. So that’s, especially for early stage startups. It’s very easy to go down the wrong road, just measuring the wrong. And start building towards hitting goals for the wrong metrics.
And so that’s super important in terms of context and communication. We’re big on asynchronous communication and not just really slack, but like writing write long form writing and setting that context. And the reason is because I think that as leaders. We’re in context all the time. We’re constantly talking about the context and the business and the market and what are users doing and whatnot.
When you get down to, project folks and engineers, they’re not necessarily in that context all the time, they’re solving micro problems, making, tens of thousands of decisions every week. And, they lose that context. And so you have to constantly.
Reinforced this and let people know why they’re building the things that they’re building. And that’s much easier to scale if you have it written down somewhere. One of the things I learned like mid in my management career was that, when you’re trying to convey context to folks, if you don’t write it down, you’re going to find yourself saying the same thing over and over and over again.
And that context will never set in until you find yourself sick of saying it. And then you have to say it three more times and then maybe the team gets it at that point. And it’s not because you’re necessarily doing a bad job. It’s because you do the big hurrah and the status meeting.
Everybody goes out and build this. 48 hours later, they’re not even thinking about, the big speech you gave. You’re still patting yourself on the back for, starting off the week, yet you’re not even to Wednesday yet, and everyone’s forgotten about it.
And so you have to constantly be able to reinforce that context and the scalable. And so being able to write things down with the context is super important because it gives people an opportunity to digest that information and whatever way is most optimal for them, some people will get it right.
When you say it, there’ll be good to go. Some people need to go read it, reread it, think about it, sleep on it and drink some coffee, and then they’ll be like, oh, I have a really good question. And they’ll bring that one key piece of insight. That’s really good. Transform the way you make decisions moving forward, but they needed that time to really process that.
And you want to make sure have an environment where those folks, have an opportunity to contribute may bring that to the next meeting. That’s one thing we always find too, is you ever going to have a meeting, we have an agenda document, everything, the next meeting I’m like, okay let’s look back at the show notes from the last meeting, right?
So where did we last leave off? What did we say was a good idea? What wasn’t because if you don’t. Split it around. It’s gone. Yeah. Nice. Again, just be mindful of time, any specific clothing notes that we want to maybe touch on for this specific. Yeah. I’ll hop first and then give our guests a chance to think.
But I think the, one of the big takeaways for me or something I hadn’t really thought about was the idea of, not bad product managers, but rather just bad fits and, it’s I think that’s a good takeaway for me, at least and making sure, moving forward, we always try and hire the right people.
I, I inherently know that. And then, but framing it that way was definitely a. Eye-opening if you will, Tiffany moment.
Yeah, I can jump in. The big thing for me was first fill. It feels like we left a lot on the table because that’s so much to talk about. Like we really hit hard and light, maybe two or three things, to Mike’s point, having, the right fit. And the other thing that I’ve learned is that, this is not static, right?
There’s a time dimension, someone who is a right. At the very beginning, early stages, particularly engineering and that really talented full-stack engineer. Who’s not really an expert in anything, but can do a bunch of stuff is going to be like your MVP, until you get that fit.
And then bringing in more specialized folks is super important. So you may talk to that specialized person very early on. They’re super excited. About the mission. They really want to come on board, but you have to tell that person knows something because it’s just not the right time. And so that could be very difficult as well.
So that’s something really take away with people. And that’s like a very hard thing to do because you want people who are aligned with your mission and are really believe in the same things that you are in terms of, your values and whatnot. But it just may not be the right time for that person.
Yeah, I would add I think a lot of what we’ve discussed is the like soft skills that make somebody a good fit. Your level of self-awareness and things like that. The other piece of that I think is just looking for people that have. Genuine empathy for their colleagues. I think to me, that’s the most important thing between a product and engineering relationship is if a product person doesn’t really understand the challenges that come with an engineering role.
And like the biggest thing that gets me sometimes is like having a lack of appreciation for how hard it is to estimate how long it takes to do things, which is silly because you think about it. If you asked me to estimate how long it takes me to do anything, it would be wildly inaccurate. So why do we look at engineers and say this took more time than you expected. Like of course it did. And so I think it’s just like that perspective of really trying to understand what are the things that make an engineering role hard within this organization and what are the things that make a product role hard?
And I think if you can remind yourself of those things, it creates just a much closer working relationship between those two functions and just greater alignment towards, whatever bigger picture goal you’re working on. Because it, it comes from a place of understanding. I think on that alignment piece, I think that’s an important part.
And hinted at it, which is making sure there’s also alignment between what is it that we as a product development organization, like what are some of the metrics or whatever that we want to prioritize, not from a goals perspective in terms of the product itself, but how we operate. Do we prefer speed or do we prefer predictability?
Because we can be super. Back to your estimate point. Like I can give you great. I can give you very precise estimates. If I’m given enough time to do all the research, to figure out where all the gotchas are going to be, it’s basically the halting problem. And by the time I’m done and base it, by the time I’m done estimating, I basically solve the problem.
And now I can tell you that it’s going to take me, whatever. But that’s a very slow, but predictable and maybe that’s what the organization needs, but maybe sometimes it’s more about speed. I think that’s making sure there’s alignment. There is an important part between product and engineering.
Yeah. That’s well said. I think it’s unique to that. We’re getting some perspectives when they get a lot of what we’re hearing is like from an early stage perspective, I’d be really interested in a follow-up episode to get somebody who’s doing product at like series D and beyond, and see what kind of perspectives they have.
But yeah, we could talk for hours about this. Let’s put a bow on it on this, at this segment and jump into this next segment here. We call this round out my career. It’s a fun session where we have, it’s very colorful community wheel behind me. It has topics and questions that are crowd source from the Hatchpad community.
And these are topics that can range anywhere from compensation to diversity. And will be chosen randomly as the wheel spins. We do have a price section here, if we’re lucky enough that if it lands on it, that one lucky member of the community will receive a free raspberry buy. So we’ll go ahead and spend the, we’ll see if we come up with.
Communication is actually very relevant to a,
okay. So let’s see here.
I guess just, yeah, it’s general, but communicating when you’re asking for and receiving feedback, any specific tips that you have found helpful when you’re going through this form of communication with asking for and receiving feedback Johnny, when you, if you want to tell me about some of your specific examples.
Yeah. So we have a set of engineering tenants internally, and the things that like we value on the team in order to be able to work really well and effective together. And one of those things is like very candid feedback, obviously respect with everything, you obviously want to respect your colleagues, but I find not much value in like sugarcoating too much because People receive feedback very different ways.
And some people unfortunately go out of their way not to receive a critical feedback, but, and that’s very easy to avoid cognitively if you know it sugarcoat it too much. So I think being very honest with each other is probably the best way. It can be a bit uncomfortable in the beginning, but that’s only until you actually build a relationship with the person communicating that feedback.
And once that is established itself, it’s much easier to do. Okay. I think that as a team, we definitely value that. Because it allows us to move much more quickly. I don’t have to wonder what you think. You don’t have to wonder what I think we’re very like honest with each other and it allows us to move forward in a way that allows us to be much more productive.
So I’d say the indications to be like pretty candid, always respectful, that sort of thing. But that, that’s what my advice would be.
Yeah, I think candid is exactly right. The other word I would add is consistent or continual, right? I think it’s really important. There’s this old school mindset around oh, we wait for a annual performance review to give feedback and that doesn’t benefit anyone.
One thing that we have done that I think has really helped us is in our one-on-ones that we do. That’s just like a standard agenda item is this mutual feedback. So I’m giving feedback to my direct reports and they’re giving feedback to me and. I think part of what makes that great one is that you just, it doesn’t have to be a production, it’s just, Hey, this is what we do every week when we meet for our one-on-ones and it really normalizes it. And I think it, it makes folks really comfortable with the idea and making it mutual, I think is really important too. Because it can’t just always be, Hey, Your manager top down giving feedback.
I think it’s really important that flows both ways. So yeah, that’s something that we’ve done. I think that’s really helped. Cause it’s a muscle that I think people have to build. Don’t often have opportunities to do it. So yeah, that’s worked really well for us. Yeah. I totally concur with the mutual cause the fact is everybody can get better, but it can learn and enrich growing in their job in their role.
If you’re managing, you have to be able to learn from the people you manage on how to manage them better, what you’re doing with what’s working for them. I think it also, it, doesn’t just not just from the growth perspective, which is the obvious benefit to you. But also on the being able to show look, this is how one receives and provides critical feedback, makes it much easier for the other person to receive and give critical feedback.
And I think that’s a really important aspect. And I think it’s something that I always write my one-on-ones. Number of years ago, I started a very formal one-on-one and that was my first agenda item is any feedback they have for me, any feedback I have for them, I was like, Ted, let the other person go first.
I totally agree. And I think the other part to Johnny’s point of what the candid, I think one of the things that really helps with candid feedback is establishing a rapport between people. Like it’s really easy to like, not like someone or be upset with someone if you don’t really know them, but as you get to know someone, and then I think that’s an important part of that.
One-on-one. Feedback is just getting to know people and knowing Hey, generally speaking people aren’t malicious. And and so just having that basic understanding of who they are, where they’re coming from a little bit of background, what else is going on in their life? It gives you that empathy gives you more, more insight, and then it just makes it easier to have those conversations, because it’s just one of one of many conversations as opposed to, oh, now I’m going to go into the principal’s office and hear how I screwed up this week.
So I think those are all important parts. Yeah, that two-way feedback. Becky, you said you guys do a weekly one-on-ones that’s nice. Yeah, that’s a, I think when you’re that small it’s super, super effective. Like right now, I think we, we do weekly one-on-ones that are a little bit more of just casual of like task focus, and then we’ll do monthly and then we’ll have like more of like quarterly or semi-annual like bigger one-on-one.
But one thing I thought was interesting too, is yet on the candid front. I think that’s, there’s definitely value there. There’s also a value to confidential. For example, we just we finally got to a size where we’re big enough where we can do like company surveys, it’s confidential, but it’s not like you’ve got to know who is, who said it.
And so we started to do them and I think that it’s interesting. It has pros and cons because you’ve got job satisfaction or you think the vision is clearly communicated to you. How would you rate this or that? And you maybe see one, that’s just like a little bit of an outlier, but you don’t know who it’s from.
And so we were like how do we troubleshoot this? So I think we’re, we make it very clear now of, if you chose, six or below out of one through 10 are you willing to suggest, give us some suggestions or recommend some advice and then separately, there’s just an ongoing kind of like a suggestion box that you can throw at any time, if you have an idea or if you think something could be done better.
And I’m very clear too. Whenever we do all hands, we do a monthly all hands. Just being vulnerable and I, this is my first time to like leading a team of this size or growing a company to this point. This is all still unchartered territory. And so I will take any feedback you’ve got I’m not going to put a shield up and say no, I think you’re wrong.
I do it the right way. So I try to make myself vulnerable. And they seem to, my team tends to relate to that of he’s put his guard down. Like he’s not pretending like he does know everything. I think it’s really important. Like I think everything that we’ve described.
Involves creating a safe place, creating a safe place for that feedback. And it sounds simple, right? But it’s more than just oh, Hey, you won’t get fired for saying critical things. Like it’s going beyond that and really encouraging it and making sure that people feel like that’s what the organization wants and that’s what will make us all better.
But it’s easier said than done. Yeah, again, thanks for hanging out with this Johnny, Becca, I think your perspective has been super helpful on this whole product meets engineering concept. I’m sure we’ll have many followups to come. But just for the listeners out there, is there anywhere specific that our audience can find you on social?
Johnny? I’ll start with. Yeah, you can always find me on Twitter at recursive funk. That’s funk with the K or my websites, recursive funk. That IO. Cool. I am just on LinkedIn, Rebecca Moran on LinkedIn. The smart way.
Thanks again for hanging out with this guys. So thank you. Thank you.
