Rory Madden, Co-Founder of UXDX, joins Richard on this episode of the podcast to talk us through his journey to creating one of the most dynamic, barrier-free conference series’ in tech. UXDX (UX being user experience, DX being developer experience) was born from Rory’s frustration when he couldn’t figure out how to implement innovative solutions in the companies he was working in, and he was always looking for case studies of people who had done it before him, as a way to boost his colleague’s confidence in new ways of doing things. His partner Catherine had a wealth of conference experience, so they decided to collaborate. They created UXDX, under the principle of connecting people from across every stage of the development process.
Rory talks about how the attendees of UXDX may work in a huge number of different fields, but underneath it all, they’re all united by a common interest - getting things done. It’s what the conference is all about. Many of their attendees have common frustrations; projects getting shelved or dropped with no explanation from their higher-ups, lack of transparency, etc. Rory feels the solution for this comes down to communication. Management sharing their vision with developers can help immensely when developers need to make decisions that require knowledge of the company’s overall goals. Lateral communication between different workers at the same level is another key element, and something that UXDX is just the place for.
Rory has a varied background in product development, and he dives into the pros and cons of really catering to your superusers, or going the other direction and changing things up to try and impress the people who just feel “meh” about your product. This decision applies to conferences too, as he reveals that he himself has thought about trying to cater UXDX for more of a niche audience. But ultimately, the multi-faceted crowd is what makes UXDX such a special event.
We also hear from him on the topic of community building, and how you begin that task from the ground up. The trick seems to be avoiding loaded expectations. Like product development, your desire to foster a community should stem from the desire to solve a problem that you see around you, and UXDX is truly a wonderful example of this.
Check out UXDX at their website.
Interview Intro
Richard Rodger: [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started.
Today I’m speaking to Rory Madden, one of the founders of the UXDX conference series. If you work in developer relations, it’s always a good idea to get friendly with conference organizers, because trust me, they’ve seen everything. Given Rory’s background in product development, we get deep into the weeds on API design, API version management, and how to make sure you don’t lock yourself into an old, horrible to support version of your own API.
We also talk about the challenges of building a community when you’re a conference. Think about it; conferences happen once a year. What happens all the rest of the year? Where does the community live? You could do worse than checking out uxdx.com, and you can tell from this podcast I’m a big fan.
Okay, let's talk. [0:01:04]
Main Interview
Rory Madden
Richard Rodger: [0:01:05] Hey, welcome, Rory. Welcome to the Fireside with Voxgig podcast. It’s great to have you on here today talking about uxdx.com. First of all, tell us what is UXDX. [0:01:18]
Rory Madden: [0:01:19] Sure. Thanks for having me, Richard. UXDX is a conference where we focus on the full product team, because we think of software development as a system. And instead of where companies have silos, we break down those silos. We have product managers, UX researchers, designers and developers, all learning how to build better products faster together. [0:01:42]
Richard Rodger: [0:01:44] This is the state of the art these days; you’ve got to be able to bring all these different people together to build an acceptable SaaS product. The quality standard is a lot higher than it used to be, right? [0:01:57]
Rory Madden: [0:01:58] Yeah, well, you like to think so. [0:02:00]
Richard Rodger: [0:02:00] Or is it?
Rory Madden: [0:02:02] You’d like to think that it’s the standard today. And it’s funny, because you ask anybody and they’re 100% working agile. Everybody will say they’re working agile. And then you dig into their actual process of what they’re doing and they’re like, “Of course we have the business case and we have to sign that off because that’s where we get the budget from. And then we have to stick somewhat to that scope.
“But we do do sprints. And we break it up into two-week cycles and we run retros. And then we can’t quite release on our own, because it’s quite difficult with all of the way the – our system is made. So then, we just put it into the bucket to get release later.” That’s a lot of experience that I’ve had talking to people. But they’re like, “No, we’re definitely agile because we’re doing those sprints in the middle. [0:02:49]
Richard Rodger: [0:02:50] Well, we can definitely dive into the whole agile of the – these days it’s a dirty word; isn’t it? You see a lot of different ways of doing things out there. Are two-week sprints still the most common? We moved to one-week sprints; I find them much better. [0:03:10]
Rory Madden: [0:03:12] Yeah, I would say two weeks, because in a lot of – now for context, we’re dealing with scaling startups and enterprises would probably be our sweet spot at our conference. Because by the nature of a startup, they’re so small they are cross-functional. So, everybody is working together. The challenge comes when you start growing and getting big and it’s – those informal networks start breaking down.
So, the risk is that companies go, “We’re big now. How do the big boys do this? Let’s break it up into our functions and we’ll follow strict processes.” And that’s where you end up with that – everything has to have a process. And we might be a PMO and it might be mandated exactly that everybody follows this. And two-week sprints just seems to be the industry standard that we’ve seen.
We do – then there are the people who are experimenting, and there’s people who are doing, as you said, one-week sprints. There’s shape-up; I don’t know if you’ve looked into that, but they go with advocating for six-week sprints, because they say you can’t get much tangible done in two weeks. And then there’s everything in between as people are experimenting and trying to figure out how do you scale this, without resorting to something like safe, which almost mandates waterfall, those ones. [0:04:40]
Richard Rodger: [0:04:42] I don’t know. What I always found with two weeks or longer is that it tends to create cyclical activity, where there’s a mini-deadline and everybody puts in extra hours. And then people are exhausted, and things reach a low ebb then at the start of the next sprint.
And also, if you’ve got two weeks to do something, you can procrastinate a little bit more, and your processes and your CICE doesn’t need to be quite as tight. Whereas one week forces everything to be well oiled and forces everything to be made into – broken down into really small pieces. I don’t know. I don’t want to end up in an agile discussion, but- [0:05:32]
Rory Madden: [0:05:34] I’m going to break this into two different things. Because you brought it up there. And I think people conflate them, and that’s one of the things we try to separate. That there’s one is the timing and the – so is it one week; is it two weeks? What’s our deadlines, that kind of thing. And that’s what I would say the process.
And then there’s your CICD pipeline that’s your – just the things you need in the – almost the background, is the basics of what you need to get set up and running. And I like to treat them as almost separate things, because you should – even if you’re doing a two-week sprint or a one-week sprint, we would still advocate that every commit – trunk-based development, test-driven development almost – sometimes I’m a bit of a zealot there.
But when I’ve been working in projects, that’s what I push my dev teams to implement. Because I want to be able to release at any point in time and not be restricted by, are we two weeks and one day; are we – whatever the timeline of the process. So, it’s, can we get the workflows in place where we are literally on every commit red/green refractor.
If trunk goes red, everyone drops tools; jumps on top of it, to make sure that we’re always in a healthy, releasable state. And then, back to the process, it’s this kind of catch-22 that deadlines are motivating; they actually are. And it’s proven to show that people do work a little bit harder to hit a deadline. And if you don’t have a deadline, things can stretch out.
But the negative side of a deadline is if people are cutting corners and introducing tech debt and things like that. That’s where on the process side, what we advocate for is more of – at a quarterly level of setting goals, but the team own it. And if the team then decide what they can do to do it, they need to be looking after the pipeline; they need to be looking after the tech debt. Because if you’re given a goal and you start keeping introducing tech debt because you’re trying to hit milestones or deadlines the whole time, you’re not going to hit next quarter’s. So, it's that – trying to get that longer-term thinking into teams. It’s a difficult one. [0:08:04]
Richard Rodger: [0:08:07] It’s a really deep problem and nobody’s really solved it, but I think you’re a genius. Your and Catherine’s genius was setting up a conference on this very topic, that is one of the most controversial in the software industry, that everybody’s trying to figure out. I’ve always found – I’m shilling here – I’ve always found the speakers at your conferences to be really great, because they are discussing these critical issues of delivery. [0:08:35]
Rory Madden: [0:08:38] One of the things – on the conference and the background. As you mentioned, Catherine – her background is in running some of the largest conferences in Australia; she knows conferencing inside out. My background is in software development, so we came together and figured what could we do. And the challenge I was facing was, I had learned about agile; I had learned about – my background is, I’ve been a bit of a developer. I’ve been a business analyst; I’ve been a project manager. I’ve been – I’ve done all the different roles testing.
But I couldn’t figure out how to implement it in the companies I was working in, because it was always the - as people would say, the cultural problems that would always get in the way of, you can’t do that or you can’t do this. So, I was always looking for case studies of who has done this and how did they do it?
And that’s where UXDX came from in a way, that we don’t invite the same types of speakers you might see at other conferences. There’s what we call the circuit, where you’ll see the same speakers and they appear at every single conference. And they’re great an they’re fantastic and they have a wealth of experience. But what we’re looking for is actually practitioners in companies and how they’ve done it.
So, if you look at the agenda of – we have a conference coming up soon, and if you look at the agenda, you’ll see that the speakers are from big companies, and they’re the heads of design or the head of product, chief product officer, the CTO, people like that. Because they’re the people who are facing the reality. It’s not a consultant who can come in, give some advice and then leave. They’re facing the reality of how do I actually implement this? So, that’s our goal, is always to get the practitioners and to get real case studies in the conference. [0:10:33]
Richard Rodger: [0:10:34] Yeah, and I guess that ties into stuff that a lot of our audience would be dealing with on a day-to-day basis as well. Because a lot of them are in product-led growth companies, where the product itself, even if the product is for developers, is the thing, is the engine that drives revenue. And the – what you’re focusing on is how to execute on product-led growth, right? [0:11:02]
Rory Madden: [0:11:04] Yeah. I really think – I’m a massive advocate for product-led growth. You have to think about what your customers want, and that’s why the name, UXDX. UX is the user experience; DX is the developer experience. And it’s melding the two of those together. Because it’s neither one is going to improve things for – you need to be focusing on what works for your customers, but then what works for your internal team as well. And that’s the idea that if we can meld the two of those and figure out a process that works, then it’ll be fantastic.
To your point about, though, product-led growth, I’m a massive advocate of understanding your customer problem. And then if you do that, even if you are marketing or even if you are sales heavy, having that understanding across the teams means that you’re not going to end up in those situations where you get blindsided by sales coming along and saying, “We just sold this feature to somebody.”
Because once your team is very user focused and you should be seeing the same problems, and you should be using sales and marketing and other people as a source of information in the product team for what the needs in the market are. So, it’s one of the things that – I’m a massive advocate of product-led growth, but it’s complemented by the others. And if you can get them all working together, that’s the sweet spot. [0:12:37]
Richard Rodger: [0:12:38] I think a lot of – yeah, and I think a lot of the companies that we talk to, especially when they’re selling to developers, have to have an API. And if you design your API too early, you get locked into something that doesn’t work. You see a lot of people with V2 in the URL, because after a while they’ve got feedback and now they know how to do their API properly. Any advice for developer teams out there, building developer products? They know they have to build an API. How do you get it right? How do you solve the API problem? [0:13:11]
Rory Madden: [0:13:13] My first reaction when I heard that was one that I always remember from my business analysis days, was the business would say, “Just make it flexible.” [0:13:21]
Richard Rodger: [0:13:22] Ah yes! There you go. [0:13:23]
Rory Madden: [0:13:23] Just make it so that it can work in whatever happens in the future. And you’re like, “I’m not quite sure how to…” But yes, so APIs, it is a massive user experience challenge doing an API. Because it’s the same problem hat you get whether you’re building a product for end customers, where you stand on a whiteboard and you design it and you think, this is amazing; everybody’s going to love this. It makes so much sense; how we’ve designed this is perfect.
But that saying, no business plan survives first contact with a customer. It’s the same with an API, whether – you might think this is the most perfect and flexible and it solves the needs or whatever. But then when your customers start using it, that’s when you learn what they want and what they need, and things will change. So, the way I’d advocate for how you’re getting really high-quality API is the same way I’d advocate for getting a really high-quality end product.
Try something small; do a quick prototype. Test it with real users. And that way you instantly – it’s so eye-opening every time I do it, when – it’s that point in your brain. And I learned some – I think it was Thinking Fast and Slow, the book, where it explained that when you’re remembering something, you’re using the same synapses as when you experience it the first time.
And when you learn something new, that creates a new connection in your brain, and you literally cannot think about how you thought about it before, because your brain is no longer structured that way. So many times I’ve come across new information, I’ve gone, “Of course it has to work this way. It couldn’t possibly work in any other way.”
But yet, just before I’d learned that information, I was very happy with how it had originally been designed. So, doing those quick little tests help you to get to those points of understanding and clarity., and hopefully will get to you to a longer V1. I don’t think you’ll ever escape the V2b but it’s about how high quality you can get that V1. [0:15:42]
Richard Rodger: [0:15:43] Yeah, and maybe try to keep the V1 small. A lot of people are – really like to use GraphQL these days, because of flexibility; literally, that’s the selling point. But GraphQL scares me. Do you have any thoughts on – does it – it is a help or does it create too much flexibility? [0:16:05]
Rory Madden: [0:16:07] For me personally, I love it; use it on our website. We have a very – on the uxdx.com website, we have Airtable as our back end. So, I’m not sure you’re familiar with Airtable? [0:16:20]
Richard Rodger: [0:16:20] Yes.
Rory Madden: [0:16:22] Like Excel on steroids is how I’d describe it. But it’s great, because we’ve tried so many CMSs and they’re so clunky. But Airtable is just great because it’s got the ease of use that people can use like a system. It’s a little bit risky because if people don’t know how joins work, they start updating a record instead of creating a new one.
But the – those – there’s Undo and there’s all kinds of history on Airtable, so just as a product, I find that very good. And then it’s great for the team; it’s infinitely faster than the other CMSs that we’ve used. And then to get that into the website – Airtable specifically says: “Don’t use our site. Don’t use our product as a back end.”
And their rate limit – they have pretty aggressive rate limiting. So, what we do – I use Gatsby and put a GraphQL layer on top, so it takes a copy at build time, and I just use GraphQL to place on the data on all the different pages. So, I personally love it and it gives – if we come back to what we’re trying to go, of get teams working better and faster together. There’s always going to be probably a layer of platform engineering as the company gets larger. [0:17:43]
Richard Rodger: [0:17:45] Rory, I have a nasty question now, which is – that API is – that’s not a public API though, right? [0:17:53]
Rory Madden: [0:17:55] Sorry – yeah, no, the GraphQL, no; this would be very much an internal API to be shared between- [0:18:01]
Richard Rodger: [0:18:02] What happens is often exactly this, where an internal API has been built, which has lots of flexibility and features and capability, but assumes an awful lot of domain knowledge and internal upskilling and all that sort of stuff. And then for business reasons, or as part of the strategy – let’s make our API public, or part of it. And we already have one; there we go. Stick an API gateway in front of it and off we go. [0:18:36]
Rory Madden: [0:18:38] If you ask me that question now, about making it public, I would shy away from GraphQL. [0:18:42]
Richard Rodger: [0:18:45] I promise I wasn’t trying to trap you. [0:18:46]
Rory Madden: [0:18:49] Internally, it’s great, and it’s great for sharing between teams internally. Because the big problem with GraphQL is, you don’t know how people are going to query it. So, you might start getting these crazy expensive queries being called by people that you haven’t optimized for, so there’s a little bit of a risk with that.
Even though it is more flexible, there is something in making it a little bit less flexible. It’s the choice paradox, that if you give people too much choice, they don’t choose anything. There is something that in product, you’re not giving the customer everything they ask for; you’re giving them what they need.
And it’s a subtle difference there, and the same is true with an API. You don’t just go, “here you go. Here’s everything. Best of luck.” You need to think a little bit more about, what problems are they trying to solve and how can we do that and make it as easy as possible for them to solve that. [0:19:53]
Richard Rodger: [0:19:55] Yeah. So, it is – the API design, once it becomes part of the product, you have to apply just as much care to it, don’t you, as you would for the UX of the product. You can’t just take an existing internal API and fling it outside. [0:20:10]
Rory Madden: [0:20:13] It depends on how well you thought you’ve designed your internal API. But I do think it’s – the argument is that if you’ve got a front-end team or something and they’re using that API, then that’s great; let’s expose that. Because they’re using it for a website and somebody else might use it for a voice or maybe an AI bot or something like that.
It’s subtly different. What I’ve enjoyed seeing is the transition from we have a single API to rule them all to – you know what? Mobile needs a slightly different API than desktop. Because what we’re serving to customers, we don’t want to give them a fat API where they’re getting so much data and it’s slowing things down.
So, that kind of back end for front end model is quite useful. And then if you translate that then into a public API versus an internal API, it’s again thinking about what is the problem I’m trying to solve, or rather, that my customers are trying to solve? And how can I help them do that as best and easy as possible. [0:21:28]
Richard Rodger: [0:21:29] Would it be a good strategy to follow Jeff Bezos’s instructions? Because when he decided to turn Amazon into AWS, every API had to be externalizable from the word go. You had to – even if you were designing an internal API, you had to have it in the back of your mind that eventually, it would become external. [0:21:29]
Rory Madden: [0:21:54] Yeah. It’s hard to argue against anything that Jeff Bezos has done. [0:22:00]
Richard Rodger: [0:22:01] Could all just be luck; could all just be luck. [0:22:03]
Rory Madden: [0:22:03] The results speak for themselves. With Amazon, one of the best things is how many different industries they’ve tackled and how consistently they perform well. So, it’s – either they are the absolute luckiest company in the world or there’s something in the way that they work. [0:22:22]
Richard Rodger: [0:22:23] The Dx of their APIs leaves a lot to be desired though, right? [0:22:27]
Rory Madden: [0:22:27] Yeah. And even– if you argue it from a design perspective, amazon.com almost looks like they haven’t invested – over invested in their design. But they’re - to me they’re solving the problem as effectively as they can without necessarily looking at the – making it super useful. It’s how effective – effectiveness over usability in a way. [0:22:57]
Richard Rodger: [0:22:57] Isn’t it the exception that proves the rule in that people got used to the 1990s design of Amazon, and there’s literally – literally any change will reduce revenue. So, you can’t change it; you can’t really change it. [0:23:12]
Rory Madden: [0:23:14] Yeah, there is always that risk, and that then leaves a space for an incumbent – or sorry, a startup to tackle the incumbent. And that’s the traditional – the incumbent becomes too big and bloated and slow. Reddit, the CTO spoke about that very problem at UXDX a few years ago. And he was saying that with Reddit, they had this very ugly 1990s look, and they knew they wanted to modernize it, but literally every change they made, it was uproar. [0:23:46]
Richard Rodger: [0:23:47] I know; I know. [0:23:48]
Rory Madden: [0:23:48 And he recognized though that if they didn’t, that they would become susceptible to being replaced by a fancier and a slicker one. So, instead of doing the big redesign that a lot of companies do, they sliced away at it. They would make little incremental improvements and people would – the backlash wasn’t as severe when they would just do little changes. And then they managed to push through their redesign. [0:24:22]
Richard Rodger: [0:24:24] It’s a nice problem to have though, isn’t it? You have a use – such a dedicated user base that complain if you make changes. [0:24:31]
Rory Madden: [0:24:32] Yeah. And it the – I remember that with – I worked with a software way back at the star of my career called Siebel, which was a CRM system. And they were upgrading from a desktop to a web-based application. And the challenges were, the super users were so quick at using all the shortcuts and everything and navigating around the application, that it became – they were the biggest detractors of an upgrade. It was much easier to train a new person on the new version, but the super users struggled because things we removing around and changes. [0:25:10]
Richard Rodger: [0:25:12] Speaking of super-users, I don’t know if you’ve ever come across an email startup called Superhuman.com? [0:25:18]
Rory Madden: [0:25:20] I’ve heard of them. I’m not one of the subscribers, but I see it every so often because it’s like the iPhone; it’s got that little tag at the bottom of the emails, Sent From- [0:25:28]
Richard Rodger: [0:25:29] I use it. Their gimmick is that absolutely everything has keyboard shortcuts and you have an action bar. You press CTRL K and it’ll start typing, and it’ll find the command that you want. I’m an old school dev, so I like to use EMAX; don’t like to use the mouse. So, if I can interact with a computer using a keyboard alone, that floats my boat. And it’s designed for that use case, for that high-speed interaction. That’s another question. I don’t know can you- [0:26:06]
Rory Madden: [0:26:06] And then, but it’s – so, with Superhuman – just before you jump off, because that’s a great study in product-led growth. They did- [0:26:15]
Richard Rodger: [0:26:15] Yes, alternative.
Rory Madden: [0:26:16] They did a phenomenal – there was an article that the CEO wrote a few years back, and it was about how they ditched NPS in a metric in their – their metric was, would you be upset if we shut it down? And that was the question. [0:26:30]
Richard Rodger: [0:26:31] I would be, yeah.
Rory Madden: [0:26:33] And what they found was that they had people – with most companies, you’ll have your spectrum. You’ll have your people who love it; you’ll have the people who’ll be like, “Meh, doesn’t really bother me that much.” And so, what a lot of companies would do there is, they go, “We’ve got the super users. They’re not leaving. What are the problems we can solve for the people who are going, ‘Meh.’”
And they did the opposite. They said, “Okay, these people, let’s just drop them. They’re probably going to churn anyway. Let’s just focus on the super users and let’s just keep improving and improving it for them.” It was an interesting approach, because you think that maybe you’re limiting the market. But where they were going and the growth that they were on, they were saying, “Let’s just absolutely nail it for the super users, and then we’ll come back and maybe tackle the wider market.” [0:27:25]
Richard Rodger: [0:27:25] Yeah, and they do something else that’s very interesting. You hand over your money, but you still can’t use the software until you’ve done a 30-minute online training course live, with – a one-on-one training course. 0:27:37]
Rory Madden: [0:27:40] Two things that don’t scale. [0:27:41]
Richard Rodger: [0:27:42] Absolutely, right? But at the same time, when you come out of that, then you – it’s great value for money because you can fly through your email. I only use 5% of the features. But it’s interesting how there’s not one right way to do user experience. If you tune it to your overall product strategy, it’s an input that you can adjust, and that’s a perfect example, where you just focus on power users. [0:28:19]
Rory Madden: [0:28:20[ And that’s one of the things as well. When it came back to – I used to work consulting and my job was to try and implement these product teams and implement these empowered autonomous teams that could go off and deliver in the way that Amazon have structured their internal teams. And it was always a struggle.
And one of the big challenges that you would face – yes, the skills is something that can be worked on, but that’s a fairly easy one to solve. We can train people on how to do customer interviews and to uncover those challenges and pain points that customers are facing and be able to fix that.
So, the skills wasn’t really the hard bit. The hard bit was convincing management, let’s let the team do this. Let’s let them decide what to build; let them talk to the customers, figure out what to build. And what would come back would be this fear of, what if they build something crazy? Or what if they go off in the wrong direction?
And the example I always think of is, I worked at two airlines, Aer Lingus and Ryanair, and they target a different market. Aer Lingus is a value carrier; they’re high-quality, great experience on board. Ryanair is low price; don’t expect anything else. And they have the same middle seat problem, that you don’t want to sit in the middle seat on a flight. Nobody likes it.
So, Aer Lingus said, “You can buy an empty middle seat. So, you pay a little bit more and we’ll guarantee that the seat beside you is empty.” And Ryanair said, “You’re in the middle seat unless you pay to get out of it.” So, two – it’s the same product in a way, but it’s very different.
Now the fear, if you’re in management and you’re going, “We have a brand and we have a product vision and we have all of this. Now imagine we let our developers go off and they implemented the wrong one of those two approaches in the opposite company, if you know what I mean.” That’s one of the big fears and that’s where- [0:30:30]
Richard Rodger: [0:30:31] Isn’t that a valid – that feels like a valid fear. [0:30:35]
Rory Madden: [0:30:36] Yeah, and it’s how do you convince somebody. And it comes down to context, so senior management have much wider contexts of the broader company, whereas somebody in a team often has a very narrow view of what’s happening. They know the little bit of the product that they’re working in.
The solution is that you share that context, and there’s two arguments for how you structure things. You do information up or you do information down. And what I mean by that is, the teams closest to the customers see all the problems and then they report that up. And then that gets escalated until hopefully somebody senior decides, “We’ll fix this,” and then tells the teams, “Go build some feature to fix this.”
And the opposite is, you get the context to come down, so that the management tell the teams, “This is our vision for the project. This is our current strategy. We’re going after this market segment. We’re going after this geography. We’re going after…” whatever the current strategy is. Could be cost cutting; could be revenue generation.
And these are your objectives, so give all the teams the context, so that they’re not going to make that stupid mistake. That they’re going to say, “Our strategy’s going after business customers. We’re not going to piss off a business customer and put them in the middle seat. We’re going to have to make this as luxurious and high-quality experience.”
So, that’s the route we advocate, is that you need your product people to be doing an inspiring vision, an inspiring mission for the product, to get people excited about what they’re building, and then share that context of the strategy and the objectives. [0:32:22]
Richard Rodger: [0:32:25] Now that gives me a good segue into another topic that I wanted to ask you about, which was community building. Because it strikes me that a great way to build context at all levels in an organization is to participate in the community built around that project. Again, in the world of developer relations and developer-focused products, community is a big deal.
Because developers love to be in communities and it’s part of the way that people learn about you. What’s your experience been building a community around a conference? There’s a slightly different problem, but I’m curious about how you’ve gone about that and where you’re going to take it. [0:33:08]
Rory Madden: [0:33:10] Yeah, it’s a challenge. I don’t think – I’ve often heard people say, “We’ll build this community and it’ll be great and we’ll get all this business from it.” And you underestimate how much a community is – it’s more – you might get something out of it as a side effect, but you shouldn’t go in expecting that. You should go in saying, “What’s the problem?”
Same way with product development; what’s the problem that your community is having and how can you help solve that? The way we’ve tackled it – and we’re still learning. I don’t know if anybody has got community building down pat.
But we try tackle it in a few different ways. One is, we want to help the people who care about cross-functional work, but often in a company you might be a developer, so you’ve very little experience or understanding about what is the work that a product manager does? Or what – how do researchers do their research? It’s a little bit of a black box, what other people do.
How we structure our newsletter is, we have five sections for five different parts of the flow. You might only be – you might join as a developer and go, “I’ll just read the developer sections.” But every week, you’re going to keep seeing, here’s what’s happening in product; here’s what’s happening in Ux. Here’s what’s happening in design. And what – I’ve spoken to a few developers and they said – they don’t even care about the developer side of our conference anymore. They come to learn about our product in Ux, because that’s where they see that they can learn and upskill the most. [0:34:46]
Richard Rodger: [0:34:47] Totally, that’s what I love about your conference, for me, absolutely. There’s any number of developer conferences with code, but what you guys do is – teaches about the rest of the org; it’s really fascinating. [0:35:00]
Rory Madden: [0:35:02] Yeah, and to me, the most frustrating thing ever was when I’d work on something and either it would get shelved without being released, or it would release and it didn’t – they knew because there was so many change requests that didn’t get approved or things that happened at the end that the product wasn’t quite where it was at.
And that’s what – I’m trying to solve that feeling of feeling terrible at the end of a project, because I’ve felt it and I don’t want other people to have to feel that. So, that’s where it’s – you can solve the problem, and if the developers really understand – because with that, what I just said about the context, the developers need to take that on board, of understanding the context, if they’re to be trusted to build the features.
So, that was the newsletter, but we also – we realized that we didn’t want it to be a one-way communication, because that’s not a community. A community is two-way communication. So, we’ve tried a few different things over the years. We did physical roadshow of meetups and what we do there is, we bring – we do a half-day. It wasn’t quite a traditional meetup of an hour or two after work. We did a half-day conference and we’d bring it to 10 cities around Europe.
And that was fantastic, because that got people – half the time was the talks, but the other half was the networking and getting to know people and the questions and all that kind of stuff. Of people hearing about something and then delving a bit deeper, to understand it a bit more. So, we found that phenomenal.
Unfortunately, COVID came along and put a stop to it, but we’re going to start that up again. We’ve been a little bit slow to get it started again, a little bit hesitant, to make sure COVID’s really not coming back. But we’re going to definitely kick that off, because that was phenomenal. People would come to the conference afterwards, and it’s a camaraderie already, just from that little event. And people love physical engagements is what I found from that.
And then the opposite of what I’m about to say there is the no physical engagement. We do a Slack community as well. And the idea here is that one of the channels in there is Ask the Speakers. Because we do a lot of different talks, and we always have people – you never have enough time for Q&A after a talk. The Q&A could go on for longer than the talk in many cases.
So, the idea is, let’s capture the questions there, because then there’s a bit of posterity to it as well, where people can go back and see what was happening and what questions were asked and things like that.
So, that was one of the was of – again, it’s trying to solve the problem of, what are people – what are the problems people have and how can we help them solve them, but aligned to what we’re doing. That’s how we said, “Okay, well, let’s build a community around our speakers and the talks they’re giving and how that they – how they can help solve the problems that everybody else out there is having. [0:38:09]
Richard Rodger: [0:38:11] It feels like you have a double challenge. Because building a community around a conference or series of conferences, which are point in time events, how do you sustain that then between events. And then the second one is, your community is cross-functional by definition.
It is easier to build a community with a highly focused niche interest, but you’re trying to bring people from different parts of the organization that share this vision of product development. But it does sound like when you get the right people in the room, it is quite strong, because if people care passionately about this stuff, it’s something that can bring together, because they are often quite frustrated in their organizations. [0:39:03]
Rory Madden: [0:39:04] Yeah. There is a – I’ve often thought, we should focus in some area because it would be so much easier than trying to get this cross-functional. Because as – to your point, the niche I believe is easier to build a community around. But what I found is, there’s a saying by – I think it was Deming said, “A bad system beats a good person every time.” And what he means by that is, you might be the most skilled person ever, but you’re only going to move as quickly or as effectively as the system that you’re working within. And it takes people a few years in their career to see that.
So, that’s why again, our audience skews a little bit more experienced. Because it’s the people who recognize that I’ve built my craft; I know how to do my craft to a degree. Now I need to figure out how we can be more effective. So, we are a little bit selecting not just purely for – if I look at some other places, I can see they’re targeting junior developers or they’re targeting particular areas.
Whereas we’re more senior, who are looking at, if I can think about the entire system, I can try figure out how I can get better products built and that kind of thing. It naturally – while it does seem like it’s difficult from a cross-functional perspective, it is appealing to those people who are thinking more process and more organization design and those kind of things, of how can I get things done effectively. [0:40:46]
Richard Rodger: [0:40:47] Rory, that is a great place to wrap things up. Certainly from a developer relations perspective, where we (inaudible, 0.40.54) with cross-functional issues the whole time, UXDX is a hidden gem, lots and lots of interesting stuff to learn, for sure. Thank you so much. [0:41:03]
Rory Madden: [0:41:05] Thank you for having me.
Richard Rodger: [0:41:06] Awesome. Take care. Bye-bye. [0:41:07]
Endnote
Richard Rodger: [0:41:08] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [41.37]