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 am speaking to the developer relations team from askui.com, Johannes Dienst and Apoorva Tewari. This episode is a kind of case study for how askui.com has engaged with their developer audience. They provide a locally installed tool to do automation for your applications. That represents some interesting challenges, because you have to get the developer to install and run your tool locally. 

‍

And the other interesting thing that we discuss in this podcast is how to execute a remote online hackathon that runs over multiple days. If you've ever run hackathons, like I have, on location, it can be stressful, because will everything actually work across the wide range of machines that people bring. 

‍

But when you do it remote and online over a number of days, everything can be much more relaxed, much more easygoing. You have time to support the participants, and you can get a much wider range of participants and more participants. So, I think that askui has done some really great innovation here, and it's well worth listening to the approach that they've taken. All right, let's talk to the team. [0:01:27] 

‍

Main Interview

Johannes Dienst and Apoorva Tewari

‍

Richard Rodger:  [0:01:29] Welcome to the Fireside with Voxgig Podcast, talking about developer relations. Today, we are talking to askui.com and we actually have two guests. Johannes and Apoorva, thank you so much for coming on and talking to us about askui and developer relations. Welcome. [0:01:45] 

‍

Johannes Dienst:  [0:01:47] Hello, Richard. 

‍

Apoorva Tewari:  [0:01:49] Hi, Richard. 

‍

Richard Rodger:  [0:01:50] Hi, how are you doing? Okay, so first of all, we are going to approach this one as a kind of a case study of askui. Because your product – and you'll have to go through it and explain it to us in detail in a minute, but your product is very much aimed at developers. So, you sell by doing developer – by executing on developer relations really well. 

‍

So, for this one, it makes sense to do a deep dive into the nature of the product, the specific challenges that generates and how you guys are doing. And I'm really fascinated to get into it, because you're not just doing an API, but I will let you guys explain. So, first of all, what is askui; what does it do? [0:02:42] 

‍

Johannes Dienst:  [0:02:44] I will start with the product description; that's what I do all the time. Apoorva can iterate on the community side, because we have an active community there. askui, I joined askui last September and it was really intriguing what askui is doing there. There are two parts to askui. 

‍

First, we automate the operating system, like real mouse movement, key presses, also recording your screen, what you see on the screen. And then there's another thing, so you have the end user interaction, like a real user would do it. And then you have the second part where we say – when you want to automate something, the usual approach is, we go over the structure. 

‍

If you’re automating in a web browser, you go over the DOM tree, [inaudible] Time: 0:03:33, or if you activate something in Windows, you can extract something from the structure of your application. If you're going on Android, then you have the hierarchy, the view hierarchy, it's called, I think. 

‍

That's not what we're doing. We are recording the screen, trained a model, an AI model, to recognize all the elements on a screen. And then you can say, "Okay, I want to click the button That has the text login, for example. 

‍

And what this enables is, together with the operating system automation, is that you test like a real human user would. And you can test stuff you cannot test at the moment, for example, mobile apps or native window apps or legacy systems, like if you have a remote desktop in a browser, where you can't extract the structure of the application you're automating. So, that's what askui does. [0:04:35] 

‍

Richard Rodger:  [0:04:36] Yeah, that is pretty cool. I have worked with tools previously, mostly with websites, where you have to specify the DOM structure. And the moment you change your design, that's it; all your tests are broken. And most people give up and they don't do that sort of testing or automation. 

‍

I really like the idea. This is an example of something that AI now enables. It's not crazy writing the entire code for your application, but something specific and vertical like this, where – and can you specify the tests once and then they can be reused for different platforms? [0:05:14]

‍

Johannes Dienst:  [0:05:16] Yes, that's the promise. [0:05:18]

‍

Richard Rodger:  [0:05:19] That is very cool. [0:05:20] 

‍

Johannes Dienst:  [0:05:20] If it holds true, so if you have a single-page application and you can use it as an app, [inaudible] Time: 0:05:25, and it looks the same and the buttons don't change too much or the text fields don't change too much – the user interface – you would say, then you can reuse it. So, you can use one tool to automate everything. [0:05:37] 

‍

Richard Rodger:  [0:05:39] So, who do you – how do you guys make money? Who do you sell to? [0:05:41] 

‍

Johannes Dienst:  [0:05:43] Yeah, that's an interesting question. It started out two years back with a tool. Our CTO said, "Needed this tool all my life and now we're building it." And we started out as a testing tool, as a no-code testing tool; then we changed to a code tool. It's JavaScript/TypeScript ecosystem. And now we're building again the no-code tool because we saw individual developers have a hard time selling this to someone, and at the moment, we're targeting enterprises. [0:06:17] 

‍

Richard Rodger:  [0:06:19] Okay, so do you look to get the developer in the enterprise to start using it and then recommend it to their boss, or do you sell directly to the boss. [0:06:28] 

‍

Johannes Dienst:  [0:06:29] I would say it's both. We have people coming in, "They, that's interesting. I could automate stuff I couldn't before," And then they're building a proof of concept and going to their superior CTO/manager; that's how it works. And we also do sales, of course. [0:06:44] 

‍

Richard Rodger:  [0:06:46] What strikes me as a challenge for askui is that -- for example, if I'm trying to choose a payment provider, I already know the -- the value proposition is already there. It's clear that I want to be able to take credit card payments. So, I know that I'm going to be using an API or a credit card widget or something like that. 

‍

With you guys, I have to install your solution first, don't I, and I have to use it to see the value. And that's a challenge, isn't it, because unless you can get it into – onto the developers' machine, it's very hard to – for them to understand what -- the value that it provides. [0:07:32] 

‍

Richard Rodger:  [0:07:34] Yeah, that's correct, and we are still working on that, because automating operating systems is not as easy as it sounds. For example, if you're on Mac OS, there – Mac OS is very restrictive with the rights of screen recording and accessibility. You have to grant our UI controller the rights. 

‍

And there are also specific things you have to remind yourself about the different platforms, like Android, Linux, Windows. That's why we're building the no-code tool, to make this a little bit easier, but I'm constantly on the lookout for pain points; that's what I do all the time. And trying to help your developers, our users, with documentation. [0:08:17]

‍

Richard Rodger:  [0:08:19] Yeah, because it's – there's a slightly more difficult pathway. I can't just go to your website and sign up and then I'm done. I need to install it and I need to run it a little bit. But that sounds like something that I'm just running myself locally. So, do you have a hosted part of the product? How does that work? [0:08:43] 

‍

Johannes Dienst:  [0:08:45] Not anymore. At the moment, it's local installation; that's what you do. You have to install it on the system you want to automate. It can also be a remote system; it can – it's installed as a web service, so you have to install it. [0:09:01]

‍

Richard Rodger:  [0:09:02] Okay, and is the piece that you install open source or is that closed source? Could I just install it locally and then not pay you, for example? [0:09:11] 

‍

Johannes Dienst:  [0:09:11] Yeah, the problem is always with AI that you have a big model there, gigabytes of training data, and the model has to run somewhere. At the moment, we cannot run it on your local machine, so you have to connect to our cloud environment. But it's for 500 – instructions, we call it. It's free; you can try it out. 

‍

And we also have a Gitpod repository; just want to plug in Gitpod here because it's such a great thing. Shout out to that community and that product. Where you can just spin our Gitpod environment and see how askui works without registering or logging in [Inaudible] Time: 0:09:51

‍

Richard Rodger:  [0:09:52] Okay, so I get it. There is a local tool, but it's useless without your hosted AI model. [0:09:58] 

‍

Johannes Dienst:  [0:09:58] At the moment, but we are based in Germany and enterprises always demand, "We need to host it on premise because of data privacy, European data privacy regulations. [0:10:07] 

‍

Richard Rodger:  [0:10:08] So, you also provide an on-premise solution then, the whole thing. p 0:10:11] 

‍

Johannes Dienst:  [0:10:12] Hopefully, yes. 

‍

Richard Rodger:  [0:10:14] Okay, cool. So, let's – clearly, you need to get developers onside; you already said getting developers to use it at first is one of your routes to market. Even if you go to the big boss, the big boss will certainly, I'm sure, ask their developers to evaluate what you're doing. But your solution is – there's a little bit of complexity. So, how have you developed your developer relations strategy to overcome those challenges? [0:10:44] 

‍

Johannes Dienst:  [0:10:51] The first thing when I joined was – okay, we're not represented enough. There's this – I think it's called awareness; I always get this wrong. So, you have awareness and then some on the developer journey, they have to know that you're there. That's what I'm working on. 

‍

And then I realize, we need better docs; we need more explanations on how we work. That's – and at the moment I'm focusing on this. We are not at the scaleface, I would say; like someone says, "That's the right solution. I want to roll it out to every system we have." That's not where we're at right now. [0:11:25] 

‍

Richard Rodger:  [0:11:27] And are you guys doing things like community building or sponsoring open source or that sort of stuff? [0:11:33] 

‍

Johannes Dienst:  [0:11:35] Yeah, that's where Apoorva comes in. [0:11:36] 

‍

Apoorva Tewari:  [0:11:40] Yes, absolutely. So, Richard, when I joined, before Johannes did, there was a community that we started called Automation Advocates. We are now underscored with more than 1.5K members, community members. And all of these members are either our users or have used our tool or are interested in using our tool. Or they are in generally interested in test automation, so that they can learn with the new resources or they can learn new technologies that are coming in the market. 

‍

And the community that askui – powered by askui, is giving their members platform to – a space to come and attend the online meetups. We – myself, I'm the manager of the community and Johannes takes a workshop, conducts workshop every month with the community members. We get around 60-70 members' participation each time for each event. 

‍

And through these events, the members feel empowered and use – somehow get their hands on the tool and give us feedbacks. We also try to get good speakers who are in the test automation industry, so that they can share their experiences, their insights, and sharing knowledge. And generally sharing resources to the participants or the members of the community. 

‍

It's – the community stands strong and we are growing each day. Just yesterday, we had a no-code tool – glimpse of the no-code tool workshop facilitated by Johannes. And each month, there's 3-4 events that we host, on demand as well as on the latest – whatever is going on in the market, trending, we just make sure our members get their hands on of that. [0:14:22]

‍

Richad Rodger:  [0:14:24] That is a lot of activity, which is quite great for – you guys are still an early stage startup, so to have developed your community to that level already is really cool. When it comes to running the Discord community, do you have any insights for people who are thinking of running one? Do you have a schedule of monthly activities? Who checks in each day? How do you do moderation? Do you have a specific approach to keeping that community healthy? [0:14:57] 

‍

Apoorva Tewari:  [0:14:59] Yes. We tend to be more organized, in a way that we have our own schedule of posts that we want to share it with the members each day. There's virtual coffee meet, which is irrespective of any technical topic. You just come in each month; talk to the follow participants; get to know each other; make friends; make connections.  Get – make sure of that platform to learn something new or maybe share something that you recently discovered or learned with the other members. 

‍

We have created a schedule of posts, schedule of activities, and moderate that every day. Johannes and myself, as well as we have another colleague, Ron – shout out to you as well – all three of us be there for the community members, dedicatedly giving resources, sharing the insights, bringing the top speakers from across the globe to talk on the topics they request, the members request us to. And that's how we do. 

‍

But initially, when we started with the community, we were on the platform Slack. And when we migrated to Discord, there were a few – every time, when you see there's – when you start using a new tool, that the balance becomes disbalanced. The balance of the whole thing changes. And initially, there were those days, but we were consistently providing to our community members. 

‍

And thanks to the consistency that our team has given and even the members were there since starting and just growing. So, the main goal is to take the community along with the company's growth. You just can't leave the members who were there initially and not provide and not give them the support they need when the time is right. [0:17:28] 

‍

Richad Rodger:  [0:17:28] Yeah. Because they, at the early days, they were part of the – they're the reason the company is- [0:17:32] 

‍

Apoorva Tewari:  [0:17:32] Of course, absolutely. 

‍

Richad Rodger:  [0:17:33] It sounds like it's a lot of hard work. You can't just have a Discord server and that's it, and just – everybody talk amongst yourselves. All of you are putting in – three – that's three people are putting in significant moderatorship and activity into that community to keep it healthy. 

‍

The other interesting thing that you mentioned, which has come up a few times with other guests, is Slack versus Discord for community chat and online communities. You guys were originally using Slack and then you moved to Discord, so I'm interested in that; why the decision to move? [0:18:19]

‍

Apoorva Tewari:  [0:18:21] The decision was based on a lot of data, a lot of surveys that we conducted to our participants and the members – active members of the community. But the – it's always – you need to make changes in your life in order to find out what fits. So, for us, Slack was there, but it wasn't that right fit. We were targeting the – the target audience for us was developers and who are constantly building apps, or the testers who are constantly trying to test something new out of curiosity. 

‍

Looking at the target audience, we decided to – let's try and change our approach; try a different platform. And let's – since we were an early-stage startup even back then, we thought of taking the risk, and it works out for us. And that's why we are now on Discord. But we just don't know this is stable. After a few months, we decided to – let's move on to Discord or something; we just don't know. But let's keep changing and trying things out. What fits bests for us is what we will now take in the end. [0:19:53] 

‍

Richad Rodger:  [0:19:55] Yeah, that's good advice, and quite brave as well to say, "Let's move our whole community from one platform to another." So, well done; I'm glad it worked. Before we came on, we were talking a little bit about – you guys have had quite a lot of success with Hackathons. So, do you want to talk about that, how you guys have used hackathons and how to run them really well and get great results from them? [0:20:19]

‍

Apoorva Tewari:  [0:20:21] Absolutely. Hackathons, we are still trying to learn to make a bigger success in our events series. Because it is also one – part of a yearly or quarterly events series that we do. Hackathon initially started last year when we were a really small team of maybe 5-6 people overall. Johannes just joined the team back then, so he wasn't that involved. 

‍

But we did start out as a fresh company; people didn't know about it, about us a lot from across the globe. We prepared the list of tasks that we want to – initially, what goal we want to achieve out of the hackathon, or what in general, why we are conducting the hackathon. For us, the goal was to have more outreach; people should – even though it's just because of hackathon and just because they will get a few bugs in their pocket, they are using our tool. Let whatever be the reason; people should start using the tool in order to make – get idea what we are doing. 

‍

So, that was the goal initially, and we did have a good number of participants. We did get a lot of results out in the first time after the first time. There were very much interest from across the globe, majorly from Asia, from the US, from Europe, everywhere. They had around – more than 100 participations. 

‍

And those things kept us motivated, because even though the goal was to make more outreach, it was also that we get more feedback so that we can keep improving our product. And Johannes, you can also pitch in how you felt, how – after the second hackathon we hosted this – a few months back. 

‍

It was way more successful than the previous ones, way more collaborative, way more – the results were even better; the feedbacks were even more great. We did get a lot of self-help from various developers to our developers so they can build the tool even better. So, why don't you speak about that, Johannes, what you think about the latest results that we received? [0:23:17]

‍

Johannes Dienst:  [0:23:19] Yes, as a developer advocate, you're advocating for your users, for your developers, and you're always hungry for feedback. And feedback is hard to get by, as any dev rel professional might know. A lot of times, users just get frustrated and leave, and that's what developers usually do, myself included. When I try out a tool and I'm so frustrated, I don't want to write a two-page essay on how the tool just sucks for me. That's not what I would – people usually do. 

‍

So, always hungry for feedback, because you need the feedback to compile it into a priority list and then go to engineering, to go to product and say, "Yeah, that's the main pain points." And the fun thing is, a lot of the times, engineering isn't even aware that that is a pain point. I remember a meeting where we talked to our AI model team, and at the end of the meeting, Johannes, who's actually the lead there, said, "That was really helpful to get the user view, user experience in there, so that was really helpful, Johannes, thank you." 

‍

And that's what we as developer advocates actually need, so if we don't get feedback, that's not what we want. So, a hackathon is always nice; it's intensive. You get a lot of bug reports; you get a lot of suggestions. And you can use this to make the product better for your users. That's – especially the second hackathon was a huge success in this way for us. [0:24:55]

‍

Richad Rodger:  [0:24:56] Yeah, it sounds like what you guys get out of the hackathon is really intense, really dense information back about the product and how people are using it. I remember running one myself years ago for a docker-based tool that we were building, and people turned up with Linux machines and windows machines and Macs. 

‍

And of course, we only built our product on Macs, so it didn't work on Windows and half worked on Windows. It was very embarrassing. How do you deal with that? Because when people turn up to hackathons, they've got this wide range of systems. Did you validate that your tool worked quite well across a broad range of systems, or did it show you interesting bugs? [0:25:44] 

‍

Apoorva Tewari:  [0:25:47] Well, there are lots of prerequisites needed before the hackathon to make sure that the participants don't face issues during the – it's also about the time you're giving to your developers to develop the whole tool or to develop their project. We – initially, we started off by giving only eight hours of time to – for the participants to develop, and develop the project. 

‍

And the drawback that those one day or a few hours of hackathon is that you can't ensure that your participants will have – it's not that traditional hackathon anymore. Earlier, in those days when there were offline hackathons, when people used to come onsite, be there for three days continuously without food. And then there were food given, but it sounded that it was more intense three days' continuous hackathons. It's no more the case these days; it's just people be wearing their own pajamas, sitting chilling on their own sofa and coding for hours on their own time. 

‍

We give them the timeline, maybe 10 days or 20 days, or depending how the theme of the project is. And we give them the prerequisites, telling them that whatever they're doing, they need to do with the tool that we provide, the library that we provide, askui; build a project, make this theme. 

‍

If there are more questions during the time they are building, our developers are there during our business hours to help them. Maybe get on a call with them or create a thread with their questions and we'll be there to help you. So, it's all a lot of step-by-step process and a lot of team dedication and hard work. And it's not, definitely not a one-person or a one-man army's job. It's the matter of creating a whole structure, project, and running it in front of people around you. [0:28:22] 

‍

Richad Rodger:  [0:28:23] This is really interesting. So, you guys have – you've reimagined the sort of in-person hackathon or workshop that you'd see at a conference into a multi-day remote online event, which sounds much less stressful. Did you guys come up with that idea yourselves? Did you see other people doing it? Was it just that you thought that was the only way to do it now, post COVID? How did you it – how did you come to the decision to run it in that way? [0:28:51] 

‍

Apoorva Tewari:  [0:28:54] I come from a background of hosting events, even back then when I was a developer. I started my career as a developer and I still was volunteering, during my free time or my weekends time, to host workshops or host hackathons, lead a meetup. So, I have seen the pain points and struggles of these participants when we – those were the days before COVID, when I was there to help another lead or facilitator of the workshop or hackathon to help them organize the hackathon. 

‍

And I was able to see how people left their home and came on site to code for three days. I was able to see them having dark circles. I know it's fun; it has a different kind of fun and interest among people or participants. But at the same time, it's also – when you see people are working from home on their own sofa, you also want to have more relaxed way of enjoying the competition that you're taking part in. We – when I joined askui, I made sure that we are not going to do the authentic way of any event that we do. 

‍

So, I spoke to Johannes about it that we're not going to have an intense three days or two days or any kind of hackathon like that. And Johannes was so supportive and he said, "Do whatever you feel is good and try out if it works." It's – if it doesn't work, we'll improve or if it works, it's way better." So, we plan in advance that it's going to be more relaxed; it's going to be more care for the people and not for the time or those things. So, it was more relaxed and flexible. 

‍

Even I would highlight that the recent hackathon we did, we did have the deadline, for example, 10th of March. But because there were a few participants who requesting us to postpone a bit for a day or two, we were able to do that. Because the participations matter to us more than the timeline and those things, which are more strict. So- [0:31:43] 

‍

Richad Rodger:  [0:31:43] I just love this; this is so cool. I've never participated in a remote one; I just think it's such a good idea. I'm going to be – I have a few startup friends doing more traditional SaaS things with APIs and platforms who – I'm going to be telling them about this idea, because it sounds really cool. 

‍

And a much better experience than mine has been with physical hackathons at conferences and stuff like that. Wow, I'm really impressed; that is a fabulous idea. And almost obvious, but it sounds really wonderful. How did you get the participants? Where did you find the participants? [0:32:25] 

‍

Apoorva Tewari:  [0:32:28] Participations from across the globe was from word of mouth, from the advertisement we did or from the network we built through the community events. So, the community events played a major role in getting the participants, because we – until now we are known by the people who are in the top list of the test automation or testing industry. 

‍

So, we – they know what askui does; they know what automation advocates are who these people are. So, those played a major role, because they were the ones who kept sharing our hackathon posts with – across their network. And it helped us get participants from across 69 countries, and it was one of the major successes, I would say, for our hackathon reset. [0:33:32]

‍

Richad Rodger:  [0:33:32] That's amazing. Yeah, that is – that's fabulous. I think Johannes and Apoorva, askui is a model company for showing how a startup, an early-stage startup, can benefit – especially one focusing on developers – can benefit amazingly from putting resources and time and strategic focus into developer relations, and get these amazing results and engagement. Wow, it's really impressive. [0:34:01] 

‍

Apoorva Tewari:  [0:34:04] Thanks, Richard. 

‍

Richard Rodger:  [0:34:07] I'm afraid we have run out of time, unfortunately. I'd definitely like to go into all sorts of more details about the hackathons. But I think we've enough information, just from what we've already discussed and the results you've seen. And certainly, if you're listening to this and thinking about emulating this hackathon idea, I would say go for it. It sounds like it was a really big success. Johannes, Apoorva, thank you so much; it has been great talking to you. [0:34:34] 

‍

Johannes Dienst:  [0:34:36] It was our pleasure. 

‍

Apoorva Tewari:  [0:34:37] Thanks, Richard. Always pleasure, yes. [0:34:38]

‍

Richad Rodger:  [0:34:39] All right. Best of luck, guys, we will keep an eye. Askui.com, one to keep an eye on. All right, thank you so much. Bye-bye. [0:34:45]

‍

Apoorva Tewari:  [0:34:46] Great. 

‍

Johannes Dienst:  [0:34:47] Bye-bye. 

‍

Apoorva Tewari:  [0:34:48] Bye. 

‍

Endnote

‍

Richard Rodger:  [0:34:49] 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:35.15)

‍