Hello friends, this is the Alphalist Podcast. I am your host Tobi. The goal of the Alphalist Podcast is to empower CTOs with the info and insight they need to make the best decisions for their company. We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
If you believe in the power of accumulated knowledge to accelerate growth, Make sure to subscribe to this podcast. Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events, just go to alphalist. com to apply.
Welcome to the Alphalist podcast. I'm your host, Tobi, and today with me is. Stefan, and Stefan is the founder of Freiheit. And what we talk about today is radical engineering culture and Freiheit's very high bar in hiring. And normally I don't like to have guests from agencies because agency guests always try to sell.
But, um, I think, um, Freiheit is very special and that's why, like, I know Stefan for ages and I just wanted to talk. To him about it because he thought about so many things and, uh, his thoughts on in many, many, um, areas very special and different. Um, and, um, I, I think it's, it's really worth sharing. So, uh, that's why we're here. Um, Stefan, you founded Freiheit. In 1999, is that correctly? Is that correct? Yeah,
that's correct. I have, uh, first I have to get two things straight. So one is the company is called Freiheit. com Technologies. So Freiheit is a German word for freedom. And, um, one of my clients said, like, this is the only word that is positively annotated in all languages.
So that's, that's one thing. Um, and we're not an agency. So we are a software engineering company. We always have been. Of course, we started in the internet times, like a quarter of a century ago, but the focus was on writing real software. And for the internet at that time, nobody did that. Like nobody knew how to build systems that had to run 24 seven and, uh, on, on high load. This was not normal. And so we had to figure out how to do that.
But at that time, there were like many others also trying to figure out the same thing, right? Like ID Media and others. Well, they were mostly more like design oriented, right? And not so much software oriented. And I guess that's the difference. Yes,
that was actually was great times in Hamburg was like the center of the internet world. And everybody was totally excited. And I just started the company. I wanted to write software that runs in the browser, actually. But at that time. This was very edgy. Nobody was doing at that time, but I thought like installing software on the windows was a pain in the ass.
It still is not as painful, maybe as it was 25, 30 years ago, but that was basically the starting point. And, uh, and the internet times were actually great because this was the first time when my mother was able to understand what I was actually doing. When they said like, I do software, nobody had seen software before.
It only basically when the internet started, people knew like, ah, okay, you can build this stuff with it. And, and the agency were doing mostly the. And we were doing like the really hardcore backend stuff at that time already. As, as far as it was there. Right. I mean, I guess it like was quite different to today.
Uh, everyone is now writing software for the browser and, uh, applications got much more complex. Yeah. Back then there was nothing. Right. So you build on top of nothing, which is also hard. So, um, yeah, it was actually very funny because. So often at that time we said, Oh, we only had ones and zeros. And sometimes not even the ones or so that was really a great time.
We had to build our own web frameworks. We had to build our own database access layers. We built our own server software and that was always part of the project. So we had to build all the infrastructure first, uh, before we could start anything. When you see this now, how many stuff you have, and of course you literally have to find the first one out how to use all that stuff.
Uh, so there's like, also when I started programming. I couldn't look up anything on the internet, so I had to figure out everything myself as a programmer, so I couldn't ask anybody, you always were sitting in front of a problem, you were alone, you could not ask the internet how to solve it. Or chat GPT. Or chat GPT.
So amongst your clients, so your software runs on Mercedes cars, as far as I know, uh, so Daimler is one of your clients, Mitro, Chibo, um, and, and Stackit and the Schwarz Group. Um, anything I forgot or anything you want to add? Yeah. It's like a quarter of a century. It's like really who's who in European business and industry. It's, it's really like that.
Why I invited you, like, from my perspective, you stand for a high pace culture with like really talented people and at a very high bar and recruiting. And that's what, what fascinates me in a way. Um, because on the other end, you also have. Every once in a while. I mean, you also have interesting problems, right?
Like every, every engineer wants to write software for Mercedes, I guess. Um, but you most likely also have boring problems with like more boring clients. And, uh, I wanted to talk about like how you keep your team motivated and how you actually get the right people in. Um, and, uh, how do you, how, how you build that, like, let's say high bar that you have in recruiting, um, and, and how you maintain it, uh, at that level.
Uh, so, so happy to talk about that. Maybe, um, like from your perspective, could you describe the culture of, of freiheit. com in three words or less? Yeah. So what
we say our mission is, is a ship great software. So, and this. We were not like choosing it. It basically came to me at one point in time. Uh, there was a great story from Jamie Zawinski who was writing the Netscape browser, I think most of it probably alone, probably not alone, but he wrote a lot of code and once they started to rewrite the browser and Java at that time, another team, and they were like doing like this.
Crazy object oriented stuff. And so it's, it's one of the books he wrote and you can read it up and they were never finished, they never finished the browser. And basically he talked with the guys and he said like, your job is not to write code, your job is to ship great software, to ship software. So this really stick with me because, uh, it's not about like what people say, like, Oh, everything has to be elegant.
And this is often a synonym for over engineering. What you really want to do is build something that is robust and super simple that you can build stuff that is super simple that you can assemble something complex from simple components. And this is what we mean by great software. Great software is actually simple, has as few dependencies as possible, as few parts as possible, like any good machine has good parts, as few parts.
Uh, and then shipping means you deliver it. And this means on, on time on budget. And that's really. What I started and you said like what we found 1999. Yes, but actually I started in October 1st 1998 when Google was founded. So it was the same month. And when I started, it was, it was really, um, So and and we said 1999 because it's cooler, right?
It's like found in last millennium or so, uh, but 1998 October was actually the first part and and, uh, yeah, and and that now I found now I lost my my thread by getting into too many side sentences. But so, um, You build great software, uh, with little, uh, little complexity. Um, and, um, and that also sips over in your culture or that you reduce friction, for example, or.
Yeah, that's, that's, um, a program that is always running in our company. It's called find and remove friction because we, it's like other companies that like, Oh, we have a scrum master doing that, but actually I've never seen that in real life, not quite sure if anybody has ever seen it. It's very unlikely that you can hire people that really can.
Um, fuck, like complex organizations when they're not part of them. So we really think programmers should do this themselves. So when I started, I'm a programmer, I studied computer science, I studied systems analysis. I wrote programs my whole life, since 1983, so over 40 years now. So and I wanted to write code and, and I worked with project managers, really smart people, but they were working in the projects and they didn't know.
Um, how to do software. So they were promising things that were not possible. They couldn't estimate timelines because they didn't know how to do it. And then I thought, and then I always had to fix their problems in planning. I had to then make it happen. And so I thought like in my company, there's no non engineers, actually, there's.
Really doesn't work out. You need business people and you need good people that don't do engineering, but we have a very, very high number of NGOs, like always 85%. And it's because I started that company. I wanted to write code. I wanted to understand the whole thing myself, and I constantly improved the performance of your.
Organization, like when something didn't work, I fixed it. If we had problems when the communication was a client or they didn't know what, what they wanted to do, I went in there and talked with them. And so that's what I also teach to our people. It's like in our company, every engineer does from idea to running it in production.
So you, so it's really like you build it, you run it. It's really like from idea. Talking with the people who will use it, write the code and then run it yourself. So the whole thing. So anybody who worked in our company can build a whole company around something. Probably, maybe not everybody's a company builder in the end, but you could build the whole product.
Okay. Yeah. Um, I'm, I'm looking forward to understand like how that fits into your hiring. Um, uh, strategy as well with like hiring very young people that come from university directly, but maybe let's, let's, um, start, start back or move, move back a little. So that was like, then there was one, one fundamental moment when you said, I don't, I don't just want to write software.
I want to fundamentally, uh, change the way software is built. Right. Um, and then you built that agency, uh, sorry, software engineering company. Um, uh, I, I always mix that up. Uh, forgive me. Um, and, um, then you straight away started to find good talent and straight away had that culture or when did you, was there a moment like a fundamental shift where you said, Hey, this is fucked. I need to rebuild it. I need to refactor it. Um, what was that there or no, it
was, I think it was. So when I started it, I wanted just to work with some friends who I know are good programmers. So I went, everybody went to university, maybe went to a group where you did a group work. And you were like maybe five people and only two were doing the work.
Right. And so I also worked on software teams like that. And I did their work and I think everybody should do their own work. So this was one thing where I said like, Oh, I only hire people who know who I know who can do the work. And so I can rely on them. They can rely on me. And, and when somebody has a problem, you can ask and people help you.
But in the end, everybody does their own work. So everybody is like, try to achieve their own thing. And that was basically the founding moment. I actually didn't want to have a large company. I only wanted to have a great company writing great software. Actually, the, the founding day, when I met with the first three guys that I wanted to hire, we, we sat in a bar in Eppendorf here.
And I said to them, like, Hey guys, imagine that we like write really great software. And, uh, we only hire people really know who are great and guess what, people will pay us for it. It was, it's still amazing to me that my hobby, I'm getting paid for it. And at that time it was even more. I was like, Oh, now I found my company.
It's actually my hobby. And then I'm getting paid for this. Maybe like a bodybuilder or so like being a professional bodybuilder and you go every day to the gym or so maybe that's the same feeling. But that was actually why I did it. And I never imagined it to be at the size that we have now. Okay, and then you basically figured out from the start, Hey, I always want to have like 10 X engineers basically on each team.
So I want to like everyone to be productive in a way. Um, and everyone to focus on reducing friction. Um, and how did that reflect? Um, or how is that reflected in your hiring process now? Like, how does your hiring process look like? Yeah, I, I, I often see things from a different perspective. My, my point on that is actually that probably the 10x engineer is a normal engineer, how an engineer should be.
Yes. And is, and everybody else is maybe not qualified to read and write software, right? They're, they're not really good people. And that's how the world is also so distributed. Most of. Everything is average. It's also what I say in the company all the time. Uh, basically the world is average. What, what everybody is doing is by definition average because everybody's doing it.
So for me the question is always what is outside of average. And of course you want to be, don't want to be below average. You want to be above average. And how to figure that out, that's the interesting part. And it comes with like asking, when somebody tells you something is the truth, then think for yourself, what if not?
What if this is not true? And then you come to interesting things. And, uh, and this is also how I started the company. I, I knew I worked in like in the industry before for over 10 years, I wrote over 10 years, a C code, for example, and I worked in many, many projects and everybody was doing this waterfall model and everybody knew it doesn't work.
And then people said like, yeah, you have to be PMM five or so like this, the certification level, and then everything works. As, as the chime. And actually it didn't. And I thought like, why are they doing this? And I had a good experience doing iterative work, like going to somebody ask them, oh, what do you really want to accomplish?
And then I write a tool for you. So I think programmers actually tool build us for humans. So talk with the humans who want to work with your software and then you go in there and then. Yeah, you show them what you, what you understood and write code and show the example. So this iterative thing we did from the very beginning, that's why I said programmers do all the things they, they actually talk with end users.
And so we did this way before this agile thing, which actually I. I don't like the term Agile and I don't like how things are often religiously executed in Agile without thinking about what you really want to accomplish. And how Agile became the new waterfall, right? Like, I mean, you just take one big waterfall and, uh, like cut it into smaller ones.
Yeah, yeah. And also this endless loop of. Two week cycles, like, Hey, what do we wanna achieve? What do we wanna achieve? And then smuggling through stuff like, I, I dunno, I, I'm not a big fan of how, how it turned out to be, uh, ultimately for company. Yeah, that's, that's really funny because, uh, it's, it feels the same for me as in the times of Waterfall because everybody said, yeah, it works just at, not in your place because you, you didn't like Certify PMM five and today's the same.
It's like, oh, agile doesn't work. If it doesn't work. You don't trust your people enough. So don't. Just have to have more trust, and I think you cannot just have trust, you can, you should, you should, of course, you should trust people, but if you really want to accomplish something, you must also, people must have the skills, you cannot just hire random people and hope they have the skills, so one part of also our onboarding process is figuring out what kind of skills people have, and of course our hiring process is the same, we have to find out what kind of Skills people have and it's not about experience.
We don't hire for a stack. For example, we don't hire like whatever programming language is hot. And then we hire people for that. We basically hire software engineers or actually we turn people into software engineers because we think what we learned in 25 years and what I learned in 40 years you cannot learn in university and you don't learn it A normal companies today, um, and especially universities is I, I went to all the soft engineering seminars and read all the books about it.
And actually all of these books are wrong. It's complete bullshit what they write. Why? Because they were written by professors at that time. And these professors never left university, they never built a large system, maybe some of them, if you were lucky, were programmers, or some were like great computer scientists, like Knuth or Dijkstra or so, like great programmers, probably also great mathematicians, but like, how to build software in a large team, a professor doesn't know, and when he writes a book, Um, what do you think will happen?
So, and this is also why, why we think we cannot just hire people from university or from the market and then, um, have them lead our team. So everybody in our company has to go through all the engineering levels. So we start at the bottom and if you're a principal engineer in our company, we have only a few of them, but they are 20 years in our company and staff engineers are at least 10 years in our company.
So we have a. Like it's, it's not like the rest of the industry where people like jumping jobs every two years, because in our company you can learn to take over larger scopes of work and do really large projects with 10, 000s of mandates and, and dozens or hundreds of people, uh, involved. And this is a different beast.
When you, when you start out as a programmer and you do one user story, that's basically your smallest project that you get in our company. And then you grow. And at one point in time, you will be responsible for 10, 000s of mandates. Of work and millions of lines of code. And this is of course, a long journey that you cannot learn in, in, in five or 10 years. Mm-hmm. Mm-hmm.
A absolutely. Um, like when we pre discussed, you also said that you often hire people that ha achieved something in life already, like a PhD or something. And you said like a phy uh, physics PhD is like the best. Um, or one, one of those achievements that you look out for. Does it then work for like.
How do you filter than people that are like more academia focused to the ones that are, uh, maybe practical. So they are, from my perspective, the ones that like better become a professor, um, because they are really tied to academia and never, never applied something. And then the ones that can apply. And can code and then those two can even be split into two groups the ones that really perfect become perfect in it and good in it and the ones that just use it as a tool how do you how do you differentiate there and how do you like spot the right.
Uh, critical talent for you. Yeah. It's not that we focus on academia. It's, uh, it's a concept we call tested in life. So we want, so obviously I said, like, we want people to all do their own work. So, and everybody should like, uh, strive to, to. Be successful, make this mission successful. So I have to add that in 25 years, every project that we started was delivered successfully.
So it means on time on budget on target on target means the functionality that you need. So for example, really hard to believe for someone who is strong in software. So yeah, that's cool. But, uh, That's, that's, I'm, I'm, I cannot just say this like out of thin air when you, like, uh, when you look at, at the past that we had.
So, Friat employees, if it's different, please call me. Yeah, yeah, yeah, yeah, you can. So, yeah, but this is a, it's a strong journey because, uh, um, This is also basically our mission now, it's called Never Late, Never Failed. So that's a, that's a mission that will never be fulfilled, that, that is already fulfilled.
And we always, every day, today, we have to fulfill it, like, different, like, normal visions, like, uh, one, it's not a normal vision, but when you see, like, SpaceX, for example, where the vision is to bring a person to Mars and return. And return it to us. That's the vision. And at one point in time, it will be fulfilled.
But it is not today. Our mission is already fulfilled. We do successful large projects and even like getting larger projects every day or not every day, but every year. And, uh, and we cannot fail, right? If we fail, then Then we can close shops. That's basically, and this is a high pressure, but it's also a lot of fun.
And so it is why we try to hire people from university that are tested in life. And that means they were, they had to work hard through something. What, what is a good signal is for example, a PhD in physics, because it's really hard to get one. And I think nobody in university Like the professors will explain you physics, you have to figure out yourself.
All the physics PhD that we have, basically they, they are not nannied by the professors there. So it's a hard job and once you got through that, you have to be systematic, you have to sit alone in front of your computer. You have to do the stuff alone and you have to reach an end. And this is also what a programmer has to do.
You sit in front of your computer and you have to solve problems every day alone. And, uh, you have to become good at that. And, uh, and also physics also teaches you a lot about structure. So I, this is like the, the Primary target we have, but of course we have many people from mathematics, computer science as well, but we always look for like the one thing where I think like I, uh, you really got tested in life.
And university degree is a must for you or do you also have some people that I don't know dropped out or never started, um, and just took a different path and are still tested in life? Yes, so
for years and years and years we didn't, and we always had also people applying without a finished university degree, and in the interviews they were not making it, so, but we're always trying it, so we never have like, like fixed rules, like we have this one rule and we never break it, so we always say like we have rules and we stick to them, until we don't, like, break it.
Maybe there are sometimes exceptions to the roots. And when you understand the roots, you can also break them. Um, but also you can also remove roots when they are wrong. So we, and obviously this, why we, this, this like changing yourself all the time is important. And this same is true also for hiring. You always look for good people and sometimes tested in life can also be something completely different.
For example, we had one guy who was very shy and so, and we were not really. Clear if, um, so we, we have a lot of shy and introvert people and they really strive when they talk about technology, but not so much when, like in customer meetings or so. And we need enough people who can do that, right? So we cannot have just shy people, but, um, uh, we really then, um, found that guy and he was writing, um, uh, a front end for, uh, a console game, not for like a terminal game.
And it was maintaining it and hundreds of people were using it. So it is spare time. So it was also like an interesting thing that he was able to do this alone, running it for all the people without making money out of it. And it was really, everybody loved his game interface. And, um, yeah, this was also a part of tested in life. And it was also really good then. Okay. Okay. Um, what, what are your absolute deal breakers in an interview?
Yeah, that's very different. It's in the end you can check a lot of boxes and select all the grades and what did you do and what, what kind of accomplishments do you have? Um, but in the end, you really don't know how people in the end, um, perform in a team.
Um, I, I think, I think the more, we always look at people and say like, Is this person interesting? Do I, do I like to talk with that person? It's really important. Of course, one should check as much boxes as possible, but they should not be like, where you think like, Oh, I don't want to talk with that person or this person is rude sometime.
We like people to also be polite because you work together the whole day. We love to be in the office. So you want people to around you that, uh, that you like. And we, from, from like all the time we, we never had it. People fighting inside our company. We don't have departments fighting each other or politics or stuff like that.
We have nobody like, Oh, when this guy's in the kitchen, I leave and come back later. So we don't have that. So we really try to pick good people with good education and really want to accomplish something with Tested in Life. Okay, so no real deal breakers, but, uh, like you have to work out, uh, you have to fit to the culture.
Right. Um, is it, um, do you also hire senior people or do you mostly aim for like university, uh, like just finish, like people that just finished university or like, what is your, what, what's your, what's your aim normally? Yeah, so, um, we, we hire senior people, but you. So we have an engineering level permit.
So we have 14 different levels from junior to mid level senior staff and principal level. And so there's roughly 14 levels on a roughly, but exactly 14 levels. And, um, it's very clear on which level you have to have, which Skills and attributes like character traits. So it's written down, you get peer feedback around everything, you get, like the first 12 weeks when you start in our company, you get written feedback for every user story you do.
To really get you fast going on becoming really good. So it's really like a rocket ship, man. And so, um, we hire also senior people, but you start at the bottom. So you cannot, we don't hire people into a senior position. You start as a newbie. Also Google is doing that as well. Really? Yeah. Okay. So you start as, I think everybody starts, I don't know if it's still today, but uh, when, when we started looking into like, As a noogler, right?
Yeah, it's like, I think they start at level three, so I don't have level one because, Probably nobody wants to be level one. I, that's maybe an American thing. Uh, and then after nine months or so you get sorted into your level and this can also be above that. But we also say that we say like, uh, if you accomplish what is like needed on, on level six or so, then you could maybe jump, but we never have seen that, so we have only seen like a person jumping two levels. So
that means that like, let's say you, you want to hire like a very senior person, a senior IC. Uh, who has like 10 years of experience in different companies. Um, you also bring them down or them down to that salary level of a, of a, of a, of a starter. Um, and like, then after, after nine months, you, you, you, you increase it again or. So
I think somebody who worked 10 years somewhere, we had that in the past and then we were also matching the, um, the salaries, but often it didn't turn out, um, that they, people were able to do what is needed in our company. And so that's actually an interesting part. What is a senior? What does 10 years of experience mean?
So when you look at like all the. large engineering organizations you often have. I've seen so many. I, I did hundreds of projects also large because we started in the internet times. This was always scalable software, 24 seven large systems, many transactions, really stuff like that. So I've seen hundreds of projects like that and led them to success.
And I worked with so many different organizations and there's so many dysfunctional organizations like, um, What people often complain over on the internet, like you have one department doing the pipeline, but the pipeline always breaks in a slow. Everybody complains about the pipeline, so we don't have that.
We fix our pipelines ourselves, and when they break, when they're slow, we can do it in other companies. You can't or you cannot do like figuring out what should be built. You cannot find out what is the right thing to build because there's some product manager doing it alone, and you only have to work on tickets.
Like, that's the worst thing I can imagine. It's like when people say like, you have a team and they're working on tickets. Give me a ticket. I mean, who wants to work their life on coming to the office and working on a stack of tickets? Yeah. And this, and this why I think Many people have never seen what a successful and efficient organization could look like because all the organizations are tailored and have like, no, there's no end to end responsibilities in that.
And so that's why always everybody's trying to figure out how to make it work. And it's so exhausting that they, that they don't have experience how a really good project is actually working. But I think that also comes from like Agile. Um, being first applied in automotive industry where you really have like production chains partly.
Right. And, uh, where it's, uh, where, where you have those, those types of, of those stereotypes that really like do one thing again and again and again, and again. Um, Potentially that's like, like doesn't, doesn't work for software, right? You have to have. Um, rather a flow that, uh, you, you feel, feel fine with, um, and you have to be like enter and responsibility have to have and to enter into responsibility from my perspective as well, like really like being dependent as like I found like today's.
Front end world very frustrating, um, because, and that is right now dissolved with AI a bit, and because you're depending on someone else who has to build your backend first, right? That's why we don't do that. You get me? And this, for example, like front end programs, back end programs, we don't have that.
We, we have, today you call it full stack engineers, and, uh, we never called it that way. When I started the company, I was the first engineer, so I had to build the whole thing alone. I built the front end, built the backend. Did the database and start the software, maybe compile the kernel and start the machine, stuff like that.
I had to do all this by myself and I hired like the second peak, but I couldn't hire like a specialist for UI. Right. So we build all these people and often people say like, ah, the. Full stack engineer who can do front end and back end is not existing is too complex. No, it's actually not like learning two languages and two things.
It's not more complicated than doing a PhD in physics, which is way more complicated than learning two languages. And of course, there's like many, like some people have more neck for front end and more for For backend. And so you can be like more specialized in one area, but building a whole thing for an engineer is not a problem.
And so this what we shouldn't be a problem at least, shouldn't be a problem because when you work like one is front and one is backend, then you, you just introduce a new complexity. You introduce a new dependency between people and, and, and the more taylorism you have, the more communication you need and the more difficult it gets to, to get something done.
I share that that opinion and also, um, I mean, that this is how the engineering world always changes. Right. And most likely also will change with AI from my perspective. So, I mean, many people ask themselves right now, like, Hey, will AI make me irrelevant? Like, uh, do I have a job still in five years? Maybe if you don't adapt, right.
Like if you don't adapt to new, new conditions, but, uh, what happens in engineering? And I think you can sing a song of that, um, that you. Like, you always stack layers on top of layers, layers, layers, layers, layers, right? Um, like, I mean, front end, back end is an example, right? Like, back in the days, I don't know, I'm a Rubyist, and I'm, I was happy, uh, that, uh, like, everything was so simple and that I could do everything on my own in one system.
And then, all of a sudden, like, someone adds layers. And now, like, with AI, you also add layers, um, on top of that. And layers always mean, like, increased complexity. Um, and, um, uh, way, Or new chances, um, and, and obviously also new problems. Yes, also, of course, layers. And, and, the first thing that comes to my mind is basically the obsession with, um, abstractions.
Right? You abstract everything away and then everything is totally simple. Which is actually not true. So you mentioned Ruby on Rails, which is fantastic because I think it's like a standard way how to build things and like normal things are super easy, but super hard things are very difficult. Or upgrading to a newer version and stuff like that.
I don't know how it's now. I'm not an expert, so don't quote me too much on that. But it's, I think that's a general thing of frameworks that abstract away many things, make simple things super simple, but hard things, super hard. And when something breaks, you don't know where it is. So we try to make stuff as simple as possible.
Don't use frameworks. at all, when we use libraries, we really sanction the amount of libraries we use also to make the bill of materials very small. This reduces supply chain attacks, like what, what good engineering is doing. Like when you build a car and you have a car was 5, 000 parts. It's better than a car was 10, 000 parts.
And the same is for software, but nobody is really pursuing that. Then also an abstraction is a part and, um, And yeah, that's, that's, uh, that's what we're trying to reduce mostly. So let me guess, you're a fan of Go. Yes. Okay. But I'm also a super fan of Common Lisp and I did a lot of Clojure. Okay. But yeah, we also tried to use it in the company, but, uh, yeah, that's not. Not, not so easy to apply. People will hate me for that, but if you want to have simplicity, that's not the way to go.
Okay. Um, let's, let's go back to your, your career later and, um, your, your 14 levels. Why is that necessary at first? Yeah, so we really teach people to take over a larger scope of work. And, uh, what, so obviously when you start out in our company, we cannot put you in a project with ten thousands of mandates of work.
Why do I always say mandates? Most people say like, oh, story points or whatever. But mandates is actually also a complexity metric. Because it means everyday people write code. And thousands of mandates create probably millions or 10, 000 of minutes, probably create like millions of lines of code. So you have to create a very, you have to create a simple code base that can solve a complex problem and many people can contribute it.
So that's a hard problem. And very few people on the planet have seen such a code base. have maintained it over 10 years to really understand if the assumptions they made of good architecture really worked. We did that. We're doing this for 25 years, over 25 years now, and we have maintained systems, uh, over 10, 15 years in that area.
So we, we had our share of, of things that we did wrong. And after time we've said like, Oh, we hadn't shouldn't have done this. No, no, we have to fix it. So, and I think that's the, that's the, that's the most important part really. to, to really understand, um, that you have, that you have to, to keep, keep things simple and, and build complex things out of simple parts.
Okay. Um, but, uh, back to the, to the career letter. Um, so you, or your, your, uh, Roster basically you, you, you, you came up with that after a certain while, or like, did it, was it built by HR or who, who did that? No, no, basically. So this, everything we do in engineering is also designed by engineering. So we design our organization ourselves.
And so what we have a people team, very good one, which Basically for engineering education, creating training programs, but the trainings are then done by engineers, but they are doing a really good job. And also performance, uh, management, like, uh, uh, feedback system, stuff like that, they are supporting that as well because the feedback is then done by engineers, uh, and also not by, um, business people or HR people, which is called people in our company, because we think we shouldn't call humans resources.
I think it's weird. Um, but, um, We, uh, um, no, I'm already got out of the question again. Um, uh, like who built that? Who built that? Yeah. Um, yeah, so I actually, we started doing that in 2015 until then we just were like. We, we knew everybody and we knew what they could do and then you were putting them in the right roles, but in 2015, we saw that this is not enough anymore and we might have too many people and we need some kind of mechanism to tag them correctly because I knew when I now know everybody, I worked with everybody.
It's very easy for me to decide what should work on which project maybe. So you cannot just like mix all the new members into one team. Right. Obviously. So you need to listen. You could look at the number of years, maybe, but also maybe, maybe more feedback from the peers is needed when you have a large organization.
So and we started in 2015, I sat with some friends who worked in our company and now worked at Google and Mountain View, for example, and they told me about like, um, how Google is doing it. Well, we worked with one guy who was an engineering manager at Apple, told me how to do that, how Apple did it. I have a friend worked at Riot Games, was one of the founding engineers of like, uh, um, uh, here, their, their main game. Um, uh, I don't know Riot Games. So,
yeah, so yeah, every, everybody knows now which game I mean, um, And, uh, and so how they did it for two and a half thousand engineers and game developers and, and so we figured out then one way to do it and then we improved it now the fourth time and we made it so in the beginning was like, um, every quarter you had a peer feedback so you can do it four times a year, but actually what you actually want is like a continuous feedback you want Like every time somebody go to bed happens, you want to give feedback.
So we also trained that in a way. So we got a company in who did all a lot of training for people in Silicon Valley. So they trained like the early, um, product management program at Google, this associate product manager, APM program. I think they're still doing it. And they also taught like a lot of Google engineers, um, the, the communication and management of people.
So I really very engineering focused. They're called SNP, the smart, nice people sit in San Francisco. And, and so the founder, um, found us, I know them where they're really cool. So we worked with them on, on, uh, Um, uh, how to give, how to give hard feedback, for example, one of the trainings they have so that you, uh, that you learn how to give feedback in situations because normally everybody wants to give good feedback, right?
You want to say something is good. And so this is why we create these engineering levels that we can create good training programs and create kind of an university where you enter as a. I think in the U. S. it's called Freshman, right, like first, first year. And then you get like, uh, basically we say everything you do in our company, every user story you do, see it as an exam in a, in a kind of, uh, of, uh, academic career.
And you get feedback for everything that you do. From more senior people who also been through that, had got feedback and reached higher levels. And so, and while we're doing that, you get basically on your first day, you get your first user story. It's well prepared. You don't have to figure out what you do.
You just have to learn the stack and you also get an estimate for it. Which is an estimate that a person did who already knows all this shit. Okay. And so, of course, you will fail. So you will take longer, but we know that. And you know that too. So you don't have to be scared. Most people, when you start a new job, you are scared, right?
But, but, uh, but you shouldn't be. And then you get help. You get feedback. And the feedback is really made to, also, you can give feedback. Like, what, what kind of support do I need more? And so then you get to the next. thing. And for the first 12 weeks, you get like very thorough feedback. So it's a very, very good training.
And parallel to that, our people team provides training courses, um, on different things, also maybe communication parts or because in the end, large projects in the end are not a technical problem. They are a problem of humans and communication. And those courses are, then you have learning management system or something where you teach people or is it like physical or how does it work?
Yeah, we have physical training. So we're in the same room. We also love to be in the office. So we have like three days in the office and two days can be like engineering can do that. Everybody else is five days there, but engineering can also currently work outside, but we also. attract people who want to work in an office.
So a lot of people stay longer than three days. Many people say five days because we have a nice office, but also people love to really, really get to work and sit together with change. Yeah. And so then we have like, uh, training courses done together. We also have an office in Portugal, which is on eye level.
They also come like we exchange people between offices. So we also share. And then we also have like safe studies and we have a vast knowledge base integrated into our planning software, uh, where we write down best practices and bite sized articles like that. You can like, uh, eat while you wait for the compiler so that you can go through the knowledge base and learn stuff from other projects or from your own project.
And you also built. built like a tool for project management and, or company management, let's say where everything is in there, right? Like, uh, which replaces basically notion or some sort of a wiki, uh, where you do like the project management estimations for everything. And uh, this is like a closed, closed loop, um, as far as I understood it, like, like basically all tickets are in there, all user stories are in there.
Um, and you estimate everything and that's like also, like, I think a radical and important piece of your culture. When did you start building that? Um, so we always did software for ourselves because when I started and I worked with so many project managers, I thought, like, we, I think we can automate software, uh, project management, like the project manager in itself can be automated.
That was. My premise and we started doing building software for ourselves to free the engineers from organizational work because I wanted to write code. So, and if a program can help me to organize stuff, that was what I wanted to do. So we built a first system called Captain Feature at that time. Maybe you still know Captain Future, the manga series.
And so this was, uh, the name was from that. And for the first 15 years we use that. So we did all estimates there. Everybody knew who, what to work on. Everybody knew who worked on what. And so this helped us to, to get to that success level. And we already at that time, I think in 2003 or so, um, one of my. Um, principal engineers, he's still in the company.
He did his diploma master before master thesis and bachelors where they, we had a diploma system. He did his diploma and he wrote a chat agent with, um, the XMPP protocol, the Java protocol, uh, and a prologue program that was using our Captain feature data. To give people insights about the plan and forecasts.
And basically this was the first chatbot and we did this in 2003 and, uh, Philip, uh, one of my, um, principal engineers is that, so we were always like into data driven software engineering. And then in 2015, uh, we did a very large microservices project with many teams and, um. I couldn't see, uh, didn't have the transparency anymore and kept in feature to, and to, to really do the work.
And, um, and I had to write a new system and I really started myself. I, I picked react. I, uh, did started with Firebase at that time actually. And, um, and then I started with Kubernetes in 2015 when it was the beta. And so, um, I started writing that system and we moved these teams to that systems today is called revolution, um, into that system and subsequently, uh, put the whole company and then into that.
And now this system is like in production, like. Almost 10 years now, so we're constantly evolving and now it contains everything that we do in a large engineering organization. It's, it has a knowledge base with all best practices. It contains the feedback system. It has a whole engineering level system inside.
Uh, you're basically a reputation profile. So every work. That you got in our did in our company. It's stored in your profile so people can look up in which projects you work, what you did there and what's what stuff you work. Our code is linked to our user stories, so we have everything in all projects we have from idea. To code and to test is completely linked and you can look it up in the profile of the people.
Sounds quite transparent and, and, uh, interesting, uh, to, to, to do it that way. So that's basically also how you get around things like DX or like. Product developer productivity in a way, like, uh, it's, it's, it's a tool to, for, for radical productivity as far as I get it. Right.
Yes. I mean, it's like when you, I mean, everybody of us probably loves like, uh, these, um, self improve, uh, self, self improvement porn, right? It's like how to be more efficient. And so, uh, and maybe you, you do GTD or whatever, whatever you do, get things done. Or so you always start with like, where, where am I spending my time?
And then you, then you figure out where do I want to spend my time? And then you try to move to that direction. And basically this is also what we do. We, we give you a tool where you can lock your time and you can figure out where am I spending my time. And. Um, is this good or not, and can I fix it? And we give you a lot of like tons of metrics that you can configure yourself.
You can set targets, uh, on it. And we teach our people how to do that. So we really, we don't hire managers to do it like project managers. We really teach our engineering teams to manage themselves for success and productivity. And that's really the difference that we do. We don't. Just hope and trust that people can do it. We trust people, but we also have to enable them to do it. You guide them, basically. Yeah, we teach what
we know. It's like, yeah. Cool, cool, cool. Um, and then, um, like one, one, um, a bit provocative, um, uh, thing to ask is like, I mean, you, you, you're basically running a software development company, not an agency, but you still have clients that like pay you for the work and billable hours, et cetera.
Um, How do you maintain in your high pace culture, how do you, you keep engineers motivated, um, when they sometimes have to work with, uh, in quotes, boring clients. Um, I mean, I don't know, there are some like e commerce clients, let's say cheap or metro, like they don't have like necessarily the biggest challenges. Um, and engineers mostly strive to solve hard problems and you're also getting the ones on board that want to solve hard problems. How can you, how can you ship around that?
Yeah. So I think there's also an interesting perspective is, are these clients actually boring? I don't think so because they have. Large problems. So for example, when you build a system for a company with 500, 000 employees and was like hundreds of billions of turnover and you build a critical system for them, that is something that cannot fail, like delivering it cannot fail, like maybe replacing an old system cannot fail. It must work, um.
And you have to build something that can be maintained over decades to come. So when we build today a system for a large company, and we mostly build really large systems, then this is something that will never be replaced in the future. You have to build something that can be gradually replaced, parts of it, but you should not have ever made like a non reversible decision, what we call it.
We have to replace the whole system because there's one thing like when you. But like a large system in Ruby, Ruby on Rails and Ruby on Rails is gone. You have to replace the whole thing, right? And this is a non reversible decision. So, um, some companies did that successfully, I know, and they got really good then on Ruby, but I don't want to blame Ruby here, so it's, uh, it's all good, but I just want to say like non reversible, reversible decisions shouldn't exist and the system should be in a way built that you can replace it gradually over time and that everything is like a complex system made of simple pieces, so, and this is what we teach and this is very difficult.
Because most people can't do it. Look at around, look around you in the world. Look at all the large corporations. Everybody has an software architecture department, but did they ever end up having great software in the end? I've never seen that actually. It's really, really difficult to do because there's only very few people who have seen A software piece evolve over decades and then take conclusions from that, tell it to the young people.
This is actually what we do. We have, we have made, have made our share. I made my own share of writing two complex things and, uh, and this is what we really try to, to bring to the, to the people. And this is why I think what we do is actually. Interesting software engineering problems doesn't matter if it's like software for music streaming in a, in a luxury car, or if it's like a, a system for global retail sales, it's all large systems, they have to work.
And this is an engineering problem. Like I always compared, like was an interesting engineering problem. Let's say you have to, to, to drill tunnels. Like through mountains. There are companies doing that. So they have like, I'm not quite sure if you've ever seen like, they're drilling machines. They're like also a nice piece of engineering.
So they drill holes. Every fucking day they drill holes, but it's a nice engineering job, and every hole that they drill is for sure different. So while it's still holes, it's still tunnels, it's still like a boring machine, but they, they solve a complex engineering problem, which is like how to drill. A hole through a mountain. And this is what we, what we basically do. We drill large holes through mountains and we come out on the other side on time, on budget and with a hole that
doesn't break. Cool. And was there ever a client you rejected because you said like your problem is just not interesting enough for my people or can't that happen because you basically find in every, in every client's nature somewhere like the, the really interesting problems.
Yeah, that's of course some maybe of my traits that when I look into problems, then I can also find the beauty in it and tell myself what is an interesting part of it. Actually, I think most all problems that I have seen, once you start looking deeper into things, you see the complexity of it, right? It's like when you do e commerce, it's like, yeah.
A shopping basket is a shopping basket. Yeah, but the shopping basket is different for like screws and bolts and lingerie and for, uh, food, right? It's like, and off on, like on the top view, it looks like same, um, but, uh, they're technically, they're vastly different. And, and I think that's also an interesting thing to really look under the hood, what the problem is actually like, and then to solve that
with the clients we mentioned, um, you'll also often be Confronted with corporate bureaucracy, I guess, right?
Like, uh, and how do you maintain, um, motivation and, and, and, and, and a high pace if you have to somehow sync with their environment? Yes. So that is part of a project, um, that you also are able to do that because we say like we have end to end responsibilities and obviously we have to work with internal departments from large companies and these large companies by definition, because they are large, must be complicated.
Um, we can argue about that if they could be more simple, but actually today it's, uh, they are very complicated because they are large. And the, the thing is they need us because we are not complicated. We are simple. We try to, we strive for simplicity in everything we do for efficiency. And, and this is why I, this is really nice because If we were not like that, they wouldn't need us.
So, so it's like a, a very nice, um, coincidence that, that we can deliver that to them. And yes, we have to work with these departments, but we try to simplify the work with them, the work they do internally. So we, when we set up a project, we do something we call, we build an optimal work environment. That means we try to reduce the entropy to the lowest level possible.
Because once you, so entropy is maybe basically the. I wouldn't say in that case, in physics, it's a chaos, but it's in that way, it's maybe unorderedness. It's not the same as chaos, but you want to, you want to have it as simple as possible. The number of people you talk to, the number of people in the team, we try to bring as few people and as few engineers as possible into the team.
We try to have as few organizations. We have to talk with, we try to find the right people. And this is part of setting up a project to get to, to the lowest entropy possible because entropy in itself will grow. So you have to fight against it, but you will never get lower than when you started. So the start part, starting point of a project, that's the lowest entropy you can have from that on.
It only grows if you don't fight back. So we try in the beginning to get to the lowest entropy possible and to, to try, like, for example, communication chains. Can we talk directly to end users or do we have to ask like a chain of 15 people who after six weeks come back with an answer? Now of course, we want to talk directly to the end users.
Mm-hmm . And so that's just one of the many things we do to set up projects. And this also then makes engineering more fun, right? Because we actually try to not have the bureaucracy and of course it's not always perfect and it's not, like, life is not perfect and the world is not perfect, but we try to reach the lowest amount of entropy possible.
Cool. Um, so, slowly coming to the end, um, one thing that we haven't mentioned, um, but I think it's worth mentioning, you do Freiheit for so many years and, um, like, I think, Two or three years ago, you decided, um, to also, um, like have a different owner, right? And so you're now private equity owned. Um, how, how, how did that like turn out for you?
Like, are you still as a founder of it? Like, is it still your baby? Are you still happy? Um, and how did the collaboration with a private equity? company. I don't need to mention the name. How did that work for you? I can name them because they are really good. We have very good experience with them. Actually, I didn't never thought that because I had no good impression from private equity, but these are, these guys are really great.
They're the Deutsche Beteiligungs AG, DBAG. And, uh, basically Um, Claudia and me, my business co founder, um, we didn't have to say we were always profitable, great company. We really love to work there. So, but we don't have kids. We don't have a family who could take over the business. So we had to think about it, what we do.
And we had several thoughts like, uh, building a trust or like, um. What, how can we like, um, um, make the people working in the company as, as partners of, of that in the future and also how to bring them in the first level, like do what Claudia did in business and do what I did in engineering. So this is of course a multi year journey.
You can do this. It can do this just in like, Oh, Hey guys, in six weeks, I'm out. I'm leaving the keys here. So you have to prepare this over. Yes. This is when we got this offer from DBHG. Um, we were considering it because they were also promising because we are successful run company. We don't need management advice.
We don't need nobody telling us how to do that. Um, but they promise us to help us like with business. Contacts and stuff like that. So this was a very good, good combination. And this is also how it's done today. I'm still doing the same job. I'm still running this company as I would, as I've done in the past. And this is also what the DBAG is, is, uh, like holding their promise. And, and so we are, we are super happy with that.
Okay. And, uh, did the, the, the growth come as expected, et cetera, like did that work out? Like did they. We were able to pick our growth rate. Uh, so I said, what do you want to do? And then we, we could pick that and we did.
And then we basically after now four years, we will have reached our five years gold already. So we are, we are better than expected. Um, yeah, and, and we also in the, when we did the deal, we also had a profit participation program where we made like around. 100 people or so also became, uh, virtual share owners or real share owners, partially, uh, because this was always a dream we had and now, uh, people have a share in the company, uh, they're dedicated, I love to work with them, love to be in the office, and, um, Yeah, and what I'm doing now is preparing the company for the next quarter of a century because I really like companies who are centuries years old.
And is that then, uh, the next quarter of a century is that without you or with you? I'm still here and I have no plans to leave. Okay, cool. Um, and if you would ever leave, do you think you could, um, somehow, um, leave this rigid culture alive, uh, in your company? Like, could it, could it survive without you? You say
rigid, but I think it's, it's orderly. It's like we, we have, of course we have discipline, we have order, but when you see this, it's a very, it creates freedom, actually. It makes people free. People can do really make really cool decisions. They can work on, on cool problems. They can, we teach them how to manage themselves and we, we teach them how to remove friction, how to keep entropy low.
And this makes. It's fun. Like being efficient is fun. So in itself, people who are working in this company really love this. And we have many people being there for over a decade. So I think the, the people are there. Um, but of course my goal is also to prepare them to evolve that. Thing without destroying the main premise of it.
And this is basically my main job today. Of course, also engineering also know, uh, how to, how we, um, leverage AI. We didn't talk about that. I could also talk for another hour about that because we also do also crazy, crazy stuff there. But, um, yeah, that's, that's basically, I think this is built into the company, but also I'm, I'm working on that to really make this long lasting. Okay, cool. Yeah, let's talk about
AI, uh, in another hour when we have one. So now, um, I, I, I, I come to my, my final question. Um, and I, I actually, I don't know if I told you, but I talked, I spoke to Claudia, uh, your, your former partner, right? Like she, she's no longer with the company, um, as far as I know. Yeah, she left end of last year.
And, um, she, like I asked her to show me revolution. Uh, the tool, because like you also promised me that, but I was, I was keen to, to, to see that before the, um, the talk here. Um, and, uh, she actually showed me like a secret Easter egg. She said, ah, this is so cool. You have to try it out. It's, it's, uh, it's a time machine feature that, um, you personally built into that.
Um, and it's kept secret, like no one knows about that. Um, and, um, she. basically showed me like how we can like all travel back in time with your revolution tool. Um, and like, imagine we're now using that revolution tool to travel back to the year 1997. Um, like shortly before you founded Freiheit, uh, freiheit.
com. Um, and, um, you now can observe yourself for a while and you have like exactly 30 seconds to whisper something into your younger self's ears. What, what would it be? What would you whisper to your younger self? I know you often ask these questions. Yes, always. Oh yeah, I've, I've, maybe I've thought about this already, 30 seconds. You can also think for 20 and then answer in 10.
Yeah, I could talk about like, um, when, when I look at myself and the person you are is always the sum of the, the things you did good and the things you did bad. I wouldn't scratch away any, any. Errors I made or stuff like that, right? It's, it's part of what I am now and what the company is now.
But what would I say? I think, I think it's really following your instincts, really following your gut feeling because your gut feeling is always right. The, the worst things I did was always like when I already knew it's wrong. And I did it because I wanted to be friendly to somebody or, or didn't want to be hard on something and to really, when you think something is right, then do it.
No matter how hard it is, that's also what I always tell now very much to all our people. We don't go the easy path. We want to be on the easy path, right? Simple path. But we want to be on the right path. We don't do easy because it's easier. We do the right thing. And I think this is the most important part. Trust your gut feeling. And when something is wrong and you think it's wrong, then it's wrong, then don't do
it. Thanks a lot, Stefan, for your time. And, uh, yeah, we have to record another one on AI then. So let's do that next time and, uh, have a great day. Nice. Thank you very much. As they become available. Also, please tell us if there is a topic you would like to hear more about, or a technical leader whose brain you would like us to pick. Alpha List is all about helping CTOs getting access to the insights they need to make the best decisions for their company. Please send us suggestions.
To cto@alphalist.com sent me a message on LinkedIn or Twitter. After all, the more knowledge we bring to CTOs the more growth we see in tech or as we say on Alpha List accumulated knowledge to accelerate growth. See you in the next episode. These are podcast, but put it see it. Font podcast stars us by OM Air.