D for DevOps: The philosophy of software engineering

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.

‍