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.

In developer relations, we often talk about the three Cs: code, community and content. But how do we bring that all together? Because really, what we're offering to our users, who are developers, is a service and surely, we should design that service properly. My talk today is with John Lynch, the founder of Context Studio, and what they do is service design, which is an all-encompassing approach to delivering a service to your users.

John, of course, has worked in Denmark; he might have picked up a few things about design there. He is also on the board of the Institute of Designers in Ireland, so he knows his stuff. We have a really interesting discussion about how you can use service design principles to guide the implementation and execution of your developer relations strategy. So, if you want to know how to make your code, community and content coherent, John Lynch is the man to listen to. [0:01:20]

Main Interview

John Lynch

Richard Rodger: [0:01:21] John, it is great to have you here today on the Fireside with Voxgig podcast, talking about design and getting developers to understand design and the importance of design. Welcome.

John Lynch: [0:01:35] Thanks a mill, Richard. It's great to be here. [0:01:36]

Richard Rodger: [0:01:37] Awesome. Just to set some context – and you'll see why I use the word context in a bit. To set some context, developer relations is the thing we're talking about, and we've asked you to come on board to talk a little bit about how to integrate design thinking into developer relations. Because as a developer – you were a developer once, so you will understand this experience as well. A lot of our jobs these days are integrating third-party services, working with APIs, working with SDKs, trying to read documentation.

And our experience as developers, of that process and of third-party services as a service is pretty painful. And we've all seen that when Stripe came along and had a really big focus on design and on developer experience, that it was a core element of their success. So, that's our topic today. But first, just for our audience, it might be interesting to understand a little bit about your business and what you actually do, because it's broader than just design for websites. [0:02:58]

John Lynch: [0:03:00] That's right. And I'm glad you said that, because I usually have to start with saying it's broader than just design for websites. Context Studio is based in Dublin; we're about four years old. And I founded the company with the goal of bringing the impact that I saw design have in other economies back home, because I'm originally from Ireland.

And we do service design. People ask me – without fail, they ask me, "What is that?" And what I like to say is, it's aligning – making sure you understand, not just your customer experience, which I tend to talk about as UX – it's what people are using on the front end of your service – but also how you design the backstage services that enable that experience.

And the chat we had just before we came on is that if you walk into a shop and someone on the staff pays no attention to you whatsoever, and then when you finish your transaction they throw the receipt at you, it's not necessarily because they're a bad person. But maybe the service hasn't been designed to enable them to fulfil the needs that that service requires. So, we do a lot of research in understanding the context – hence the name – of the ways in which services are delivered.

And we do – then we build the innovation within that service with the teams across the board, so that everybody gets their perspective shared. And then the last piece is – and this is key to design – is prototyping, and developers love a good prototype. But to test at low cost with small numbers, make sure things are tipping over and then scale. Because if one thing characterizes services, which I think we might come back to, is how quickly they scale sometimes. [0:04:45]

Richard Rodger: [0:04:46] Yeah, and I think you're – it's important to note that the equality of service delivery, as a developer, when you're buying coffee is as important as the quality of service delivery when you're using an API. Both – to getting code out the door. [0:05:01[

John Lynch: [0:05:03] You – yeah, you wouldn’t get the code out the door maybe without the coffee. [0:05:05]

Richard Rodger: Exactly. [0:05:05]

John Lynch: [0:05:06] That question of scale is important, because when you talk about building services based on services, you suddenly have an exponential problem if there are issues there, in terms of the quality of experience, to deploy those services, because you have stacks. And an issue with one micro-API service that's providing a building block for 12 or 14 other, you end up with millions of people having terrible experiences as a result. So, it's becoming more and more important because of that exponential possibility. [0:05:38]

Richard Rodger: [0:05:39] Yeah. Just to frame it from my personal experience as a developer, building things for people and relying on third-party API's. The ones that are well-documented, the ones that are reliable in the sense that I can get good support, are going to get my recommendation to the client, rather than ones that – where it's clear that the developers themselves are not that important. It's like, here's badly written documentation; off you go. Or oh, whoops, there was downtime again, but we're not going to admit it, and doesn't appear on their status pitch.

Let's try and put some structure on how you approach things though. Do you have a framework or a set of frameworks that you use? Walk me through – I'm setting up a coffee shop – let's have a coffee shop example – and I come to you. It's a high-end coffee shop; we're talking 3fe or even worse in terms of coffee. This is my dream; I've sold my startup and I want to do coffee shops. [0:06:46]

John Lynch: Go for it. [0:06:47]

Richard Rodger: [0:06:48] Which I may well do. What framework do you use to approach that? How do you design that service? [0:06:54]

John Lynch: [0:06:56] To be honest, the coffee shop is a bit of a tired example in the service design world. It's the one everybody goes to because we are our own social bubble. But leaving it behind a little bit, we can look across all services. And it's important to ask yourself what defines a service. And my best baseline for that is a number of interactions that happen, an – and I hope you're a Star Trek fan, but a number of interactions that happen over space and time. [0:07:23]

Richard Rodger: Very good. [0:07:24]

John Lynch: [0:07:25] And what that means is, sometimes we sign up for a service as early as when we're born. I remember – I lived in Denmark for four years, and I remember someone, a migrant like me, telling me, "You know when you have a child here? They give you your social security number the moment the baby's born, and you're then part of a lifetime of service use." Sometimes we experience those things over 40, 50, 80, 90 years in lots of different places. Other times, it's, I'm on holiday and I'm experiencing a service. In the world of tech, you sign up for a service online. I got my 14-year anniversary on Twitter tweet yesterday. [0:08:04]

Richard Rodger: [0:08:05] Wow, okay.

John Lynch: [0:08:06] And they can be very elongated and maybe change over time. It's true of developers too. So, the first thing service design tries to do is understand that ecosystem of interactions over time: when they're happening, where they're happening and why they're happening. And we do that through research; we do it through talking to people, through looking at data.

A lot of mapping and visualization is involved, because one thing that also characterizes services is, they're never delivered by one person. There's always – in the case of technology. There's business analysts; there's engineers; there's designers; there's data analytics people; there's software developers. Maybe there's two teams of software developers, one for Android, one for iOS.

And what we need to do is align all those people about what is the best model we can build of what's happening and that's what mapping helps us to do. So, research, mapping, and then we start using things like co-creation and ideation to ensure that everybody's ideas – we use the creativity across all the talent to come up with the potential solutions.

In the case of APIs and documentation, sometimes it's as simple as raising the bar from "it works" to "it works for more people." And that's what that framework allows you to do, because you understand who's using it, where they're using it, what they're looking for. And then you get the ideas out in a format everyone understands, which helps everyone solution together in order to find the way forward.

And then the last piece of that framework, Richard, is prototype. So, rather than just writing the doc and lashing it into the documentation, to put it in front of some people who are your users and say, "Does this work for you?" And use methods that ensure you're getting real feedback from those people, so, you can change it quickly before it scales. So, that would be a bit of a summary, while the coffee is still on the brew. [0:10:11]

Richard Rodger: [0:10:13] It sounds like it's a process that needs to run continuously. [0:10:18]

John Lynch: [0:10:19] That's absolutely true. So, one of the things I try to do – with every project we engage, we like to try and do – sometimes we literally do live learning work where we join a team and work with them on a problem in the hopes that when we leave, they are the design services exemplar. But we always try, no matter what the work is, to ensure that when we're gone, the team can continue to do that iterative process.

And there's lots of overlap here with agile and things that developers are really familiar with. But services never end, and therefore service design never stops, because you – there's a great – allow me to just indulge for a moment, but there's a great quote from Jeff Bezos from the launch day of the Kindle, which I think was 2012.

And he's launching a gadget, but he said, "People don't want gadgets anymore. They want services. They want services that get better every day, every week, every month, every year." And he said that on the day he launched a gadget, which was really strange. But then if you bought a Kindle that day, it's better now, because you've got so many services that it's the window to. [0:11:30]

Richard Rodger: [0:11:31] I never – that's interesting. I never knew he said that. It ties in with something else that happened at Amazon years ago. And it's strange to be talking about Jeff Bezos as the poster boy for design thinking. [0:11:42]

John Lynch: [0:11:44] Yes, that's true. [0:11:45]

Richard Rodger: [0:11:47] Usually, it's the other fella. But part of the reason that Amazon web services are so successful is hardline decree that Bezos made years and years ago, that everything had to be – all the internal technical capabilities had to be delivered as services that could be exposed to the public. And there's actually a very famous article about it, an internal memo that got exposed by accident, by a guy called Steve Yegge; it's quite famous in developer circles.

But that simple decree – I'll send it to you – that simple decree – and we'll post it in the notes as well. That simple decree ultimately led to Amazon Web Services. Now don't get me started on the developer experience of Amazon Web Services. There are lots and lots of startups making good money, simply providing a well-thought out, well-designed experience layer for Amazon. But that's an ecosystem. [0:12:54]

John Lynch: [0:12:54] But that's true too of – this is not new news. When you look back at things like SAP, years ago, there was an entire economy built around helping integrate the systems they provided. And the really large technology consulting firms are the ones who, from 2012 onwards, were buying service design consultancies all over the world.

I sat in my own studio and I worked for CID in Copenhagen, and watched the news stories come in; every three or four months; another service design studio was bought. And it's because they saw the relevance of that, that the framework could assist in helping teams understand services so that services could be improved perpetually. Using your own references earlier on; it doesn't – it can't stop. [0:13:45]

Richard Rodger: [0:13:47] Tell me about Denmark, because it has a reputation for having –they're good at design. How did you – was that deliberate or – [0:13:54]

John Lynch: [0:13:55] It was through a friend. I studied multimedia in DCU, and it was a good friend of mine, Kevin Cannon, who's now working in design at a startup in Germany called Pitch who some people might have heard of. Kevin surfaced a design school in Italy and said to me one day – we were in our mid-20s, and he said to me, "You know, we should be looking at the schools like this."

And the school in Italy was called Evraia; it was an original interaction design school. And they closed and then reopened in Copenhagen under the word – under the name Copenhagen Institute for Interaction Design. And Kevin went off over there; we thought he was mad. I visited, saw incredible work being done and immediately was sold.

But the real change was when I moved to Copenhagen, and what you learn is that in the Nordics, design is understood as a mindset. It isn't pigeonholed into aesthetics or pixels or fashion. But it's understood as a way to approach the creation of something new, whether it's a solution – although I have a sense that almost all design is a solution to something, whether it's a need or a want. But they really do, and it's been the case since the cooperative movements in Nordic history. I'm not an expert, but there's a culture of applying design to make people's lives better, as opposed to just selling more things or making things pretty.

And it changed my perspective. And a real a-ha moment for me was our first user research project as a student there, which found me on the streets of Copenhagen in the freezing cold in February, after that cold winter of 2010, talking to heroin users about their experience of the city, so that we could report back to the municipality about the user experience of a drug addict around the train station in Copenhagen. And that was deep-end stuff, really amazing experience.

And showed me the value – having been a software developer all the way up and just building ideas based on what my boss told me, it made me think, hang on a minute. We can learn a lot and eliminate a lot of mistakes by having conversations. And that was a massive pivot for me, for sure. Yeah, and a great place to live. And service design is not maybe recognized in the terminology, but you can see it all around you in the way public services work, in the way banks deliver their services in the Nordics, than elsewhere. [0:16:43]

Richard Rodger: [0:16:45] Yeah, we could definitely do with a bit of that. The – it sounds like there are fundamental models that most people have, that don't exist in other parts of the world. [0:17:02]

John Lynch: [0:17:03] I wouldn't be so critical as to say they don’t exist. We are starting to understand, and there's good work being done in particular in education here in Ireland and in the UK. I lived in London for two years, and the UK's national government is really great at – there's – I think there's 750 service designers in the UK's Ministry of Justice. I'm pretty sure that was the stat when I spoke to the last person I'd spoke to there last, maybe two years ago.

So, it's more common that you think. It's just the terminology. We do ourselves the disservice of changing the terminology quite frequently, and really, it's about the mindset that underpins it. For example, the Irish government launched their own design principles for government back in October. There's a real awareness of – what I – the catch-all is people centered design.: making sure you're meeting the needs of the people who use the service. And that's a moving target; that's – we're definitely on the up. [0:18:04]

Richard Rodger: [0:18:05] So, you're saying change is happening; it is starting to infuse a little bit. [0:18:10]

John Lynch: [0:18:10] There's no doubt. But it's also because it makes business sense. It makes business sense to be able to better connect with your customers in a really competitive marketplace, and in a situation where changing a service is becoming so easy. If you think about the services we experienced when I was a kid, to move your bank account was a nightmare. Whereas you can open an app now and have a digital bank account with a German bank in a matter of minutes.

So, it's becoming more and more important that that loyalty isn't because of friction, but actually is because of a great experience. And loyalty counts; if you have a community of developers who are consistently recommending a particular API, a particular service because it has a great API and documentation, that's not because of their lock-in. We're not looking at a lock-in based relationship, because that doesn't work anymore; it's very easy to find an alternative. [0:19:05]

Richard Rodger: [0:19:08] Yeah, okay. So, I'm just trying to pull this all together from the perspective of somebody whose primary users are developers (0.19.19) for an API of some kind; they have a set of SDKs. A lot of the times, what we see in our work is, the SDK's built and then that's it. And you might get occasional updates. The documentation is done and then that's it. And then that definitely doesn't get updated, because sometimes it's very out of date.

If you're lucky, you get example code. If you're lucky, there's some sort of forum; maybe it's on Reddit or Stack overflow or something. And the better ones tend to have put effort into the community and support on that level, and tend to focus on community building and running events and that type of stuff. But you can clearly feel the difference between companies that treat developer relations as a service, as an ongoing activity, versus companies that treat it as, okay, that's just a fixed part of the product. It's done now; let's move on.

And as developers, we've had to put up with it for a long time. But going back to Stripe, which is my go-to example, we had to put up with really awful payment gateway integrations – I've done a few – versus Stripe, that applied the design thinking. And it's not just, they had beautiful docs and they have a beautiful website or whatever. It's the whole experience.

Even something as simple as API keys and identifier keys in the Stripe system have little prefixes to tell you what sort of key they are, and that's a practice that I've seen adopted now in other services. As opposed to just giving you an opaque goop, you don't know what it is. But to come up with that means that they must have applied design thinking, I'm sure. [0:21:26]

John Lynch: [0:21:27] I would be absolutely certain they did. And I don't know them personally but what it comes back to for me is what you mentioned, Richard. That word – it only snuck into your story towards the end – is the word product. It's one of the most abused words.

I remember my first bit of dissonance around the word product was when I was working as a cashier at 18 years of age in a bank in Dublin for the summer, and the investment advisor started telling me about products we should sell. And some of them were pensions and some of them were savings accounts, and I was like, "They're not products; they're services. But I was an 18-ytear-old summer employee, so I couldn't object.

But we have an entire world which has come to the limelight in the last 10 years, this idea of product. And I've worked with product teams helping them do discovery through service design, because that's what the terminology in the product world is. But if you start a product company and you have a one and done mentality, then you build it, write it up and then start taking the money in – that's when your mindset will breed the experience of outdated documentation; API keys nobody understands; frustrated users who are only still with you because they're locked in five years later and they can't shift. They don't feel like they can get the buy-in in their organization to try something different.

Whereas if you start a company that is – it calls itself a product company but it is taking the service approach, to say, "We will have customers. They will be customers for a long time and we need to be there for them." And also, that the world is going to – when we launch, no-one's pressing the pause button on the planet. Things are going to change. And no-one's pressing the pause button on the internet; things are going to change. If you took the same approach to service provision as we do things like security, it'll be a very proactive type effort, instead of reactive, where you spot something that loads of people on a forum are complaining about. You know what I mean? [0:23:35]

Richard Rodger: [0:23:36] Yeah. And word – a lot of this is governed by unfortunate word choices, because the traditional VC view of startups is that you can't be selling services; it has to be a product and services don't scale. So, that's taken as a ground truth in the startup world, the tech startup world; I have to do a product.

Maybe it's time to peel back the layers a bit and say that actually, the financial model that the VCs like – the tail is wagging the dog here. Because a true product that scales – and it particularly has a very high lifetime value; the key is something they really care about – it actually has to be a service. It's not a high-touch consultancy, perhaps, but a service nonetheless, not a product. [0:24:38]

John Lynch: [0:24:39] Exactly. And it is; it's a semantics problem. I don't think we're going to change the language people use. I don't think we're going to rename the products world the services world. But I do think there's something in the mindset that is within, say a startup or any organization that they can call themselves a product company, but if there is that service mindset, the product won't – will probably evolve. And when you go past whatever round of funding and you've got whatever number of users, the needs that that service meets will change as well.

And then separately, here's the external factors like the evolution of new business models on the internet might mean that the – your product's being used. There's this wonderful diagram, which I think was created over at CIID where I studied. But it's s the stages of the service journey. How do I know something exists? How do I learn about whether I want it? How do I commit to using it? How do I learn to use it? How do I challenge that service and maybe use it for something it wasn't intended for. How do I advocate for it? How do I quit?

And then the service design mindset would try to design all of those stages. If something on the internet changes and your service is being challenged, that's not a bad thing. It could be an opportunity, and if you're not maintaining your service, you're going to miss that opportunity. So, that comes back to that perpetuity piece and keeping your research, spotting the opportunities, having the mechanisms to respond. [0:26:23]

Richard Rodger: [0:26:26] Let's – yeah, if you can give us a link or something to that service journey. [0:26:31]

John Lynch: [0:26:32] I will, yeah; I'll try and dig it out. [0:26:33]

Richard Rodger: [0:26:33] Yeah, dig it out; that'd be super interesting. You know, it occurs to me that the term minimal viable product should probably be changed to minimal viable service. [0:26:43]

John Lynch: [0:26:47] I'm not going to get hung up on the – like I said, I don't think – there's an ecosystem there. There's a world that is developing products, and that's the language that that world uses. What we need to do is talk about the mindset of a product developer. Because you could flip this on its head, and I do this quite often with students if I get the chance to teach, which I still love to do.

Look around your house and ask yourself how many services are connected to every single physical product in the room you're standing in. You can go down – so I can go downstairs now. I had – I'm working from home today. I put a wash on this morning, which we can do, and that washing machine has a support service. There's – Zanussi have a network of technicians; they have a supply chain for parts for that washing machine, and they've a distribution service. They needed to be connected to a water service and to an electricity service.

If it was a fancy washing machine, which it isn't, it would likely have layers of digital services. There'd be QR codes I could scan; there might even be a wi-fi chip inside it – it's connected to the internet – to know how best to handle my new shirt. So, in actual fact, this debate between what – is it a product or is a service, what I find more and more often is that it is a service, even if it's something you're holding in your hand. So, the two are actually – they're symbiant. It's very unusual now to find a product that doesn't have some services connected with it. [0:28:19]

Richard Rodger: [0:28:21] This – we have to wrap it up unfortunately; we've run out of time, and may return to this discussion. But a lot of the time on this podcast, we get into the nuts and bolts of how to run developer relations and manage communities and that type of stuff. But this has taken us up – this is going meta here; we're getting philosophical here about- [0:28:41]

John Lynch: [0:28:41] It is.

Richard Rodger: [0:28:41] We think – how do you think about gestalt, about the whole thing together? Super interesting. I'm going to have to process the whole thing a little bit. I can't wrap it up neatly, I'm afraid. I have to do some thinking. But wow, great, it's given me a lot to think about. Thank you so much, John. Fabulous. [0:29:01]

John Lynch: [0:29:01] It's been a real pleasure, and sorry to throw the cat among the pigeons a little bit, Richard. [0:29:05]

Richard Rodger: [0:29:05] That's what we're here for. All righty, thank you. [0:29:08]

John Lynch: [0:29:09] Thanks a mill.

Richard Rodger: [0:29:10] Take care.

Endnote

Richard Rodger: [0:29:12] 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. [0:29:38]

‍