[ BETTER TECH LEADERSHIP ]

D for DevOps: The philosophy of software engineering

[ THE SPEAKERS ]

Meet our hosts & guests

Matt Warcholinski
CO-FOUNDER, BRAINHUB

Co-founder of Brainhub, Matt describes himself as a “serial entrepreneur”. Throughout his career, Matt has developed several startups in Germany, wearing many hats- from a marketer to an IT Engineer and customer support specialist. As a host of the Better Tech Leadership podcast, Matt talks about growing successful businesses and the challenges of being a startup founder and investor.

Romano Roth
Chief of DevOps

A Senior leader with over 20 years of experience in various domains, including financial, insurance, cyber security, electricity, medical, and aviation. Romano has a passion for helping companies bring people, processes, and technology together to deliver continuous value to their customers.

Transcript

Romano I'm really happy

to be here today with you.



You're pretty long in the tech

industry, as I must say so.



And I would like to talk with you a lot



about DevOps because I think

you are the DevOps guy.



Here.

And I wanted to start



this interview with the first question,

what are the biggest mistakes that you see



are around the DevOps

side on a client side?



So the biggest mistake that I see

on the client side is that you try to do



a little bit of DevOps so that you

want to introduce that DevOps thingy.



That's something I see.



What you can see is that clients then tend



to go and say, okay, let's build

a DevOps silo organization.



But when you look at what we are trying



to solve is usually we are trying

to get a value stream going.



So really the flow of value through

the organization and we don't want



to have, let's say, these walls

of confusion between the silos.



So by introducing just another DevOps



unit, you are introducing just another

silo in the end between dev and Ops again,



which can be a first starting point if

you want to experiment with DevOps.



But usually you need to get rid of that.



So that's usually one of the big problems

that I see that the management says,



I also want to do a little

bit of that DevOps thingy.



And how about if you are starting work



with a new client or you

are in talks with a client?



I mean, what problems are you

solving for them with DevOps?



What problems do they have and how

you can help to solve them?



Usually when you look at the CIO or



the CEO of a company,

what kind of problems do they have?



So first of all, the problem is they need



to have a faster time

to market for their products.



It doesn't depend what kind of product it

is, big cyberphysical systems,



or electronic mechanics and software

together, or only a software product.



They need to have really

that faster time to market.



They need to improve the quality of their

product and they need to do more with less



money and they need to have

higher customer satisfaction.



So when you look at these four points,

you already can see that you need



to change something fundamentally

how you develop digital products.



And here DevOps can massively help because



DevOps is that mindset,

the culture and a set of technical



practices which allow you to increase

the flow of value through the customer



by continuously delivering value

to the customer and bringing or building



in the quality directly

from the beginning.



So that's the problem which we

are solving with devop.



Okay?

And I assume it might be challenging



to introduce it for established businesses

which are pretty long on the market,



they do things in a way they

do and they think it's okay.



How to convince those stakeholders,



I mean, many tech leaders

have the problems to convince like why do



we need to change,

why do we need to disrupt it?



Yeah, and here we are in a problem

space that I usually see.



We had it already in the beginning.



We want to introduce a little bit



of that DevOps but we don't

want to really change things.



That's usually also something that I see.



I distinguish between two things,

one area or one type of company.



They really struggle heavily so they



are short before going bankrupt or they

are really with their back on the wall so



they have a burning platform

they really need to move.



So there it's quite

simple to change things.



This is usually a type of company



where you can introduce DevOps,

the new way of working and you also can



introduce fast changes because management

is heavily aware of now really we need



to turn the ship around or

there will be no ship anymore.



So I think this one is not so interesting,



the other one are more interesting where

let's say someone from a senior management



or even the CEO says we need to change

things but we don't yet have that burning



platform and again, here we

have two types of company.



One type of company is where senior

management really sees hey,



in five to ten years we will have

a massive problem because our industry or



our product will be disrupted by startups

or by anything else, AI, you name it.



And they really have that sense of urgency



and they want to invest into that and I

think we need to talk about these.



And then there is the other company where,

let's say there is sort of a sense



of urgency, but they don't

really want to change.



And for me it's always quite important



to understand of what kind

of company are we talking about?



Because the approach is a little bit

different in that case where senior



management only wants

a little bit of change.



Yeah, you can do that but you

do that at a slower pace.



You really go slow step by step through



the processes and you

change it step by step.



The other part where you have the senior



management wants to have that change,

you need to utilize this and you really



need to work heavily

with the senior management.



And because you have the senior management

support, you also get a person



who supports that and you are then doing

the strategy and also the alignment with



that person and then you go

into the change with that.



Okay, that makes sense.



And you mentioned the AI.



I wanted to ask you about your opinion

about the Chat GPT and the similar models.



Do you think in the upcoming years this

will disrupt the way or maybe solve



the problem of talent shortage within the

developers or what is your opinion here?



It's quite interesting,

I read quite a lot.



What I can see is with this whole AI.



I think some of the problems which we

are having will just go away.



So we don't need to solve a certain

amount of problems anymore.



I don't know which one it be, but I

think some work will just disappear.



What I believe is that we will

have new types of work coming up.



So I don't think that prompt

engineer will be the next big thing.



I think it's more maintaining these

AIS or these digital assistants.



This will be a new group

of jobs which will come up.



What I also see when I look at,

especially when we are building complex



pipelines or complex products,

I'm not sure that an AI at the moment can



really handle these complex type

of products which we are building.



They can build parts of it.



But especially when it comes



to requirements engineering,

asking the right questions, engaging



with the customer or with the clients,

I think this is still a problem.



But AI can help us here and will of course

also help us here to get the right



requirements and asking

the right question.



But the doing I think is still on our side

and then also making sense out of it.



So I think there will be a disruption,



but I don't think it will be massively and

it will help us with the talent shortage.



I think this is something

we will still have.



Okay, and your experience here at Zulka,

you are 21, 22 years here.



So he started as an engineer and

you grow to the role when you are more



in contact with clients, creating

offer for clients on a DevOps site.



So I'm wondering how your perception

on working with clients change over time.



So when you started 20 years ago,

when you were an engineer,



probably you've seen it a bit

different than you see it today.



So are there any concepts that I.



Mean, it's quite funny that you are asking

that because when you look 21 years back



so in the year 2002,

sort of when I look at the projects



which we have done,

we have done amazing projects.



I worked on a power plant



mapping tool which we were

implementing with C plus plus.



It was amazing.



But the cool thing was we were a team



of engineers

doing everything from requirements



engineering, over development,

over operation of the software,



testing it, releasing it, and also working

very, very closely with the client.



And then things have changed during the

time the projects were getting bigger.



And what I could see is

that new silos were introduced.



Like you have the requirements

engineering silos or of the development.



And suddenly you were only

focusing on development.



And no, you don't do the testing,

you are just doing the development.



And

what happened is the development task went



into a direction where you just was

developing features that you were



in a feature factory,

but it was absolutely not good.



And at the moment we are reverting



that completely with the DevOps approach

we are going again back to cross



functional teams where the team is really

responsible about the whole product.



So for me this was sort of a journey



and now we are sort of back

at the starting point.



The only thing that I see is

that the complexity is now quite big



and this is something which I see is quite

challenging because when I look again back



in the year 2002, the only thing I needed

to do is doing C Plus Plus programming.



Of course this was a challenge and we



didn't have a stack overflow or

code pilot or anything like that.



We had books which you need to read

exactly and we talked with each other.



We were also struggling there,

but on a different scale.



We had Windows machines,



this was our focus and we had a small

deployment, so the complexity was lower.



Nowadays, when you are developing

a software we need to learn more things



like potentially you need to learn

multiple programming languages.



Of course they are sort of easier



to handle than C Plus Plus,

but still you need to understand them.



Then you have the CI CD pipeline, a whole



ecosystem of tools which allow you

to continuously build your software.



You need to understand security,

you need to understand architecture.



And then the whole thing about deploying

it into a Kubernetes cluster is again



a whole new universe where you are

going to operate the software.



So the cognitive load



on single person on the whole team

is higher because of the technology.



I think like this year for many

companies is about doing more for less.



So we entered the session phase and a lot



of companies aligning themselves around

optimization, around the profitability.



And I'm thinking like what you would



advise other tech leaders what they could

do in their companies to save on the cost



or to improve the performance

on a tech site.



So one of the biggest issues that I see,

I see that also at Tilka when I look



at internal initiatives which you are

doing, we are doing too much,



you have so many possibilities

and the problem is always priorizing.



priorizing things is

really a difficult thing.



Also I have difficulties

with priorizing the things,



but especially at companies

it's really a difficult thing.



Now, again, out of perspective of DevOps,



I usually say you need to build

the right things right?



Now the right things right.



So building it right is more, let's say,

the pipeline, the software engineering,



how you automate things,

how you're building quality.



But I think that's already something

that we mastered quite good.



We have a good tooling, good technology,

I think we know how to do it.



But building the right thing

is in my opinion also something that is



in the DevOps area, but goes

more on the business side.



So deciding what to build and also

defining the MVP out of it.



And here there is also

great tooling out there.



One of the toolings is you introduce



a Lean portfolio management which is

nothing else than a Kanban bot.



So you're giving transparency on what you



are already building and what

is sort of in the pipeline.



I think having an overview on what is



upcoming and what do you want to do

is already a great start point.



The other thing is when you want to build

something or you have a new idea,



then behind an idea there is

always a hypothesis.



You have a hypothesis that building

that will enable us to bring that.



So extracting out of an idea



the hypothesis statement and also saying

okay, this is the hypothesis is a great



thing and then thinking about what are

the leading indicators which will show us



that this hypothesis is

true is very very good.



And with that you can then define

the MVP which you can then build.



And when you look at that,

then suddenly every idea that you have,



you are going to break out

the hypothesis behind this idea.



You are going to look at what are

the leading indicators which show me



that this hypothesis is true,

and then you define an MVP to approve



these leading indicators

and that this hypothesis is true.



Which means now you are building Lean



experiments where you validate very fast

the hypothesis behind every idea



which leads to faster decision making

and not building stuff that nobody needs.



And this is the building, the right thing.

Right.



And this is something which comes

by the way from Eric Reese from the Lean



start, the lean startup

cycle that I just described.



But implementing that is really essential

and it's not only for startup



in my opinion, it's also something you

need to implement in mature companies.



Yeah, I think what you said.



I talked with one leader yesterday who is



head of engineering at a company of I

think like a couple thousand people.



And he mentioned the same the way



to experiment and to build

stuff in a more MVP way.



And especially in established

corporations.



It's really challenging because sometimes



people want to make

everything bulletproof.



Right.

And if you make the experiment,



you cannot approach it this way

because it doesn't make sense.



It's not an experiment anymore.

Exactly.



And we at Turkia we also have

that challenge and I think there are two



types of let's say

projects or initiatives.



I think there is this initiative where you

just have an idea and you want to prove it



sort of on the market,

if it's really worth it.



And then of course there is let's say

you are introducing SAP in a company.



Yeah, well, that's not the hypothesis,

this is a project.



Yeah, in that case you

will just do that project.



There is no hypothesis behind that project



but you still can slice it into smaller

parts and then just do that.



But I think we need to distinguish

between these two things.



My guest mentioned yesterday one more



environment where you cannot do so

many MVPs, he said about the airport.



So you cannot play

with the plane set much, right?



Yeah.

And also medically.



Medical, the same.



And how do you stay with

current market trends?



How do you educate yourself?



How do you find the ideas



to create something new for the client,

to create the innovation or disruption?



There are different ways.



At Tulka, we have our employee day every

month where we have different sessions.



We are quite a big company now,



and you have different tracks from the

different practices which we are having.



And there you can sit in and you also get



a glimpse on new trends and new

things that are coming up.



So that's one important

thing that I'm doing.



Then, of course,

I read a lot of books, news,



which I am reading,

also watching a lot of video.



But I think what for me helped me quite

a lot is we at Silka,



we have the O'Reilly license,

and the O'Reilly platform is really a cool



platform and you get

a lot of insights there.



That's one thing where I get, let's say,



most of the knowledge out of it from the

books and the videos from this platform.



And on the other side,

we also have a Gartner account.



And from there I get the strategic



insights from Gartner, which is,

in my opinion, very valuable.



And I'm thinking, like,

what is your decision making process



around new tools, around new frameworks,

new approaches in your area?



Because there are so many things,



for example, let's say in JavaScript, you

have each library and framework each day.



So you need to at some point decide



and influence the team because you

have big team and you influence them.



What and how you approach problems



for clients and what is your

decision making when you decide?



Like, hey, now we use the chat GPT.



Everybody use it with the new trends.



Usually what I'm doing

when I'm a project or outside



of a project, I always introduce

an architectural decision record.



And with the architectural decision record

in a project, I always state what is



the problem I'm trying to solve and sort

of what is the trade off analysis of it.



And then I document the decision.



So when it comes to deciding whatever we

want to go with a new framework,



I usually go with the team and make

a trade off analysis, where I see,



first of all, I ask the question, what

kind of problem are we trying to solve?



Do we really have that problem?



Because that's always

a good question to ask.



And then I usually say, okay,

what are the categories which we have?



Where we say, okay,



where we do the trade off analysis

and what kind of tools do we have?



And then we just make a trade

off analysis out of it.



And the cool thing is you can do that very

easily and very fast



on a whiteboard but it helps you visualize

the trade offs,



your options sort of and also

the categories where you are going through



and it also helps the team in the

discussion wherever they want to go.



And usually what you see is

there is no silver bullet.



You always have trade offs when you are

going with framework A or with framework B



or with tool A or with tool B

there are always trade offs.



But naming these trade offs and saying



hey,

at the point of the decision we were aware



of these trade offs and we accepted them

because we think we have these and these



points which are more valuable

and these are the strong parts of it.



I think this is a very good thing.



Then you can make based on,

let's say facts the decision.



Okay, let's talk now more

about the teams and people.



I'm wondering what kind of skills or

qualities are you looking for in new



employees or the leaders

that you are hiring?



Do you have your approach like

what is really important for you?



So when we are hiring,

our hiring process is always in that way.



We have a recruiting department

which scans through the CVS.



There we have some rules defined what we

are looking for also in terms of job



profiles and then in the next step

when they have filtered the CVS we are



going through the CVS and then when we

have identified a potential candidate now



we always do a so called

cultural assessment.



This is 1 hour meeting where we just have

a look if the person's culture fits



into our culture and also our

culture fits to the person.



It's really an open discussion where we



having and where we just look

do we like each other?



And I think this is in my opinion

one of the most important things.



It sounds a little bit stupid,

but cultural wise this is really



an important thing and this is also why

I'm still at Turkish since 21 years.



I really really like the culture



and the people and it's so important

with whom you are working



because you're working quite a long day

is await hours a day with these persons.



So that's an important part.



Then when we have done that then there is



the second part which is then

the technical assessment and this is then



over 3 hours where we

really go into technology.



And I mean, there it really depends

on the role, but it's quite obvious.



You need to have a good technical

background and you need to explain certain



things in your area

and if that's really a fit so the cultural



part and the technology part, then

we decide to hire that person.



And how about team setup?



I mean hybrid remote, in house outsource.



Do you have any opinion?



I mean like pro opinion or you say like

no, always no about one of those setups.



I have a very strong opinion about that.



So when you look at the value flow



and also reducing barriers and also when

you look at science, it's quite obvious.



A team which is in one location and works

strongly together physically in one



location is sort of the best

performing team point.



It is very very obvious.



And also science shows that.



So I always go into this direction,

I always say hey look,



let's have a team and also language wise

and culture wise,



they need to have the same culture, they

also need to speak the same language.



So also when you have sort of a German



speaking team and you want to introduce

an English speaking person,



it is usually not the best idea to do

that because it will slow the team down.



So again, when you look just



at the performance then really one

language, one location and everybody



at that location, of course

this is not always possible.



And then you make trade offs.



It's again all about trade offs and

you can do these trade offs but you need



to be aware that you are

slowing down the team.



There are certain setups which I

absolutely don't recommend.



For example, you have one team at one

place and a second person completely



remote and you need

to do everything hybrid.



These are in my opinion so called bullshit

set up which you absolutely shouldn't do.



Of course it can happen that you get



in such a situation, but you

should not go into that situation.



So to make it short, really in one

location would be my absolute favorite.



The other thing what you also can do if



the whole team is completely distributed

yeah then go completely distributed



but then you have a distributed setup

but with all of the trade offs and.



How about within those distributed teams

when you go this direction,



what are the key factors to have the best

performance out such a distributed teams?



How to keep them efficient, let's say.



So what I usually do is when we have such

a distributed setup then every three



months

we want to meet at a certain location



somewhere where we can sort

of do the team bonding.



And I think every three months is a very

good schedule to again bond the team



at a certain location where everybody



meets in one week and works all together.



That would be my recommendation because

you need to have sort of these team



bonding phases when it comes then

to let's say the normal working.



I usually recommend to have sort

of a daily stand up which is on time,



but not the bullshit daily stand up,

a real daily stand up where you are really



also listening to the people

and trying to help each other.



It's not that status meeting,

it's really about understanding what are



the challenges of the other members

and how can we help each other.



So that we can really progress.



I think these are the important things.



So having sort of implemented some

ceremonies which helps the team to get



sort of a structure in the day,

plus that every three months,



coming together and having that

get together, I think these are the two



most important things that I would

recommend in a fully distributed setup.



Okay.



And I'm wondering,

have you experienced talent shortage



in recent years,

especially here in Switzerland?



Because I'm not quite sure.



And my second question is if yes,

how you deal with it?



Yeah, we have talent shortage massively.



How we deal with it is



on one side we are doing education on.



We are offering an apprenticeship

for really the youngest people.



So we are really trying

to bring the software engineering really



to very young people so that we can build

them up already in a very early stage.



And I think as a company



this is also something you need

to give back to the society.



You need to enable the people.



What we are also doing is we are doing



lectures at the universities to already

educate the people in a right direction.



We also do, for example,



the DevOps Meetup Zurich,

where we enable also the community.



It's all about enabling sort



of the community, making the people aware

that software engineering is a cool thing.



But of course, these are sort of



things that take quite a long time

and we are still working on that.



On a short term, what we are doing is

we are going of course to the market



and say, hey, look,

we are a very cool company.



You also see we are working

in a quite nice office.



We have a good culture,

we have good people, we have education



at Silka and this is sort of how

we deal with the shortage.



We really make it pleasant

for the people to work at Cirque.



We also offer them part

time work and so on.



So it's really about understanding what



the people want from a company and then

giving them the possibility to strive.



But of course, when it comes to recruiting



new people, it's also for us, it's very



hard to hire new people, but it works.



We don't have the growth rate we would



like to have, but I think

we're doing quite good.



That's great.

I think the academic it's a great solution



for young people so you can shape them

with the culture and all that stuff.



And I wanted to ask you about your most

important lessons as a tech leader.



Maybe you have some lessons you say like,



hey, ten years ago I thought about it

in this way and today I have completely



different opinion on, I don't know,

training people, hiring people,



building some stuff, some lessons

learned that you could share.



I think one of the most important lessons

that I learned is that you should



always strive for a simple

solution, but not simpler.



I know that that quote comes



from Einstein, but I think

it's a very good quote.



And in the past I also did quite a lot



of architecture or software engineering

where I built quite a complex system.



And what I then saw is that I

was able to understand it.



But my team members struggled

to understand such a complex system.



So what I've learned is



this goes from software engineering

to also organizations or even if you



document a thing, you always need

to bring it down to very simple things.



But of course not too simple,



but in a way so that everybody in your

team really can understand it.



And I think this is the magic

which you need to do.



Usually we as tech leader,

we are overthinking things,



making things more complicated because

we want to solve all of the problem.



And in my opinion,

you should always strive for the 80 20



solution and make it really as

simple as possible, but not simple.



That's a good point.

And I have the last question for you.



Any books, blog post, resources,



podcasts that helped you

shape yourself as a leader?



I mean, what helped you as a tech leader?



Yeah, so for me the book Accelerate

was really an eye opening book because it



looked at the whole software engineering

process in a scientific way.



And that was for me quite an eye opening



book because I suddenly understood

the science behind software engineering.



Of course, there are other books

out there which are also amazing.



One which I would like to mention is



Getting Things Done because that book

really helped me,



let's say with priorizing stuff and also

dealing with the high amount of input or



emails and tasks you are getting

and really getting along with it.



So that was quite an influential book.



And then there was also a book

on Notetaking, but I don't know,



I think it's professional notetaking

and this also had quite an impact on me



because it showed me how I not take

meeting notes, really take notes when you



are learning things and how you build

up the so called tettle constancy stem.



I think it's also in English that you are

using that word, really building that up.



That helped me quite a lot.



Also remembering all of the stuff

that you need to remember.



Great.

Thank you Romano.



Thank you for really insightful

answers to my question.



Yeah, and thank you for finding

time for this interview.



Thank you also, it was awesome.

Explore similar episodes

Unlocking Engineering Leadership: Insights from the Automotive Industry

In this episode, Felipe Streb explores cultural variations in work practices, communication, and trust-building in the tech industry. Felipe contrasts his work life in Spain and Germany, particularly noting differences in work hours and organizational preferences. His role at SEAT:CODE a digitalization center for the automotive industry, showcases the importance of agile development processes.

listen now
Crafting Success in Tech: Stories from the Frontlines of Innovation

In this episode, Pat Kua shares insights into his leadership success through nurturing others, particularly new tech leads, managers, directors, VPs, and CTOs, and stresses the need for personalized definitions of success. He highlights the importance of support for those transitioning into management roles and effective teaching skills for leaders.

listen now
From Sports to Success: Unveiling Leadership Strategies

In this episode David shares insights from his career at eBay and mobile.de. He underscores the importance of delivering valuable products to users and giving back to the community by advising early-stage startups. At mobile.de, his team is a balanced mix of internal and external members to foster innovation while maintaining core business integrity.

listen now
Agility and Adaptability Strategies for Success in Product Development and Leadership

In this episode Leszek interviews Andrew Martinez, VP of Product at Honeysales. Their discussion highlights the role of AI in enhancing human efficiency, focusing on balancing AI autonomy with maintaining seller control over messaging. Challenges like ensuring personalized communication and improving AI output through examples of effective messages are addressed.

listen now