Dev Productivity, Platform Engineering & Architecture | Dennis van de Laar | Beyond Coding #141
Hi everyone. My name is Patrick Akil 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 van de Laar.
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. 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 I have to go downstairs. Because you were waiting for me, right? Yeah. No, but I work with JP for a year and I think just one of the first times that I met JP, we directly went to the U.S. 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. It was good. Yeah, yeah, yeah, it's really good. Yeah. You mentioned Executive Briefing Center. What is that? Because I've heard that twice now.
Yeah, Those are sessions that we organized to with our customers. So we invite our customers to come to Redmond or to Munich. Yeah, and we craft an agenda, depending on, on, on the strategic objectives of our customers, we cross an agenda. It can be about security is going to be about over development.
And then we invite our customers. We have a full agenda and we discussed the most important topics for our customers. Yeah, 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. Nice. Yeah. 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. The Microsoft is not anything I know now it's Mongo I guess, or the magnificence seven Magnificent Seven. Yeah I've heard that as well. Yeah. But I've, I've never seen it kind of from behind the scenes. But before we touch on that.
Yeah. How did you get in touch with Microsoft anyway. Because I saw you started at Consultancy. Yeah. Ofunato was there as well. Yeah.
How'd you land at Microsoft? Yeah, so I worked for 12 years at Evernote. So that's. That's almost where my, my career started.
Yeah. And as people hopefully know, is that Microsoft sorry, Evernote is a joint venture between Accenture and Microsoft. So all the projects that Evernote is doing is based on Microsoft technology. So during my entire career, I'm working with marks of 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 frontend development, a CRM implementation, a lot of integration projects with with business 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 here owning a it was funny and there was an Accenture project, so I was working for Forever Nots, but it wasn't. Accenture projects that I switched to were to Accenture because Accenture 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. Yeah.
And I think it was working for two years at Accenture. And then Microsoft reached out, Hey, we have a role available which is Cloud Solution. Architect. Yeah. 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 was a change in the organization. So there were there were some changes in the organization. And then I was thinking, okay, what is what is what is my path within within Microsoft? Do I want to be what we call a swarming architect, covering multiple accounts with your specialty? Or you 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? Okay, 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.
Yeah. So it is new team and and I was invited to talk to the manager of the team who was creating the team and I was really thinking that 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 they were people focusing on cloud, native technology, but now it became an official team. Okay. Yeah. And that's, that's that. So that team was started four years ago, so I had the opportunity to I want to be swarm an architect or do I want to be the PDF specialist and specialist 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. It's also always how I explain it.
So an innovation specialist or an Airbnb specialist focuses on starting new cloud native projects. Okay, Modernizing existing applications. Yeah. And when I say modernize, 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 observers or Kubernetes or whatever.
Yeah. 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. Yeah. 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. Yeah, no, that's not possible.
That's not me. But that's 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 do you want to buy it? Exactly. That's not how it works anymore. Snake oil salesman. 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 or whatever. We have this toolbox 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 doesn't work. So you really need to listen and map their requirements on, on, on the toolbox that you have, Right. Yeah. 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 show your throat and this is what you need. Now that doesn't work now. It's not the best salespeople I've talked to on the show and off the show all kind of align with that.
They you have to understand what the problem is. Yeah. And then it might be a good fit what you have. Yeah. Or it might not be a good fit. Yeah. And the more you say it's not a good fit, the more that kind of contributes to your. How do you say that. That's integrity.
It's also credibility. Yeah. Right. You build trust in that way. Exactly. And when there is a good match, they'll know it's a good match. Because you said no before. Exactly.
I think that's the better way to do it. Yeah, 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.
So win win, right? So the customer wins 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 meaning of selling. Yeah. You mentioned four or five years ago you joined this team with the mindset of this is where the future is going to be, right. Yeah. Kind of engineers or organizations leveraging cloud technology to be more effective, more productive. Yeah, it's kind of a a lesser cost of ownership, at least where they came from, right When we're talking about traditional infrastructure. Yeah, you have to mean 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 they don't have big team issues and focus on the most interesting part. Yeah. Yeah.
And also the, the most complex part and delivering value. That's, that's what excites me. Yeah. Do you think it still is the future.
I mean we're now four or five years ahead. Are organizations now more and more leveraging cloud because I've also seen this movement and I'm curious to hear what you think. There's this 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 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 a VMs, a cluster of teams, 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 now, like we already said, you can really focus on adding value, making sure that you have a backup of your database. Yeah, 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, maybe it's a it's a fancy term, but reduce government 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 managing the underlying infrastructure. Yeah, I think that's that's one that's a waste of time. But it's, yeah, it's a technical problem. It's yeah, yeah, exactly. That's what I feel like.
And what I really like about I often use the, the page layer application strategy. I'm not sure if you familiar with that. That's the structure that's laid out.
And to be honest, when I started using it, it had three layers and, and, and maybe I heard it's update it's I thought I think there was a fourth layer, but it is the first layer is the system of records. Well, that's a that's a term that we all know in the 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. Yeah. And also what, what Gartner States is that, yeah, just by such a system implemented in your organization, make sure that you use it properly, but don't build it yourself.
It doesn't make sense, right? Yeah. 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. I 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 second layer is the system of differentiation. And this is where you can like the layer already or already dimensions.
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 built your applications, right? Because you want to be different than your competitor. And I think if we go back to you two, to your question, if you can really focus on your application to different at you from your competitor so that you can gain market share, why do you want to spend too much time on managing the underlying infrastructure for that application? Yeah, no, 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 see definitely a cloud native development as a as the future and the third layer to to to, to finalize 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, okay.
Then you make it part of your your your i.t 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 base layer replication 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? Yeah, and how can we help us, Microsoft, to make you even better, more successful. And that's that's yeah, that's, that's why 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. Yeah. In a more fast way. Right.
Talk 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. Yeah. And you can get up and running faster. Yeah. I don't know if it's used kind of in that experimentation layer because I can see it working and be productive and 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 a, has absolutely. If you talk about these three layers, you can build an application in which is a differentiating application with low code.
Absolutely perfectly makes sense. It's not only the innovation layer that you say, okay, I'm just going to try something but local to you, if it's if it's if it's working and keep it small. 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 local to Yeah. In this journey. And what is your view on it? I, I think I always thought local was interesting.
I almost became, let's say a local developer like very early on in my career. But then I was like, is this really going to give me an edge or are a lot of people able to do so? And because of that thought, 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. Yeah, 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 code automation platform. He doesn't call it low code because it generates code.
Yeah. For those applications I'm like, man, with generative AI now I see a big risk there. Yeah, yeah. But I also think that you need to think about who is the the end user in this case, Right. So, so yes, with, with its 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. Yeah. 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, there's a, there's a lot of room for low coding as well.
Yeah, 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 lead or something like that and you mentioned something like low coding, it's still a dirty word. Yeah, it's like, yeah, yeah, yeah. Sometimes you really see No, no we don't do logo. Yeah. No that's not coding.
Yeah. Yeah I, yeah, I don't know where that comes from. Like people are maybe fearful of like being obsolete. That's, that's the feeling I get then. Yeah. Like, we don't do look like maybe they're better than low code because it has this kind of negative connotation sometimes. Yeah.
And like, I mean, if people use it, if it does what it needs to do, then I don't care. I'm not going to use it. I've tried to click around and yeah, I can see the power of it. Yeah, but it's not. Principally it's just because I like building things in a different way. Yeah. If I needed to build something really quickly and there was a local tool, let's say I was comfortable with or that got the job done faster than I could is the same as using generative AI to spit out a bunch of code.
But yeah, yeah. It's just to get the job done. Yeah, yeah, yeah, yeah. Absolutely.
And talking about you and I, are you using get copilots already for a long time or what. What is your experience. I've, I haven't integrated copilot in in let's say my ID because I mean I'm a consultant and the 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 call it it's a slack plug in in the organization's got slack Djibouti and because it's through our organization we kind of get to decide okay how much of this information get stored, how long and stuff like that. Yeah. So with that, 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 a certain way of working with data and I needed to understand that. And I basically used this. It's like 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.
Yeah, I do love this notion of copilot. I think the marketing in the name is genius. It's because it's a copilot, which means you're still sometimes that confusing. You have so many copilot.
Yeah, Yeah, fair enough. But still, like the the person in control is the pilot. And you're using this copilot also? Indirectly, Yeah. Yeah, exactly. Yeah.
And we have a lot of conversations about a 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. yes. It looks great. Right? So move on. Let's push it through 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 yeah, if it would spit it out, I would still be like, okay, is this good or not? Or do I need to tweak it? Or not? Yeah, most of the times it wasn't enough and I needed to tweak it for my context. Exactly. We're still at that face. Yeah, I do see you getting better and better. Like that's, I think, natural, but I wouldn't necessarily push anything to production. I mean, it's also 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. Yeah, let's see. Yeah, but that's my opinion.
Now. 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 get up advance security for instance. Yeah. Yeah. You still need to use tools, right? So and it's not that I'm making a joke about, about that that, that question pops up, but you see that that's people are thinking about where does it help me? 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 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 but yeah, you still need to use the other tools as well before you bring it to production. Yeah. Yeah. And I see like you also mentioned, right, you're still the owner of the code.
Yeah. Yeah. If you bring this to a test environment and it breaks or it doesn't deliver the functionality that. That was the original idea.
Yeah. You can't blame copilot. No, it's on you. Yeah, it's on you. Yeah. So. Yeah, I was wondering because you said you transition from this architecture role and now more of a customer facing sales role as well. Yeah.
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 dependent and very different at times as well? I think I see a lot of similarities, to be honest. So 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. Okay.
And when it comes to developer productivity, yeah, everybody has embraced the DevOps teams. They're also looking into platform engineering. They're all exploring that will get a copilot, of course. So I see a lot of similarities. Yeah.
You also see some customers who are more focused on on first lift and shift to 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. Yeah. Then of course, you have customers who are fully focused on infrastructure and and they don't fully embrace the power of the cloud. And they're still you can still do things strategically at that traditionally in the cloud, right.
You can even do in deployment with a manual next to you. Right. But the majority of my customers 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 want to 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 want to 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, I platform engineering and platform engineering. To be honest, they're exploring it, right? So I think plus from engineering is 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 can be pretty complex.
So they are exploring it. So yeah, I am 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 say, Well, what have you seen so far? I think my customers are all in at the beginning of this journey. Okay. So, so I didn't see No, I don't I didn't see already a full functioning platform team and my customers and I'm of course, they're doing bits and pieces. Let me let me because it is a very busy.
Yeah, I suppose so. Sure. I have TerraForm Modules. I'm doing platform engineer. Yeah. Okay. Yeah. So, so but fully functioning like, like, like Greg, our whole performer, is describing in his book.
Yeah, I haven't seen it yet, to be honest. If I take a look internally, we have a team who is focusing on on making other teams more productive, right? Yeah, that's what we briefly touched upon, which is called one. Yes. Yeah. So I think we are doing this already for at least ten years. I'm but our customers are exploring it. Yeah, yeah, yeah.
But what is your experience Because you are also now working at it and do you see a place from engineering team at Ingwe or not yet But I'm, I'm seeing, let's say, pain points of us not being able to experiment or innovate. I like the way my friend Carlos Kalpoe me was in a previous episode. He says The way 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. Yeah, right.
And the faster you can do that, the more innovative the organization is. Exactly. 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 way. 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 my own, more so on the team.
But now I'm thinking about, okay, overarching productivity because that's going to contribute to the product. Yeah. And if we don't have something like that, if it's not very easy to go from 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 want to be in the latter phase 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. So yeah. 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 going to standardize. Yeah, people say, I'm going to 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 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 does this build pipeline? What does it look like? I'm interested because 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, okay, 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 still the the best analogy. But then I think you have a people problem. You have to figure out how to get that win win, let's say, because that's not a technical problem. Yeah, 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, and I like your comment.
It's a people problem, right? But I think that platform engineering is, is if you want if you want to implement this successfully it is about technical building blocks, it is about culture, it's about processes, It's, it's everything. Yeah. And that's also, you know, if you take a look at 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 DevOps, 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, yeah, you also need to help the customer with processes and think about what do you need to change in your culture. So it's a lot I'm and that's why I'm also happy that we now have on Microsoft learn a now and document at least two structured is a bit right so to share a bit how we would structure this. Yeah. So it's not only about the technical building block so I think that's a that's a great, great thing that we have it on Microsoft Learning right now, but it is a complex journey. Yeah,
Yeah. And where do you apply platform engineering and where don't you apply for engineering? It's a, it's an interesting topic as well. Yeah, I'm one of the things you mention 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 consultancy perspective you go in and out, so obviously you get a preference, but from your site to then advise customers in this way of working, yes, might be standardized, but it needs to be kind of context dependent. Yeah. What is that based on?
Is that based on how Microsoft, those things kind of team organization structure or what you've seen in other customers that you've kind of gathered and standardize is 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 sharing experiences how we do things. Yeah, of course, the the platform engineering strategy which is on microphone right now. I have to ask the guys who developed it, but 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 this over development domain and share experience. This is what went well. Yeah, and this is where we made a mistake and we had to revise 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 is how we do things. And that's that's I see that's our customers are really appreciating that. So we have we have conversations between our customers and our platform engineering team, but we also have conversations with people who leverage our platform, engineering at them internally with our customers. 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.
Yeah. And I'm not the one who's sharing that. I'm connecting of course the leaders with with their the customer, the leadership, 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 Yeah, 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 is going to work. Yeah, yeah. 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 architectural role. People have ideas and they don't want to let go when it when it doesn't actually let's say, work.
Yeah. Or doesn't deliver the value that they think it does. Yeah. And then is their baby. Yeah. Is that exactly right? 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 X, Y, and Z, but the way you use them and the way you structure them, I feel like more and more that's where the challenges within organizations now as well.
Yeah, I fully agree. Yeah. Really 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. Yeah, 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 or are interested in that. So then they do the hands on as well as kind of the. Yeah. Figuring out the nonfunctional as well as the functional. Yeah.
Because otherwise you have this kind of man in the middle that needs to translate because the developers need to understand whatever the architect understands. Well yeah. In their ivory tower. Yeah, I know. And I agree with you.
Yeah, yeah, yeah. So, so if I take a look at my own career. So I started as a developer, then lead developer, then became solver architect. But then I also moved more to a technical architect role 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 the company, okay, where we implemented a new scalar system, which is managing the physical gas network in the Netherlands, right? So opening and closing valves, starting compressor stations, etc.. 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 network, the guest network. So I was not, not focusing anymore on this over in development part. Yeah, but what, what I really like about but moving to more of an architect role and I know we briefly touched upon it a couple of weeks ago when we first when we first met, I remember 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 long time ago. So, yes, I forgive me for my memory, but I remember that there was one pillar which was human dynamics. And at that time I was software developer and I was really thinking about I want to grow into an architectural role and I want to become an architect, but I'm human dynamics.
I was really thinking about that should be easy, right? You what? I I'm okay with talking to people. So I got this. I got this.
Yeah, well, I totally underestimated that part. So when I became an architect and I had these these pitfalls, sometimes I had a great idea in my mind and I was really thinking, 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 and he said, okay, take a look.
I think we should solve it like this. And I was only listening with one ear and everything. Yeah, okay. And I always said yes, but. And then we moved to my architecture right as well.
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 that the dance off doesn't work, but the human dynamics parts and it's also part Jim while the that time said I'm pretty sure that he said like that that the human that image was the most important part you need to convince people about your ideas right Yeah. 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 in 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 to human dynamics.
Part two. Yeah, it's extremely important. Yeah, that's, that's, that's really true. Yeah. That's funny. I really appreciate you sharing that. Like the, the idea part.
I think that everyone is going to see that everyone thinks their idea is right. Yeah. And all of a sudden when the person across from you has a different idea, then it's interesting. Yeah, but to explore that I think takes a certain skill. Yeah. If you say yes, but. And then you go back to you, right. Yeah. No one's listening to each other. Yeah.
Big mistake. Exactly. Yeah. So then you just either it's a conflict or someone gives in and they talk shit about your behind your back. Yeah. Yeah. That's all the human factor. Exactly.
And what I, what I learned in I'm pretty sure you also, Sabiha, you also have these, these consulting trainings or whatever how they are they call it I learned in one of the trainings is that okay then is but if somebody has a different idea and then you have you, you, you should ask questions a lot of questions and do things can happen by asking these questions. You get answers and you are convinced that the idea of the other person might be a good idea. Yeah, 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 available? And then you also can steer them in a direction that they also open up and say, yeah, you're right.
I didn't talk about I didn't think about it right. So there and both is positive, right? Yeah, you can steer them also but asking questions into your architecture if that's your purpose or you can ask questions and be convinced about the architecture that the other one creates. So that was a really good learning and I didn't learn it at the technical a course, but it was really on, on lots of skills. Yeah, Yeah. I think human dynamics. Yeah, I think that's a great example of sometimes you push it because you want the person to hear your ideas.
Yeah, but push might not always be the best option. Sometimes you have to pull that information out. Yeah. And then maybe sometimes meet in the middle or. Absolutely. Then choose your battles.
Like, is this, is 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, really fighting for what I think is right. And more and more I feel like sometimes I'm just exhausted. If you're fighting every fire, it just gets exhausting. Yeah.
And then all of a sudden you lose battles. Yeah, All all around. Yeah. Instead of fighting, let's say battles or fighting for what you believe is right. Yeah.
When it counts and let's be honest, you meet a lot of people around you, right? Yeah. Yeah. You keep fighting, but everybody knows Go like, you know, you're not going to be successful. Yeah, yeah. But it also like you also mentioned, if you have an architecture, you designed it, it also becomes your baby room and you don't want to kill your own baby. So yeah, but yeah, yeah. Fighting, fighting with all the peoples and think you are right and that's not going to make you successful at all.
Yeah. No. Yeah, it's, It's hard, right? Because that I think the whole conversation here has been more so about human dynamics, let's say. Yeah. Quote unquote, here and there. And that is also very human. If you like, or to think that you're right. Yeah. And what I've learned and this is I mean, I've never had trouble with saying, I'll get your ideas better or I change my mind.
Sometimes I have to say out loud, okay, I changed my mind so people realize that I'm not actually arguing with them anymore. Yeah, and I have no trouble doing that because I think, like, for ideas, I don't really care who's right. I want the best idea. Absolutely. But I will fight if I think my ideas. Yes. Yeah, that's the important part. Yeah, yeah, yeah.
And also an interesting situation where human dynamics again becomes very important is that I think we all know that there are architectural review boards or some kind of boards 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 roundtable of architects where you need to get that stamp. Yeah. During my career I also learned it the hard way that if there are eight people who need to approve your idea and 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 eight have an opinion about your architecture and the other four and 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 Architecture Review board, deep technical guy nose knows this domain, but he didn't talk to any of 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. But he missed the part where he need to influence the people before he go to that meeting. Right. Yeah.
It was, it was also 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 not going to teach you that, right? Because probably from his mindset, it's like, okay, everyone, 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, they cannot be the final hurdle because then you get blocked.
Yeah, exactly. Then it's done. You need to make them part of your journey. Yeah, yeah, yeah. It's, But again, no one's going to teach you that when I'm starting it now.
And I talk to my colleagues and one of the people I actually worked at and gave me this advice, he's like, Whatever you do, since I'm not going to 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 that's out of the blue and you have this thing and it's it's now or never, they're going to say never and sucks to be you. So yeah, yeah, yeah, yeah, yeah, yeah. Ads are really funny. So yeah, if you're, if you're in this i.t department that you're starting your, your ID career. Yeah, I think that would be good advice. Right?
Yeah. It's not only about the technology, it's not only about the programing language. It's not only about you building these awesome microservice architecture.
People are extremely wanting to become successful in it. Yeah. Yeah. 100%. Yeah, yeah. I've, I've really enjoyed this. Then as I say, this is a lot of fun. Yeah. Yeah.
Was this kind of what you expected going into it as well? To be honest, I wasn't expecting. We had a conversation some time ago. Yeah.
And I was thinking this can go everywhere right now. Yeah. Yeah Yeah.
And I also listened to some other podcasts and it's going in a in a, in a normal way. Yeah. You ask questions, you get a question back, it can go everywhere.
Yeah. So I wasn't expecting anything, right. Yeah. Yeah. yeah. Well, I hope you enjoyed it.
Absolutely was fun. It was fun. It's fun to do. And, thanks for the invi for the invitation. Thank you so much for coming on. Yeah, cool. Then I'm going to round it off here. Thank you so much for listening.
I'm going to put all Dennis's socials in the description below. Reach out to him. Let him know you came for our show. And with that being said, thank you for listening. We'll see on the next one.
Beyond coding.
2024-02-02 04:26
