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.
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.
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.
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.
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.
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.
Well, I hope you enjoyed that. Yeah, absolutely.
Absolutely. 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.