Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Android | TuneIn | RSS
Maaike Groenewege began her content career in technical communication. She is now a leading voice in conversation design for AI.
Maaike draws on her technical writing background in her conversational AI practice, having observed that whether you’re writing for humans or designing prompts for LLMs, you have to truly understand your audience and consistently provide clear and specific instructions.
We talked about:
- her work over the past couple of years as a prompt designer
- how the instruction design principles from her days in technical writing and technical communication prepared her for her current role
- how her early exposure to help desk duties prepared her for the many question-answering responsibilities in her current role
- how her writing skills, her critical approach to generative AI, and her love of technology combine to give her a unique perspective on conversational gen AI content
- how retrieval-augmented generation drawing on high-quality content datasets can help set a base level of knowledge for LLMs
- her opinion that conversational chatbots are a transitory stage on the way to transactional chatbots that can provide self-service problem-solving
- the workflow for incorporating retrieval-augmented generation into LLMs
- the similar meaning of the concept of “chunking” in technical communication and LLMs
- the differences between how LLMs process language and how humans read – and the implications of this for prompt design and engineering
- the emerging structure for prompts: assigning a role, describing the task, providing a context
- the differences between conversational prompting, prompt design, and prompt engineering
- how she works with her engineering partners
- the difference between the logical inference that knowledge graphs do and the statistical inference that LLMs use
- how she keeps up with the rapidly changing developments in her field
- her invention: ALIs, application language interfaces
- how she uses ChatGPT in voice mode to capture and summarize her thoughts when she’s out for a walk
- her prediction that “the future is bright for those who know how to write”
Maaike’s bio
Maaike Groenewege is a conversation design lead, linguist and prompt designer with her boutique consultancy firm Convocat BV. She coaches both starting and more experienced conversational teams in optimising their conversation design practise, NLU analyses and team communication. Her main focus right now is on how LLMs can benefit enterprise conversational AI. Maaike is the founder of www.convo.club, an online community for more than 700 conversation designers.
Connect with Maaike online
Connect with Maaike at these events
- European Chatbot and Conversational AI Summit, Edinburgh, March 12-14, 2024
- UX Copenhagen, March 20-21, 2024
- Unparsed Conference London, June 17-19, 2024
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Content and AI podcast, episode number 20. A false dichotomy has arisen in the AI world between conversational prompting in chatbot interfaces and prompt engineering under the hood. Maaike Groenewege works in the middle ground, in a role she calls “prompt design.” She also draws on practices from her background in technical communication, after observing that whether you’re writing for humans or designing prompts for LLMs, you have to truly understand your audience and always provide clear and specific instructions.
Interview transcript
Larry:
Hey, everyone. Welcome to episode number 20 of the Content + AI podcast. I am super delighted today to welcome to the show Maaike Groenewege. Maaike is … Well, she’s a principal at Convocat, her company, and she’s an actual genuine, prompt engineer. So, Maaike, welcome. Tell the folks more about what it’s like being a prompt engineer at Convocat.
Maaike:
Thank you so much for having me, Larry, and it’s such a pleasure to be here with you. Yes, I guess that I can say that for the last two years, I’ve been working as a prompt engineer, or perhaps rather a prompt designer. When I tell people that, they’re all going like, “Oh, that must be really sexy,” and, “It’s the job of the future,” whereas, in reality, I basically write instructions for large language models.
Maaike:
I guess I wouldn’t really associate it with being sexy because most of this is very much getting your feet in the dirt kind of work, Excel sheets, lots of analysis, lots of document analysis and content analysis. I guess it’s basically a job for … Well, can I call them language nerds like you and me?
Maaike:
So, yeah, right now I’m working for a large Dutch publisher. I help them finding out what kind of work we can automate by prompting. It’s really interesting. But I’ve also worked in situations like hyper-automation, where the prompts are not the prompts that you write in ChatGPT, but they are part of a larger workflow. For instance, a workflow where you receive an email, you want to have a first suggestion for an answer, you generate that text, you put it in an email again, or perhaps in a phone call. So it’s not really visible, but it’s definitely there in the background.
Larry:
Oh, interesting. Yeah. Well, you’ve done so much. I guess, first, let me … Can you do a quick job description for what a prompt engineer does?
Maaike:
Absolutely.
Larry:
You just outlined the main duties, like…
Maaike:
Yeah, yeah.
Larry:
But what does that look like day-to-day? What’s your new job?
Maaike:
My new job … And it’s so funny because it’s actually my old job. I feel I’m back to technical writing and technical communication again, because in order to write a good prompt for a machine, I actually apply the same principles that I use for prompting humans, instruction design. So basically …
Maaike:
Let’s take a situation, like a real-life situation. This is not from my actual client, but it was an assignment I once got. It came from a developer. He’s quite well-known in the space. He’s like, “Maaike, listen. I need to prompt a newsletter or a one-pager for three different audiences, and it should be based on two or three articles from the news, from actual news, about LLMs and machine learning.” He’s like, “Well, I prompted it and I must say that the output is meh.” I looked at this prompt, it was literally like, “Hey, generate a newsletter.”
Maaike:
I’m like, well, when I would tell a junior editor to create a newsletter, I would give him more instructions. I would tell him something about my target audience. Who is it for? What are the information needs? What is their level of expertise? Because technical writing 101, don’t write for your own level of understanding, but make sure you understand your target audience.
Maaike:
So it was so funny because prompt engineering is positioned as a rather technical job sometimes or a very marketing job. But my job is right in the middle. So what I do is I do a lot of domain analysis. I need to know who I’m working for, and in order to determine the information need of my target audience, I, of course, need to know a little bit of what they’re doing.
Maaike:
I do target audience analysis, user task analysis, all kinds of stuff. Then when I write my prompt, I do find I write it in the form of a traditional instruction, and that, of course, is one. I’ve been doing that for 25 years. So it’s almost like being full circle back into the place I never left in the first place, because even as a conversation designer, I still feel very much … At heart, I’m always a technical writer because I always support users in completing their tasks successfully or answering questions, solving problems, and these are just new incarnations, I guess, of that job.
Larry:
As you talk about your background and where you are now, I’m reminded that everybody in content design, conversation design, technical writing, I mean technical writing seems to be like that’s the most straightforward one. People often study that in college and then go actually do it. But everybody else, the conversation designers and content designers and UX writers I know, they all come from some crazy amalgam of careers and backgrounds. In your case, it just seems like the perfect storm of that technical writing plus conversation design.
Larry:
I guess tell me, because, well, you first came to my attention a few years ago as a really prominent and well-known and well-regarded and super-helpful content and conversation designer, and these new agents we’re working with, the chatbots and GPTs all that stuff, they’re all conversationally based things. Does my idea that you’re perfectly positioned for that, does that resonate? Did you feel like this has just come really naturally, or-
Maaike:
Yes, and it’s interesting because when I started as a technical writer, I wasn’t even aware that that was a formal job. It was in the early 2000s. So little trip down memory lane, it was the time of a news group called Tech Role where people like me gathered. I was what we call the lone technical writer at the company. So I basically invented my own job.
Maaike:
I found that I just got really fascinated, especially by how people ask their questions. I also spent some time at the help desk at the same company where I started as a tech writer. The way people ask questions, it can be so completely different from what you think they want to do, and that’s what started to fascinate me throughout my career.
Maaike:
With conversation design, 20 years later, I felt like I had won the lottery because, for the first time, we got our user questions handed to us on a silver plate, because especially if you create a chatbot with natural language understanding, you get the literal questions from your users. This, of course, as a technical writer.
Maaike:
Well, I was lucky I spent 14 years with air traffic control, so I sat next to my target audience literally in the tower and behind radar screens. But in many other situations, I didn’t have access to my target audience. So I was trying to help them, but I didn’t know who they were, in what kind of context they worked. All of a sudden here I am with hundreds, thousands of user questions for me to analyze and to turn into answers, turn into user support, turn into task-based, yeah, user assistance.
Maaike:
Of course, now with generative AI, it’s a bit different because it’s even better at question recognition than traditional chatbots. But all of a sudden people are also starting to talk about generating the answers rather than having them written by humans.
Maaike:
Of course, that’s something to be aware of. That’s also why I wanted to get involved with prompt engineering, because I thought, well, if someone needs to teach these things how to talk, it should be someone who knows to do that herself. But also I wanted to prove them wrong, like, “Hey, listen, this generated content, it might look really surprising and magical the first time you see it appearing on the screen magically, but when you start actually reading what it produces, you’ll find that time and again, it not just hallucinates but it’s not very language-oriented. It doesn’t have a soul. There’s no voice in there.
Maaike:
So I thought, well, it’s good to have someone who’s both a writer and critical and in love with the technology, all three of them, in one person, and let’s see where this goes.
Larry:
Yeah. As you’re talking, you’re reminding me that so many people have talked about … Like I’ve talked to Scott Abel and Sarah O’Keefe and a number of people in the technical content world about this stuff. They often make the case that in technical communication, especially customer support, like help desk kinds of things, the last thing you want is an LLM because they’re so prone to hallucination. But more to the point, not even if it’s hallucination, but just that they don’t always get the facts exactly right.
Maaike:
Yeah.
Larry:
If you’re trying to fix your machine that they’re documenting. Tell me how … So but your role as a prompt engineer, it sounds like you’re in there doing this and creating these kinds of things. Are you able to get these … Because the other … Instead of hallucination, you might say they’re just creative, to get these new creative writers that are on the team now. How do you help the LLMs answer those questions in a way, or do the … Create conversations are actually productive and they aren’t just creatively making stuff up?
Maaike:
Yeah. Well, it’s interesting because the one thing I don’t do as a prompt designer right now is actually creating chatbots or conversational experiences, because my prompts are usually like what we call single-shot prompts. I give an instruction and it outputs something, and that goes into a workflow as input for another step. But what I do find, because of course I have been experimenting in my own time with chatbots, is that retrieval-augmented generation, if your content set is good, it’ll actually give you quite a nice base to start from.
Maaike:
But we’ve also seen what happens if you just leave it at that. There have been some examples in the media lately, or some chatbots who were LLM-based and not well-designed without any guardrails. So that can go terribly wrong.
Maaike:
So can we use LLMs as the core technology of our customer support chatbots? No. Also, because people are not really … At least that’s my opinion. I don’t think people are really helped by having conversations. People are helped by solving their problems. So having a conversational chatbot for me is only a transitory stage on the way to real transactional chatbots that have access to all kinds of backend systems where you can self-service and solve your problems.
Maaike:
Only when your problem is too complex and too personal, well, then you shouldn’t be talking to a chatbot in the first place. You should be handed over to a human regardless, because people are not stupid. They’ve usually read the website, they’ve read the FAQs. So yeah. But having sat … Set … Send … Sorry about my English today. It’s after 5:00.
Larry:
That’s all right.
Maaike:
I do feel that this retrieval augmented generation, which we also know as “talk to your doc,” again, if your content set is good, it can greatly reduce hallucinations, which leaves you with another challenge because hallucinations are quite obvious. It’s usually quite easy to tell unless you count, because there are also hallucinations that are not nonsense, that are slight modifications of the actual text in the documentation, which, for instance, when you have two facts, which each individually are true, but if you combine them might still contradict each other. That is something that really depends on the quality of your source content. I think that’s where we are in familiar territory again, because what makes good source content?
Larry:
Good. You probably wrote some of that, or could easily have written those technical content source documents that you’re referring to.
Maaike:
Yeah.
Larry:
Tell me a little bit about that workflow, because the way you just described that, there’s the benefits of the way these new LLMs work and RAG is just putting those knowledge bases into that flow. How does that work? Is the learning model actually learning from that corpus of material that you’re drawing on, or is it just referring to it as a source material?
Maaike:
The last is what’s happening with retrieval-augmented generation, although the boundaries are blurring a bit because large language models now all of a sudden have these quite big context windows, which means that you can upload a lot of information directly to the context of your conversation. But that’s quite technical.
Maaike:
But if you look at traditional RAG where you, say, talk to a large document or a set of documents, basically what happens is these documents, they need to be chunked. Chunking, of course, is another familiar term for us as technical communicators. These chunks are encoded into what we call embeddings or vector embeddings. So those are numerical representations of word distances. It’s quite technical, but there’s no full text in the large language model.
Maaike:
Basically what you do is you allow the large language model to retrieve relevant information in documents and use it as context to generate an answer. The better your context, so the more specific your context, the more consistent your context … And instead of context, you can also read content … the better the answer is going to be.
Maaike:
So if you want to reduce your hallucinations with RAG, you have to make sure that your source content is chunkable. So each chunk should ideally be a self-contained unit that doesn’t refer to other units for cohesion, coherent. It should be small enough to fit in a chunk for RAG. It should be well-structured. This is technical writing 101.
Maaike:
I am very curious, and I think that Michael Iantosca and I think perhaps even Scott might have already been experimenting with this, what happens if you take some of our traditional structured formats like DITA and feed them into a RAG system?
Maaike:
I’m not quite aware if anyone has tried this and shared the results yet, but it might be a very interesting thing to do, because another thing that LLMs absolutely love is structure. If you just feed it an XML schema, it will just say, “Oh, it looks like an XML schema. That’s cool. I can do that.”
Larry:
Right. Then it can write queries against that schema, and then you’re off and running. That’s something it is good at. But back to that … Because the way you described chunking and chunks, that sounds like structured content. So how does that manifest in LLM workflows? Does it end up looking anything like a DITA topic or something like that, I guess?
Maaike:
I wish. I wish. It’s really funny and also quite remarkable that when I started out as a prompt designer, so writing instructions, I was like uber-structured. I mean with prompting, it’s very much also a matter of experimenting, very much hit or miss. Sometimes it feels like throwing a plate of spaghetti at the wall and see which ones stick and which ones don’t.
Maaike:
I still remember, the first time I was like, “Oh, forget it. I’m not going to structure my prompt. I’m just going to blurb in whatever I want to get out of it, and it should just do the thing I want it to do.” That was actually my best prompt ever.
Maaike:
So that was very confusing for me. Then I started reading up on how prompts are processed by large language models, and I was utterly, utterly shocked to learn that they don’t read. So they don’t start at the top left and end at the right bottom. So you could easily put the introduction to your instructions at the end and the instructions in front, and you just throw everything at the model and somehow it understands. This is something that is still mind blowing to me. It doesn’t read. It doesn’t seem like we do.
Larry:
Yeah. So that has something to do with how the embeddings work and how it’s vectorized, that it somehow can infer from mathematically-
Maaike:
It’s basically how transformer models apparently work. You just throw a lot of number distances at the model and a little … What is it called? Pinko, plinko board? It just falls through.
Larry:
Oh, pachinko. Yeah, yeah, like a pachinko board. Yeah.
Maaike:
Exactly. Exactly.
Larry:
Oh, yeah. Oh, that’s a brilliant image. Yeah.
Maaike:
Yeah. Then I realized that it’s very important as a prompt designer to realize which structure actually matters, because structure in the sense of, oh, let’s put in a numbered list, sometimes it works, sometimes it doesn’t because that’s how we humans read. But structure in the sense of chunking your instructions and keeping them separate from your examples and keeping them separate from your output. Put your instructions at the end of the prompt rather than at the beginning or in the middle, because things tend to get lost in the middle. It’s a whole new world to discover in terms of what’s the machine’s structure? What kind of structure do they like?
Larry:
That’s right. So I’m guessing or inferring from what you just said, is there a convention like journalism writing or other kinds of writing where there’s a … Like the inverted pyramid in journalism, like in prompt construction? Is it like, okay, here’s the setup, here’s what we’re going to talk about, and then at the very end you say, “And based on this, I want you to do this”? Is that what’s going on?
Maaike:
Yeah. Absolutely. There’s a very classic structure emerging for prompts, which starts by assigning the large language model a role, because the large language model in itself, it’s nothing. It’s an amorphous blob. It’s up to us to carve a role, an identity, a personality even, for it.
Maaike:
So I usually start by saying something like, “You’re an expert technical writer and your role is or your task is blah, blah, blah, blah, blah.” That’s interesting because this way you already delimit the prompts that you’re designing to one task. Of course, that too is very nice in terms of technical communication, because one task equals one topic, reference information, examples, it’s all there in my prompt as well.
Maaike:
So role, task, a little bit of context. Sometimes I even explain it the problem that I’m trying to solve, because then you prime the model for getting into the same problem space. This is magical, I think, still.
Larry:
Yeah, that’s-
Maaike:
Yeah?
Larry:
The way you’re describing it, it’s like because the L, the first L, is large, these are giant models, and they need some kind of context like, “Hey, in this vast amorphous, vectorized embedding space, you are this entity and I need you to do this right now.”
Maaike:
Yeah.
Larry:
But, hey, I want to circle back to something you said a few times now-
Maaike:
Sure, sure.
Larry:
… that you make the distinction between prompt design and prompt engineering. Talk a little bit about that.
Maaike:
Of course. Yeah, actually, it’s a little bit of a framework I’m developing on the fly, because people talk about prompting in all shapes and guises, and I actually have three levels of prompting. The first one is what I call conversational prompting, and that’s what everybody does with ChatGPT, with Bard, and Bing. It’s typically in a commercial end user app. So Bard, ChatGPT, it’s typically for personal use and entertainment. No need to reuse your prompts a lot. It’s very much on the … Well, the interface is conversational, so it’s basically talking to a general knowledge chatbot that can also help you with all kinds of tasks. But it’s up to you to think up what you want to do, what you want to solve, and how you’re going to phrase that.
Maaike:
Then on the other end of the spectrum is what I call the prompt engineer. These are typically machine learning people or developers who build these commercial apps on top of a large language model. They are typically also the ones that connect with all kinds of APIs and backend systems, and do a lot of actual interface design but also make sure that these apps are deployed. So LLM ops is typically their realm.
Maaike:
I do find myself exactly in the middle. I don’t work with ChatGPT as my design environment. I usually use a playground for that, and that gives me access to way more parameters and configuration options than you have in ChatGPT. But what I do is designing the prompt. So I do the use case analysis, domain analysis, user analysis, much like a business analyst almost.
Maaike:
What I do is I design the prompt in a very free-form way. So I don’t bother with output formats like should it be JSON? Should it be tables? Well, I do that under the hood, but my focus is on making sure that the prompt meets user requirements. For that, I write.
Maaike:
So I don’t code officially. I do code as a hobby. But my main focus is on writing a prompt that is effective, is robust, and then I hand it over to my prompt engineer, because I’m so lucky now, I actually work in a team of more than one person. So I have a developer right next to me, Marco, and he’s the one who says, “Okay, it’s a great prompt, but how do you want to deploy it? Should it be a standalone prompt? Is it part of what we call a prompt chain where you have the output of one prompt is the input for the next one?” Then he’s the one that makes sure that it works in the code, that it’s tested, that regression tests and stuff like that happen. So he’s the one that implements it in actual applications.
Larry:
That’s very familiar to people who’ve done other kinds of design around software products, that relationship.
Maaike:
Yes.
Larry:
It’s been interesting that the same thing happens in … we know each other also from the knowledge graph world. In that world, it’s all ontology engineering all the time. There’s no ontology designers anywhere. I’m like, “Come on, you guys.” And so, I might steal your idea and try to carve out an ontology design role in that world.
Maaike:
Yeah, especially because … Well, I love that you are touching on ontology because graphs and LLMs together, well, I wouldn’t call them a match made in heaven yet, but they are definitely a combination that provides the best of both worlds, because what LLMs can’t do is … And I should be precise here. They can’t do logical inference. They do statistical inference all the time because that’s how large language models work. But causal relationships and prompting for them consistently is just something that we cannot do with large language models.
Maaike:
So that means that in order to have a persistent reference to the outside world or a model of the outside world that where graphs come in. Those relationships, of course, are persistent and queryable. We’re going way into the deep end here, but I still see a very important-
Larry:
Well, it’s also very topical, though, because I’m sure you’re following Dean Allemang and Juan Sequeda’s research around the incorporate … It’s like how much knowledge graphs can help LLMs in not just retrieval augmented, but just in general, like applying that paradigm. So yeah. This is why I wanted you on the show. You’re so deep into this. You must be light years ahead of most people in this. Well, how do you keep up? There’s so much going on and you’re doing it day-to-day. How do you both practice at the leading edge of this and get yourself to where you’re ready to do that?
Maaike:
I am very particular in what I choose to keep up with. So when I’m in doubt, I always revert back to first-order principles. Do I understand the underlying principles of a technology? Then I don’t need to learn 20 different platforms that do the same thing.
Maaike:
The thing is I mean I’ve never actually built a full-blown ontology myself because I find RDF and OWL too difficult, but I understand the conceptual thinking that goes on. So I’m now even at the stage where I prompt my large language model to imitate a graph or to imitate the behavior of a graph to make these little impromptu, almost like … I call them ALIs, application language interfaces. So at places where APIs are too structured, I build an ALI.
Maaike:
But keeping up, yeah, each morning I spend one hour reading. It might surprise you, but I’m actually reading up on classical rhetoric and conversation analysis, and I do find that somehow that transfers to the knowledge I need to do this work. I try not to get too overwhelmed. I’m like, well, I mean we’re in a bubble, but I know so many people that haven’t even used ChatGPT right now that I’m not too worried about, oh, should I keep up? Oh, well. I mean yeah.
Maaike:
I also have a life. I love walking outside and talking with friends. But, yeah, I guess I’m blessed with a very kind of … Well, you can notice it here as well. My head is not linear. So sometimes I just go for a walk and I come back with a whole set of new connections. I guess that’s just a blessing and a curse at the same time. But right now it’s mostly a blessing.
Larry:
Yeah. That’s where I get all my best ideas. Well, the shower and walks, those are the two founts of ideas.
Maaike:
Absolutely.
Larry:
That’s where you go.
Maaike:
I must say, walks, I used to walk with a little voice recorder. But nowadays I do my walking with ChatGPT in voice mode, and that is actually mind-blowing.
Larry:
I have not tried … I use Otter when I’m out walking, but I might have to try Chat … Yeah, that makes a lot of sense.
Maaike:
Well, the thing is that talking to ChatGPT, you can actually tell it to shut up for, I don’t know, 20 minutes or until you say so. So you can just ramble, and then when you’re done, I tell it, “Hey, Chat, listen … ” I’m always very polite to Chat because, well, you never know when the large language models want to take revenge. But I’m like, “Okay, this is me talking. Now could you perhaps help me by doing … ?” and I just give it a task, like, “Can you give a transcript of my notes? Can you highlight some of the more important ones?”
Maaike:
It’s the actual conversation that I’m having. Half of the time I’m not even listening to what it gives back, but I do know that when I come home and I log in on my text ChatGPT, everything is there. I also know that something has been listening and something listening or something in listening mode is just an invitation to keep talking.
Maaike:
So that’s how I do most of the drafting for most of my articles. I never let it write the final version because I hate ChatGPT’s tone of voice with a vengeance, even if I trade it on my own tone of voice. It’s this song by Tom Waits. It’s the wrong smile in the wrong face. Though her lips are smiling, it’s not her face. That’s exactly how I feel about ChatGPT. Okay. It’s nice text, but it’s not me.
Larry:
I’m going to try to link to that Tom Waits song in the show notes. That’s too great. Hey, Maaike, I can’t believe-
Maaike:
I’ll send you a link.
Larry:
Yeah, no, I appreciate that. Yeah, I can’t believe … I could literally talk to you forever about this stuff, but I like to … Part of my conversation analysis is … Folks have let me know that a half hour is a good time, so I try to keep these around that. But, hey, before we wrap, though, is there anything last, anything that you want to make sure you share with folks before we wrap or that’s come up in the conversation that you want to revisit?
Maaike:
Yes. For anyone, any writer out there who’s worried about their future, I have this really … Well, it’s kind of a lame final last words, but they are mine, not ChatGPT. Let me quote them from my own slide. The future is bright for those who know how to write. We’ll always be needed, and I think now even more than ever.
Larry:
Nice. That’s a perfect note to end on. Oh, one very last thing, Maaike. What’s the best way for folks to stay in touch if they want to connect? You have to mention Convoclub, because I want to make sure people know about that.
Maaike:
Yes, I do have a small community of linguists, language lovers, conversation designers, tech writers, and that’s at www.convo.club. I have my virtual living room at LinkedIn. So my LinkedIn profile is MaaikeGroenewege, but I’m sure that a link will work much better. But LinkedIn is literally where I hang out all day, so that’s where you can find me.
Also, conference season is coming up. I am definitely there at Edinburgh in March, I’m there in Copenhagen in April, and of course Unparsed in June. I mean all these communities are wonderful. So if you get the chance and want to meet in real life, this is definitely something to look out for.
Larry:
Excellent. I’ll link to those events as well-
Maaike:
Perfect.
Larry:
… because I’m going to try to get to at least one or two of those.
Maaike:
Lovely.
Larry:
Well, thank you so much, Maaike.
Maaike:
My absolute pleasure. Yeah, it’s been great sharing some thoughts with like-minded people again. So thank you so much.
