The Product Momentum team continues the series of conversations that we recorded at INDUSTRY Global; in today’s episode, Bukky Adebayo and Rye Castillo join Sean and Sean to talk about the challenges and opportunities that come with building products for technical audiences. Bukky is Chief of Staff, Digital Customer Experience at Autodesk, and Rye is a Design Lead at Render (a self-described “curious generalist.”).

The discussion revolves around challenges in product design, particularly in technical environments (where users are often tech-savvy developers), and emphasizes the importance of collaboration and empathy in the development process.

“The overarching theme of our talk is ‘collaboration,’” Rye says, “with special emphasis on including your engineers as part of the team and not people you have to fight against. In engineering-heavy organizations, sometimes it feels like you’re fighting an ‘us versus them’ uphill battle.”

This kind of environment reflects one of the challenges teams face, especially in larger organizations. Silos bubble up, and developers tend to retreat and narrow their focus on product specs. This hinders creativity and innovation. But good things happen when teams collaborate. Bukky suggests having developers sit in on usability tests and in conversations with customers; as much as developers want to be right, they want even more to be heard – to feel like they’re part of the solution.

Be sure to catch the entire episode with Bukky and Rye to learn about some of the tactics they’ve used to encourage collaboration, tear down functional silos, and build powerful products for their technical audiences.

In his blog, Maximizing Developer Value: The Intersection of Tech and Business Domains, ITX Senior Solutions Architect John Roets offers the following advice to his fellow developers:

“If you fail to see beyond technical skill as what makes developers and teams valuable, you’ve got it wrong. Developer and organizational attitudes, structures, and operational models continue to (mistakenly) reinforce the idea that developers are mere ‘order takers,’ fungible assets to be moved around from domain to domain where the work is.”

Podcast: Play in new window | Download

Sean Murray [00:00:19] Hey, everyone. I’m Sean Murray.

Sean Flaherty [00:00:20] And I’m Sean Flaherty.

Sean Murray [00:00:21] Welcome back to Product Momentum, a community of product people and a marketplace of ideas where leaders and learners come together to shape our way ahead.

Sean Flaherty [00:00:28] Our production team is the best in the industry, and we are dedicated to producing high-quality content from thought leaders across the product development space.

Sean Murray [00:00:36] Check us out on your favorite listening platform or if you prefer the video experience, You can find all our latest episodes on the Product Momentum YouTube channel.

Sean Flaherty [00:00:44] Let’s get after it.

Sean Murray [00:00:48] Sean! That was an awesome episode. Bukky Adebayo, right? Rye Castillo. Talking about a really interesting topic, building products for a technical audience, right? We got some great quotes out of it, what did you think?

Sean Flaherty [00:01:00] It was amazing. We talked about siloing. How to know when you see siloing on teams, but what to do about it. Like there’s some really good content in there.

Sean Murray [00:01:09] Yeah, and they work awesome as a team, the two of them, right?

Sean Flaherty [00:01:13] Exactly.

Sean Murray [00:01:13] They’ve got a great bond. And there’s a quote at the end. You shipped your org chart. So listen to the end. Yeah.

Sean Flaherty [00:01:20] You can see the results of how you’re organized in the product. I thought that was pretty valuable insight.

Sean Murray [00:01:26] Pretty cool, right?

Sean Flaherty [00:01:27] Let’s get after it.

Sean Murray [00:01:28] Let’s do it.

Sean Murray [00:01:31] All right. We are here with Bukky Adebayo and Rye Castillo. Bukky is a leader of high-performing product engineering teams, and Rye is a self-described curious generalist. I want to, like, learn more about that. But like, you’re here at Industry talking about designing products for technical teams or technical audiences. So what is that? Why did that become like your what? How did that become your focus?

Bukky Adebayo [00:01:53] So we’ve both spent a lot of time working on technical products at GitHub. Hashicorp. And  one of the things that’s super interesting about it is, especially since we were the least technical people on our teams when we were like, Hey, we’ve done this a few times. There’s something really scary about it. For folks who aren’t particularly technical with how like, do I have to know how to code? Do I have to know how Kubernetes works? The thing that we really wanted to talk about was, no, you have to bring the skills that you already have to this new context into building for technical audiences. So the same user research skills still work, the same synthesizing skills still work, all of that still works. And so you can just keep doing that. But now it’s with Kubernetes and more technical things.

Sean Murray [00:02:43] That’s great context. I think we have a lot of you know, I have friends in the industry right now who all of a sudden they’re like, Well, now I’m on teams that are building APIs and I’m like reading up on what an API is, and all of a sudden I have to figure out like how to design this. And so it’s kind of it’s refreshing to hear that it’s the same problems. You just have to frame it a different way.

Bukky Adebayo [00:03:02] Yeah, okay. What’s cool about working on technical products is you actually have experts on the team, right? Like you, you don’t have to be an expert on designing APIs because there’s a whole team of engineers who use APIs every day. Know what an ergonomic API looks like. You just have to include them in the process. And I think that that’s the challenge for engineers in a way that’s actually meaningful.

Sean Flaherty [00:03:28] Including them in the process is the key though, right? You know, as product leaders, we’re always dealing with technical people. So this is just instead of dealing with customers who aren’t technical. That’s the key difference here. Building products for technical people to use like APIs, for example.

Sean Murray [00:03:44] All right. So what’s a curious generalist and how has that helped in this kind of in this journey of building products for technical audiences?

Rye Castillo [00:03:52] Yeah, I have not nailed myself down to any particular niche. I like  dev tools. I started out doing front end and design and I’m on the design side of the house. And so I just find it really interesting to like see different perspectives. And I think that served me well when we were working together at Hashicorp because I was involved in both the design side, like working with Bukky on the product side, and then had some background on a little bit of what the engineers were doing. But again, that’s where the kind of gulf happens. It’s like, I’m not technical enough, can I actually help the team? Like when they’re this technical, but like having that sense of curiosity I think really helps to feel like we’re not in our little silos, like we’re able to work together and like, be curious about like, Hey, what are you doing? Can you show me? How can, like, pair together?

Sean Flaherty [00:04:36] So what are signs that teams are getting siloed?

Rye Castillo [00:04:39] Yeah, that’s a good question. I think if you could ask your development team, like what is your customer’s pain point? Like what are your customers say? Who are your customers? And if they don’t know, who knows? Like, is that being siloed within product or design and does design know what’s happening in product and engineering? Like if you’re not knowing what’s happening with your other teams, then like that very nature you’re siloed, I think.

Sean Flaherty [00:05:03] And what happens when teams get siloed?

Bukky Adebayo [00:05:05] I mean, I think you end up spending a lot of time when I would almost call over documenting. So like I think one of the things that’s that when we were doing a lot of deep collaboration. There are actually a lot of things that are I don’t wanna say left unsaid, but we’re like, understood. And if you ask everyone on the scene, they would say the same thing. We didn’t have to spend as much time writing the detailed PRDs with every single user acceptance test and all of those things because we’d internalized. This is where the bar is. This is what the customer needs and this is what’s important for us to be successful.

Sean Murray [00:05:40] So coming from the design side of the house, working with somebody on the product side of the house, building products for technical audiences, what is something that surprised you the most in this process as you got going?

Rye Castillo [00:05:50] That’s a good question. A really good question. I think back to something that you’re that you mentioned in the talk, which is that a lot of times the questions that you get from the engineering team don’t come formed as questions. They come as like very kind of suspicious, like almost like contempt, like we don’t believe like what you’re doing. Like, it’s not phrased as a question. It comes as more of like, gosh, like we’ve got to come up with a good reason for why we’re doing this. But as Bukky explains, there is a question underneath. And once you find out what that is like, then that person eventually turns out to be a very strong supporter of what the team is doing. It’s just that, like you have to recognize it. Like it’s phrased in this way that’s kind of guarded. That’s what comes to mind.

Sean Flaherty [00:06:31] By their very nature, technical audiences or products you’re building for technical users. They’re smarter. I mean, they’re intelligent, especially in their domain, whatever domain you may be building a product in:  Hashicorp, GitHub. Great examples, right? They’re smart. So along with intelligence comes a certain amount of, say, a lack of humility, sometimes. And there’s a defensiveness too. And, you know, I find another unique feature of that sort of audience is they tend to not be so expressive. They’re often more introverted .Not always. But certainly there’s some patterns there that you have to learn to deal with as a product leader.

Rye Castillo [00:07:07] Yes.

Sean Murray [00:07:08] So how do you I think one of the challenges that I have when I’m designing products is discovering that user and trying to not make trying to not make a lot of assumptions about the user. Right. You want to start from kind of like a clean slate. It’s hard to be kind of hard when you have developers working on a product for a technical audience, right? So how do you get them to like, how do you get them to kind of separate from what they think the developer wants to what to treating that developer more? It’s treating their audience more like a user

Sean Flaherty [00:07:37] Empathize with the audience.

Rye Castillo [00:07:38] Right? That is $1 million question. Have many, many tears, which.

Sean Murray [00:07:43] I know this is not for everyone.

Bukky Adebayo [00:07:47] You know, I think some of it is like what there a couple of things I would say. One is engineers are pretty smart, right? And so what we found where they were engineers on the team who were like, I mean, like people keep saying this, but like that hasn’t been my experience. So there’s already like, people are pretty critical of the product direction like, and if, when it doesn’t make sense when there’s kind of cognitive dissonance, so  like that is one thing like relying on that a little bit And the other thing and that took me a minute to learn, I think both of us a while to learn was we couldn’t do what we did at other companies where maybe the designer and the PM and maybe a user researcher would go talk to the customer and bring that insight back to the team because the team would go, No, I’m a developer. You don’t know anything. I’m like, No. And so bringing them into those conversations to literally hear from the customers themselves, to watch the customer, not know how to use the initial versions of the product where it was extremely technical people were confused the entire time.  And so watching that confusion and being like, you see it right when I’m making this up…and this is somebody who has a decade of DevOps experience. So they’re not a novice. They’re confused. And so like I think you actually have to have the engineers experience the pain and see the disconnect. And there’s also a broader answer to this too, is one of the things I also started doing was, is a lot of frameworks where I would be like, Well, we know that a DevOps peron at  a startup is actually quite different from a DevOps person at a large enterprise. So starting to add that nuance of folks and be like, you’re right. Like even though I’m a developer, there are developers and all sorts of contexts that are different from the context that I exist in.

Sean Flaherty [00:09:35] Yeah. So do you have any tips for us and how how do we build empathy between the technical users and the technical team?

Rye Castillo [00:09:42] As you were saying that, I thought of something we did where it sounds so simple, but this just kind of I think to go back to the siloing and just like how piecemeal different things can be, we had different features that as we’re shipping out, we decided, Hey, let’s kind of have different groups from engineering go through and like use these use case scenarios and write out how it works. And people were engineers were so confused using the features they had worked on, but like individually and like seeing it as a whole, as an end-to-end process without even talking with customers yet, they were like, Hey, do you know how? Where am I supposed to go for this? And like, asking each other, like, how to use the thing because they hadn’t considered the end-to-end process and like, how it the cognitive overload and like, the effect it has when you’re like, out of the context of developing it and thinking about code all day. So that was one step that I think I noticed a change.

Bukky Adebayo [00:10:34] Yeah. And I think I think, again, just having them sit in usability tests in conversations with customers and I think giving developers permission to speak in those conversations. Because I think especially because developers aren’t used to being in customer calls. So I remember some of the first ones I did with developers, they were so uncomfortable like, Do I have to say anything? I don’t want to say anything.

Sean Flaherty [00:10:56] That’s a problem. Like I said, they’re not so expressive like you’re saying. You got to get it out of them. And this is your job. You got to get the ideas out of them, you know.

Bukky Adebayo [00:11:08] 100%.  And like, I would explicitly like 30 minutes in, be like, does anyone have any questions? Like, was something confusing to you? And then afterward, also being like, you asked a great question. Thank you so much for asking that question. Like, we had a really good example that we’d talk about where we had a customer and he was talking about his QA environment and his QB environment. And I was like, QA, QB yeah, sure that makes sense!  And  an engineer, When I opened it up was like, What’s QB? And he was like, Yeah, we have QA, but we had more things we wanted to test, so we needed a QB environment. And I was like, What? And he was like, It’s actually challenging to manage both of these environments and make sure that they, they’re, you know, up to par to testing. And so we learned about this really cool pain point a number of customers having because engineer was their engineer was also confused when asked the questions. And I think that’s also a really big way of bridging that gap is making sure they’re in the room and making sure that they feel comfortable speaking and that their input is appreciated.

Sean Flaherty [00:12:14] Making sure they feel heard.

Bukky Adebayo [00:12:16] Yeah, yeah.

Sean Flaherty [00:12:16] Yeah, yeah.

Sean Murray [00:12:17] I like that tactic of kind of like validating their, like, hey, validating your social skillset, right? Like, hey, you did ask a great question and you should feel welcome to ask more, right?

Bukky Adebayo [00:12:26] Yeah, yeah, yeah. Like coaching that behavior away. And I always like, think about this is such a weird thing to think about. But Oprah said in all of her interviews at the end of every single interview she had over her 25-year show, everyone, once they got off the seat was like, Did I do good? And so like just being like, thank you for showing us affirmation. Yeah, you did great. You ask a question, goes a long way because we all we all need help. And I’m sure at the end of this podcast we’ll be like, Was that good?

Sean Murray [00:12:55] Is that our first Oprah reference?

Sean Flaherty [00:12:58] That was our first ever.

Sean Murray [00:12:59] So we’re really we’re moving up.

Sean Flaherty [00:13:02] Moving up, outstanding.

Sean Murray [00:13:03] What are the other key takeaways that you want the audience to have today? I think your topic is really unique and it’s building off of more unique topics that have, you know, been a part of INDUSTRY this year. We’re just we’re hearing about so many different things this year. So what’s the key takeaway that you want the audience to have?

Rye Castillo [00:13:22] I mean, I think the overarching theme is collaboration. Just considering the engineers to be part of the team and not people you have to fight against essentially, because like in a lot of organizations, it can seem that way. Or in engineering-heavy organizations, it can feel like you’re fighting an uphill battle and it’s like us versus them. And it’s like really building relationships and forming kind of that social aspect of the team and like affirming each other, I think is.

Sean Flaherty [00:13:48] Just to bring it back. Breaking down the silos.

Rye Castillo [00:13:50] Exactly.

Sean Flaherty [00:13:51] Yeah. I think in large organizations there’s a natural tendency to move towards the silos because engineers, you know, if their goals aren’t clear and there is a lack of alignment and the organization’s big, you know, they tend to tend to move towards like, just tell me what to do, just give me and not be involved in the overarching understanding of the consumers and the empathy and like and you’re not going to get ideas out of them. And they’re smart. So we want their ideas. We need them to be motivated to be aligned to really care about the product. But I’ve seen it over and over again, this tendency to kind of move into commodity roles, like I just give me the specifications, I’ll build it and I’ll throw it back over the wall and that’s a mistake. That’s a big mistake.

Rye Castillo [00:14:33] Especially when you’re building technical products. But then again, you balance the line of like, I know who the customer is because I’m a developer versus like, but it is a so it’s like, yeah, like walking that fine line of using their knowledge and like also forming that like kind of genuine bond with them to be able to not be siloed.

Sean Flaherty [00:14:50] I love that.

Sean Murray [00:14:51] I used to have this philosophy that the developer really all a developer really wanted was to be right. And that was their number one thing was I want to be right. And I think what’s changed in the last decade for me has been it’s not that they want to be right. It’s that they want to be a part of the solution and they feel they’re planting this flag, this thing where I want to be. Right. They’re planting this flag because they don’t feel like they were part of the original solution.

Sean Flaherty [00:15:16] I think they just want to be heard, more than anything else? You know?

Rye Castillo [00:15:19] Give me them space to do that.

Sean Flaherty [00:15:20] Giving them the space to communicate their ideas and talk it out? Love it.

Rye Castillo [00:15:25] Yeah, yeah, yeah.

Sean Murray [00:15:26] Tom, we asked you questions at the end, okay. Right. So the first one is, what are you reading right now?

Sean Flaherty [00:15:34] How are you up leveling your skills.

Rye Castillo [00:15:37] Well, it’s funny you ask.  So I’m reading a book called Private Government about the concept of the workplace actually being a form of private government and how that affects people who work there. Very interesting. Kind of like sort of touches on some of these topics. So, yeah, that’s what I’ve been reading recently.

Sean Murray [00:15:55] What about you, Bukky?

Bukky Adebayo [00:15:58] I’m reading The Resilience Myth by Soraya Chemaly, and it’s essentially about the myth of resilience, individual resilience. That resilience actually exists in a social context. So it’s like, what makes us more resilient is our connections to other people and like more about them. I think that like, that also, I guess ties in a little bit with our talk because I think that especially like as a product manager, there’s been this like push to be the CEO of the product. I know people are moving away from that, thank God. But  to have all the answers to be the person who’s like resilient and figuring things out. And I mean, we’re giving this talk together because I think I’m realizing more and more that I do my best work and I’m more resilient when I’m on a team where folks are flexing into different roles and working together.

Sean Flaherty [00:16:49] You take advantage of everyone’s skills, knowledge and passion.

Bukky Adebayo [00:16:52] Yeah, exactly.

Sean Flaherty [00:16:52] You get a better result. Yeah.

Sean Murray [00:16:54] The physical embodiment of breaking down silos. I’m giving a speech with somebody else on the stage. Right?

Bukky Adebayo [00:16:59] Yeah

Sean Flaherty [00:17:01] Yeah. Yeah. So how do you guys define innovation independently?

Sean Flaherty [00:17:06] How do you define Innovation?

Rye Castillo [00:17:09] I mean, I guess, like, it’s something that hasn’t been done before, but is it really like in context of our talk, is it doing something in a different way that maybe you hadn’t thought of before, that when the product comes out, are people going to be able to tell the way that you worked on it? Like a friend of ours once told me you shipped your org chart you can tell by the finished product….

Sean Flaherty [00:17:32] I’ve never heard that before.

Rye Castillo [00:17:33] Let’s go back to the silos. You can see if teams were siloed when the product finally comes out, like your audience will be able to tell. And so I think, like, it might not sound innovative. To work differently together. But I do think, like, how else do you find innovative solutions if you’re not willing to change the way that you work on it, like how you arrive at the final solution.

Bukky Adebayo [00:17:53]  I love  that, now me wanting to borrow that answer. You know, I think I kind of want to broaden innovation out of like, we’re working on AI or working on something like that. Yeah. Where it’s I think it’s in a lot of ways. It’s also all of the small things that folks are doing in their daily lives to improve.

Sean Flaherty [00:18:17] To improve everyday.

Bukky Adebayo [00:18:18] I mean, I think that those like, mini innovations all add up, like not to use Agile, but like all the iterations add up to like big innovations. And so I think a lot of I’m trying to think of a really good example of this. My mom is in food science and so it’s some things like when she’s like, we don’t have any vinegar, you can use lemon juice, like those kinds of smaller innovations. And then all of a sudden you have a completely new recipe that was different from that.

Sean Flaherty [00:18:42] It’s better.

Sean Flaherty [00:18:43] Sometimes. Yeah. What do we do here?

Rye Castillo [00:18:45] Yeah. Yes. And so I think I think of that and giving everyone, not just technologists permission to be innovative and to try.

Sean Flaherty [00:18:53] Yeah I think you know you the strongest teams are the ones where you’re getting input in ideas and passion from everybody on the team, not just the leader. And yeah, I love that. Well, thank you both very much for joining us.

Rye Castillo [00:19:04] Thank you.

Sean Murray [00:19:05] This was awesome.

Sean Murray [00:19:06] Showing up to INDUSTRY.

Sean Murray [00:19:07] Like in half hour, you’re going on stage, right? Just do what you did here. You’re going to kill it, right?

Sean Murray [00:19:12] Awesome.

Sean Murray [00:19:13] We don’t have.

Rye Castillo [00:19:13] Any gotcha.

Sean Murray [00:19:14] Questions. Yeah.

Sean Murray [00:19:16] Yeah. Thanks again for joining us.

Rye Castillo [00:19:18] Thank you.

Paul Gebel [00:19:20] Well, that’s it for today. In line with our goals of transparency and listening. We really want to hear from you. Sean and I are committed to reading every piece of feedback that we get, so please leave a comment or rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.