Episode 183: Building a Team Culture of Ownership and Collaboration with Todd Wilkens
I recently had the privilege of chatting with Todd Wilkens, Chief Product Officer at Qualio and a seasoned expert in product development and scaling teams for success. Todd brings a wealth of experience from his tenure at IBM, where he spearheaded transformative projects that reshaped how teams collaborate and innovate in the digital age.
Throughout our engaging discussion on the Product Thinking podcast, Todd delved into the intricacies of building customer-centric solutions and breaking down organizational silos. His insights into the role of agility and strategic alignment in driving continuous innovation were particularly enlightening.
Read on as I share more of Todd's invaluable advice and strategies for navigating the evolving landscape of product development and innovation.
You’ll hear us talk about:
04:34 - Designers Stepping into Product Management Roles
Todd discusses the potential for UX designers to step into product management roles, drawing on his past experience. At Atlassian, the product management culture was less developed than engineering and design, allowing designers to naturally fill gaps in product management. Although designers did not officially take on product management roles, they often assumed similar responsibilities, leveraging their strong design and user research skills. This overlap allowed for a seamless integration of user experience into product decisions, enhancing overall product quality. In later roles, particularly at Automatic, Todd formally took on product management responsibilities, gaining firsthand experience and credibility to coach others in similar transitions.
13:33 - Implementing Shared Goals and Celebrating Outcomes
Todd describes how he implemented shared goals at Qualio to foster a collaborative and outcome-focused culture. When he joined, the engineering team felt burdened by the lack of support from product management and design. By rebuilding these teams with well-rounded individuals and clarifying their roles, Todd helped shift the focus towards customer impact. He encouraged the team to celebrate achievements that improved customer or colleague experiences, moving away from metrics like commits or bug counts.
36:58 - Scaling Culture Through Shared Competencies and Trust
Todd highlights the challenges and strategies of scaling a company's culture while maintaining collaboration and efficiency. He argues that as companies grow, they often encounter issues with siloing and disciplinary boundaries. To combat this, Todd emphasizes the importance of building a culture based on trust, empowerment, and a shared set of goals. By establishing clear, shared competencies across product, design, and engineering teams, he ensures that everyone is aligned and working towards the same objectives. He introduces a skills matrix and role definition framework that he has developed and refined over several companies. This framework includes shared competencies such as user science and understanding, strategic thinking, and collaboration, with specific competencies tailored to each discipline's craft.
Episode Resources:
Other Resources:
Follow/Subscribe Now:
Intro - 00:00:01: Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking podcast. Here's your host, Melissa Perri.
Melissa - 00:00:37: Hello, and welcome to another episode of the Product Thinking podcast. Today, we're diving into a topic that I've been thinking about a lot lately. It's breaking down silos in organizations. I'm joined by Todd Wilkens, who's a Chief Product Officer at Qualio. Todd has extensive expertise in product design, UX, and engineering. He's worked in all sizes of companies, starting at IBM and then moving to Atlassian and Automattic before becoming CPTO of Qualio. He has successfully led companies through significant growth phases, including three consecutive companies that saw over 100% year-over-year revenue growth, reaching valuations over $5 billion. Todd is going to share his lessons learned along the way with us about building high-performing teams. But before we talk to Todd, it's time for Dear Melissa. This is a segment of the show where you can ask me any of your burning product management questions. Go to dearmelissa.com and let me know what's on your mind. Here's our question for today.
Dear Melissa, long-time listener, first-time caller. I'm curious if you have any guidance or suggestions or recommendations for someone like me who's interested in transitioning out of product management. In particular, I wonder if I can use my skills in something a bit less cutthroat. I'm thinking about a job on university staff.
Okay, Maurice, you have an amazing product profile, and I'm really sad to hear that you're transitioning out, but I get it. It's funny. After I trained a lot of people in product management, they decide like, hey, hey, it's not what I signed up for. This is not really what I want. And you'd be surprised. Like, we do a lot of really large-scale trainings. But I've seen that you've been in this for quite a while. You've been in here for over 10 years. You're a mid-level manager at this point. So I'm sad to hear that you've had really negative experiences. I'm finding a lot in product management that people are holding product managers accountable for the success of the entire company. And they don't hold the other team members to the same way. Leaders are looking for like, one third to choke, which I think is awful. That's not how it should be with product management. The whole team should be responsible for the outcomes of the product and for the outcomes of our customers and our business. And of course, we do make a lot of critical decisions as product managers. And I do think you should be holding your leaders accountable for the outcomes of the business. But in many places, it's extremely cutthroat. And what we are looking for in the responsibility for just the product manager really should be shared by the whole team. So I'm sorry that you're experiencing this pressure and I'm hearing it a lot. Like a lot of the conferences I'm going to, people are talking more about mental health and product managers and why we're putting this kind of burden on them. So I don't love that. I do see a lot of people today moving from leadership roles back down to IC. This is a trend that I'm noticing. So I've seen a lot of product leaders go, you know what?
I'm really great at just like working with the developers and the designers, and I don't want the burden and the responsibility of being a leader over all this stuff and all these people. I'm just going to go back to IC. And you can get paid really well if you're an IC in a large organization like Facebook or any of those big companies, right? They don't pay small amounts. So I saw a lot of people doing that. That might be one option. But let's think about your skill set in product management and how you can apply it to other places. First of all, if you're thinking about university staff and staying within tech, still trying to go adjacent to product management. You might be looking at on university staff at teaching role. So what's your experience with teaching? That's what I would look at. Are you good at taking frameworks and putting them into language that people can understand and breaking it down and teaching people who are new to product about that? I will say in universities, it's extremely bureaucratic. A lot of times it's very hard to make a living unless you have a PhD and you're on the professor track. I was lucky because HBS isn't like that. It's a great place that actually hires a bunch of practitioners and it pays them well. But I have a lot of friends who are adjunct professors making like $3,000 a year for a lot of full-time work. Let's say they're not working 10 hours a week. They're not working five hours a week for those universities. They're working a lot more. So think about if you want to do a teaching thing in a university, just expect that. If you need the money or you're supporting people, that might not be a great route for you, depending on where you go. I'm sure there's universities out there like HBS who treat people well, but I have not heard of a lot of them. Let's put it that way.
So know that that's the route you're getting into if you do go the university route and you want to teach. To me, it's been great. I've seen people really like it when it's a part-time job that they do adjacent to other things. Now, if you want to stay within tech, you can look at adjacent roles. Like, are you good at design? Are you good at engineering? Can you move into UX design? Could you do user research? Could you do engineering? Could you do sales? Anything like that. That might be a path where you can definitely leverage your skills as a product manager if you've dabbled in anything like that. Another option is to look into consulting. You might not even have to go out in consulting on your own. A lot of people will do that like I did. You can go out and consult on your own. You can work part-time for companies. Sometimes the burden or the responsibility there is not as great because you're coming in and helping with the project. And other times too, though, if they don't see the results, there's no way to get around that. Like, you have to have results if you want to continue and succeed as a consultant. So there's that part, but you have a little more control over who you work for and what you do. So you can say no to projects that you don't want to do or you won't be successful in. So there's an option there. You can also consult for bigger consulting companies. So maybe you go into an agency or a software dump shop and you help people with that. Again, shorter-term projects, you don't stay with the same people all the time. When it comes to working with those companies, you get to switch it up. That might be a little bit of a breath of fresh air. I don't know how less cut through, some of these things are, but it might be enough to shake it up for you where you feel like you are still learning. You still get to do the fun things.
You still apply your product management skills, but it might not be the same as what you're experiencing now. If you do want out of tech, I've seen a lot of people go on to leverage the skills in product management, problem solving, communication, growing things from a metrics perspective to things like nonprofits or other areas. Remember, a product doesn't have to be a software product. You can grow a services business. You can grow a nonprofit services. You can think about productizing those things. A lot of times people do that to help those systems scale and help them reach a lot more people and reach their goals and provide some more standardization to it. So I think you can actually leverage a lot of those skills and maybe just don't apply it to software. Maybe apply it to something else. Anything that really helps solve a problem for customers repeatedly, is a product. Remember, it doesn't have to be a software product. You can productize services. You can productize a lot of different things. Maybe that's what you do. You go out and you help somebody actually productize something. I hope that helps. And I'm sorry that you're going through all of these things, but I really wish you the best of luck, whatever you decide to do. Now, let's talk to Todd. Are you eager to dive into the world of angel investing? I was too, but I wasn't sure how to get started. I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side. This is why I joined Hustle Fund's Angel Squad. They don't just bring you opportunities to invest in early stage companies, they provide an entire education on how professional investors think about which companies to fund. Product leaders make fantastic angel investors. And if you're interested in joining me at Angel Squad, you can learn more at hustlefund.vc/mp. Find the link in our show notes. Welcome, Todd. It's great to have you on the podcast.
Todd - 00:08:04: Thanks. Good to be here.
Melissa - 00:08:05: So you've worked at quite a few companies, a lot of large companies, some very rapid growth stage companies, and now you are at Qualio heading up their product and engineering teams. Can you tell us a little bit about your career journey and what led you to Qualio today?
Todd - 00:08:20: So I get interested in lots of things. And so I've always been a bit of a generalist. Got a computer science degree, but then very quickly started doing a lot of design, user experience, that sort of thing. And then I spent a little bit of time as a sociologist because I was interested in understanding people. But I tell you all this because when I kind of got serious about working in product development, I kind of started moving my way from design into product, but I was always kind of straddling both. And I started at big companies. So like I was at IBM for a while, and then I went to Atlassian just before the IPO. And then I've kind of been going to companies that are just like a little bit smaller, a little bit earlier stage, trying to apply the things I learned about bigger companies. I'm really interested in scale. I'm really interested in how you get teams and working really well together at scale. And so like I studied, IBM was like 400 something thousand people when I was there. And now I'm at a company that's like 115 people. And I've been all in between.
Melissa - 00:09:15: From that first company, you know, from IBM, where did you go after that? And what did you take with you and apply it to a smaller company there?
Todd - 00:09:21: I went directly from IBM to Atlassian. I was a VP of design for them over a bunch of the communications stuff. So that was HipChat slash Stride at the time, as well as I was all their mobile apps. And then I was working on a bunch of their like global UX strategy stuff. I joined a month and a half before the IPO. And part of the reason they hired me and some other people like me was because they were kind of trying to scale up and be ready to be a public company. One of the things about IBM I really love is that they've always just hired like the smartest people and then they kind of let them go. And so sometimes that works really well and they move really fast and sometimes that they move really slow. But they always have these incredibly smart people who are really kind of following their muse, following their best intuition. I saw that as a real advantage and I saw that work when I got to Atlassian. Atlassian's full of a bunch of people who just ship stuff like nobody's business, like they just roll out stuff. And they also had a lot of autonomy. But what I did is I started hiring people. I was hiring people who were less about like production UX and more about design research and more about sort of strategic design. Because I wanted to kind of recreate a little bit of that, bring the really smart people in and have them have a lot of autonomy.
And that I really saw from IBM that I liked. And then the other thing I learned a lot from IBM is that putting the designers in charge of things can really go well if they're ready for it, if that makes sense. Like I used to have this conversation with people at IBM. the designers would, they'd complain about the product managers and they'd say, I really wish the product manager would just do this. They're not listening to me about this and da da da da da. And I would say, well, you know, like there's no product management degree. You could go be a product manager. You basically have all the skills. And I was like, but you also then have to be responsible for all the outcomes. And like 50% of the designers are like, I'll go try that. And then 50% are like, no, thank you. I'll stop complaining. And that was something else I saw at Atlassian. I went there because they had a great head of design, Jürgen, who ended up being their chief experience officer for a long time. And he had really tried to put the designers in charge of a lot of things. And when they stepped in, they really did a great job. Like they just kept the user experience at the center. So I learned that at IBM, which is not something most people would think is true at IBM, but it was really great there. And I kind of followed that and kept doing that at Atlassian.
Melissa - 00:11:33: I think this is a hot topic right now too, because there's so many UX designers and user researchers too who are out there and they were affected by the layoffs. So we're product managers. But one of the most frequent things that I hear when I go into companies, especially when we're trying to help with product management, is the designer is going, I know how to do the product manager's job better than some of these product managers. What do I do here? Why is this fair? And I see a lot of frustration from the UX designers because they want to do their jobs, but the product managers aren't doing the jobs that they need to unblock them and get them going. So when you talk about putting the UX designers in charge, how did you do that? And what did that actually look like?
Todd - 00:12:11: At Atlassian, when I was there, in a really strong engineering culture, and then Juergen and the team had built a really strong UX design or product design culture, and the product management culture there was a little bit less developed. So it was relatively easy for the designers if they had some good background and they were stepping into the breach, right? There were some good product managers, but it just wasn't as well developed. So there, it was sort of easy. As long as you've hired the right people and told them what they needed to help fill in the gaps, they would do it. I didn't have any of the designers that I worked with there really officially stepped into a product management role. Whereas I did have that happen at IBM to the point where some of those people like actually they're still really great product managers. Like I check into them now. They never went back to deny. But in my later companies that I went to, it was much more of an official people actually did it. And I'll be honest, I think it's also because at IBM for me, for a lot of the time I was there, it was all talk. It wasn't like I didn't do it right. Like I was like, you can go do this.
But I was still like design principal. So I hadn't done that work. I was just telling people they should do it. And it was sort of true at Atlassian too. But my next job that I went to at Automattic, I sort of became the CEO of the company. Automattic had acquired a company and the founders were exiting and I took over that P&L, which means I had to run everything and I had to really be responsible for everything. And it was when I did that and made my mistakes and learned lots of things from it is when I could give really good advice to people. Like it's not just theoretically you can be a product manager, but it's like, here's what it's really like. If you want to take on the real responsibility of the P&L or the product. And I started having more success. People were more likely to be like, oh, yeah, I'll give that a shot. Or they would see something I did and they would be like, you sound like a designer, but you're not. You're doing these other things instead. And I'd be like, well, yeah, you can do that, too. And so if they didn't do with me, I would like I was coaching a lot of people in other companies to try to make that jump.
Melissa - 00:14:01: That's really interesting. It makes me think of this topic that a lot of people are talking about. And do we need product managers on teams? Or can it be UX designers and engineers, and product managers are like higher level? They might sit across multiple scrum teams or something like that. And I've had people ask me this, and I think this question is going around a lot. Like for me, when I think about it, I tell people this, when I started as a product manager, I was a hybrid product manager and UX designer, and I didn't know they were two different things. And back in the 2000s, we didn't really treat them as two different things in New York City, at least, which was weird. Some people were pure product, but I did it all. And then one day, they just decided to split my role. And they were like, we're going to hire a real UX designer. And I was like, what do you mean? Like, I do both those things. That's my job. Like, what's this talking about? And then I started to see how they were splitting. But I had a bunch of friends who were also in similar spots. We'd call them product designers. But now I feel like product designers has lean very much more towards like a UX design term, design pure term, rather than a hybrid product manager and designer. And now I feel like those conversations are coming back about like, is this a one person can do this role? Do we have to split this role? What have you observed in the different companies? How do you feel about that?
Todd - 00:15:15: And it's a really good observation. So, I mean, I have an idiosyncratic perspective because like I've done a lot of all these things. Like I was a front-end developer for a little while. I was a UX designer. I led design and I led a business line. I've now been running engineering teams a bit while I ran product. Like I've done a lot of these different things. So I don't really have an allegiance to a particular discipline. I like to get good stuff built. And so you can see the skill sets that come out of these disciplines. But at a certain point, especially with a small to medium-sized company, like something that's more like growth stage, like if you're less than 500, maybe even less than a thousand people, there's a ton of overlap. Like, it really doesn't make sense to have a super strong distinction between a lot of these disciplines because they're mostly working in small, whatever you call them, pods or squads of eight or 10 people, right? And you really need them to have co-ownership because they bring different skills to the table, both for the discipline and because of who they are personally. So I don't put a lot of emphasis on disciplinary boundaries because I find sometimes it's counterproductive. So specifically to your point, of the three in a box, you know, you have engineering, product management, design. Product management and design tend to overlap more. So it's easier to imagine having one person do both of those jobs. But what I've experienced is that when that works out well, the only way it works out well is actually if one of your engineering leads also has a certain kind of product-y mindset and experience to fill in gaps. Because you can't really have one person do all the research, all the design thinking, all of the strategic work, it's really hard to do that unless the product you're working on is really small or really early stage.
I mean, there are people, there are unicorns that can do this, but like it's not a scalable thing. You can't hire 20 of those people. So I find it at some point you do team the three in the box, but how they overlap with each other, I tend to be very flexible around. It depends a lot on the people. And also I give the team a responsibility and then I'm like, y'all can figure out who does which part of this responsibility. Just when we get to the end, the stuff needs to be done. And I found that teams work pretty well that way if they're a good team. If they're a good team, team culture and trust, people fill in the gaps. The only time you're going to do a problem is when people don't have good teamwork and trust. And people want to argue about what they get to own or what someone else is responsible for, but I'm not responsible for. You've lost already once your team's talking that way. It has nothing to do with what the roles are or whatever, right? So I guess I'd say that that's true in my experience. I've worked really, really hard to break down disciplinary boundaries in all the teams that I've been responsible for building and managing.
And I would say at this point where I'm at at Qualio, it's the best example of a discipline-less team. We're super cross-disciplinary and it's so beautiful, like so little friction. We move so quickly. All of our time is about understanding customers and understanding how we do something instead of negotiating or fighting or being unclear with each other about who does what. So we get a ton done with a relatively small team because of that. And it's really hard to do. But after a while, you're like, oh, wait a second, I survived that. It was really hard. But I'm still here. And it chills you out a lot about it. And so I think that I've been beat up on enough that I'm now like, whatever, am I going to get fired? Okay, well, I took a risk. Actually, my last great quote, if I can name drop somebody who I really loved working with, John Maeda, he's a designer. Most people don't know him. He said this great thing to me one time. He's like, Todd, if you don't get fired once or twice in your career, you're really not doing it right. At first, I was like, oh, that's a terrible idea. And then the more I thought about it, I was like, maybe you're actually right. And so I've been fired because I messed something up. But I learned a lot of things. And I'm not paralyzed by the fear of it, which is, I think, one of the most important things.
Melissa - 00:18:49: And it's about learning from it too, right? And I think that's what you've taken in your career. And we just had Amy Edmondson on the podcast talking about like the right way to fail. And it's all about learning, right? Like if you fail and you don't learn, then that wasn't worth it. But if you failed and you learned and you went somewhere else, that's worth it.
Todd - 00:19:06: I don't know that I failed the right way, but I definitely learned a lot of things. Failing is never pretty. It's easy to look back at and be like, that was, I meant that. That was good. I learned from it. But like in the middle of it, it's like, this is terrible.
Melissa - 00:19:16: Oh, exactly. Yeah. I was posting something on about that mentality too, like on LinkedIn. And I said, like, I've treated every single interaction in my career and anything that I've done as like an opportunity to learn. And if I've gone out and try to like present something to, anytime I've gotten an opportunity to do something, I was like, yeah, I've never done that before. Like, let me do it. So I'll try it. And then if it doesn't land the way that I want to, I'm like, okay, how do I treat the next interaction or the next thing that I have? Even if it's like pitching something to a CEO or like an executive or somebody and you're like, how do I put this in a way where they're going to be like, oh yeah, that, right? Like convince them onto my side or get what I need from them. And I feel like a lot of people don't approach even just like conversations or interactions like that in a way where you go, hey, this is all like an experiment. And if it doesn't work this time, I will figure out what to do next time. Let me poke. Let me try. Let me see this. Let me refine my approach and not just think that the one way is the right way.
Todd - 00:20:12: That is completely right.
Melissa - 00:20:13: So I hope a lot of the UX designers out there who are listening to this and want to be product managers don't get scared of the responsibility.
Todd - 00:20:19: Totally, totally worth it. Like you'll grow as a human so well from taking risks like these and getting to the shared responsibility. And it's so good, especially after you get through the part because there's going to be some pretty parts. Right. But it's so good afterwards.
Melissa - 00:20:33: So how do you as a leader, right? You're the CPTO, you're on cross of engineering, product design, everything, right? How are you helping to structure those teams and develop the people for those roles? Like, what does it mean to be flexible when it comes to the disciplines there?
Todd - 00:20:51: With Qualio, I'm lucky, I'm lucky because I inherited a team that was already a little less discipline focused. So I had some good material to work with in the culture. I mean, the best thing to do is to talk in concrete terms, not in abstract. So I'll kind of just tell a little story about what actually happened at Qualio. So when I joined Qualio, I would say, in all fairness, we did not have a very robust designer or product management team. Not that we didn't have good individual folks on those teams, but the way they were working together to get things accomplished was not as mature as I think it should have been. And so what that ended up meaning is the engineering team was always feeling like they didn't have what they needed and were having to step into the breach and do things. The engineering team, they had a sort of period of focus on things like engineering outputs, commits, and numbers of bugs, and how long does it take you to respond to an issue and that sort of thing, which is like good engineering practice. But they want, no one ever talked about what our customers needed. And so when I showed up, what I realized was that the engineering team felt a lot of responsibility. Like they'd actually almost been spending as much time talking to customers as any of the product managers and designers had, mostly because that product management design wasn't very strong yet. So what I did was worked on rebuilding the design and product management team a bit with some people who were a little more well-rounded. And then I helped them feel like they knew what their role and responsibility was. And then a lot of it was just telling the engineering team. And I actually had this conversation with them. And it was funny how well it actually went.
We had a big kind of all hands conversation and I was like, I don't care how many commits you make. I don't actually care how many bugs you like. Our bugs are pretty low. Like our bug counts pretty low. I don't care. It's like all I care about is if you ship a thing and one of your colleagues or one of our customers is using it and there's some sense that it improved their life. I don't want to hear. I don't care. I don't care about anything else. And they kind of looked at me like, what? And I was like, you shouldn't care about anything else. That's the truth. And then all I did is I just started celebrating anytime anybody did something that helped an internal staff member do something better or that helped a customer do something better. And then all of a sudden they all started celebrating each other's doing that. And then we started getting more quantitative and objective about, well, how are we choosing what we're going to build? And did it actually accomplish the thing we thought it was going to accomplish for a customer or a colleague? That just made a huge difference. There's that. And then something actually I learned from IBM that I've continued using for years now is at IBM, we had this practice we call a playback. It's kind of like a demo, but we used it more general. So it's like, it's not just a, you don't just demonstrate code. You play back all sorts of things. You play back research. You play back code, you reach playback. It's just the idea of sharing out a thing. But one of the things I loved that we came up with was this phrase, we want to have a culture of showing, not telling. And that has been such a foundational thing for me. And so when I came here, I've done this everywhere, but here, what I did was I was like, show the thing you did and show the effect that it had.
And it was amazing because people stopped talking about their JIRA burndown and they started talking about this cool thing that they built and what it did for people. And it was that sort of thing that really made one of the biggest differences there. And then I just said, you're all responsible. Engineering is not responsible. Product management is not responsible. Design is not responsible. You're all responsible. It was always team celebration. That helped a lot.
Melissa - 00:23:56: When you are looking at your teams too, do you give them team-level goals? Because this has been a big thing I've heard from product managers in many companies, all different sizes, is that the product managers get to be the one to choke because they're responsible for the outcomes. And then I've seen engineers and designers kind of point fingers at the product manager and go, well, they get to make the final decision, so I shouldn't be responsible for the outcome. How do you get away from that friction? What are you doing specifically to prevent that?
Todd - 00:24:25: So we have shared goals. Our organizational structure is not, there's nothing innovative about it, right? We've got, my team is about 40 people across everything and about seven of those are design and product management. The rest are engineers. So your ratio is roughly what you'd expect and everything. It's broken into two big pods and the pods are focused on two different parts of our product. And within each pod, there's three engineering teams and there's some product managers and the diners on each pod, right? It's very common structure. And we just set our goals essentially by, kind of set it across all of our product development team, but really by the pods. And all of the product planning and goals are set based on data we have around, close loss and product usage and that sort of thing. It spells a ton of feedback from our current customers. And basically all I ever tell everybody is like, I mean, I help with this, but this quarter was actually one of the best ones ever. I didn't have to do hardly anything, which was, I was like, we have all the information about what's important to our customers and to our business. You tell me what you think we should focus on, but you don't get to tell me because you feel like it's important and you don't get to tell me oh, well, we've already been thinking about this. We have a lot of inertia, so we're going to keep doing it. I was like, tell me what you want to do and tell me how it's going to have the biggest impact based on the data that we've got. It's messy data. It's not perfect, but it's accurate. It's truthy. It's not the most, there's enough truth there. So they come back and they say, this is what we want to sign up for. And I'm like, okay, let's tweak that a little bit. Let's make sure that we frame it this way.
Or I want to challenge you to push that a little bit farther, but they sign up for the goal and we frame our goals as initiatives. We've done ours too, but it's essentially the same thing. Like here's the outcome we're going for. Here's how we're going to measure the success of it. Here's our timeline for it. And the teams, they take ownership of that themselves. And then I always say the team owns this. You know who your designer is. You know who your product manager is. You know who the engineering team lead is. You know those people have an outsized set of responsibility and a bit of authority because of their role, but the team owns it. And in most cases, when they focus on objective things, like here's the data, here's the user research, here's the whatever, you reach alignment really quickly, right? And so it's few and far between when someone has to come in and like break a tie. And I do really say like, if worse comes to worse and someone just has to make a call, product manager makes a call. At this point, that's like 10%, 5% of cases. In most cases, they have plenty of information to make a decision that is easy to align to.
Melissa - 00:26:43: It's nice to hear you say that because I see people get into these debates if you tell them to go make shared goals where they're like, well, what happens when this happens? And you're like, well, that happens 5% of the time. So do we really have to worry about that right now? Like what you're talking about? But that's been my experience too is you give people shared goals, you're all aligned and you're going to do what's in the best interest of the goal, not necessarily like what somebody's ego is dictating. And I've seen it rarely where product managers have to make the call either unless somebody's going rogue, where like somebody's going crazy, which doesn't happen if you all have aligned goals.
Todd - 00:27:14: We have a fairly low ego culture is part of it. And then I'll admit, like, I think if there's a strength I have as a leader, it's that I really love design and product management engineering. I actually love all three of them. I know just enough to be dangerous in all three of them. I'm not an expert in any of them. I haven't really done design for a long time, so I've lost a lot of my skill there. But I genuinely love them. I am genuinely interested in them. And one of the best things to do to combat ego and fighting is to actually just have a very fun, creative, authentically interesting culture. Right. And so, like, I cheerlead a lot authentically. And I think that that really helps the team in general. Right? Because I've noticed other people picking up a sort of like cheerleading attitude as opposed to a I'm really good at this thing and I'm going to show you how good I am at it or. Responsible for this and you're responsible for that. Like those work in some cultures, but like, it's not a culture I really particularly like. And so we have a much more, we have a very supportive, very cheerleading sort of culture. Right. And I think that helps a lot.
Melissa - 00:28:14: What are you doing to help cheerlead?
Todd - 00:28:16: I give a lot of positive reinforcement. Like I call out people by name all the time about things. Like we use Slack a lot, so I'm in there a lot. And like, I'm an emoji and Giphy person, which is much more than like, that was great. I try to celebrate people in a kind of fun way a lot. So I do that. I'm just all over the place doing that a lot. I call people out by name in whatever situation I ever can. That helps quite a lot. I'll be honest with you. I also spend a lot of time telling people how we are actually different than other places I've worked and why that's special. And it is true. It's not, I'm not making it up. But reflecting that back has been really great, right? So like my best example, I use this whenever I'm hiring somebody, when I try to tell them, like, hey, we have a really cross-functional team. Like the culture is super cross-functional. We pay much more attention to our pods than we do to our disciplines. And I was like, yeah. And I was like, well, I'll give you an example, which if you really think about it is kind of crazy, which is we don't have an engineering Slack channel. There's no Slack channel associated just with engineering. All engineering discussions happen in the cross-functional channels with the product managers and the designers, which is kind of unheard of in a lot of ways when you think about a technology company. But it really means something to me. It shows how committed we are. And I've mentioned this a few times. And like the engineers are all like, they're like, damn right. They don't even want one, right? They're like, we don't want to be that way. And that helps a lot because they buy in to what's really great about what we're doing. So, yeah. And then I cheerlead, I champion. I move things around a lot. I'm a bit of a systems thinker. So I try to make sure that we have incentives set up properly, but I keep the structure fairly low. So people have a lot of autonomy. That helps a lot too. People feel they can control their own destiny. And that helps a lot.
Melissa - 00:29:47: Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations. I think that sounds like a really nice culture. In a lot of companies, what I observe is when they're small, we have that tight-knit culture that you're describing. And then as we start to scale, we start to get very siloed, not even in just engineering or product, but like sales and marketing too. There's so many companies I work with that are hyper growth and sales and marketing like don't even talk to product. And that's the first thing you got to fix, right? Is like, how do you build that bridge between them? And how do you make sure everybody comes together? What are you doing as a leader? And what are you taking from these large companies that you've observed, right? And these smaller companies, growth stage companies into Qualio to make sure that those types of things don't happen either.
Todd - 00:30:56: It's a really good question because I hadn't thought about it the way you just asked it before. Two things I think have come out of my particular career journey that are totally applicable for other people but have given me the opportunity to see. So something really interesting in my experience at IBM, IBM is incredibly big, right? They've got very, very clear hierarchies and groups and so many levels of seniority and responsibility, right? So most people think of them as very bureaucratic. And they are in a lot of ways because they have to be at that size. But what's interesting is it's like my experience of IBM was that they were almost so big that the disciplinary boundaries didn't matter. So like I interacted with a ton of people from IBM marketing, which was such a disparate place from where I was in design and product development. And I never experienced a sort of like, well, we're marketing, we own this and your product development, you own this kind of culture. It was much more like. I am really good at this thing. And this is what I think about all day long. And you're really good at that thing. And that's what you think about all day long. And I would really like to figure out how what I'm really good at and you're really good at can work well together. And it's because there's just there's so many people. There's like thousands of people in marketing and thousands of people in product development. So it's like trying to have a kind of like senior, like who's more senior, who has more responsibility, authority kind of like argument almost doesn't make sense for a lot of people. And so I can see a culture that's scaled quite large about where people just like, what are you smart at? What am I smart at?
How do we get the smart thing done? And then the other thing that I think I learned, it's an advantage and disadvantage of my like dilettante generalist approach is like I did engineering. I did design. I ran a whole company where I had marketing and sales and finance and engineering and product and design all reporting to me. And I had to work with all these people. They all worked for me. And so I had to learn really quickly not to play sides, like not to, I wasn't on anybody's team. I was on everybody's team. And I saw how good that worked. I saw how well it worked for that. And so I was trying to build the culture of that there mostly just because I needed it. And then since then, that's what I've been doing is like the best companies I've worked at are places where I can try to help people say, you know, like it's always about what's our end goal and how do we talk about what we need to do to get there and how do we evaluate if we're getting there well and have it not in any way be about someone's personal skill set or personal discipline or personal perspective. And so that's what I like. I'm kind of doing that now. There are some companies that are very marketing and sales driven. And that's a very that's a completely reasonable, valid, successful approach to having business. There are some businesses that are very product or service driven. And that's the kind that I tend to work at. But it's not the only way. And they're successful at doing things there. If you're a product driven company, as in like you exist with a hypothesis about a thing you're going to build and bring out into the world and that it's going to have an impact. And all you really want to do is figure out how to let people know about it and convince them to start working with you.
The product development vision and the team behind that has to be deeply, deeply involved in driving what marketing and sales are doing. And since I tend to work at those companies and I also was kind of running sales and marketing at a place, I found that I can help say that. I was like, I know what sales wants to accomplish. I know what marketing wants to accomplish. We all want to accomplish the same things. Let's start using the same language. And that way, then there's not an argument anymore. Like we can have disagreements about what the best way to do it is. But that's fine. Let's try one and see how it works. But it's not personal at that point. It's not disciplinary. So I think that's the thing that works really well. My last example I'll give you is like one of the things I think was most successful when I came to Qualio and there was all these different disparate things going on and people weren't speaking well to each other. They didn't have good silos was I just told product development. I was like, all I want you to care about is ARR growth and retention. Because if what we're building in our product isn't bringing in new customers or keeping current customers, we're not doing the right thing. Yeah, there's a lot of sub metrics and goals and proxies for understanding adoption and engagement and all that sort of stuff. But all those things are only really proxies. Like when the rubber hits the road, your business only is succeeding if you're growing ARR, if you're retaining customers. But the nice thing is those are exactly the things sales and marketing care about. It's exactly the things that customer success care about. So the minute I got us thinking about that, all of a sudden we're speaking the same language to everybody. And it's just been building more and more collaboration there. And the product development team is now like literally this week.
We just kind of started our quarter and the product development team came in and was like, here's what we're working on this quarter at a high level. We haven't built the things yet, but here's what we're trying to do. And here's the impact we hope it'll make. You have questions, you have concerns. Great. In a month, we're going to come back and show you what we've got in alpha and beta. And we're going to get your feedback. We're going to show you how it's starting to come to life. And at the end of the quarter, we're going to be like, here's what we built and here's what we're going to launch. But you've been hearing the story of it the whole time. And you know the goal of it is all about these things you already care about. ARR and retention or whatever. And you had all these opportunities to step in. So that's products driving the message for marketing and products driving the playbook for sales in a lot of ways. But not in a way like we're stepping in and bigfooting it. People are like, thank you for showing up and telling us what you're doing. And I agree with that. Or I'm excited about that and I can think about it for a couple months so I can come up with ideas about what I'm going to do with it. That's been working out really well too for us.
Melissa - 00:35:49: I think it's so funny when product managers get mad at sales for coming to them and saying like, hey, we need this feature to close this sale. Because you're like, don't you realize that they're telling you this is the thing that's going to drive ARR growth because it's going to get us these types of customers? Of course, I'm not talking about people who come over and swoop and poop on you and say, I need to close this one deal. And this is a custom feature, right? But I've talked to so many salespeople who are just sitting there so frustrated that no product people will talk to them. And the product people are like, well, they just keep coming over here and telling us what customers want. It's like, well, then maybe you should freaking listen to them. Isn't that the point? Aren't we all here to drive the same metrics at the end of the day? And I think the best companies I've worked with as well are exactly what you're describing. It's like, everybody's in it together. And sales understands that they can't sell anything unless product builds the right thing. So they're interested in making sure product builds the right thing. And product knows that sales is talking to customers every day, and they're going to be able to tell them what sells. So we have to do that. And I get from probably more junior product managers, a lot of angst about this, about the concept of sales coming over and trying to tell them what to do because they were like, oh, it's sales-led. It's not product-led. And I'm like, no, your job is to figure out, should we actually build that now or should we build it later? They're telling you, is that the right thing to build? Are they asking for the right way? You shouldn't get mad that it just came from sales.
Todd - 00:37:15: Yeah, I actually, I said this to the team. So I've been at Qualio just about a year, three months in when I started trying to get us to talk about ARR growth and stuff. I spent like a week and a half, just, I spent almost every day just digging around in our Salesforce, right? Just kind of, cause I did, I wanted to see what's going on in there. And then I had this meeting with a couple of the sales leaders and a couple of my product managers and we were talking about stuff. And what I realized was like the sales teams, they all have different cultures, but a lot of like you're on the ground AEs and stuff like that. It's very qualitative and anecdotal. What's in front of you right now? What can I remember? That sort of thing. And that can be true with customer success also. They're very deeply personal. Like each of those interactions is really important. And what I ended up doing was like, cause I was in Salesforce and I didn't talk to a single customer at all. I was just looking through all of this data about the people we close lost and that we won and all this stuff is I had this conversation and the sales would be like, here's this thing that we need cause it's really important.
And I would say, Yeah, yeah, no, I saw that here. But in fact, that's only 5% of our close loss. The 30% of our close loss is this thing. And they're like, oh, yeah, yeah, that comes up a lot too. And I was like, it does. I know, I can tell. Like, I didn't talk to anybody, but I can see it here because you all put that in Salesforce. Like, that comes up a lot. So I'm going to have the team build that, not the thing that was 5%. And they'd be like, that seems reasonable. Yeah, sure, let's do that. And it wasn't because I was smarter than them. I just like, that was the thing I had to do and I rotted in. But I told the product managers, sort of secretly, I was like, it's our job to know the sales data better than the sales team. I was like, it's our job to know that better than them. Not because we're smarter than them, but because they're out there face-to-face with people selling our stuff. And they are gaining lots of insight and mostly putting it into Salesforce. So we need to digest that. I think we're getting pretty good at that, actually.
Melissa - 00:38:54: I've never had a salesperson say, no, don't build me that thing that you just showed me can help reduce our losses by 30%. Instead, build this one that does 5%. Nobody says that. You come with data, you do the research, and that's how that works.
Todd - 00:39:09: I know it's right. And we've done it in a very friendly way. It's not like a we know this better than you. Right. But it's like, let me show you something I learned that you may not know. And they're like, oh, that jives now that I'm thinking about it. But it wasn't my initial gut feeling. And I was like, your gut feeling was also right, because that's clearly a point. That's been a really good point for us in our culture.
Melissa - 00:39:28: When you think about scaling, Qualio right now is pretty small, but you've seen all of these companies have scaled. What are you thinking about that might break or what are you worried about trying to prevent from breaking as you start scaling?
Todd - 00:39:40: Big companies, their biggest problem they run into is siloing. It really is. It's all the stuff you and I've been talking about. The discipline, they hire a bunch of people who are expert in certain things, but they don't work very well together. And then the way they try to solve the working well together thing is they get these very abstract frameworks of various things that they put into place to try to sort of force a way for people to interact with each other. Whereas you're better off establishing a really good, I'm gonna use the word culture here, but I'm gonna define it because it's such an abstract thing. I hate the people who use it wrongly. If you can develop a really good culture, then you can have less structure as the team grows and still scale well. And when I say culture, what I mean is you need a strong sense of trust and empowerment. You need a really hyper-shared set of goals and success criteria. And then you need a culture of really celebrating and supporting people. And then that will actually cover a ton of stuff. I was just talking to a person we were talking about hiring the other day, and I was like, you know, we have this structure right now in our organization where we've got a pod, it's got three dev teams. We've got another pod, it's got three dev teams. And we're relatively flat. The pods each have a senior manager, and then we've got my head of engineering, and then a head of design, and I'm actually head of product. But what we could do is we could add three or four more pods without adding really any another layer of stuff. We'd still have our head of engineering. We wouldn't have to hire another one. I wouldn't need another layer of design leadership or product management leadership because our culture really supports people having this ownership and trust with each other.
And they're not fighting across disciplinary boundaries. Now, at a certain point, we have to add some layers. But really, the minute you start adding layers is the minute you start siloing things out a lot. So will this structure scale infinitely? No. But it's really surprising scale. I have seen this work. Atlassian worked a lot like this. And when I was there, it was there from 1,600 to 2,400 employees. And they had a sort of similar structure in a lot of ways. Several of the other companies have worked this way. I think it scales quite well. It's scaling culture that's really hard. But again, I don't like to just use culture. I have to say very clearly, it's trust. It's empowerment. It's hyper-focused on shared set of goals. People have to use the same language, and they have to mean the same thing when they talk about the shared goals, and the goals have to be external. And then if you celebrate successes, people want to do good. You'll raise the quality of the work purely just by having external criteria for success and celebrating successes. People want to do really well. You can almost not have to worry about anything else.
Melissa - 00:42:05: One thing that I've been thinking of too, when you're talking about breaking down these interdisciplinary boundaries, right, between product and design and engineering and sales and marketing is hiring and scaling that. And I've seen a lot of organizations kind of misinterpret this as well for hiring a bunch of smart people and then just letting them figure it out versus like hiring for skill sets or in larger organizations without any definition of what a product manager means or UX designer. I've seen a lot of that break. How do you think about balancing like, you know, smart people, skill set, just enough role responsibility, and how do you organize that?
Todd - 00:42:44: So this is where I feel like I have an unfair advantage because I was an academic sociologist for a while. So I've thought a lot about structures and incentives and how to like do this stuff. So if there's anything that I literally have carried around with me and been building and working on, it's kind of basically like a skills matrix and role definition thing I've been building that crosses product design and engineering. I've been building it and evolving it over the course of several companies. And I literally just bring it in and I brought it in here. And I think that that helps a lot because a really clear definitions of what the roles are. Really clear definitions of what the different levels are and what's expected and how people grow in those. So that's really important to me. It helps me hire well. It helps me grow people well, people understand what their responsibilities are. That in and of itself should not be that innovative, but it's something I spent a lot of time on. Like it's not something I it's something I do in the first three months at a job. It's not something that I just wait and do later because it's nice to have. The other thing about it, though, that I think is the thing that I learned is that I always do it for product design engineering at the same time. And what I have is like, let's say I have a set of competencies. And that's the way we call them right now in my current company. I have like 12 competencies and they're things like user science and understanding or communication and collaboration or whatever. What happens is that I have 12 of those, 10 of them are shared competencies across design, product management and engineering.
And then I'll just have one thing that's like craft. I usually call it craft. And then I, in craft is where I lay out stuff that's very specific to someone's disciplinary background, product management, designer engineering. And that really, really that helps because people can start to go, oh, I actually understand that most of the competencies I'm supposed to have are things that everyone else I work with is supposed to have to some degree. And that the things that are special to me would be this craft part. And there are things that are special to me. So it does make it clear that it's not super fuzzy about what someone's real distinct roles are and responsibilities. But what you see is that over time, the description of the craft becomes less and less important because if someone becomes more and more senior product managers, engineers and designers, the more senior they get in a company, the more they should start looking alike. Because more of what they're doing is customer centric and company centric and not craft centric. And so I have a career framework that's put together to kind of really reinforce that. And I find that it makes a huge difference because I use it. I use it meticulously for hiring and for reviews and for all sorts of things.
Melissa - 00:44:58: What are some examples of the shared competencies and what would be something that's like more specific for product people?
Todd - 00:45:03: User science and understanding is a shared competency. People will implement that in different ways, but it's a shared competency. Collaboration is a shared competency. Strategic thinking, I think is the way we're calling it right now, is a shared competency. Within craft, so for product management, the thing that's really different in craft, so they're responsible for things like, I don't call it roadmapping, but it's essentially like laying out a plan for the future, right? Or disambiguating ambiguous decisions. And then I give concrete examples of them, like it's very detailed, but they're very product managing. Whereas like for design, I have things that are much more like, there's a sort of visual design craft and visual and communication design kind of craft description. And then there's like a flows and classic user experience. There's information architecture. There's that sort of thing. Planning and alignment is one that I use for them, right? Like, so if there's anybody who needs to align, like everybody can align, but the product managers, like one of their core competencies has to be like, they have to have a skillset in aligning a bunch of disparate people around something. So I call that a product management skill. Everybody does it some, but if the product manager is not doing it, you're in bad shape.
Melissa - 00:46:05: I like this too. I haven't heard of anybody starting from the perspective of like, you should have shared competencies. I found natural overlap in the competencies, right? Between UX designers and engineers and product managers when you go through their HR frameworks. But I haven't seen many companies actually start from a perspective of you guys should all actually have this. And especially the user science one. I like that because a lot of times they don't put that on engineering and the engineers go, oh, it's not my job to like talk to the users or know anything about the users. And this kind of like bakes it in.
Todd - 00:46:33: It's super self-centered to me because basically I'm one of those people that wants to do all the things. And I think that sharing things has helped me. And so I'm kind of building an organization that looks a little bit like me to some degree. But I will also say something that's been successful for me is when you start people earlier in their career, thinking about these shared competencies, it sets them up for leadership later. So I have a very good track record of people working for me and going on to become directors and VPs and whatever's of companies. I really think it's because I spent a lot of time saying, I know you come from product management, but you really need to get good at this user science or you really need to get good at this other thing that's a little bit more like engineering and vice versa. Right. I think that's what people really want out of people at higher levels and organizations. They have to be able to bridge. And that's not just as managers, right? Like I always have manager and IC tracks, like even high level ICs are more about bridging than the earlier career ICs. So that shared competency thing serves people really well as they grow in their careers.
Melissa - 00:47:27: I have seen it where I think the most successful companies I've seen, they share a lot of goals. They share a lot of competencies. Everybody's in it together. And I think that's a really big hallmark of great leadership in companies. So I'm on the same page as you when I hear all this. And I learned something, too. I'm going to totally go use that. Share your competencies between your engineers, your product managers, and UX designers.
Todd - 00:47:47: I don't have a place where I've shared it, but it's not a secret. So like I'm happy to put together a version of this and share it to people somehow if people want to get it. I just, no one's ever asked me about it. I've always thought about giving a talk at a conference or something like that.
Melissa - 00:47:57: Yeah, and if you want to put something together, we can link to it in our show notes too, so people can go and see what you've been doing with this. That would be great. Well, thank you so much, Todd, for being on the podcast today. If people want to learn more about you, where can they go?
Todd - 00:48:09: LinkedIn is probably the easiest place to find me and get a hold of me. There is actually a toddwilkens.com, but I usually, I kind of use that more for like doing some like coaching and consulting on the side. But either one of those is a good place. I respond really well to the emails or for LinkedIn.
Melissa - 00:48:22: Great. We will put all of those links in our show notes at productthinkingpodcast.com so that you can get in touch with Todd and follow him and read more about his style of leadership, which I think is fantastic. Thank you so much for listening to the Product Thinking podcast. We'll be back next Wednesday with another guest. In the meantime, if you have any product management questions for me, please go to dearmelissa.com and let me know what they are. We answer them every single episode. If you liked this episode, don't forget to like it and subscribe so that you never miss another one. We'll see you next time.