Made by
Made by
Olja Rastic-Dulborough
In this session from DevRelCon London 2019, Olja Rastic-Dulborough shares her experience of bringing older software to new audiences.
Olja: Hi, my name is Olja. And I work at IBM in Hursley. It’s the biggest lab in Europe. I’ve been there for four and a half years. I started straight after university. I went to university late, did a technical degree. This is my first tech job as well. For the first couple of years, I did writing, testing, different kinds of things in the messaging department.
The team that I’m in, the team that I’m in works on developing the code for a very old product. It’s been around 26 years. And it took a while to get used to it. It’s quite complicated but I like a challenge. I’m also passionate about making things better, so immediately I was doing things slightly differently. But two and a half years in, two years ago, there was an opportunity to get involved in a new project. Our engineers found there were some problems with how our developers find out how to write code that interacts with our service, so application developers who are starting for the first time. So what does it mean to advocate for your developers when your product is 26 years old? How did it get to be 26 years old if there are problems, and it’s still really successful?
We don’t look after just devs. The way our product works, we have multiple users, we have application developers and administrators. Right back in ’93, we did start looking after application developers, and we baked in goodness from the start. So what happened? Initially, we were supporting James quite well. He liked to learn, he liked to spend a lot of time going really deep and finding out how everything works. But somewhere along the line, things changed for the developers. If developers came out of university or they were starting in the ’90s, they were used to having to learn and spend a lot of time finding out about technology, and they had time and they were measured on how well the stuff that they created worked.
But more recently, the developers that are coming out of universities are used to trying things out for a little while, and then things working. They don’t want to spend three months learning about something and then building something. They want to find it, try it, and it then works straight away. And we were having a few problems with this. We were explaining how our stuff worked, but it wasn’t easy for people to get started. So for existing developers who like our product, we would support them with new function. But for new people who needed a bit of help, we needed to accelerate their progress.
I want to share a little bit about what we did in the last couple of years, and our journey was quite organic. I’ve heard a lot of things, this is my first dev role and a first conference, but I’ve heard a lot of things in the last couple of days that made me think. And one of them was, what could I share with you guys, that I’m not just talking about myself. We’ll go through some of the things that we did, and what I think the good things out of that are. And so when we started a couple of years ago, we were quite junior team members. And the way we worked was a little bit like our developers. We were charged on how long it would take us to produce content, to produce tutorials.
But actually, we were learning. And not only were we learning, we were having to talk to lots of our stakeholders who all had ideas about how those tutorials should look. But at the same time, they were telling us, well why isn’t this happening faster? We gave you an idea of what we’re looking for, why is it taking this long? We were going through a similar journey that our developers were going through. They were being measured on Time to working code, and so we felt quite sympathetic to their problems.
So, what I had for you this afternoon is that, as I said, our efforts grew organically, and having heard all kinds of frameworks, and what you should be doing, and what you shouldn’t be doing, maybe doesn’t matter for you. You should pick out different things from what everyone else is saying. But think about what your developers actually need. Your developer advocacy might not look like anyone else’s, and I think that’s okay. I’ll dig in a little bit deeper into what we did, that maybe you might find interesting.
Let’s talk a little bit about messaging because you need a little bit of context to what I’m going to talk about. How design thinking helped us in what we were trying to do. And we actually created a badge, and that’s one thing that I’ve not heard anyone here talking about today. So that might be of interest. And then eventually we mainly worked on samples and demos. What is messaging? Or if you really want, what is MQ and how does it work? Mainly, we have a server component that is installed and configured, and then we have applications that interact with the server. And basically what this is for is moving data in messages between systems and applications; in a very low level explanation. Why am I showing you this? Because the two types of our users, admins and developers, tend to circle around– The admins are looking after the server side of things, and application developers are developing applications. And there’s something in how they’re interacting, and how things have developed over the years that isn’t quite working anymore. We’ll dig into that a little bit later. But on the higher level, in terms of what it does for business, it connects the pieces and makes everything work together.
We had a few graduates start recently. And normally when they start, we give them a project. And this time they worked on putting MQ, which works on mainframes and all kinds of other platforms, onto Raspberry Raspberry Pi Zero, and create an activation project, so that you could actually come up to it with your phone, and send and receive messages without having to write any code or do anything. But you could take it away and then actually create proper codes and write applications and get familiar with how it works. They created some comparisons with how your body works, and what happens in the same amount of time in MQ. And we thought this was quite interesting.
How did design thinking help us? In IBM, we call it Enterprise Design Thinking, because it helps us work with clients and across teams inside IBM. And what does that really mean? We focus on user outcomes. The loop is the really important thing, the Restless Reinvention. We observe, reflect, make. And we try and work with diverse teams because at that point, you get the best information and different points of view. But for us, because we’re in the engineering team, we have help from designers but we don’t necessarily adopt everything. We took a little bit of things that we liked, from Agile, from Design Thinking. And for us, Hills were the things that we adopted. I’ll talk about that in a moment.
Also Playbacks. We don’t have a budget. We’re not a typical devrel team. We’re looked over by the engineering team. In Playbacks, we have one every week, and it gives us time with our stakeholders so that we can tell them what we’ve been thinking about, what we’ve found out, what we’d like to work on next. And very quickly, we get feedback on whether they think it’s a good idea, can we explore more, or do we need to move onto something else. And obviously, because at that point, we weren’t yet talking to actual developers, we had Sponsor Users. These are the users that we are targeting, but ones that we had access to. They would be mainly graduates and recent graduates who joined us and they would help us, and we would test everything that we were doing with them. We also worked with, I mentioned, we have design teams. And we worked with them, and with other engineers, to come up with different kinds of personas for our products. These are all the personas that we have for messaging. And for us, James and Andre are the most interesting ones.
So how do you start with design thinking? We start with empathy. And let’s remind ourselves what empathy means. So it’s putting yourself in the shoes of your user. Although we’re often told you are not your user, but it’s good to imagine how things work for them, and to understand what their problems are. But practically, we work with empathy maps. We try and figure out what our users say, think, do and feel. And that really helps us understand, when we start building solutions for them, how best to go about it. And we keep this in mind, when we try to create a better experience for them.
I mentioned Hills earlier. These are statements that we set to ourselves after we’ve been through design thinking processes, so that we can have shared understanding between different stakeholders so that everyone knows what it is that we’re working on, what we’re working towards, and what the mission is. And so from the very starting point, when we were trying to figure out what we wanted to improve, we wanted a developer to be able to understand a little bit about MQ and start a sandbox environment and start a sample application. And then also in an afternoon, that was in two hours, but in an afternoon, they’d be able to write an application in the language of their choice. How did we go about it? We created a platform. It wasn’t anything very complicated. And however complicated it got, we would strip down the more words, the more pictures. We literally kept taking 50% of the content away, 50% of the pictures, that we thought initially were great, and they were helping the user to understand absolutely everything. And then we put these things in front of some of the users, and they would go, “Oh I’m not reading all of that. “That’s just too much.” So every time we did tests, more stuff would go away, and we would cry.
What did we help them to understand? Just the very basics about what our messaging is, what MQ is. How they can stand up and setup, without understanding everything that admins have to understand. And we gave it to them in Docker, with some default configuration in there so that they didn’t have to learn everything. And then we really started with Java because that’s where our traditional developers live. We created the first tutorials for walking through all the code, what you need from the library, so that your application can connect to MQ. We did it in a secure way, and then we carried on adding value to these tutorials.
At this point, which was about six or nine months in, we were getting good feedback through the websites, and through some events, but there was this hard audience that we really wanted to put it in front of, and it wasn’t developers yet. It was actually admins. They came in for a user-group meeting, and these are quite scary people who know probably more than all of us in the room. And we try and tell them about everything new that’s happening. But also we weren’t sure how this was going to go. We asked them some questions, what they thought problems were when developers deliver codes. We tried to get them to empathize with developers. Why would they deliver such bad codes, that then wouldn’t work? And we didn’t think they were going to engage with the process but they went all out. And we got so much that it took weeks to deconstruct. But what comes out of it? When we tied it up, and we worked with our designers to understand what things are coming out of it. And this is then how we drive the work. We drilled down into what’s important. Maybe spend a week or two on each of the things. And then decide whether it’s worth pursuing or if it’s something that we drop.
In this case, we thought that it would be cool if we could give some street cred to developers, so that when they could talk to their admins about the problems they were having finding their message if something went wrong. Because admins constrained things quite well. Because when they configure their estate, they don’t want anyone messing with it. They’re not going to let you near production, they’re going to give you the minimum information that you need. And then that starts to cause conflict. We went and had them create a badge. We didn’t start from scratch. We had some materials from the LearnMQ platform, that I started with before. But we started really simply, which sounded quite weird. We started with questions, we went around our team and asked everyone what they thought the questions would be for developers to learn. What they need to do in order to have some street cred. And then we worked through what we already had, checked the things that we didn’t have, create some more material. And we created a challenge for developers to actually go and look at some codes. We did it in such a way that they would have some backup and troubleshooting. And we put those samples in GitHub in three ways, so that if they didn’t really want to get their hands dirty, and code it from scratch, they could fix some bugs. And this really started working.
Now initially, we thought, okay so most of our team is going to take this up, because this is how we learn in IBM. If you do badges, that’s how we do our education. We expected within a year that they would be maybe three to 500 people taking the badge. And that was going to be our success. As of this morning, we have 1,235, and it’s just been over a year. This has been really successful for us, and we keep tracking it and we report on this metric, because it’s gone wildly beyond what we were expecting. And the amount of work that it initially took, it was very strategic, it took like three weeks. It was amazing. But this helps us, when we then talk to developers, when we talk to admins. People are taking this up, and we are now talking to students, taking it to universities, and possibly doing customer workshops.
Having come up with this success for our small team, we thought, what do we work on next? Mainly, we concentrated on Java with all our samples. But we thought it would be useful to widen our horizons and create more samples in five different languages. And we touched three of the APIs. What does that mean? There’s these things called MQ Verbs, and they tell you how to interact with the server. And we often say it’s a very elegant API. Only has 26 verbs, and then you can do everything with those. But what people don’t tell you is that, behind each of those, there is like a Library of Alexandria, of material that you have to go through, in order to understand what you need to do. And for admins, they understand all of this, they know how it works. But for developers, they see this, and they tend to move on to something else. It was really useful and hard work to begin with. But we came up with all our samples and all the patterns, in different languages. And they’re consistent. You can send a message in Go and pick up the same message in Python. And we did ship samples before, of course, but you had to download the server in order to get the samples. This was freeing goodness out of the existing development, and letting developers play with it.
How did we do this? We picked some of the basic patterns, and obviously we started with Java because we wrote a lot of our initial material for JMS. But then we also touched our MQI, which is the native API. And we have thin wrapper libraries for Go and Node. And we also have a third party contribution in the library that is quite popular. And we went through and coded all these samples. How it worked in practice is that, we would start with Java, we thought we’d finished, test it, and put out Java. We’d start on, I think we went and worked on Go and Node. And we were finding new things out about how things worked with these new languages. And we’d find out more about the MQI. And then we would go back to the previous language, make changes, and then start again. We went in circles quite a lot, but that meant that all the samples are quite well tested. You can literally take them. They’re not supported in production, but they’re quite close to what you’re likely to need, if you start coding.
And the way in which we worked, although we’re surrounded by experts, and developers who developed MQ, they know how everything works, we wanted to go through the pain that our developers go through, and not ask too many questions. We’d ask for pointers initially and say, okay, so we’re going to do this, just tell us roughly how it’s going to work. And then we would go away and try and see if we can get to it ourselves from what we could find online, or what we could google, or what we could find in Stack Overflow. And we wouldn’t actually ask for more help until we would spend two or three days not being able to do it. But what that meant was that we could find all those pain points that other people were going through, then document them and create better samples, and explain things that we really found difficult. Like sometimes, it was setting up your environment, it wasn’t really a problem with the samples. And it worked out and they’re reasonably popular. And they’re helping us move along our journey.
I want you to remember what I said earlier. Your developer advocacy might not look like anyone else’s, and that’s okay. Ours was messaging. We used some enterprise design thinking. We created a badge. And then samples in five languages using three APIs. We have more, by the way. So where did we start? Where did we end up? Where are we right now? Initially when our developers would be told they had to use MQ and write applications that would interact with MQ, they would start. And this is our happiness curve that we mapped out from the experiences that people told us they were having. So they would start, and they thought, oh yes, I can do this. They would come across concepts. Start their sandbox, maybe get some working code. They would be really depressed, but hey, they’ve pushed something into production. And then they have to debug it, because the admin would return it to them. And then maybe eventually they would deploy it. And we didn’t think this was a good representative experience to have. What we tried to do is to provide materials, samples and tutorials, that would lift those developers and improve on the happiness curve, by targeting specific parts of the journey where we could actually help them. And at the end of it, they would have some skills and some street cred. And we were happy and hopefully they were getting happier.
So what are our next steps? We’re doing uni workshops. We’re taking our badge as a workshop to universities because we found that most of the graduates who come to us to work have never experienced messaging in their courses. At the beginning of the evening, they don’t know what messaging is. At the end of the evening, they have a badge. They’re going through our developer experience. We’re hoping to do those for developers. We’re slowly building up to developer workshops and meetups. We’re looking more at cloud native apps, and how we can work on those. And this is the first conference we’ve been talking about our work. We want to do more of those, and actually maybe drill down into some of the technical stuff. I don’t know how we’re doing for time. I think I’m over, maybe. But that’s all I had. And thank you for being a patient audience.