4.7 • 53 Ratings
🗓️ 18 September 2025
⏱️ 28 minutes
🧾️ Download transcript
Although the concept of the 'citizen developer' isn't new, with the rise of AI the relationship between those building software without much technical experience and seasoned software developers is becoming more significant. That's not to say there's conflict exactly, but there are often competing interests and demands — which can lead to tension, organizational friction and governance challenges.
On this episode of the Technology Podcast, host Ken Mugrage facilitates a debate (of sorts) between Christopher Hastings, Global Tech Product Lead at Thoughtworks (and citizen developer) and Scott Davies, Head of Technology for Thoughtworks Europe (very much in the developer camp). They discuss the needs and interests of both sides, how to avoid regressing to the dark ages of shadow IT and how citizen developers can be properly empowered by engineering teams.
Click on a timestamp to play from that location
| 0:00.0 | Hi, everybody. This is Ken McGrage. Thank you for joining another episode of the ThoughtWorks |
| 0:10.5 | Technology podcast. Kind of a cool thing today. The few of us are here in our ThoughtWorks, Berlin, |
| 0:16.0 | office, talking about AI for software development, a bunch of things. So we set up a little bit of a cage match that things, people that you think, I don't know, have some controversy between them, but it turns out they actually like each other. So what we're going to talk today about is empowering the citizen developer and what we can do to make both sides actually win, if, you know, if there are sides. So got two great guests today. I'm let them introduce themselves. I'll ask Scott Davis first. Hi, I'm Scott Davis. I'm head of tech for Thoughtwitz Europe. Hi, I'm Christopher Hastings. I'm a global tech product lead. So basically what we have here is Christopher runs a lot of our research around AIFSD. And as such, click me if I'm wrong, prototypes, like lots of applications and things like that. But you don't consider yourself a developer. I am not a developer. In my background of being a developer is I took one Python class and the rest of it has been, what can I Google, throw up in a Jupyter notebook and kind of survive from there. If you ask me about anything more complicated than that, |
| 1:11.5 | I make Scott angry. Yeah. And so, you know, as a head of technology, you know, you're kind of |
| 1:16.3 | responsible for some of our technical quality and that sort of thing. There's the phrases that |
| 1:20.6 | people throw out like shadow IT and those type of thing. Does that scary? No. No, not at all |
| 1:26.6 | actually. You know, we get along well. For me, software is all about feedback, right? It's the feedback loops, getting them as short as possible. We've done it from unit tests, C, I C, C, CD. You know, we always concentrate how do I get around that loop quicker and quicker and get closer and closer to building the right thing. This is helping us do it together, right? |
| 1:44.9 | So how? I mean, if he's off in a corner doing something and then, you know, how do you get in |
| 1:49.1 | that feedback? And how is the hell is it helping it? Particularly in the space of like prototyping things, |
| 1:54.5 | these are great tools now and great tool chains. We'll talk a bit probably about tools and a bit. |
| 1:58.7 | But now we're going to a situation where you can iterate and build something that you can show somebody in minutes, right? That used to take for a fidelity like prototype. That would take days normally, you know, but like you and I can riff on something now. You can show me quick. Give me a bit of feedback. I could talk to you about some other things. And we can go again, right? And we can just keep going around that really quickly. And that used to take so long. And it also required, like, lots of synchronous time from both of us. You know, as a product manager, one of the things that I'm trying to do to communicate about, if I'm effective in my role, is not just being able to talk to whoever our user or customer is about what it is they want to build and why it's also to understand |
| 2:38.0 | on the other side of the table what's your job what tools are using how do you work how do they |
| 2:42.4 | play and the last thing on the planet I would rather do is to go read documentation about how to |
| 2:48.7 | get something working but I do need to understand those tools. |
| 2:51.2 | I need to be able to see how they work and have a mental model of that. Yeah. And it's saying, Corin the other way, right, I need to understand what goals you're trying to achieve and what you're trying to do, your business process, your interactions, all those things. But that shouldn't be a barrier to us getting going. So I think this is a way of you showing me something far quicker. |
| 3:10.4 | We can iterate and go back. We can talk about how we can make it, you know, enterprise grade. We could put the guardrails in place. We can do all that. And we can get the corporate look and feel and all those other things. But we're still talking about the happy case, right? The happy case being you and I can get on the same page. |
| 3:27.0 | But I think there is a bleeding edge of, and that we are rapidly coming into, whereas me having prototyping tools or access to, how that looks like, causes problems for people in the technical side of things because I come back and without the |
| 3:41.3 | understanding of depth I come back and say hey I made this thing it took me 15 minutes why is it |
| 3:46.3 | taking you guys so long or hey I've done this just make it like that and you go turns out you |
| 3:52.0 | actually don't know how to design anything and I go but I see it and from my limitations of understanding from my role, I'm a bit more technical than many. What are the things he needs to be aware of that, you know, I mean, this is an developer that does think I can just launch us on my own now. Well, I think there's a whole bunch of facets, right? There's the security angle who has access to data, how you control it, should it be updating it? Should it go beyond the |
| 4:14.6 | boundaries of our organisation? You know, are you using tools that are outside the corporate |
| 4:19.6 | boundary? Is our data leaking out? All those things. Usual privacy concerns. Then there's the |
... |
Please login to see the full transcript.
Disclaimer: The podcast and artwork embedded on this page are from Thoughtworks, and are the property of its owner and not affiliated with or endorsed by Tapesearch.
Generated transcripts are the property of Thoughtworks and are distributed freely under the Fair Use doctrine. Transcripts generated by Tapesearch are not guaranteed to be accurate.
Copyright © Tapesearch 2025.