# AI-Native Engineering: Product Engineers and SaaS Disruption

**Podcast:** Software Architektur im Stream
**Published:** 2026-09-23

## Transcript

A note from our team.
Software Architecturum Stream will be streaming live from the ISAQB Software Architecture Gathering in Berlin this November.
Join us on-site.
You'll find more about the program and special discount code for our community on our website, software-architectur.tv.
Yeah, so welcome everybody to another episode of Software Architecturum Stream, this time with Senda, so great to have you on the show.
Before we actually get started, there is one announcement that I want to make.
So my colleague Lukas has started sort of a sister stream, which is called Machine Room.
So that is going to be more Machine Room in English.
So this is going to be more about concrete technical things while we will continue to do the software architecture stuff in this stream.
Okay.
So Sander, did you want to say a few words about yourself and thanks for joining by the way?
Yeah, thank you for having me again.
Yeah, what can I say?
Well, I am a software developer by nature and also a software architect and I've been writing code since 1987.
No, that's basically when I started making money with it.
So I've been writing code for a very long time and things have changed over the last Let's say a year, a lot.
But that means we still write code, but in a different way.
I used to work for large consultancies for a very long time.
And I went freelance like 15 years ago.
And since then, I've mostly been doing CTO roles of smaller companies because I like to work for smaller companies because that gives me the opportunity to both deal with the strategy of the company and still write code with my team every day, which I do.
Und dann habe ich viele Talks, ich habe viele Konferenzen, ich habe ein paar Bücher.
Ich habe drei Kinder, ich live in Amsterdam und habe eine wirkliche Frau.
Und die lustige Sache ist, als ein Developer, ich live in der Java Street in Amsterdam, die natürlich nach dem Indonesischen Islander, weil all die Straßen in meinem Neighborhood sind nach Indonesischen Islander.
Aber es ist einfach ein Coincident.
Ja, das ist mir.
Und ich arbeite für dieses Unternehmen called iBoot.com, ein e-commerce company, in sechs Ländern, Deutschland für eine.
Und es ist ein sehr interessantes Unternehmen, weil es daily gibt, verschiedene deals.
Es macht uns anders, von einem technologischen Perspektiven, als bei anderen e-commerceen Unternehmen, wo Marketing Tools, für instance, kann mit der Sachen, wenn es online ist, wenn es online ist, wenn es länger online ist.
because then they can see what recommends and what people visit and et cetera, et cetera.
However, we take most of our deals offline after a day, you know, because they're sold out or not.
But that means it's really hard to connect to default tooling, which means you have to do a lot of stuff ourselves, which is really nice.
And that makes it a very interesting challenge to work here, actually.
Yeah, great.
And you will also talk about...
So this is one of the episodes in preparation of the gathering that will be in Berlin on the 16th to the 19th of November.
And we have a special discount code.
So it's SATV underbar 15 for 15% off to any ticket.
And we will also be, I mean, I will also be there and we will have live stream from there.
So that's how we got started about this.
Exactly.
Okay.
At that conference you will talk about surviving the AI native era.
And there are quite a few things that, as you said, that you changed during your way to AI-based development, I guess.
And you just said before the stream started that this is a journey and you're doing things differently all the time.
Und ich habe ein paar notes.
So in your abstract, you said that you're now doing trunk-based development instead of pull requests.
Why and how is it different and how does it relate to the usage of AI?
Oh, yeah, good point.
Well, we've been doing trunk-based development for a very long time already, like probably a decade or more with different teams at different companies.
And it's basically...
You could say it's part of that journey.
And that journey for me started a long time ago when we were still doing Waterfall.
And the ways of working with Teams has changed throughout that 40 years in this industry.
And I think that's in its core what Agile is about.
There's a lot of posts nowadays and voices that say, yeah, but Agile is death.
Ich glaube, dass Agile sehr gut ist, weil Agile, in mir, bedeutet, was in der Main Statement sagt, dass wir uns überholten bessere Worte von der Software entwickeln.
Und das hat nicht verändert.
Und nichts, was mit dem, macht man mehr Agile.
Was ist das?
Das ist die Framework, die Leute in der Formen verwendet, um ein bestimmtes Weise zu arbeiten, die sich immutabliere, Those are dead, basically, because what I see is that the more we move into the AI era, the more the ways of working diverge instead of convert.
So it's like, if I look at my team nowadays, and we talk about this a lot in my team, is that we see that where we put our basis is very strict, right?
We have everything automated from, we know what our architecture looks like.
Wir haben ein Microservices architecture, so wir haben über 160, 170 verschiedene Pipelines.
Aber sie sind alle der gleichen, sie sind immer der gleichen.
Das ist immer der gleiche, die wir uns alles zusammenstellen, die wir uns alles zusammenstellen, die wir uns alles zusammenstellen, die wir uns alles zusammenstellen, die wir uns alle, die wir auf jeden Fall haben, die wir auf jeden Fall haben, in der Produktion, um sich alles in der Produktion zu sehen, ob alles in Produktion läuft.
Das ist ein sehr firmes Basis für die Entwicklung des Software.
So, bevor AI hit uns, so let's say zwei, drei Jahre ago, wir hatten alles sehr viel standardized.
Das bedeutet, ich könnte ein bisschen code schreiben, wenn ich mein Unit Test habe, und ich checkte es in, die Pipeline ran, und es würde in Produktion in 12 bis 15 Minuten später, literally.
Wir waren voll, continuous deployment für quite some Zeit bereits.
Und wir haben es um, so mein Team und ich, wir haben seit sechs Jahren schon seit Jahren gearbeitet.
Und wir haben es in so viel Automated gemacht, dass wir von, sagen wir, ein paar Commits per Day und ein paar Pushes per Day zu über 100 Pushes per Day zu Produktion.
Und wenn die Pipeline war green, dann geht es um Produktion all die Zeit.
wie Sie haben Ihre Veränderungen in 15 Minuten, in 15 Minuten, und das nur wegen der schlone der Pipeline, nicht wegen der Speed, die wir entwickelt, das Sie schneller gehen.
Und die schneller die Feedback-Loopse sind, und die schneller die Feedback-Loopse sind, die wir zu Business und Backlöp sind.
the more trust you gain with the people in the business.
If they can say, okay, actually we want this and this and this, and then we can say, okay, we'll have it ready for you this afternoon.
And that means that for them, their thought choice shifts from, I need to tell them everything now because otherwise I will never get it.
On having sprints, which we also don't have, people are a bit like, yeah, but if I don't tell them now, Ich bin afraid, dass ich nicht mehr getet habe, was ich will.
Aber wenn man sich das, kann man das und das sagen, ja, okay, wir machen das und haben das in der Nachmittlung für Sie, das bedeutet, dass man sie sich relaxieren und sagen, okay, ich will das jetzt.
Und dann haben wir das später.
Und das verändert sich die Perspektive.
Trunk-Based-Developung ist ein Teil davon, weil die kleineren oder die kleineren cycles, the smaller the features are that you want to implement at once.
And once you learn how to break them down into really tiny pieces, that means you can pull the code from the repo, make the change and push it back again without anybody else touching it in the meantime.
Now, that gives you a bunch of constraints and also a bunch of consequences that you would like to have is that on trunk-based development, You want to check in as fast as possible because you actually don't want to have merged conflicts.
So to avoid merged conflicts, you make stuff smaller and smaller, which very much contributes to having shorter cycles.
So going to trunk-based development actually means that you're going to be able to shorten your cycles even more, meaning more feedback, faster feedback, meaning you can go faster and faster.
So, going to Trunk-Based Development contributed largely to being more agile.
So, it removed necessity for having sprints a long time ago.
So, we don't have product owners because, well, the people from the business are their own product owner for the stuff that they contribute.
And we are sort of becoming, I call it product engineers.
So, we engineer the actual product of the company.
mit der Business.
So, es ist sehr wenig.
Es ist kein Mann in der Mitte mehr.
Und das ist wiederum.
So, wenn du eine e-commerce-companie bist, wie wir sind, du willst, wie wir sind.
Es gibt andere Unternehmen oder Unternehmen, die sich auf der opposite Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite auf der anderen Seite Meaning they don't have to do this.
But being an e-commerce company, you want to be able to change as fast as possible, right?
If one of the competitors introduces whatever, an AI chatbot for their customers, which a bunch of the larger ones now seem to have in place, then immediately the necessity for us to do that too, basically being FOMO, of course, and that means we can work on it really fast.
And this actually hit us yesterday.
I think we'll have a first version of it ready on Tuesday.
So it's not that we didn't know that it was coming, but we postponed it as long as possible.
So make the decision as late as possible and then build it.
So that all nicely falls together into a very different way of working.
And then moving into the AI era, well, that changes a lot again.
And that changes daily, basically.
Yeah.
So, I mean, I really like how you made the point that Airchild is not like the one prescribed way like Scrum, but it's about constant improvement.
And I also think it's a very important point that you made that a trunk-based development even means more speed and is sort of the ultimate version of Airchild in a way.
But I mean, basically the subject of what we were going to discuss is AI.
Und der Punkt, in der manchen, ist, dass es so viel speed-up ist, dass du kannst, bei dem Sachen wie trunk-based development, proper agile development und so weiter.
So, do wir eigentlich need AI?
Weil, ich meine, wenn wir einfach trunk-based development und proper agile processes machen, sind wir bereits quick.
So ist AI wirklich die Sache, die wir brauchen, um eben quicker zu bekommen?
Das ist eine gute Frage.
Quicker is one of the things that AI could bring.
I think what it even more brings is the possibility of doing things that we couldn't do before or didn't have the time to do before.
Okay.
Yeah, and it also brings quicker, actually.
I was actually thinking about if we are actually increasing in speed and our management team, of course.
Wir wollen das in eine Chart sehen.
Wir haben eine kurze Investitionen über die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die Nutzung auf die N a relative understanding of what you're doing.
And software development has always been hard to estimate.
But I think what it...
So the journey towards or moving to, let's say, agentic coding or whatever the phrases we use these days has been a very interesting journey.
And we've been there from the start of when it started to get popular to use for coding.
So that's probably a year and a half, two years.
Und wir sehen, so ich habe, ich habe, ich habe, ich habe, dass wir mit AI arbeiten, für eine Zeit, und das geht, und das geht, die Insights, dass ich heute habe, oder eigentlich, so ich war, ich war, ich habe, ein, ich habe, in Kroatien, und ich habe, ich habe, mein completeer Talk, so die Titel war, aber die Konten, die war, die andere, die ich habe, war, die ich habe, das war, die ich habe, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, das war, There is no way that I can now create a talk for a conference and use the same talk for half a year or a year because it will be outdated.
And if I look at previous versions of these talks from like a year ago, we were still trying to figure out what's an MCP?
Should I write code with AI?
Can it write my tests?
And all these very basic questions.
And that has changed tremendously over the last, let's say, six months.
Basically, since Claude came out, that was the big game changer for writing code, I think.
And now everything is...
Not so much about, oh, there's a new model.
Let's move to the new model.
We do that all the time.
We're not even in my team all on the same model anymore.
So we use different LLMs with different tools and different harnesses.
And I think what opened my eyes is when I started...
und tun Dinge, die ich nicht vorher hatte.
Ich will Ihnen einen realen Beispiel.
Wir haben eine UI-Library, die wir auf unserer eigenen UI-Library haben, die ist Open Source.
In der Chinese-Livärie ist es, die Nd.
Es ist die Alibaba UI-Framework, die ist ein sehr guter Framework.
Wir haben das sechs Jahre alt.
Weil du nicht wollen, deine Form Componenten, deine Table Componenten, die mehr complex sind.
Und für ein paar Jahre, ich wollte es auszudrücken, weil es ist ganz groß, die schlusser die Verlöding der Website, etc.
Und über die Jahre, ich kam zu den Punkt, dass ich wirklich wollte, ich möchte, unsere Table Componenten, stattdessen zu verwenden, so es wird viel leichter geworden.
Und immer noch mehr.
Don't do it because it will eat a lot of your time and it's not worth it.
And then when Claude came out, I was like, I should probably investigate if I can now build our own table component.
So I did.
And it took me about three, three and a half days.
And then I had a fully functional table component with everything in it that was also in the component we borrowed from Andy.
Except that it did not have a library underneath and it was only 250 lines of code.
The fact that I could do that in three days and we're now replacing all the other table components that we have with ours, it's actually faster even.
That was a thing that I couldn't do before.
And we've been on that path in a much larger extent.
People started building their own tools.
There was a guy on my team who said, you know what, I'm going to build a notification thingy on my Mac that notifies me when one of my pipelines fails.
Und an das Punkt in der Zeit, und ich bin jetzt noch ein Jahr lang, vielleicht, ich war, oh cool, soll ich das tun?
Ja, okay.
Und dann, wir haben und auf und auf.
Und jetzt, wenn ich mich an, was wir heute machen, ich bin in der Office jetzt und ein Team ist, ist es neben mir.
Das Woche, literally das Woche, er hat seine Idee gelegt.
Er hat sich weg von WebStorm, weg von VS Code gelegt.
Er hat eine sehr spezielle Workflow in der ich wie ich, um die Gartrails zu arbeiten, wie wir das Architektur machen, wie wir das Pipelines testen, etc.
Aber ich habe eine, ich mache eine mehr Komplexe Dinge, so ich möchte, um zu schreiben, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen, um zu machen.
Literally this week, his own IDE.
And that is not something I would ever have imagined to be able to do.
And the funny thing is, I was looking at it, I'm like, yeah, I actually also have my own way of how I work and how I work with the AI.
I'm also going to do this.
And he says, well, you can clone mine.
And I'm like, yeah, but my ways are slightly different than yours.
I'll build my own IDE.
Ich habe meine eigene eigene eigene Idee und wir waren an das Punkt in der Zeit.
Also, unsere Zusammenarbeit mit der Business hat sich verändert, weil sie auch Vibe Coding haben.
Das bedeutet, dass die Leute von der Beyer community, sie sind eigentlich zu uns, hey, kann wir haben das?
Und dann haben sie einen vollständigen Prototypen, die natürlich nicht all die Neues ausgesucht, aber es funktioniert.
Very good at what they need.
So they thought about it and instead of coming to us with a bunch of requirements, they come up with a working prototype.
So it changes so much in how we work.
So concerning that point, I mean, what you seem to be saying is we are now doing stuff that was not possible before because it was just too much.
Far too much effort.
I mean, you gave the example of the IDE, you gave the example of the table component.
And I mean, there is the fear in our industry, I guess, that all the developers will be out of a job in the not too distant future because of AI.
Now, what you seem to be saying is the additional productivity is just invested in doing more stuff, stuff that wasn't possible before.
So, what do you think?
Will we have more developers that are unemployed?
Will the total number of developers decrease?
Or will we have something like you seem to be experiencing in your company where you're now doing stuff that couldn't be done before and the number of developers, I guess, probably you're still even hiring.
So, the number of developers stays constant or even increases.
What do you think will happen in the industry and what happens in your company?
Yeah, this is the most difficult question to answer, of course.
And it's the question everybody asks themselves, right?
And it's rightfully so.
To be honest, I don't know, actually.
It's very hard to predict where we're going.
So on one hand, I see that a lot of the...
Das ist nicht ein Marketing Talk, das ist was ich in meine Codebase.
Es ist wirklich, die Code I'm writing heute sieht gut aus, und es fit into wie wir das tun.
So, die firmer Ihre Basis ist, die mehr du kannst, AI.
If you are already in quite a mess without AI, then you will stay in that mess because AI is not going to make it better than it was.
So if you have 20 million lines of code, legacy code based in COBOL or Java or whatever other languages, it doesn't matter, that's still going to be tough.
So that's one aspect of it.
The other aspect of it is, of course, what I said is that we can do things that we...
Das ist es nicht möglich.
We use Vouchery 5 for coupons, basically.
So they provide a service, which online we pay for that.
And we're actually looking into that.
This is not super complex.
This is a domain we could tackle as well.
So that's another aspect, is that more and more developers at those kind of companies will be, well, those kind of companies are going to slowly, well, fade out, basically, a lot of them.
Wenn du Atlassian für ein Beispiel hast, Atlassian ist ein guter Beispiel.
Die Leute in der Business hier an iBoot haben, die ihre eigenen Dashboards haben.
Sie verändern, die Sachen auf Kanban-Boot haben.
Sie haben ihre eigenen Kanban-Boot auf dem ganzen Kanal.
Und sie haben jetzt ihre eigenen Dashboards.
Ich bin nicht sicher, ob das eine gute Idee ist.
Aber Tools wie Jira werden obsoletet, weil sie das alles machen.
Und das heißt, es hat alle die Features.
So, wenn du 10,000 Features hast, du bist, aber wenn du nur die Fakt hast, dass du ein Items move auf dem Board und das du kannst, oder ein Team oder ein Team oder ein paar, und geteignet, dann wird das bei ihnen selbst.
So, das ist eine andere Schiff, die ich sehe, dass die Leute aus dem Weg von Standard Tooling, Standard Apps, Standard Websites, sogar.
Und die ganze...
Das ganze Landskapel von wo wir mit tech sind, ist rapid changing.
Und für den Developer Perspektiven, das ist, auf der einen Seite, da werden, well, jobs lost, auf der Seite.
Aber auf der anderen Seite, die viele neue Möglichkeiten haben, werden wir mehr, sagen wir, von der Business-Business aussehen.
Und ich sehe das auch, dass Leute get...
sehr bright, neue Ideen.
Wir werden eine Loyalty-Platform, wahrscheinlich, sehr schnell.
Und das ist die Sache, dass ich nicht gedacht habe, sechs Monate ago.
Aber jetzt die Business sagt, hey, wir können das hier.
Hier ist die Prototag.
So, da gibt es eine multitude von neuen Möglichkeiten, die sich in der Tech immer noch mehr, die sich in der Tech immer noch mehr, die sich in der Tech immer noch mehr, die sich in der Tech immer noch mehr, die sich in der Tech immer noch mehr, die sich in der Tech immer noch mehr, die sich in der Tech immer noch mehr, Time it costs to do coding, testing is diminishing.
So you also see that.
So it's pulling in both directions.
So where it will end up, I have no idea at this point in time.
So thanks so far for answering the question.
I would like to boil it down to a yes-no question.
And I'm not sure whether you're allowed to answer it.
So obviously your company is very invested in AI.
I mean, that's basically what we're talking about.
So do you still hire new developers?
Are you still increasing headcounts in development?
No.
In engineering?
No.
But then I also have to tell you the story about that is that I came to iBets, iBoot six years ago and we were, it was a very interesting situation because they had...
a landscape full of tools and packages and solutions and that was all syncing data and so forth as a result they could not or we could not for instance deploy new versions of the app or the website so they got totally stuck so at that point in time I was working for a company that built the very first smart thermostat in the world I think and that company was taken over by large energy vendors so my team and I decided to sort of move so I Ich bin mein Team, ich bin zu iBoot und wir merged mit dem Existing Tech Team mit einem Team von 12 Leuten, an der Zeit in der Zeit.
Und seitdem, wir haben dann automatisiert, wie viel in unsere Workflows in der Zeit.
Das bedeutet, wir konnten sehr viel auf die Probleme zu lösen, stattdessen zu machen, die all diese Boilerplate Infrastruktur Pipeline.
Wir hatten das unter Kontrollen ziemlich schnell.
So, as a result, we started to be in sync with the amount of work that came at us.
And we put some mechanisms in place to keep that in sync even better, which means that the speed at which we produce new features and new products, etc., etc., is very much on par with the speed at which the business can come up with new ideas.
As a result, we didn't have to scale the team because we automated as much as possible.
A lot, actually.
Probably much more than most companies can do because we're not a super big company, right?
So, therefore, we didn't need to grow the team.
Also, on the other hand, is that there was no churn because my team works with a very high level of autonomy.
So people can make their own decisions, to do their own design, their own architecture within the guardrails that we have.
So people actually quite like it here.
So nobody left.
Except for the first two months when the people who are already leaving left, right?
But nobody left.
And in the meantime, we grew the team with three junior people who are now fully merged into the team.
Aber das war einfach über die Zeit.
Und ich habe nicht mehr Hiring oder Scaling gesehen.
A lot of companies, Sie sehen, wir müssen auf drei bis fünfmalen, oder was wir jetzt haben.
Und ich immer wundere, warum das ist.
Und ich denke, aber das ist mein Personal Opinion, ist das, dass die meisten Unternehmen, die das Scaling haben, sind in der IT-Landscape already, ob das Architektur, ob das in Code, oder nicht haben Tests, oder nicht haben Pipeline, oder was.
It's usually therefore that they want skill, not because they need suddenly an explosion of new software.
So we haven't been hiring at all actually in years.
So it's not that we're growing the tech team.
And that's not just because of AI, but just because we don't need it.
Yeah, but probably the sort of sum up that I take away from what you're saying is Wir sind nicht growing, aber das ist wahrscheinlich weil es ein Problem ist, dass es nicht die beste Lösung ist.
Das ist ein guter Bezug auf das.
Das ist ein guter Summary.
Das bedeutet, es ist nicht unbedingt etwas, was es tied zu AI ist, weil du gesagt hast, es geht um Automation und die, let's say, der traditionale Weise, dass wir alle wissen, wie wir alle wissen, wie wir auf wie zu bauen, wie wir effectively und effiziently haben.
und das Sie können ohne AI tun.
Das macht viel Sinn.
Hier ist eine Frage von einer LinkedIn-User, zumindest nicht hier.
Sie waren über die Produkt-Engineer-Concept.
Ich habe zu sagen, dass das das, ich weiß, 20 Minuten später.
Und die LinkedIn-User sagt, dass Sie die Produkt-Engineer-Concept haben.
Das ist interessant.
So, kann Sie die Produkt-Engineer-Concept elaborieren?
Ja, ja.
So, the way we work...
Okay, let's start with what's a good story to tell.
In most companies, the amount of work that people require from their tech or IT or whatever you call it is more than they can handle.
There's always more work that we can chew off.
That means you need to prioritize stuff.
So, we've put in place a bunch of mechanisms to...
where people from the business or even from outside the company, but that rarely happens, can propose new ideas.
So for instance, our CEO says, we need to have an AI chatbot.
That was the example I gave before.
Or very recently, we implemented Apple and Google Pay just because it was posted as an idea.
And then we say, okay, so for every one of these ideas, what's the business case for that?
Wir geben es ein paar, in ein paar Wochen oder ein paar Wochen, oder preferably ein paar Tage, aber wir rarely machen das.
Und die Business hat sich mit, was die Wert ist der Wert von dem?
So, wenn wir Google Pay und Apple Pay machen, wie viel mehr wir convert werden können?
Und dann gibt es eine Gruppe von Leuten, die wir callen TechBoard, die all die major stakeholders in der Firma.
Und jederzeit...
Wir haben mit einem Thema auf dem Board gewonnen.
Und wenn es eine neue Frage gibt, dann wird es eine neue Frage.
Das heißt, all die major stakeholders von der Firma agree auf die nächste item zu picken.
Und als es wird es gewonnen, es geht in eine column.
Wir callen das die Selected-for-Development-Column.
Und das ist die wir kommen.
So, wie mein Team operates?
Just a question.
So that would be a vote by majority or on, on, on, I'm not sure how you say it.
We discuss it.
So we sit together once a week and we discuss and I was like, okay, we have some room.
So what shall we do next?
And then it's the head of finance, the head of marketing, and we talk about it.
So they all agree what the best way would be to spend the next chunk of time that we have available.
Und das ist wo mein Team kommt in.
Und alle auf meinem Team ist wahrscheinlich arbeiten auf etwas.
Und wenn jemand ist mit dem, mit etwas they're doing, sie sehen, die die Börse und wir haben zwei, eigentlich.
So eine mit den etwas größeren Strategischen Themen, so sie haben sie zu helfen, unsere Strategie.
Und die andere mit den kleinen Topen, die sind sozusagen extensions zu existing Software.
From whatever is in the selected for development column on any of these boards, they can pick it up.
And it's up to the people in my team to pick up something that they want to work on, something that they want to investigate, to learn from, or that they have done before, they know the domain, or could be any reason that they come up with, right?
To give you an example, one of my female developers was pregnant and was going on a pregnancy leave.
And she said, well, the last couple of weeks I'm here, I'm not going to pick up any big items.
So I'm going to choose to do the smaller items.
And so everybody, depending on whatever they want to do, can make their own choice.
Even though I'm sort of like the manager of the team, I hate that word.
I don't manage much, but everybody can pick up any topic they like.
For instance, Der ist ein Thema, wir sollten eine Publikum haben, mit einem Shopping Assistant in es.
Einige der Leute auf meinem Team sagt, ich will wirklich nachdenken.
Er sagt, ich will das.
So er sagt, ich will das.
So die nächste step, er macht, oder sie macht, depending auf wer es ist.
Er sagt, die Person zu den Weg zu den Weg zu der Idee.
Er sagt, okay, so was ist es du eigentlich nötig?
Und dann sie sich zusammen.
Und sie arbeiten durch es.
Die Leute aus meinem Tech Team, die alle developers und Architekt sind, weil wir alle unsere eigenen Architekt sind, gehen und die Unternehmen zu sprechen.
So es gibt niemanden in zwischen, nicht nur ein Product Owner, ein Scrum Master, ein Product Manager oder whatever.
Sie direkt zu den Leuten die es interessiert.
So es ist eine sehr direkte line zwischen Tech und der Business.
Und das bedeutet, dass wir den Intent von der, sagen wir, unseren Unternehmen, die wir in der Unternehmen haben, und dann zusammen mit dem, wir testen und sagen, okay, wir brauchen das und wir brauchen das.
Bis zum Zeitpunkt, dass wir die Minimal-Viable Feature für das bestimmte Sache haben, wir es live und dann in addition zu das, wir können auf eine andere Board, das bedeutet, wir nicht mehr machen oder wir können, was es voted für.
So it's a direct connection between us and the business.
I mean, again, that's pretty much best practices from agile, so that's great.
Yeah, true.
And yeah, I mean, it's often talked about, but, you know, seldomly it actually works.
It is actually implemented and it is done.
So that's good.
Aber eine Frage, die mir zu meinem Geist ist, dass das die Tech-People die Features interessiert und was sie interessiert und was sie denken, macht es einen Sinn.
Jetzt, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, in der Art, Well, it actually never happens.
Because we are Stagos, we're part of the company, right?
So we're invested in doing the thing that's most worthwhile to the company.
And because, so there's, the transparency is quite big, right?
So I sit in the weekly setup with the stakeholders.
I'm in there.
People from my team are in there as well.
Und dann wir sprechen über das ganze Tag.
Oh, die Business Now wirklich will das und die Business Now wirklich will.
Und das wurde voted für.
Was du denkst?
So, die Transparency ist ganz groß, meaning die Leute wissen, warum es wichtig ist und warum es relevant ist oder warum es urgent ist.
Sometimes, was es nicht relevant ist, aber urgent ist.
Zum Beispiel, da gab es legislation in Polen, wo wenn du B2B sales machst, You need to go into a government system giving you some code that you need to put on the invoice.
Everything worked without it, but yeah, that's legislation.
And we had to implement it before the 1st of April.
So that becomes urgent, right?
So urgent is also a good argument.
And then people from my team say, oh yeah, I'll pick it up and they'll do it.
They're very, well, trustworthy in that sense, right?
And that's also because we are a very close company, meaning everybody's very close to each other.
Und das Team Spirit ist wichtig für die richtigen Dinge in der richtigen Weise.
So, da ist ein Frage auf YouTube von Itzitsi, ich denke, das ist die Name.
Und da ist eigentlich ein Typer in der Frage, so ich werde nicht zeigen.
Und die Frage ist, was würde die Unterschiede zwischen einem Architekt und einem Produkt Engineer dann?
Because you actually talked about architects and developers or maybe those are the same people, I wasn't really sure.
So what's the difference between an architect and a product engineer?
So in my team, nobody has a specific role.
So that means all of us do all the work that is necessary to get stuff out of the door.
Das sagt, alle in meinem Team haben ihre persönliche Prefereienste, ihre persönliche Strong Points und ihre persönliche Weakten.
Für instance, ich habe eine sehr seniorer Developer auf meinem Team und sie lief zu machen, so sie versucht, sie zu vermeiden, das ist okay.
Und ich habe eine andere Person auf meinem Team und er ist der beste Infrastruktur Engineer, ich habe ever worked mit.
Und ich habe ein Mann, der auf dem Vorfeld auf alles, was passiert mit AI.
Und er hat sich immer noch einen Moment, wie ich jetzt habe, was ich jetzt gefunden habe.
So, jeder hat ihre eigene, ich würde sagen, emphasis auf was sie lieben.
Ich, für instance, ich tinker mit unseren Frameworks und ich liebe unsere UI-Frameworks und andere Leute sagen, ja, ich kann ihn machen, weil er lieben es, und ich mache es.
So, du kannst sagen, dass die Gruppe der Leute zusammen in meinem Team, und wir waren 13 Leute, haben alle die Skills Necessary, um alles vorzunehmen.
Das includes UI, aber das auch includes Architecture.
Das bedeutet, dass es Leute auf meinem Team gibt, und ich bin einer von denen, die Leute denken über Architecture, über die Struktur der Struktur, die Struktur der ganzen Domain und looking into DDD-like Sachen.
Und andere Leute machen das nicht mehr.
Wir sind nicht labeled.
So everybody can do anything.
That said, we have a whole bunch of guardrails when it comes to architecture.
So all of our services and all of our apps have the same software architecture.
So the same layering, the same patterns, the same way of talking to each other.
So all of that is very much standardized.
So that's part of the architecture we rarely think about.
Weil es einfach nur da.
Und immer wieder und dann ist es, wir sollten das auch verbessern.
Oder wir sollten ein contractieren.
Wir sollten ein contractieren.
Wir müssen die Servicesen aus den Central Library ausziehen.
Wir haben solche Diskussionen mit dem Team.
Wir haben die Diskussionen mit dem Team.
Wir haben die Diskussionen.
Wir haben die Diskussionen.
Wir haben die Diskussionen.
Wir haben die Diskussionen.
Let's say no personal ownership to the architecture as well.
So we all contribute to it.
And if I look into my slide decks, we say we're very lean on how we do architecture and everybody's their own architect, which means everybody comes up with a solution given the guardrails we have that best fits the needs of that particular feature.
But I mean, if you talk about things like, you know, should we have a contract between services?
That is something that is Es ist nicht so, dass es eine Person zu machen, die eine Person zu machen.
oder die sind für das?
Es ist ein committee oder ein Grupp das machte die Entscheidung.
Ja, es ist ein committee, das nicht so gut.
Aber es ist, was passiert ist, dass wir, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir haben, wir So this team has been working together for six years and some of the people on the team I've been working with for nine years already.
And even there's a Garmer team who I've been working with for like, well, 12, 13 years maybe.
So we know each other quite well, right?
So we know very well our thoughts and feelings also about architecture and we have a very open culture in the team.
That means that...
Wir können öppenen diskutieren und alle, die zu erinnern, die zu erinnern, die zu erinnern, die zu erinnern, auf die Frage.
Wir haben eine andere, die wir haben, Lean Coffee, die wir haben, every Tuesday afternoon, wo wir die gleiche.
Wir machen die gleiche.
Wir machen die Themen, die sie auf die Bedeutung haben, und dann wir wählen, und dann wir diskutieren für fünf Minuten, oder vielleicht länger.
Wir haben auch die Architektur-Diskussion da, als auch.
Und sie können ausgehen, from typical domain discussions.
One we had recently is about we have offers and deals and they seem to grow very close to each other.
So we're now considering removing everything that has to deal with offers and keeping the remaining part in what we call deals.
Deals is a part of our domain.
So we're rearranging the domain.
So that's more domain architecture.
But also, again, so we discussed Could we give our services a separate library that is separately deployed that exposes the types of that particular service so our clients can use that?
Clients could be other services or they could be front-end applications.
And that's the kind of architectural discussions we also have with the team.
But in the end, we make the decisions as a team.
Und wenn wir nicht agree sind, dann ich die beste, dann kann ich die Korte.
Aber das rarely passiert.
Und ich bin einfach Teil der Diskussion, wie es jemand anderes ist.
Es ist eine sehr gute Art, weil es auch lässt Menschen in ihrer Erwachsenen, in ihrer Abiligung, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen, in ihrer Erwachsenen Wir haben nicht mehr Junior und Seniors.
Wir sind alle da.
Ich habe zu sagen, dass ich in der realen Welt oft nicht so klar ist, dass eine Person macht eine Entscheidung, dass das eine Entscheidung, dass das eigentlich der Fall ist, weil es eine Diskussion ist, und dann irgendwann, alle wissen, was du beschrieben.
Das ist was, was du eigentlich immer passiert, wenn es etwas passieren muss, wenn es ein bisschen mehr Konflikt ist.
There is a question by Riewik on YouTube.
And his original question is, let me extend the previous question with this one.
Is it reasonable to preserve the roads and tides from the pre-AI era today?
And I would like to rephrase the question because if I look at the discussion that we had, is there any impact on...
This discussion, like the roles, how you do the interaction with the business side and so on, is there any impact of AI on this?
Because it all seems, I don't think you even mentioned AI in the last few minutes when we were discussing these roles.
So it's not obvious.
This question basically implies, okay, now we have AI, now the roles are all different.
To me, I had quite the opposite impression.
What you're saying is, or what I heard is, that there are these roles, this is how we do it, and I couldn't see any relation to AI at all.
So what's the impact of AI on this?
That's an interesting question.
So we don't have roles in our tech team, and I haven't.
Ich habe mich immer wieder mit den Firmen, die ich arbeite für.
Ich bin ein Freelancer, so ich manchmal switche positions oder ich helfe, coachen andere Unternehmen auf den Seite.
Aber ich habe immer wieder zu bleiben, weil die Röle Diskussion ist, weil die Röle Diskussion ist, dass die Leute werden ihre eigenen Territory, ihre eigenen Fieferien, und das nimmt die Öffentlichkeit.
We don't actually have roles on our team.
So everybody can do anything that they think will help the company.
And whether that's me or the most junior person I have.
But that was also before AI.
So before AI, we didn't have roles.
And after AI, we still don't have roles.
We have...
Wir haben unsere eigene eigene eigene Skills, wir haben sie und zusammen das eigene Skills ist sehr komplementar.
Und da gab es keine Nutzung für Roles und da noch nicht.
So für uns, AI hat nicht die Roles-Diskussion, weil wir nicht haben, dass wir in anderen Unternehmen haben.
Mein ehrliches take ist, dass in Unternehmen, die sehr separate Roles haben, which I try to avoid anyway.
But I think there, again, AI doesn't change that discussion either.
I think we are moving more into not writing code ourselves.
I haven't written a handmade line of code.
Well, I do write one or two per day, but that's about it.
So we slowly move away from writing code ourselves to...
helping a tool write code.
So the specification language is not anymore TypeScript or Java or C Sharp or whatever language you have.
It's now, in my case, English.
It's less precise, but it's good enough.
So we moved to a higher level language for specifying what the software needs to do.
But that's, I think, the biggest change so far.
That doesn't change the roles.
We're still solving problems.
We're still solving business problems, and that hasn't changed.
So I don't think AI has a huge impact on roles, unless you have like 40, 50 different roles, then there's probably roles that are changing or disappearing.
So I really like the point that you made that there is now English or German or, I don't know, Dutch as the language in which you define what needs to be done.
One thing that I keep wondering about is, I mean, this is something that a non-technical person could do, like someone who didn't study computer science and never wrote any code.
So to maybe put it bluntly, why would you have developers then?
Is there anything that sets a developer apart from a business expert that could also come up with these definitions in English or in natural language?
Even more advanced, we've actually been trying to teach people from our business to vibe code.
And some of them pick it up, some don't.
So there's still a fairly large group of people in the world that even with AI is not able to build software.
I was listening to some talks at the conference in Zadar, the Shift Conference, where I was this week.
And there were companies saying, yeah, we are going to...
Das heißt, es gibt alles, was es möglich für non-tech-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec-tec Wir sehen, dass ich die Dangerschaft von everybody zu schreiben, dass sie jetzt schon so machen, ist das alles jetzt eigentlich das.
Sehr gut, die non-technicale Leute sind.
Ich habe tatsächlich die Leute auf unserer Marketing Team, die ihre eigene Idee gebaut.
Marketeers, right?
Die gebaut ihre eigene Idee.
Und das ist insane.
Wenn du über das zwei Jahre alt hast, das war unimaginable.
So now what happens is that people from the business come to us with almost fully working prototypes, which is the specification language that they now use, even instead of English.
So they come up with the ideas themselves.
Look, here's a webpage that does sort of what we do.
Can you put it in production?
And there's the difference, is that we know how to put stuff in production.
We know about, oh, it needs to be multilingual.
Oh, wait, we need to use these frameworks, or we need to use...
Think about security rules permissions, about where does it fit into the domain?
How can we sort of keep the integration together between all these separate tools that people are building?
And that's our work.
That's what we do.
So for now, I think that we're going to keep on doing this and transforming prototypes into actual working enterprise software.
And there's still a big difference.
Whether that's enough to keep us relevant, I don't know yet.
But that's what the future needs to point out.
But it's almost impossible to predict where we'll go with this.
Yeah, I really like the idea that you say.
I mean, in a way, what you said is that business experts are able to write prototypes, but it's different from stuff that goes in production.
And that's the difference.
I think the difference between software engineering and software engineering.
was business people can do.
So that's great.
There is another question by Rieewik on YouTube or a comment rather.
So he says, I think why we still have the roles like developer, engineer, PM, PO, etc.
due to accountability and responsibility for what we deliver.
Okay.
Und das wäre nur eine Person.
Aber es ist eine Schade-Responsabilität.
Ich bin nicht sicher, ob das Wort applies.
Ich denke, dass wir sehr auf den Vorfahren arbeiten können.
Und unsere Wahlen haben sich auch auf dem Weg geholfen.
Wenn du mich 15 Jahre fragt, dann würde ich sagen, ja, oder 10 Jahre, du musst eine Product Owner.
oder Product Manager oder jemanden, und jemanden, die ist accountable.
Und ich denke, die Verantwortung jetzt ist mit den Leuten, die die Features kommen.
So das ist, in unserer Fall, die Leute von der Businessen direkt.
So, wenn wir implementieren Google Pay, dann ist die Finanz Manager der Verantwortung für das Fakt, dass das Ding läuft.
So, er ist responsible für die Faktor, was wir eigentlich brauchen.
In most cases, it's the marketing department.
So the marketing manager needs to take things into account or we do stuff for our content department and it's their feature, right?
And we build it together with them and they are going to give the final approval.
And that's for every feature that we do.
So it's a shared responsibility between the sub-team of my team that implements something.
mit der Person von der Businessen zu tun.
Das ist eine sehr direkte Art und wir tun das, weil wir das speziell, weil Speed für uns ist sehr relevant.
Wenn du in eine Organisation mit 300 Teams hast, wie wenn du für eine große Banken, oder sogar eine große E-Commerce-Company hast, haben wir ein viel mehr, wir callen sie, enterprise-y Dinge in place in der Weise, die wir nicht brauchen.
Das ist, für mich, eine der Reise ich nicht für sehr large Unternehmen, Das ist nicht etwas, was ich wirklich nicht so lieb.
Ich habe das für ein lange Zeit gearbeitet.
Ich habe für 20 Jahre gearbeitet.
Sie arbeiten für große Kunden.
Und das ist alles gut, aber ich bin nicht in diesem Weltmeister.
Für mich, die Rolle haben sich nicht mehr verstanden.
Da ist eine andere Frage, also von der same Person, Rie Eivik.
Das geht zurück zu der Diskussion, die wir hatten vorhin.
ZAS providers and the people who work on standard software.
And what he says is, I think the traditional enterprises like Adobe, where I work at, Autodesk, Atlassian, etc., or ZAS providers in general, have to update their organization structures, roles and worker skills if they want to survive.
And to me, what...
Okay, because what...
Was ich gehört, wenn du über die Unternehmen gesprochen hast, ist, dass sie einfach nicht mehr haben.
Und was du hast gesagt, oder was ich gehört, war, okay, wir sind nicht mehr als SIS, weil wir können es einfach nur bauen.
So, no matter how sie verändern, die Rolle in der Unternehmen, wenn sie nicht verändern, die Problem werden nicht weitergehen.
Und das scheint zu sein, was das eine andere Frage.
Should we reorganize?
And it seems what you're saying is the problem is the product and the market.
Yeah, it's combined.
So what I see happening is that a lot of the SaaS providers, and again, a lot of the SaaS providers, especially in the AI space, like we have an AI for this, an AI for that, and we look at it like, yeah, so what?
We can build it in two days' time.
And we're not the only ones, right?
So that means that...
A lot of them, especially the smaller companies, unfortunately, that provide a particular service to other companies, mostly B2B, I would say, are going to be, well, have a very much diminishing set of clients.
I'll give you two examples.
We get a lot of invoices from the people that we buy the products from.
Vendors, suppliers, whatever, right?
And those invoices, they need to be handled, which means we had invoice recognition software that does OCR stuff, which is kind of complicated and very expensive too, because for every different supplier, we had to set up a template that fits their documents so the OCR software could read those documents.
Und über ein Jahr ago, wir haben uns gesagt, wir haben uns um die Anzahl an X amount of Geld um diese Tool in place, das still macht viel Arbeit, weil es nur ein paar Jahre lang kann.
Für alle company, alle supplier, wir hatten eine Template, wir hatten oder hatten wir eine Template.
Und wir haben uns gesagt, was wir einfach nutzen AI, um die Invoices zu machen und zu machen, um die Informationen aus den Invoices zu machen?
Give the rest of it to our finance department so they can fill in the remaining details.
We built that.
It took us two to three people, depending on where we are in the process.
And it took about two months to build the first version.
And after three months, we had a version that replaced about 70% of the workflow that we originally handed off to this external company.
So we stopped the contract.
We have done our own invoice recognition.
And it works.
We haven't touched that in a while.
And there's probably better AIs that support it now.
But those we can build in-house.
I'll give you one more example.
There's a company that does translations.
And we use that for translating our content, translating commands made by customers, et cetera, et cetera.
And we pay them a lot of money.
Then we move to AI-generated content, AI-translated content, which means our bill with that particular company went from 6,000 Euro per month to, I actually approved the invoice yesterday, to 280 Euro, right?
So that difference in money needs to be accounted for in those companies, which means they don't have the money to pay large amounts of people to keep that company alive.
It's the same that you will see with the Atlassians of this world and all the other service providers.
They're going to shrink, basically, due to AI.
Okay, but I mean, when you started talking about these two examples, you said that it's not just that the product is dead, but now you gave, or that's at least what I understood, you gave two additional examples where the product is sort of dead.
So is there anything that those companies can do in terms of reorganizing internally, having other roles?
I mean, it still seems to me that what you're saying is, well.
Ich denke, dass viele Unternehmen in der SaaS-Sache sehen werden, dass es sich um die Produkte zu einem neuen Produkt gibt.
Und zu einem großen Stadten.
Weil jetzt alle denken, wir können das selbst bauen.
So als resultatze, es wird weniger Income.
Als resultatze, es wird nicht mehr profitiert.
A lot werden sie nicht mehr profitieren, wenn sie ever waren.
Das bedeutet, dass sie nicht mehr verhäten oder sie re-organisieren werden.
Das ist nicht gut für viele Unternehmen, dass sie das nicht gut für viele Unternehmen.
Let's put es das einfach.
Unfortunately, weil sie auch nice Leute und nice Unternehmen sind.
Wir haben uns auch noch ein Konfluence Billen, die wir uns noch nicht mehr nutzen können.
Wir haben uns noch ein paar Wики für Keepen Content.
Wir haben uns noch ein paar Wики für Keepen Content.
Wie viel wir noch noch nutzen können?
The few cases that we use it, why don't we build it ourselves in a couple of days?
And if you only use a few features of a particular product, then you could easily rebuild it these days, right?
And it doesn't even require tech people.
However, if you are a user of 100,000 features and you have your full tracking in place on everything and whatever you do, like large enterprises do, then you're probably still relying on Jira for the rest of your lives.
Wir werden nicht tun, wir werden wegnehmen von diesen Tools.
Tools wie das zwei Jahre alt waren, so standard waren, dass wir nicht mehr haben, und jetzt we realize wir nur eine kleine portion von all den Features gibt.
So warum würden wir all das Geld für das?
Und wir sind nicht die nur diejenigen, die denken wie das.
Wir sehen das überall.
Final question from Mark Dehaan on LinkedIn.
Big thing I'm wondering is about the number of people who do this, who know how to put stuff in production.
That is about, you know, the difference between engineers, product engineers and business people.
And the question is whether the number of those people who know how to put stuff in production will increase or decrease in the coming years.
Trends that I see seem to be pointing to a reduction, but that might mainly be a macro development.
So what do you think?
We're going to have more or less people who know how to put stuff in production.
Yeah.
Hard to predict the future.
Yeah, that is tough.
But what I see is that, so one of the developments we are doing currently is we are building a, let's call it a sandbox.
We call it a sandbox, where everybody else in the company kann das alles, was wir haben, die wir mit dem APIs verwendet haben, oder von externalen Parten, so dass sie ihre eigene Dashboarden, ihre eigene Software, oder was sie.
Aber das muss sich in den Boundaries von iBoot sein.
Wir sind jetzt die Sandbox, so dass die Leute das tun können.
Und ich denke, die Enablinge von Leuten, die keine Ahnung haben, wie sie in der Produktion haben, ist es ein großer Teil der Arbeit wir tun.
Wir als tech-people müssen, dass wir die Software-SafWare haben, und nicht einfach deployen mit einem Postgres-Database, mit einem Cloud-Postcast-Database, mit einem PIDO-123-Tab.
Ich denke, das ist ein Teil unserer Arbeit.
Das braucht ein paar Leute.
Ich denke, es braucht sehr skilled Leute.
But I'm not quite sure whether we require the same amount of people.
I think we probably need less people.
But there's a counter-side.
I'm sorry.
I mean, the other point is, if I consider myself a product engineer right now, I can also become a domain expert.
So that would be the other option to me.
The question sort of could imply, well, I'm now a product engineer.
Will I have a job in some years?
And the answer might be, okay, if you change to the more domain side of things maybe you have, maybe that's an option.
And I would even argue that has always been, it doesn't really understand the domain at all.
So I have to have a different skill set.
I can't specialize in the domain.
That doesn't make any sense.
True, true.
Yeah.
Yeah.
I'm not, so.
Ich denke, das ist wahrscheinlich ein mehr architecturaler Punkt, ist dass wir, was wir noch immer noch tun können, als der Produkt Engineer, wir übersehen die ganze Sache, die ganze Plattform, die ganze Domain, die ganze Landschaft, während die User aus einem bestimmten Department, in unserer Fall, wie Finanz oder Marketing oder Logistik oder...
They mostly oversee their own part of it, which is just a small part of the domain.
So we have to take care of that everything still works together.
And that's part of being product engineer, product architect, whatever you might call it, that people from the business are not going to do.
So in that aspect, and that's a large part of it, that's domain engineering, domain design, that is very much still part of our work.
Because we know when we register a claim to where it sits within the orders and the offers and etc.
And people from the business rarely oversee all of them.
And that's okay.
They do other stuff.
So we have actually done quite some overtime today.
So thanks a lot for answering all the questions.
Also thanks a lot for the discussion in the chat.
Das ist über das.
Ich bin nicht sicher, ob es da sind, ob es eine finalen Bemerkung gibt?
Nein, so was ich basically sagen, ist, dass eine Sache in meinem Slide Decks ist, die Just Sharing Principle, und das sagt, dass die Sachen, die ich Ihnen über sage, ist die Sachen, die in unserem Kontext funktioniert.
Und ich habe sehr viel gelernt, dass in der anderen Kontexte alle anderen Kontexte ist sehr unterschiedlich.
So that sort of eliminates the discussion like, no, that will never work for us.
Yeah, that might be true, but that's what I just said.
So it's like, there's nothing that works for everybody and that's good because that keeps it fun.
Yeah, thanks a lot.
I think those were excellent final remarks.
So thanks a lot.
Thanks a lot for taking the time.
Thanks a lot again to the audience for the questions and the discussion and hope to see you at the Software Architecture Gathering.
As I said, there is a rebate.
Und wir treffen uns da.
So, danke sehr und ein tolles Wochenende.
Danke.
A note von unserem Team.
Hallo Software Actual Stream listeners.
Mein Name ist Lukas und du kannst mich aus ein paar Episodes hier kennen.
Ich will starten ein Podcast auf Maschinenraum, die wir auf Web-Developments, Operations und Design focussen.
Du wirst die ersten paar Episodes auf diesem Channel hören, aber wenn du nicht mehr eine Episode in der Zukunft wirst, kannst du bereits abonnieren auf Maschinenraum.fm.