Developer Productivity, Platform Engineering & Architecture with Dennis van de Laar

Hi everyone, my name is Patrick Akio, and if you're interested in developer productivity, platform engineering, as well as the role of an architect in software development, this episode is for you. Joining me today is Dennis Vandalon. He's an Azure App Dev Specialist at Microsoft and I had such a blast this conversation. Lots of laughs, lots of funny anecdotes, so I'm sure you'll love it. Enjoy beyond. Coding. So how was it catching up with

the with JP? Yeah, it was fun. Yeah, it's fun. It's a it's a very energetic person, right? So yeah, we only spoke, let's say, 5 minutes because, yeah, I had to go downstairs because you were waiting for me, right? No, but I I worked with JP for a year and I think that one of the first times that I met JP, we directly went to the US for an Executive Briefing Center meeting. Yeah. And I really like this guy. A lot of energy, very positive. Yeah. So it's good to see him again.

Absolutely. Yeah. Yeah. Yeah. It's really good. Yeah.

You mentioned Executive Briefing sent what? What is that? Cause I've heard that twice now. Yeah, that those are sessions that we organized with our customers. So we invite our customers to come to Redmond or to Munich and we craft an agenda depending on on, on the strategic objectives of our customers. We craft an agenda, It can be about security, it can be about software development. And then we invite our

customers. We have a full agenda and we discussed the most important topics for our customers. It can be new stuff, it can be how we do stuff internally to inspire our customers. That's that's the idea. Of the EBC? Yeah, that makes sense.

One of the first kind of topics I wanted to touch on was kind of what it's like working at Microsoft and the, I think the bigness of the organization. Like everyone always talks about Fang, like Facebook. Yeah, Apple, Amazon, Netflix. Yeah, Google. Yeah, Microsoft. Microsoft is not in Fang. No. Now it's manga, I guess. Or a Magnificent 7. Magnificent 7. Yeah, I've heard that as well. Yeah, but I've never seen it kind of from behind the scenes.

But before we touch on that, how did you get in touch with Microsoft anyway? Cuz I saw you started that consultancy. Yeah, Arfanada was there as well. Yeah. How'd you land at Microsoft? Yeah. So I worked for 12 years at at Avanade. So that's that's almost where my, my career started. And as people hopefully know is that Microsoft, sorry, Avanade is a joint venture between Accenture and Microsoft. So all the projects that Avanade is doing is based on Microsoft

technology. So during my entire career I'm working with Microsoft technology and after 12 years doing a lot of different projects, I've been developing almost applications in the database. You can argue if that's a good good decision, but front end development, CRM implementation, a lot of integration projects with with Biztalk Server or the Windows Communication Foundation framework at that time. So I am passionate about

Microsoft technology. During my career I switched to to Accenture. I did, I spent seven years in cloning at Ross Uni and there was an Accenture project so I was working for for Avanart, but it was an Accenture project at that time. I switched to to extension because Exchange was doing more bigger projects closer to the

business. That's where where my passion is. So I moved to Accenture as an as an architect and I think it was working for two years at Accenture. And then Microsoft reached out, hey, we have an A role available which is Cloud Solution Architect. Do you want to apply for that role? So I applied for that role, started as a cloud solution architect.

I'm working now for five years at at Microsoft, one year as a cloud solution Architect. Microsoft. Every year there there is a change in the organization. So there were there were some changes in the organization and then I was thinking OK, what is, what is, what is my part within

within Microsoft? Do I want to be what we call a swarming architect covering multiple accounts with your speciality or actually you can be an integration expert or Kubernetes expert and swarm across these accounts or do I want to become more a developer focused consultant? OK, let me put it like that. So a new team was started which is called at that time I think it was application development

specialist. So this new team and and and I was invited to talk to the manager of that team who was creating that team and I was really thinking this is where the future is if you ask me. Cloud native development, yeah, this is, this is there will be so many new projects which will be fully cloud native. So this is where I want to be so. Was that the first team that was specifically focused on cloud native technology or?

Yeah, So, So there were people focusing on cloud native technology, but now it became an official team. OK, yeah. And that's that's that's so that team was started four years ago. So I had the opportunity do I want to be swarming architect or do I want to be the the the app dev specialist and and specialist in in within Microsoft means that I'm part of a sales organization. So I start well you can you can divide it in three buckets that's also always how I explain it.

So an an app innovation specialist or an app dev specialist focuses on starting new cloud native projects, OK, modernizing existing applications. And when I say modernizing, I mean leveraging platform as a service components and move away from the underlying infrastructure, right. So you don't need to manage your infrastructure anymore, but leveraging app service or

Kubernetes or whatever. And the third bucket is developer productivity, leveraging our, our tools to make sure that your developers are productive. So yeah, I thought this is, this is, this is my thing, right. So I need to jump to the other team.

And although it is seen as a sales team, if you ask me 20 years ago, would you ever go to a sales team? I would say no, no, that's not possible. That's not me. But how I see this role is, is it's, it's not just saying, hey, we have this new tool. This is a shiny and tool. Do you want to buy it? Right. That's, that's not how it works anymore. Yeah. Yeah, exactly. That's traditional and that's that's not how I see it. And I also see my colleagues working, working in a different way.

You really need to listen to your customers, right, Because we have this toolbox. You can, you can, you can call it Lego blocks, whatever. We have this toolbox of of of great tools, but you really need to listen to your customer and fully understand what their challenges are or what they want to achieve before you can say this is a nice nice brick, it's green, it's yours that that that doesn't work.

So you really need to listen and map their requirements on, on on on the toolbox that you have, right. And that was exactly what I was doing in my consultancy work as well. So that's I see a consulting is the new selling. I don't see it anymore as I have a product and I'm going to shove it up for your throat and this is what you need now that doesn't work.

Now it's not. The best sales people I've talked to on the show and off the show all kind of align with that, that you have to understand what the problem is. And then it might be a good fit, what you have or it might not be a good fit. And the more you say it's not a good fit, the more that kind of contributes to your. How do you say that? Yeah, it's integrity. It's also credibility, right? You build trust in that way and when there is a good match, they'll know it's a good match

because you said no before. I think that's the better way to do it. And it's kind of a newer way also, yeah. Yeah. And it's a win win, right. So because if, if if we help our customers with their challenges, they are successful on our cloud platform, of course it's a win win, right. So the the customer wins and and and we are happy because you're

leveraging our tools. So really fixing the puzzle and that's also what I really like complex puzzles, make make them simple and try to see if you really can help. Yeah. And that's. Yeah. Interesting.

The new. Selling, Yeah. You mentioned four or five years ago you joined this team with the mindset of this is where the future is gonna be, right? Yeah, kind of engineers or organizations leveraging cloud technology to be more effective, more productive with kind of a the lesser cost of ownership, at least where they came from, right. When we're talking about traditional infrastructure, you have to main all of that. Yeah, maintain all of that. Yeah.

Now with cloud technologies, I mean, I love working with stuff that's managed, Yeah. Yeah. Also because then I can work with a smaller team. Yeah. And I don't have big team issues. Yeah, and focus on the most interesting part. Yeah. And also the most complex part and delivering value. Exactly. That's what excites me. Yeah. Do you think it's still is the future? I mean, we're now four or five

years ahead. Our organization's now more and more leveraging cloud because I've also seen this movement and I'm curious to hear what you think. There's a specific guy, I don't know his name, but he keeps posting on LinkedIn stuff about going off the cloud and then saving millions of of costs, basically maintaining his own infrastructure off the cloud. So there's also this off the cloud movement nowadays. Yeah, which is interesting. I don't understand it. Yeah.

No, sorry, I I still think this is the future. Yeah, I've seen, I've seen different use cases where also people on the cloud do a lot with the infrastructure side, right? So they have to manage a lot of stuff themselves, they spin up VMS, cluster of VMS, they deploy different kind of tools on top of it, open source or and they need to manage everything themselves.

And I think if you start leveraging managed services right like like we already said you can really focus on adding value making sure that you have a a backup of your database. It should be one click right or not even it should be out-of-the-box supported. You don't need to worry about it And yeah and maybe it's a it's a fancy term but reduce coconut float make sure that you can focus on building an application that adds value to your organization.

That's what you need to do as a developer if you ask me. And and managing the underlying infrastructure, yeah, I think that's that's when that's a waste of, but it's it's. It's a technical problem. It's, yeah, it's yeah, exactly. That's what I feel like. And what I really like about I I

often use the the Pace Layer application strategy. I'm not sure if you're familiar with that that that structure. Let's lay it out. Yeah. And and and to be honest when I started using it, it had three layers and I and and and and maybe I I heard it's updated I I thought I think there was a fourth layer, but it is the first layer is the system of record.

Well, that's a, that's a term that we all know in the IT industry and those are the applications that are managing the master data and supporting a lot of business processes, important business processes in your organization. You can think of an ERP system and also what what Gartner states is that, yeah, just buy such a system, implement it in your organization, make sure that you use it properly, but don't build it yourself. It doesn't make sense, right?

Yeah, and maybe it's fun to do, but it doesn't add any value. You can buy an ERP system from Microsoft, you can buy it from SAP or another vendor. Don't spend too much time because you will not differentiate yourself from your competitor by building your own ERP system. Exactly. It's not your core.

Exactly. And so the the second layer is the system of differentiation and this is where you can, like the the layer already mentions, this is where you can differentiate from your competitors. So what are the applications that you as an organization, what are your applications that differentiate you from your competitors and that's where you want to custom build your applications, right, because you want to be different than your

competitor. And I think if if we go back to you to to your question, if you can really focus on your application, did differentiate you from your competitor so that you can gain market share, Why do you want to spend too, too much time on managing the underlying infrastructure for that application? Yeah, now you should spend as much time as possible making this app application as good as possible to help your customers and differentiate you from your

competitors. So I think yeah, that's that's how I view it. So I I I see definitely a cloud native development as as as the future And the third layer to to to to finalize the the the model is the system of innovation and this is where you spin up new ideas, you test it, it can be successful. If it's successful, OK then you make it part of your your your IT landscape. If it's not successful, you throw it away and you figure you think about new, new innovative ideas.

And I use that, that that that paste layered application strategy very often in my conversations. Because if I talk to my customers, I'm not interested in having discussions about an ERP system. At least that's not my role within Microsoft.

I want to talk about what are the applications that differentiate you from your competitors and how can we help as Microsoft to make you even better, more successful And that's that's, yeah, that's that's where I'm passionate about talk about these applications. Yeah. That makes sense. That's what gives organizations the edge. Yeah, yeah, exactly. And when you, when you touched

upon kind of the layer of differentiation, one of the thoughts I had was there's also, and there's always been a community of people that love low code to kind of, I mean use as as you mentioned, these building blocks to then leverage whatever they need in a more fast way, right? Talking about productivity, if you don't have to build it yourself, if you can just click it together, then all of a sudden you have an application and you can get up and running

faster. I don't know if it's used kind of in that experimentation layer because I I can see it working and be productive in kind of prototyping something you can throw away and then build a more resilient variant or even that you could argue. But where do you think kind of low code fits in there? And do you still see this trend of low code also kind of gaining market share in that way?

Yeah, I think, I think that low code has has absolutely, if you talk about these three layers, you can build an application which is a differentiating application with low code absolutely perfectly makes sense. It's not only the innovation layer that you say, OK, I'm just going to try something with low code, see if it's, if it's, if

it's working and keep it small. Now I really have customers that are fully focusing on low code and it's an it's a differentiating application for them and they build it fully with low code. So there's definitely part for low code, yeah in this journey. And what's your view on it? I I think I always thought low code was interesting. I almost became let's say a low code developer like very early

on in my career. But then I was like, is this really gonna give me an edge or are a lot of people able to do so? And because of that thought I I went the more specialist route, let's say specifically for

software engineering. Yeah, now that kind of generative AI has been booming in 2023, I am more fearful of these low code applications because if you can generate code that is more specific and more adaptive, let's say in kind of a copilot way with with an AI, then does low code still have a foot to stand on? I think established technologies, yes. But for example, I know a friend and he's building a code automation platform. He doesn't call it low code because it generates code for

those applications. I'm like man with generative AI now. Now I see a big risk there. Yeah, yeah. But I I also think that you need to think about who is the the end user in this case, right. So so yes, with, with, with tools like GitHub Copilot, you can you can build a lot of applications faster, but you're still coding, right? So you still need to have that coding background. You're still responsible for the

code, right. And I think low coding is a different persona who's using it, right. So I think those are more the business users who are using this and can also contribute to add value to, to the organization by building an application. Yeah. Yeah. So I still think there is a, there's a, there's a lot of room for low coding as well. Yeah.

Yeah, yeah. And it's also funny if you if you if you start talking about low coding with with customers and it depends on the role, if you go to an engineering elite or something like that and you mentioned something like low coding, it's still it's a dab. Word. Yeah. It's like taboo. Yeah, yeah. Yeah, sometimes you really see. Nah, no, we don't do low coding. No, that's not coding. Yeah, Yeah. I don't know where that comes from. Like people are maybe fearful

of, like, being obsolete. That's the feeling I get. Then like, oh, we don't do like, maybe they're better than low code because it has this kind of negative connotation sometimes. And like, I mean, if people use it, if it does what it needs to do, then I don't care. I'm I'm not going to use it. I've I've tried to click around and I can see the power of it, but it's not. Principally, it's just because I like building things in a different way.

If I needed to build something really quickly and there was a local tool, let's say I I was comfortable with or that got the job done way faster than I could. It's the same as using generative AI to spit out a bunch of code. But yeah, it's just to get the job done, yeah. Yeah, yeah, absolutely.

And and and talking about Gen. AI, are you using GitHub Copilot already for a long time or what's your what's your

experience? I've I haven't integrated Copilot in in let's say my IDE because I mean I'm I'm a consultant and previous client I worked for didn't allow that yet the conversation was still ongoing embrace or be fearful like that was that was an ongoing topic but we have this I I call it's a slack plug in in the organization it's called slack GPT and because it's through our organization we kind of get to decide OK how much of this information gets stored how

long and stuff like that. So with that I I asked basic questions or stuff because in my previous project I needed to do a lot of low low level stuff. When it comes to it was an IoT project so really on on memory level people had optimized certain way of working with data and I needed to understand that. And I basically used this slack GPT to ask a bunch of questions and to gain an understanding and it was it was wrong the first few times and then all of a sudden it was right a bunch of

times. And I got it working because of that as well in a faster way because my Google searches just ended up in nothing and otherwise I needed to go deeper let's say down a rabbit hole. I I do love this notion of copilot. I think the marketing and the name is genius because it's a copilot, which means you're steering, you're a bit. Confusing. You have so many copilots. Yeah, yeah, fair enough.

But still, like the, the person in control is the pilot, and you're using this copilot also in. That way, yeah, yeah, exactly. Yeah.

We have a lot of conversations about Copilot and also people are concerned about if I make this tool available to to my engineers, do they still feel? That they are the owner of the code, right? They're just accepting every suggestion. Oh yeah, it's it looks great, right? So move on. Let's push it to production. Let me put it very black and white. Is that the fear? Yeah. Some, some, some some customers are really concerned about that. Yeah, Yeah.

So that's. From from my perspective, let's say from an engineering perspective, I like to own whatever I do. So if it if it would spit it out, I would still be like OK, is this good or not or do I need to tweak it or not. Most of the times it wasn't enough and I needed to tweak it for my context like we're still at that phase. But I do see it getting better and better. Like that's I think natural, but I wouldn't necessarily push anything to production.

I mean it's also that's just basic engineering standards nowadays. You create a test so you see if it works or not before you push it. So that notion is kind of, I feel like maybe outdated or maybe a very hands off kind of point of view, let's say. Yeah, but that's my opinion. Now I, I, I, I agree with you right. So so we also got questions about if we if I use Copilot do I still need to use a tool like GitHub Advanced Security for instance.

Yeah yeah you still need to use the proper tools right. So and and and it's not that that that I'm I'm making a joke about about that that that question pops up but you you see that that people are thinking about OK it where does it help me and and and but it's just the coding part right. So you still need to have your quality checks. You still need to have your security checks. You need to have everything in place.

It's just helping you with staying in the flow and making sure that you become more productive and you don't need to go to Stack Overflow all the time. And and and but yeah, you still need to use the other tools as well before you bring it to production. Yeah. And I still, like you also

mentioned, right. You're still the owner of the code because yeah, yeah if you bring this to a test environment and it breaks or it doesn't deliver the the the the the functionality that that was the original idea. Yeah, you can't blame copilot. No, it's on you. Yeah, it's on you. Absolutely. Yeah. I was wondering because you said

you transitioned from this architectural role and now more of a customer facing sales role as well. Specifically also for developer productivity, is there any like let's say correlation or kind of similarity in the customers you've talked to when it comes to making their developers more productive? Are they for example already using cloud technologies or are they using it optimally? Because using and using it optimally sometimes is not the same effectively, maybe I should say.

Rather or whether kind of the similarities that you've seen or is it context depended and very different at times as well? I think I see a lot of similarities to be honest. So the the and maybe it's good to clarify a bit on the accounts that that we focus on, right. So we focus on the customers are who are already in their cloud journey for a long time, right.

Yeah, so. So you see that that across all my customers, OK. And when it comes to developer productivity, yeah, everybody has embraced the, the DevOps teams. They're also looking into platform engineering. They're all exploring the tool get a copilot of course. So I see a lot of similarities. Yeah. You also see some customers who are more focused on, on 1st lift and shift and that's also the trigger, What's the trigger to go to the cloud, right.

So maybe you need to close your data center, your contract and so you need to go quick then then of course you have customers who are fully focused on infrastructure and and and they don't fully embrace the power of the cloud and and and they're still, you can still do things tradition traditionally in, in the cloud, right. You can even do an an deployment with a manual next to you, right.

But the majority of my customers are are focusing on, on, on cloud native development, leveraging the managed services. Yeah. And and like we all know, there's also a war on talent. Yeah. So if you wanna be an attractive organization for developers, yeah, you also need to bring some some tools and best practices into your organization to make sure that these people

wanna work for you. Yeah. And I see the customers that I'm covering, I'm covering manufacturing, customers are are are all focusing on cloud, native development, embracing DevOps like I mentioned platform engineering and platform engineering to be honest, they're exploring it, right. So I think platform engineering is, is it's, it's, it's not as easy just to say hey we're going

to introduce a platform team and we will be successful so that it can be pretty complex. So they are exploring it. So yeah. Also successfully I think, because I think platform engineering is very interesting. Absolutely. Yeah. I fully agree with you. Yeah. Yeah. So they're doing it successfully, you'd say, or what have you seen so far? I think my customers are all in in in at the beginning of this journey. OK, so so I didn't see.

No, I don't. I didn't see already a full functioning platform team at my customers and of course they're doing bits and pieces. Let me, let me let me because it is a very difficult. Yeah absolutely. So I have Terraform modules I'm doing plus from engineering. Yeah, OK. Yeah. So, so but fully functioning like like like Gregor hope before is is describing his book. I haven't seen it yet to be honest.

If I take a look internally, we have a team who is focusing on, on, on making other teams more productive, right. That's what we briefly touched upon which is called one ES. So I think we are doing this already for at least 10 years, but our customers are exploring it. Yeah, yeah, yeah. What's your experience because

you are also now working at the ING? Do you see a platform engineering team at ING or not? Yet, but I'm seeing, let's say, pain points of us not being able to experiment or innovate. I like the way my friend Carlos Calpol, he was in a previous episode. He says the way I I kind of view innovation is how fast, how quickly you can go from an idea concept to, let's say, live a prototype, maybe in production in the hands of the user, right.

And the faster you can do that, the more innovative the organization is. And the way you can do that, let's say the way platform engineers can contribute to that is making a platform, making sometimes people call it a landing zone that is very easy to deploy to, where deployments are standardized, where you can take something off the shelf and all of a sudden you need your, let's say, code up and running within maybe a shell structure, maybe a predefined thing, but

then you're at least up and running, right. So that contributes to productivity, contribution, innovation in that way. And from what I've seen right now my current role and I'm not a software engineer anymore, so I have this. I think I always thought about productivity more so on my own, more so on the team. But now I'm thinking about, OK, overarching productivity because that's going to contribute to the product.

And if we don't have something like that, if it's not very easy to go from, OK, the idea, the concept to kind of live in production, then from a product point of view, I cannot get into that experimentation phase. And I've learned that you can either do a lot of research and then still end up being wrong, or you can just throw out ideas as fast as possible and then experiment and test your assumptions and then see if you're right or wrong. Yeah. And I wanna be in the latter phase, Yeah.

Where it's easy to go from idea to production, Yeah. And then experiment those assumptions, test them and see if it's value or not. Yeah.

And and and what is your experience? Because I also see that you also get the argument if you talk about platform engineering, that you are using reusable building blocks or you're gonna standardize. Yeah, people say, hey, I'm gonna lose my autonomy. I'm less flexible. I'm forced in this direction. Yeah. Have you seen that also at your customers or? Not yet.

Not yet. Like I've I've been part of, let's say, an organization where I was part of the software development team, and then we had a specific part of the team which was focused on the platform, making it as easy for me to deploy to as possible. And maybe this is my bias, because I like, I like business problems. I don't want to care about technical problems. So how do we land? How does it scale? Yeah. What is this build pipeline?

What does it look like? I'm interested because I'm I'm just curious in general, but I I it doesn't necessarily need to be my responsibility to do so. If people feel like, OK, this is my let's say part of the pie and all of a sudden other people are eating it now or or I think eating is still the the best analogy. But then I think you have a people problem and you have to figure out how to get that win win let's say, because that's not a technical problem.

I think it makes sense for people to focus on kind of what they need to do instead of being focused on everything, because I think if you focus on everything, your productivity kind of goes down. You can't work on everything at the same time every little bit, because then nothing moves. Yeah, yeah. And I and I, I like your comment. It's a people problem, right? I think that platform engineering is, is if you want,

if you want to implement this successfully you it is about technical building blocks. It is about culture, it's about processes, It's, it's everything, right. And that's also if you take a look at how, how we, how we do this internally, if we have conversation about about our approach, it's not only about the technical stuff, right? And of course we have tools for our customers, GitHub actually dev OPS, we have a lot of these technical building blocks.

But if we really want to help our customers with successful implementing a platform engineering strategy, you also need to help the customer with processes and think about what do you need to change in your culture. So it's it's it's a lot and and that's why I'm also happy that we now have on on Microsoft learn and how and and document at least to structure this a bit, right. So to share a bit how we would structure this, so it's not only about the the technical building block.

So I think that's a that's a great great thing that we have it on Microsoft learn right now. But it is a complex journey. Yeah. Where do you apply plus from engineering and where don't you apply plus from engineering? It's it's it's an interesting topic as well.

One of the things you mentioned when it comes to kind of the culture of an organization or how to structure things, I think way of working is always an interesting concept because from a consultant's perspective you go in and out. So obviously you get a preference. But from your side to then advise customers in this way of working, which might be standardized, but it needs to be kind of context dependent. What what is that based on?

Is that based on how Microsoft does things, kind of team organization structure or what you've seen in other customers that you've kind of gathered and standardized in advice in that way or what is it based on? Yeah. So how I how I approach this for my customers at least is is sharing experiences how we do things. Yeah of course the the the, the platform engineering strategy which is on Microsoft learn right now.

I have to ask the the the guys who who developed it, but I I assume it's based on what we do internally. Yeah, but if I have conversations about platform engineering with my customers, I connect them also with our leaders in in the in the software development domain and share experience. This is what went well and this is where we made a mistake and we had to revise our, our vision. So I think that's also a role

for us, right. So it's not again about about the selling part, it's not only about talking about our products but it's also about sharing experiences, it's how we do things and that's that's I I see that's our customers are really appreciating that. So we have, we have conversations between our our customers and and our platform engineering team but we also have conversations with people who leverage our platform engineering at team internally

with our customers. Hey, what is your experience, how does it help you? Are you more productive or not. Yeah, sharing experiences is is is what I do very often with my customer and I'm not the one who's sharing that I'm connecting the. Of course. The leaders with with their, the customer. The leaders of the customer. Yeah, yeah. Yeah, I think it's always interesting to think about experiences and how that might help form a perspective on how things work or how things might work.

Or one of the things I really have kind of a hard time with is

sometimes letting go of your ideas. Because if you have an idea, then just by virtue of you having that idea, you're kind of biased because you think it's gonna work. And then being able to let that go. And I've seen that in organizations where some, let's say, could be from an engineering team, could be from an architecture role, people have ideas and they don't want to let go when it doesn't actually, let's say, work or doesn't deliver the value that

they think it does. Yeah, and then? It's their baby. Yeah, right. Exactly. It's hard. It's hard to kill your babies, Yeah. But in that way, I feel like most of the times when we're talking about the technical stuff, that's kind of standardized, right? You have these tools. You can use them in XY and Z, but the way you use them and the way you structure them, I feel like more and more, that's where the challenge is. Yeah. Within organizations now as well, yeah.

I fully agree. Yeah, I fully agree with.

You. Yeah. I was wondering also because you said you came from kind of an architecture role. Yeah, I feel like the role of architecture, at least from what I've seen is kind of evolving as well. And I don't know if let's say the hands off architecture approach is as effective anymore. You already said you need to understand customers. I think more and more an architect or the people that have that responsibility need to do that 100% as well to figure out what works, what doesn't

work. But I don't know if this, let's say hands off part is as effective anymore as it used to be a few years back down the line. And what do you mean with hands off in this case? I feel like more and more software engineers that I've talked to also take up that let's say architecture Mantle

who are interested in that. So then they do the hands on as well as kind of the figuring out the non functionals as well as the functionals because otherwise you'd have this kind of man in the middle that needs to translate because the developers need to understand whatever the architect understands as well. Yeah. And their ivory tower. Yeah.

Now I I agree with you. Yeah, yeah, So, yeah, so, so if if I take a look at my own career, so, so I started as a developer then lead developer, then became software architect, but I also moved more to a technical architect role and and and a lead architect. So and as a lead architect I was not focused anymore on the software development part, but

really on the entire landscape. So, so to give you an example, I worked for five years on Transuni where we implemented a new SCADA system which is managing the physical gas network in the Netherlands, right. So opening and closing valves, starting compressor stations etcetera. So my role was not any more focused on on on server development but yeah we had to build an entire solution which integrates with the the the

network the GAS network. So I was not not focusing anymore on on the server and development part. But what what I really like about about moving to more an an architect role and and and I know we briefly touched upon it a couple of weeks ago when we first when we first met.

I remember a a, a presentation from Jim Wild. At that time he was working at Microsoft and he was talking about the five pillars of architecture and it was, I think it was 15 years ago. So it's a long time ago. So. So forgive me for my memory, but I remember that there was one pillar which was human dynamics. And at that time I was a solar developer and I was really thinking about I wanna grow into an architectural role and I I

wanna become an architect. But human dynamics, I was really thinking about that should be easy, right? Human. I I I'm OK with talking to people. So I got this. I got this. Yeah, well I totally underestimated that part. So when I became an architect, I had these these pitfalls. Sometimes I had a great idea in my mind and I was really thinking about this is how we should solve this. But somebody else also had an idea about how we can solve certain problem, but I was fully

focused on my own idea, right? So he said OK take a look. I think we should solve it like this. And I was only listening with one ear and I was OK and I always said yes, but and then we moved to my architecture and so yeah, that wasn't working at all. So as an architect, the human dynamics part, yeah, I think that's that's also an important one.

You need to have the technical background like you also mentioned the the the hands off doesn't work but the human dynamics part and it's also for Jim Wild at that time said, I'm pretty sure that he said like that that the human dynamics was the most important part. You need to convince people about your ideas, right? This is the direction where we need to go and you need to convince people with different backgrounds, not only technical folks but also security people

or business people. This architecture is going to cost this amount of money. So you also need to get some budget. So you really need to sell your, your architecture to multiple stakeholders. And yeah, so I really learned the human dynamic part. Yeah, it's extremely important. Yeah, that's that's that's fully true. Yeah. That's funny. I really appreciate you sharing that. Like the the idea part, I think

that everyone is gonna see that everyone thinks their idea is right, right. And all of a sudden when the person across from you has a different idea, then it's interesting. But to explore that, I think, takes a certain skill. Yeah, If you say yes but and then you go back to your right, yeah, no one's listening to each other. Big mistake. Exactly. So then you just either it's a conflict or someone gives in and they they talk shit about your behind your back. Yeah, that's all the human

factor. Exactly. And what I what I learned in I'm pretty sure you also say yeah you also have these these consulting trainings or whatever how they how they call it. I learned in a in one of the trainings I said OK then it's But if somebody has a different idea than you have, you've you, you, you should ask questions. A lot of questions and two things can happen. By asking these these questions you get answers and you are convinced that the idea of the other person might be a good

idea. That could happen. Or you can ask questions and say, hey, I'm looking at your architecture, but what about availability? How do you make this high available? And then you also can steer them in a direction that they also open up and say, Oh yeah, you're right, I didn't talk about, I didn't think about it right. So there are and both is

positive, right? You can steer them also with asking questions into your architecture if that's your purpose, or you can ask questions and can be convinced about the architecture that the other one creates. So it was really good learning and I didn't learn it at the technical course, but it was really on on on soft skills and yeah, I think human dynamics. Yeah, I think that's a great example of sometimes you you push, right, because you want the other person to hear your ideas.

But push might not always be the best option. Sometimes you have to pull that information and then maybe sometimes meet in the middle or absolutely choose your battles. Like, it's this. It's this. The battle to go all in on. Yeah, more and more. Like I've always been. I've been labeled as being idealistic or being, like very fighting for what I think is right. And more and more, I feel like sometimes I'm just exhausted. If you're fighting every fight, yeah. Yeah.

It just gets exhausting. Yeah. And then all of a sudden you lose battles all around. Yeah, instead of fighting, let's say battles or fighting for what you believe is right. Yeah, when it counts. Yeah, and and let's be honest, you need a lot of people around you, right? If you keep fighting with everybody, no. One's gonna like you. No, you're not gonna be successful. Yeah, yeah. But it also, like you also mentioned, if you have an architecture you designed it, it

also becomes your baby, right? And you don't want to kill your own baby. So yeah, but yeah, yeah, fighting. Fighting with all the peoples and and and and think you are right. Yeah. And that's not gonna make you successful at all. No. No. Yeah. It's it's hard, right. Because that I think that the

whole conversation here has been more so about human dynamics, let's say, Yeah, quote UN quote here and there. And that is also very human to feel like or to think that you're right. Yeah. And what I've learned, and this is, I mean, I've I've never had trouble with saying, OK, your idea is better. I changed my mind. Sometimes I have to say out loud, OK, I changed my mind so people realize that I'm not actually arguing with them anymore.

And I have no trouble doing that because I think a lot for ideas. I don't really care who's right. I want the best idea to, but I will fight if I think my idea is best. That's the important. Part. Yeah, yeah, yeah, yeah. And also an interesting situation where the human dynamics again becomes very important is that I think we all know that there are architectural review boards or some kind of board where you need to get that stamp to move forward with your idea.

And let's say there are eight people in this, in this round table of architects where you need to get that stamp. During my career, I also learned it the hard way that if there are eight people who need to approve your idea, it's not about the meeting where you present your idea to get the stem. It's all about how you go to that meeting. If four people from the 8 have an opinion about your architecture and the other four, they they're they're not experts in that domain, so they just

follow the other four. You need to have that conversation with the four people before you have that meeting, right? You need to influence them already before you have that meeting. And I saw a guy presenting his idea for the the the Architecture Review board. Deep technical guy knows knows his domain, but he didn't talk to any of the the architects around the table before that meeting so they were surprised

about this idea. Why did you came up with this and a bit annoyed and they send him away? Yeah, that's a shame. Yeah. Yeah. From both sides. Yeah, exactly. Completely. Yeah so he but he missed the part where he need to influence the people before he go to that meeting right.

It was It was also an an interesting learning to see you have a good idea, but you didn't do your homework, so your idea was was killed. Exactly. Yeah. But that's no one's gonna teach you that, right? Because probably from his mindset, it's like, OK, everyone prepares and then they pitch there. And that's where the decision gets made. Yeah, and I think 100%. The same goes for security and risk and compliance. When you're working on something new, you have to take them with

you. Yeah, it cannot be the final hurdle because then you get blocked. Yeah, exactly. And then it's done. You need to make them part of your journey. Yeah, yeah, it's. But again, no one's gonna teach you that. When I I'm starting at ING now and I talked to my colleagues and one of the people actually worked at ING and he, he gave me this advice.

He's like whatever you do, since I'm not gonna be product manager, make sure to make friends with risk and compliance and security because they will block you if you don't take them with you. If all of a sudden it's out of the blue and you have this thing and it's it's now or never, they're gonna say never and sucks to be you so. Yeah, yeah, yeah, yeah, yeah, yeah.

It's really funny. So, So yeah, if you're if you're in this IT department and you're starting your your IT career, I think that would be good advice, right? It's it's not only about the technology, it's not only about the programming language. It's not only about you building this awesome micro service architecture. People are extremely important to become successful in this. Yeah. Yeah, 100%. Yeah. Yeah, I've.

I've really enjoyed this, Dennis. I must say, this was a lot of fun. Yeah. Yeah. Was this kind of what you expected going into it as well? To be honest, I I wasn't expecting we we we we had a conversation some time ago, yeah. And I was thinking this can go. Everywhere, everywhere, right. That's usually how, yeah. Yeah, yeah. And I also listened to some other podcasts and it's, it's, it's it's going in an in an in an in a normal way. Yeah. You ask questions.

You you get a question back. It it can go everywhere. Yeah. So I wasn't expecting anything, right. Yeah. Yeah. Yeah. Well, I hope you enjoyed that. Yeah, absolutely. Absolutely. It was fun. It was fun. It's fun to do. And thanks for the the invitation. Thank you so much for coming on. Yeah. Cool. Then I'm gonna round it off here. Thank you so much for listening. I'm gonna put all Dennis's socials in the description below, reach out to him, let him know you came from our show.

And with that being said, thank you for listening. We'll see you on the next one. Beyond coding.