# Agentic Engineering and AI-Native Team Restructuring

**Podcast:** HMZE
**Published:** 2026-07-23

## Transcript

The somewhat funny thing is that it would be rare if I didn't have a black T-shirt on.
It feels like this is pretty much the standard CTO dress code, right?
So wearing a black T-shirt or a black hoodie depends on the season.
Welcome to another episode of our new season of Beyond Vibe Coding, partnering with Impala Search.
The go-to tech and executive search agency in Germany.
In this podcast, we explore the transformational change in software engineering and knowledge work in general.
I'm Sebastian Heidemeyer, Zerbem, CTO at North.io.
And I'm Andrei, CDPO at Trusted Jobs.
Great to have you back.
This time we are talking to...
Ben Hoskins, ein sehr guter Tag-Leader, also mehr als 25 Jahre in der Industrie Erfahrung.
Ja, es war wie old Pals, die über olden Erfahrungen zu sprechen, aber auch die neuen Welt zu adaptieren.
Und wir haben tatsächlich viele Verbände zwischen dem alten und dem neuen Welt gefunden.
Agile, BDD, Technikallexcellence, all diese Dinge.
Ben, das hilft, speziell wenn er in Agenten engineering empfiehlt.
Und er hat es genau wie er das hier an Neustor, wo er currently als CTO serves.
Wir hoffen, dass ihr den Diskussion genutzt habt.
Wir haben es auch schon.
Wir haben es schon.
Wir haben es schon.
Willkommen zu diesem Episode, Ben.
Wir sind sehr froh, dass Sie uns zu haben.
Und als usual, wir würden uns gerne zu uns zu geben, wie wir uns zu uns zu geben.
Ja, würde ich so gerne machen.
Thank you.
Ben Hoskins, currently working for Newstore.
As CTO, I look after product, engineering, design, etc.
And I think you asked me a question earlier, Sebastian, as we're warming up.
What's your career?
I haven't really had a career.
I've had a series of choices of things that sounded fun.
So I work for the likes of eBay, Wayfair.
Ich habe auch mit verschiedenen verschiedenen Unternehmen, Neustau, für zum Beispiel.
WDS, in der Zeit, war es ein kleiner Unternehmen.
Und ich habe ein weirdes Gefühl, was ich finde es fun ist.
Aber ich finde es gut, dass ich es so.
Das ist ein tolles Antwort.
Probably, so I would definitely say the same about myself.
So there's no red line.
It's just like all over the place, right?
Probably also for André.
I mean, that's what drives us, right?
The curiosity to always learn something new.
Learning curve is super important for me personally, right?
The journey for mastery.
Yeah, cool.
Thanks a lot.
Nevertheless, probably the best answer you could give if someone asked you for your professional career, right?
I like the view.
Und usually wir starten, nach dem intro, mit der Status Quo.
So wie Sie arbeiten?
Be es in Ihren Coden, wenn Sie schon ein Coden haben, aber auch Ihre anderen Duties.
Du hast bereits erwähnt, die Sie für Ihre Managerial Arbeit benutzen.
So all das ist super interessant für uns.
So, ich habe in meinem Office jetzt, Es hat eine Ring-of-Desk um es und sie sind voll mit Computers.
Und die eine zu meinem leften ist ein alten Alienware Laptop, das ich habe, habe ich, das ich habe, habe ich, um Ubuntu in.
Und ich habe Tailscale und T-Mocks und das Ding.
Und ich benutze das, wenn ich das irgendwo um, um die Planeten zu gehen.
Und ich werde es auf meinem...
$100 Cloud license generating software.
So basically I built, maybe about 15 years ago, I built a thing called Card Planner.
And Card Planner is a way of seeing a Kanban board, seeing the same board, whether you're in India or in Germany, so that when you're dragging a card, you can actually see it move in real time in both places.
I extended that, I added MCP to it.
So I go through a phase of doing a distillation of the specification.
That gets into a series of cards.
I then pull that over into Allium, which is kind of like behavior-driven development for LLMs.
And you describe the specification.
It's a little bit of ping-ponging of what the specification looks like.
I then use that to...
und ich mache es in großen Chunks.
Es geht, dass ein Testrendorm ist in small increments.
Das geht nicht wirklich an LLM.
Ich mache es in großen Chunks, beide unit- und end-to-end, alle red zu beginnen, mit der richtigen Runden, die richtigen Runden sind.
So, für einen Beispiel, ich würde sagen, apply Boundary Value Analysis, Wenn du ein Multitenantik-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad-Trad- If it's already got some good references of how you want your target architecture.
Hexagonal was made for this as an architecture, if you're doing something standard, because basically it's got the right level of decoupling.
And weirdly enough, I've also learned how to build Flutter apps because of LLMs, because I never used it before.
And I just pointed it and said, make me the repo, make me the app.
And I've learned how the app actually works.
durch LLM-Generatung.
So, it'll run through that, mostly unprompted.
There's a couple of things I don't allow it to do.
I don't allow it to do all the usual Bash stuff that it loves to do, and it's like some kind of addiction that it crawls back to going to a grep every time, and I make it use the IntelliJ tools.
So basically I hand it the IntelliDutels via MCP and I use that to do all the refactoring etc.
automatically.
And it pops out working software at the end.
And sometimes I look at the source code, I often don't.
Now that's in my own work.
That's quite dangerous sometimes.
I spotted about two months ago.
dass mein sub-second, super-fast frontend für dieses particular App, das ich was building, weil ich nicht mehr Frameworks habe, es war einfach nur JavaScript, es war ein Sekunden, ein Sekunden und ein Halft.
Und wenn ich mich zu gucken, es hat, es hat die ganze Objekt-Modelle, including die Leute's names, e-mails, phone numbers.
Und ich habe es nicht so, dass ich das.
So every now and again, I go and I do it maybe weekly.
I will do an architectural review.
I'll review what is actually coming out of it.
But increasingly, I'm not touching it.
So that's my own stuff.
So basically, maybe I'll drop in at lunchtime when it's running to see how it's running and how it's carrying on.
But fundamentally, nothing.
I just let it produce software for me.
That's super interesting.
You mentioned a...
BDD Freiburg, das war, wie es zu LLM war?
Was das Name?
Es ist also Allium.
Es ist die Name für all die verschiedenen Types von Onions und Garlic etc.
Das ist der Familie.
So A-L-L-I-U-M.
Es ist von Juxst, die Firma hat sich zu Beginn mit gebaut.
Aber es ist, es ist eigentlich eine Art von Describing der Behaviour des Anwendungen.
Und es ist eine Art von wirklich, genau wie codifying down, etwas, das würde sich multiple lupen und oft, dein LLM würde es nicht mehr verändern.
Super interessant.
Das ist das, was ich liebe diese Episodes, weil ich immer etwas lernen, was ich immer etwas neu habe.
Da ist eine andere, die ich noch nicht versucht habe, das sehr alt, das ist sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr Ich muss nachdenken, zu finden, was es war.
Du bist sehr happy mit dem approach, sehr relaxed.
Ja, es funktioniert.
Ich meine, es funktioniert.
Ich meine, eine der Dinge, die wirklich startling ist, dass ich versucht, ich habe es versucht, zu beginnen.
Ich habe wirklich versucht, dass ich einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach, dass es einfach You tried to go back and it would just break.
The history would be all over the place.
And I tried lots of stuff like that.
And then I kind of realized it needs to be in a loop.
It needs to have a feedback loop.
And that feedback loop is what I've been teaching people for the best part of 25 years, which is give it some failing tests and make the test pass.
So all of the agile stuff that I've learned forever is certainly very applicable, which is kind of fun.
Absolutely.
That's something we learn over and over again in our sessions.
Like the better your technical excellence, actually, that you have applied before, the better the outcome with the elements, right?
And also the way you describe it, that you write a big chunk of tests before, which I have heard in that detail anywhere before.
Super interesting.
We'll think about it and try myself.
It's pretty much providing...
the scaffolding that also was there when they tried to, I think, one-shot what have they rebuilt, BUN, I think.
No, not BUN, but I think a browser, right?
So some company used the extensive testing framework of, I don't know, it was Chromoth or something, right?
Also did this with...
Ich kann nicht mehr welcher Compiler es war, aber sie rewrote die Compiler.
Der C Compiler, ich glaube.
Ja, was es?
Ja.
Ja, das ist es.
Du bist ein sehr extensive Test Suite und der LLM oder der Agenten kann einfach nur gegen die Test Suite.
Und es ist wirklich interessant, dass man 20 Jahre alt hat, wie wenn man, wenn man jemand in Test Runen hat, dann wird es über triangulation.
That is just a lightweight way of saying boundary value analysis or design by contract.
And all of those ideas, you're like, you give it those magic words and you say, apply boundary value analysis to the test suite generation.
All of a sudden you get a very, very good specification.
Because we just talk talking about TDD.
Have you ever tried semantic anchors?
Have you heard about that?
No, what's that?
Semantic anchors.
So we had a...
Was es in Deutschland?
Okay, dann wir müssen das wieder mit Ingo recordieren.
Das ist eher ein gewisses Term in LLM, das aktiviert sehr precise Knowledge.
So, wenn du TDD according zu etwas, dann die Results sind ziemlich...
Sie sind besser als mit einem TDD-Application-Followering-TDD-Application.
Ich war nur interessiert, ob Sie die gleichen observations haben.
BVA ist eher eine solche Anklage-Anklage, denn es ist ein völlig anderes Modell.
Ja, absolut.
Ja, für sicher.
Es ist wie TDD-London-School.
Avoid to fill up your context with a long description of how exactly you want to do TDD.
You say TDD London School and it does it.
Or ADRs according to Neigart is another example.
We'll do perfect ADRs.
Yeah, interesting.
So maybe we need to record.
I think it was Ralf, right?
He's the inventor of this term.
Yeah, you're right.
It was not Ingo, it was Ralf.
Because I guess it's like, hey, that specifically means this particularly small part of the graph.
And then it's super contained and like the references on it will all be like, yeah, that makes a lot of sense.
Exactly.
Yeah.
And maybe before we go to the main part of the episode, you described your personal coding setup, right?
Super interesting.
Do you also have like some like specific tools for your managerial setup that you use or is there also a tech stack that you're already using?
Actually, that's more a case of.
building a bunch of skills out of this.
And as I was mentioning earlier, I built a couple recently which were think like Ben and write like Ben.
And basically what I've done is I've shoveled every piece of communication I've had since I've been in Newstore into it.
All of my emails, all my Confluence docs, all my Google docs, all of the Slack messages that I've had.
Und ich habe es tatsächlich, dass ich alles in der Geschichte über alles in der war.
Und es ist dann auch der Weg, die ich denke und die Worte kommunizieren.
Und es ist nicht für die Reasons-Einheit, sondern es ist, wie ich, ich habe mich über den Think-Like-Ben, weil ich werde auf vacation in September gehen und ich werde auf drei Wochen gehen.
Und ich möchte es zu meinem CEO und sagen, hier ist ein Ben-Bot.
Ask him a question, um es zu sehen, wie es wird es, wie ich ihn aufwarte.
Und the Write Like Ben, I did, because sometimes when you're using Claude to do architectural analysis, or you're looking particularly at products, or the way that you want to place this product, the way that you want to think about it and position it, it comes back with garbage sometimes, like weird long chain sentences.
So I used Write Like Ben, so it can then come back to me in a language that I understand, and I can instantly...
was it's trying to explain to me in terms of concepts.
And it works incredibly well because I guess you match the cognitive, so it's quite a smart way of doing it.
But I guess one of the things that we're really in work, one of the things that we're really grappling with now in order to actually get down to something that's consistent is that canonical model across the piece, right?
Es ist ein SaaS-Temain, so ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen, ein Unternehmen.
Und wie viele Unternehmen, die Produkt Definition war über multiple Pläne.
Und eine der Dinge, die wir zusammenfassen sind, ist das eine eine.
Of course, we started in KnowledgeBases, because that's where you start.
So KnowledgeBases, Henning, great.
The guy that looks after design for the organization is great.
He's light years ahead of most people when it comes to LLM adoption.
And he also runs content, because content design, especially in SaaS companies, are fundamentally the same thing.
Because your product is often a suite of APIs, and how the documentation tells you they work.
Er hat ein paar Sachen zusammengebracht, wie Doc360, die External-Internal Docs, all durch MCP feeds und hat das einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen, einen gewissen Und die nächste Sache ist das, was das, was das, was das, was das Produkt Definition eigentlich ist.
Ich würde sagen, wir sind relativ schnell in das in das, Jonny.
Und das, mehr als anything, wird das nächste Level, was wir mit dem AI unlocken.
Und vielleicht eine weitere Frage.
Was ist das Spezifizierende Artefecht, das du in der mindest, das ist der Outcome?
Ist es, was es, pretty much, Information, das in dieser RAC-Pflege?
So this is what the module structure looks like.
This is the modules that you combine together to have these different product sets.
And then on that, then you can base your contracts, you can base your product decisions, you can then test different product ideas, potentially with synthetic personas, right?
Because we've been playing with this as well.
Like the other piece that we're, which is a complete aside.
Synthesik Persona ist wirklich interessant, weil wir auch versuchen, weil ich nicht, Tandia, exploratory Tests automatically durch einen LLM, das ich habe versucht, für den besten Teil 20 Jahre, um ich habe versucht, eine Framework für das 15 Jahre und es war nicht gut genug.
Aber ja, so das Canonical-Lehrer wird, die wir effectively be...
Das ist wahrscheinlich schon ein bisschen mehr, aber wir wissen nicht mehr, in der Struktur.
Vielleicht ein paar Sachen, die ich habe.
Ja, gott.
All right.
Danke, sehr interessant.
Und ja, ich glaube, es ist Zeit, die mit der Meet, die ist, pretty much, Agentic Engineering at Newstore.
So, du hast deine eigene...
approach already, which probably differs somewhat from how the company currently is working, however, might influence this.
Yeah.
Could you share how the company is working, what you're doing there?
Yeah, of course.
I think what's interesting generally about adoption is, especially with AI, is that a lot of the early folks that tried stuff, like they brought up Corsair and they tried using Corsair a year and a half, two years ago.
Und dann haben sie sich ein Bad Copy von Stack Overflow gesehen haben, etwas das Schmerz war, das ist ein Schmerz und Spastet.
Und was passiert ist, um bis November 2019, die Leute waren sommerlich nicht mehr, weil sie gedacht haben, das ist nicht gut.
Und sie haben nicht gedacht, wie viel es hat sich progesehen, wie es jetzt ist.
Und es hat mich...
Ich habe dann gelegt, ich habe eine Point of Sale System in vier Tage und ich habe einen AllHands für den Produkt Engineering Design Support AllHands und ich demo-dekte es zu dem Team und ich sagte, look, wenn ihr nicht schaut, das ist, was wir uns zu tun.
Wir können nicht auf das, wir können nicht haben.
Und dann, eigentlich, das hat sich angefangen.
Wir haben die Level ein bisschen und ich würde sagen, wir haben zu Level 1, Level 2.
Und als wir das haben, wir haben versucht, die Rolle zu entwickeln, so dass wir die Leute, die Leute auf die richtigen Zeit, die wir wollen.
Und es ist wirklich ein Team.
So, wenn wir uns auf die Point-of-Sale und die Selling-Team haben, Die MAUB, die oftmals haben, viele Leute mit einem LLM mit ihnen.
Ein paar Teams werden mit einem LLM mit ihnen verwendet.
Sie haben sich mit einem LLM mit einem LLM mit ihnen verwendet.
Sie haben sich nicht das in der Team noch.
Sie sind das in den Domain-Aliasen, auf welchen fünf LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM mit einem LLM Es ist mehr als die Linie von Shared Prompt, an diesem Punkt.
Und in ein paar andere Sprachen.
Es ist Python und Go.
Es ist ein paar andere in dem.
Es ist partly weil der Team, die ich in der Firma hatte, 15 Teams, nicht 5.
Und sie waren alle büten whatever Infrastruktur sie wollten.
So eigentlich, da ist ein Zusammen-Together von das, bevor du wirklich geteilt.
Aber eigentlich, mit dem, mit Leuten, mit denen, mit denen, mit denen, mit denen, mit denen, sie sind bereits ahead.
Ich würde sagen, dass die Bottleneck hat bereits geändert.
Und wenn du an, wie historisch, was in Produkte passiert, ist, dass wenn du in SaaS bist, du musst es richtig.
Denn dann, als man sich das wieder adoptiert, kann man sagen, das war ein Experiment, sorry.
Und sie haben jetzt, ich weiß, 20, 30,000 mit der Service Integrator zu machen, um sie zu machen.
So, was historisch passiert ist, dass wir das in einigen Bereichen haben, sprechen zu sechs, sieben verschiedene Retailers, um zu bekommen, um die Füße zu bauen, um dann zu sehen, um die Füße zu bauen, um dann zu sehen, um die Füße zu bauen, um dann zu sehen, um die Füße zu bauen, um dann zu sehen, um alle die verschiedenen Angeln, um die Füße zu erreichen, um die größte Dinge zu machen, um die größte Dinge zu ändern, um die größte Dinge zu ändern, um die größte Dinge zu ändern, um die größte Dinge zu ändern, um die größte Dinge zu ändern, um die größte Dinge zu ändern, um die größte Dinge zu ändern, um die größte Dinge zu ändern, um die größte Dinge zu ändern, um die größte Dinge zu ändern, um die größte Dinge zu ändern, um die Wir sagen, okay, jetzt, wir werden viel, viel kleineren.
Wir haben noch die Teams, die die Domain zu sehen, aber wir haben viel, viel kleineren Teams.
Ein Produkt, ein oder zwei Engineers, und die werden dann auch auf die Mission, die du run hast.
Und du hast etwas Ende-to-Ende zu deliver.
Und eigentlich, ich würde sagen, dass bereits mit dem, wir werden viel, viel weiter mit dem, weil du hast, dass du das, und sagen, okay, wir müssen noch ein paar Dinge tun, aber wir müssen das machen, aber wir müssen das machen.
So, für einen Beispiel, wir machen jetzt, wir machen uns von einem System of Record zu einem System of Intelligence und wir bauen ein paar MCP-Tools auf dem.
Aber wir wissen, wir nicht fully wissen, wie retailers das, so wir wollen es aus dem, wie wir es aus dem, wie wir es aus dem, wie wir es aus dem, wie wir es aus dem, wie wir es aus dem, wie wir es aus dem, wie wir es aus dem, wie wir es aus dem, wie wir es aus dem.
Get that feedback in.
And then there's two ways that you can go.
You can either use it to generate reports or you can really enhance your MCP toolchain so that folks are using the likes of ChatGPT and Cloud directly.
And basically, let's do that based on what the use looks like, which we would never have done before.
It would have always been, let's get the pre-testing done with wireframes, etc.
And then we will release it.
And it was a lot more deliberate.
And what's really interesting is that AI as a technology has kind of released you from that because you don't need a whole team to build stuff now.
You need one or two engineers.
And that part of the code that you thought was going to take months suddenly takes a couple of weeks.
And you're no longer bound by saying, oh my God, that's going to take a month to...
oder drei Monate zu re-Write an API, es ist ein paar Wochen zu tun.
Und die größte Problem ist, wie viele eigentliche ich es benutzen?
Absolut, ja.
Wir haben jetzt schon versucht, wir haben zu investieren, ein bisschen mehr auf die Ereignisse, wie man das hier macht.
So, für zum Beispiel, wenn man sich in Support passiert, dann wird man all die Diagnose und all die Tool Chains, etc.
Das ist das, was man muss.
Let's get MCP tooling around that.
I just last week saw something come out of Hack Day that I want to push across the whole of the company.
So anything that gets you your time back so that you can then invest is a win in my book.
So things that you've got just dead work, just use that.
Use an AI to do most of that work for you.
So you get the time back so you can reinvest it.
Ja, das ist immer die, die die wichtigste Parten, wo man investiert, die Efficiency Gains zu vermitteln.
Und dann die zweite Sache ist, also, eigentlich, es sind drei Dinge.
Eine Sache ist, wie man internally benutzt, die Tools und verändern und adaptiert, wie man arbeitet.
Und die zweite Sache ist, wie man das kann, wie man das zu vermitteln.
Und dann ist es, dass du auch in der Produkt-Empfassung mit dem Produkt-Empfassung in den Markt-Empfassung.
Und dann ist es, dass du auch in der Produkt-Empfassung mit dem MCPs, die du auch in der Produkt-Empfassung mit dem Markt-Empfassung.
Aber es ist nicht nur auf der Engineering-Side.
Wir haben aufhören, aufhören, aufhören, aufhören, aufhören.
Du kannst du das zusammenfassen und du kannst du das zusammenfassen.
Ja.
Und du kannst du Pattern-Matching automatisch machen, um zu sehen, wo es der höhere Signal und was nicht.
Absolutely.
So that speeds up as well.
So anything where, so what I'm kind of finding is, sure, it's not the pancia, but any area that you're looking at that was previously labor-intensive, you can often apply an LLM or some description into that and suddenly start speeding up.
So it goes back to fundamentals and Goldratt's theory of constraints.
So what you need to do is you need to look at your system as a whole, to work out what your constraints actually are.
And then don't be optimising continually in engineering if you think that's the right thing to do.
Look at everything systemically and say, actually, the bottleneck's here in product.
And after you've removed all of that unnecessary stuff that people are doing, then you need to then look at how you can elevate on that bottleneck and stop doing some work there to actually get your throughput up.
And then it may go back to engineering or it might be design or it might be something in support.
But the general gist of it is if you can optimize across the whole of your organization and not just micro optimize, it'll make your teams faster.
And that's a fundamental thing that I learned as an Agile coach years and years and years ago.
Yes, absolutely.
I think there's so much into what you've just described.
So we need to unpack it a little bit.
Maybe starting from the last point, we say, okay, you need to look at the pretty much.
wo die Bottlenecks sind, wie die Theorie der Constraints sind.
Wie Sie das?
Sie haben KPI oder ist es eher ein Qualitäts-Thing?
Wie Sie die nächsten Bottlenecks sind?
Ich denke, das ist ein sehr einfaches Wettbewerb.
Wenn Sie sich ein Kanban ansehen, und Sie sehen vieles auf einen Kahn-Bahn, dann vielleicht das die erste Platz zu starten.
Und, you know, people do accumulative flow diagrams, etc.
Most of your toolchains that you've got out there will give you that stuff by default.
But ultimately, eventually you kind of get a nose for it.
Right?
Like, it's a weird thing to say, but you can have the data and you look at the data.
But if it smells like it's slow, it's probably slow.
Right?
So basically, you're saying you're in exchange with a different...
Parts of the organization, right?
And then you get the insights from customer success or wherever there's currently a bottleneck and then you approach it.
Yeah, exactly.
And that's absolutely vital that you maintain and you have those really strong relationships with the organization to work out where the bottlenecks potentially are.
And sure, everyone's got their curing systems, they've got their ticketing systems, whatnot, and you can dive into that and actually an LLM can help you there as well.
Aber wirklich, die place zu starten, du hast wahrscheinlich einen Nose für ihn.
Und die andere Sache, dass du nicht bise dich, weil du ein Nose für ihn hast.
Du hast vielleicht einen Nose für ihn.
Du hast vielleicht einen Nose für ihn.
Und du hast dich offen, dass du vielleicht einen Nose für ihn hast.
Aber dann, du hast einen Nose für ihn.
Wie ist das, dass du vielleicht einen Nose für ihn hast?
Wie ist das, dass du vielleicht einen Nose für ihn hast?
Speeding up things will lead to less quality.
I think you mentioned earlier, so product is now the bottleneck, I think so too.
So what could happen, right, if you now have a faster engineering organization, like you just build everything, right?
So like every feature gets built.
Not sure whether this is the desired intention.
I would say no, but is there...
Something to avoid, like building average stuff?
I think that all depends on how you value user experience.
Because I think, like for me, it's sure the architecture is important.
What's much more important is how people are using the thing, right?
True.
So I would say that, yes, you can build lots of stuff of average quality.
But again, you need to question whether you actually want to do that or not.
Yeah, absolutely.
So you have anything in place at Newstore to avoid?
You're just building average stuff?
So you do any kind of, I don't know, you have some quality metrics in place to ensure product features are well thought through, it fits in the stradet?
It's a very hard thing to describe.
So I'm going to steal.
Ich habe ein Quote von mein Head of Platform und Developer Erfahrung und es, Kultur Eats Metrics für Breakfast.
Es ist die same als, wie alle drei oder vier Jahre über Dora Metrics beschäftigt.
Und ich bin, ich habe nicht mehr als das.
Nicht zu Beginn mit.
Was ich möchte, ist ich möchte, dass ich ein Team das values das und dann die Team möchte, dass es sich selbst.
Und es ist die gleiche als Qualität zu den End-User.
Ich will ein Team, das Wissen, das Wissen.
Weil wenn du nicht, sie wirst.
Du kannst das gleiche und Qualität.
Und wir können es.
Wir müssen die Failure Rate machen.
Wir investieren mehr und mehr in Produktion und Issues.
Wir sind wirklich, wirklich auf Resilienz und Resilienz mehr als jemand anderes, das ich weiß, dass wir eine Produkte haben, wie wir uns auf den Punkt, wo wir mehr Sachen zu dem device machen, um das Resilienz zu machen, in einem Storz-Einrichter, wo die Wi-Fi nicht immer gut ist.
Und wir machen vieles von Daten, aber es ist über das Touch und das Gefühl und das Affinity für den Kunden.
Wir haben...
Wir haben die Unternehmen in den Stores mit dem Retailer, damit sie sich fühlen, wie das Ding ist, und wo die Probleme sind.
Ja, wir haben die Messerungen, aber wir haben die Unternehmen, das ist wahrscheinlich die beste Art von Deskriving.
Und das ist ein guter Wettbewerb, dann einfach nur das Schöpfe, was von Intermediate Qualität, dass man könnte.
Ich denke, basically...
If that gate wasn't there, yeah, I think it wouldn't be anywhere near as good as what it is.
Let's put it like that.
Sorry, it's not a sexy answer, but it's...
No, no, no.
I think it's also a hard answer.
So I would also tend to say sometimes it's good to slow down, to not just make use of the speech which is there.
I think some people call it product taste, right?
It needs to fit in, to quote Steve, it needs to fit into a cohesive structure.
Cohesent structure, aber ich würde es noch gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne gerne Can we say sexy on this podcast, Sebastian?
I just did earlier, so.
I think the thing that's interesting is that now that you can release Fast Art, will people iterate, right?
Will people learn?
And having a learning organization that will then take those lessons and say, that didn't work, and we're deleting that.
Das ist sehr interessant, weil ich denke, die diejenigen, die das tun, die diejenigen, die das zu tun, die das zu gewinnen, aber tatsächlich, da ist es eine Art, die man kann automatisch das auch.
Es ist wie, du hast deine Metrics und wenn etwas nicht getroffen wird, dann einfach delete es, delete die Software.
Ich denke, was wir hier ist die Initiativierung, die jetzt spät ab, die die Use-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen-Agen- to understanding your customers, where they are, and if they're actually happy and capable to adopt 10 new features every week or every month, or if they need something slower and maybe gradual changes that guide them into a new direction.
And there are folks in both extremes of the continuum.
And in the end, You can have and should have measurements, I think, to pretty much have kind of like to see if you're on a healthy path, to see if there's something going out of bounds that you don't see any way other.
But the more important signal or channel is actually the relationships with the customers and understanding where they are and how they feel.
Yeah, you can't measure a team to be awesome.
It's like somehow that doesn't work, right?
Oh, you can't measure the lines of code and then you know that the team is awesome?
The old idea of measuring developer productivity, right?
So what is it and how do you measure it?
Yeah, I produced one when 10 would have done.
There you go.
Yeah, exactly.
Yeah, cool.
Early on, I think you mentioned also that you changed the roles a little bit in your teams.
Did I understand that?
What's interesting is that the roles change through the nature of AI, right?
So when you look at basically domain knowledge used to be king, and now I've got the full software on my machine, and I can...
Ich kann es auch passieren, dass das Methikall, vollstack Pi- oder T-Shirt-Beaut hat, dass man für Jahre hat, haben wir jetzt.
So, du musst nicht massive Teams von Specialist Frontend, Specialist Mobile, Specialist Backend.
Genuinely, als du ein decentes Engineer, You can get a good, like far across many parts of the stack that you don't actually know are on.
So what has happened is it's gone back to what happened at the beginning of XP.
The team that I started with in 2003, there was no product, there was no design.
There was engineers and there was customers.
Aber in reality, die Rolle existiert.
Die Leute in der Team sind einfach.
Ich habe ein paar Produkt-Arbeit und ein paar Design-Arbeit als ich in der Team.
Aber jetzt, ein paar der Engineering-Complexität ist verletzt.
Und Sie sehen, die Engineers sind überwunden, die Produkt-Thinking sind, oder die Aheader.
Und Produkt-Folks können in einem wirklich guten Geschäfts-Business-Thinking sind, sind auch die Aheader.
So es ist die Rolle für die Natur.
Ich würde sagen, es ist eher eine collapse der skillzettischen Sätze, dass du nicht wirklich an die esoterische Dinge mehr als mehr als mehr, weil ihr LLM hat die ganze Geschichte von Humanität in es und ihr könnt einfach nur fragen.
Und hat das bereits in den Roll Description-Changes bereits gesagt?
Wir sind die Roll Description-Change.
Ich denke, sie sind in der letzten, in Februar, aber wir haben sie.
Ja, wir haben sie.
You can keep them the way that they will.
So it's now more in the direction of the product engineer, if you wish, right?
So someone who...
Starting to go that way, yeah.
I think more than anything, when you look at role descriptions, they sound like boring things, but they're basically a way of distilling the culture of your organization.
They're a way of crystallizing what you actually, what you value as an org.
So we're starting to push more towards that.
And we've got a lot of people on the team that are already like that.
Because a lot of people that do XP have got that type of thinking anyway.
How do you incentivize that path?
Because at the end, right, this is like still people are doing the job.
So you need to convince them.
Is there any secret sauce you discovered on your journey?
You promote the people that...
Das haben die Valuer.
So, du hast die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, die Leute, von 15 Teams zu 5 Teams, 5 Bigger Teams.
Aber jetzt ist es, dass du eigentlich noch mehr Teams mit dem Team geht, die auf die Software-Incremenzen oder Features arbeiten.
Aber diese sind wahrscheinlich...
Das war also ein Progression.
Wir hatten Teams, die wir hatten, die wir haben, die wir haben, die von den Architekturlern haben, von 15 Teams alle machen.
So, having five teams means that when you've got fixed architectural problems, you don't need to go and ask three different teams to do it.
You can just do it within your team and you can plan it.
But basically, we'd already formed the concept of temporary squads before we really started adopting AI.
And what AI basically did is it made those temporary squads smaller.
You don't need as many people in them.
So, we'd already had cross team.
teams to do these larger initiatives.
Most of the stuff now, because whenever you've done stuff with in-domain, like at this point, the company is what, 10, 11 years old?
They've already got all of those in-domain things pretty much done and all of the problems are left or into the domain.
Yes, got it.
Okay, that's interesting.
So then you pretty much have these five bigger like domain-oriented teams, right?
And then you form temporal squads that are working or temporary squads that are working on inter-domain issues with representatives from the different bigger teams, right?
Do you have any experience already learnings?
How does it work with cognitive load and stuff like that?
Because Everyone complains about it as being like, oh, there's too much information overload.
But actually, when you do it, it doesn't really, the reality of it isn't that much.
And actually now with LLMs, it's much, much easier.
And apart of code that you haven't touched for like a year or two, it'll tell you immediately what it does.
We've got tests as well across everything.
Ja, was ich oft hear ist, dass du kleiner Teams, besonders oder auch kleiner Organisationen, aber in der Brownfield-Environnen, das ist ein bisschen unfair für neue Organisationen.
Es ist einfach zu adaptieren, weil du deinem Environmenten baut, so mit Brownfield-Abrüchern, du musst du über die alten Welt stillen.
Und dann bist du oft mit dem Faktor, dass es still complex ist.
Oh, nein, wir haben das überall.
Ja, aber in existing organizations, I think you build software maybe also differently in the past.
So you followed way more also approaches to handle cognitive load.
Now where AI is taking over the larger part of software engineering, you may also can skip certain architectural patterns and end up with different systems, is what I'm saying.
So what I can share maybe also from our organizations, we run...
A couple of hundred Lambda functions, probably something you would not do if you build that now with agentic engineering, but nevertheless, this now exists.
Someone needs to take care of that.
And then you always get the feedback, well, how do you handle that with a smaller organization?
Still, the software is built in the old way.
Yeah, I mean, we've got all of that.
We've got every possible architecture you can think of, we've got.
But basically, the gist of it is...
The gist of it is that complex system, you still need to invest in proper levels of quality, etc., in order to actually make any effective change.
Thanks, Ben, for giving us this comprehensive overview of how you're working.
It was super interesting and it was great having you on the show.
Thank you.
Thanks both.
Hopefully, speak soon.
To the recap, what stuck with us, Sebastian?
For me?
Really interesting was his personal setup and how he writes these big chunks of tests first before he starts actually implementing.
I will also definitely have a look into the Allium framework that he described.
Yeah, really interesting.
I definitely will take something away from this.
One of the reasons why we do this podcast, right?
These small but very powerful recommendations.
So my first takeaway is think like Ben, write like Ben.
I need to adapt it to myself.
I have also a bunch of skills helping me and also trying to, I would not say simulate me, but...
Well, like cover certain parts of my thinking process, but the way he specifically uses this, like very powerful.
So really need to think about building like, think like Andre, write like Andre.
Absolutely.
I did something similar to this in the past, but on a way smaller scope where I feel like, yeah, the agent has like 80% of my writing style now adopted, Ich denke, ich kann es besser machen.
Und das ist auch etwas, was ich definitiv noch beinahe.
Ich kann auch, weil du gesagt hast, dass ich es sehr einfach zu machen, oder nicht sehr einfach, aber zu den Dingen wie Ben, wie Ben in diesem Fall ist es viel mehr schwierig.
Also, ich habe auch versucht, das zu mir selbst.
Ich denke, du musst wirklich ein tonnen von documents, um wirklich ...
Derive the writing style.
So at least I would also say I landed at 80% and 80% is not good enough.
Yes, you always need to do the final polishing.
Which actually for daily work, I don't mind or even like it that way because this ensures that I always go over everything, check that the content is really right.
But for some es könnte es eher zu sein, dass es 100% zu sein.
Wir werden auch noch ein paar Jahre weiter sehen.
Und dann, was ich auch noch aus dem Ganonical Model war, was er von der Applikation gesprochen hat.
Und die Ideen, wie er es wollte, sind auch sehr interessant.
Ich würde gerne hören, dann, die Erklärung von diesem.
Was er hat er gesagt, dass er all die Informationen über die Software, die Platform ist, For example, in order to test new feature ideas via specific personas against this canonical model, he wants to utilize it, which is kind of interesting.
And also the holy grail, basically, to automate exploratory testing, which in theory actually should be possible now.
And I heard someone else do something similar in that maybe we even had someone on the...
was ich auch noch mal wieder auf die Abitur des Videos.
Product taste, I think at the end we can summarize it there, or end certification, to put it the other way around.
Like using the gained, the new gain speed, right?
So not just implementing everything, but accelerating testing, so to say, or like iterating.
Also one of the things you mentioned in the intro, so like making use of the things we always look for, right?
Continuous improvement and not just like now building every feature which a certain customer may request it.
Absolutely.
100%.
Yeah.
And last thing that I took away was the temporary squats.
This was something that every leader wanted for ages, I think.
And in the past was super hard to do this.
Also, you made the point due to the cognitive load, right?
Contact switching always, which is now probably getting way easier.
Because you have this agent by your side who can help you get up to speed and switch context way easier by giving you exactly the context that you need when you enter a new topic.
And this reminded me of our episode with Bastian from the Getaway Group who described exactly the same approach.
So also curious to see if that works and how this works out for Newstore and also for the Getaway Group.
Das ist ein guter Wunder, dass wir beide beide brauchen, vielleicht eine halbe Jahr oder neige Monate, um zu sehen, wie es geht.
Ja, und mit dem, ich denke, wir haben es.
Und danke für alle, für die Tuneung wiederholen und sehen uns bald wieder.
Bis bald.
Join the discussion on LinkedIn or visit our website where we publish all episodes.
For questions and inquiries, feel free to reach out via LinkedIn.
Thank you for your time and see you in the next episode.