Tobi: 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.
Tobi: 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. Tobi: Welcome
Tobi: to the Alphalist podcast. I'm your host, Tobi. And with my current guest or my guest today, I first discussed having a Glühwein session because it's shortly before Christmas. Now to be honest, I can, my cup is only coffee. Dennis, what's, what's in your cup? I won't share. I appreciate it. I won't share. Let's see how the podcast goes.
Tobi: So, uh, today with me is Dennis Winter, CTO of Börse Stuttgart. Um, and, uh, Dennis has a vast experience in like, um, fintech, um, and very regulated companies. Before, um, joining Börse Stuttgart, Dennis served as CTO of Solaris Bank, uh, which is, um, a German Bank as a service. Can you banking as a service or as a service provider?
Tobi: Actually? Yeah. Yeah. Yeah, so, you know compliance best And when we first discussed I proposed that we talk about compliance and then I said, ah, no, that's so boring Let's let's rather look at organizational growth from a CTO's perspective And, uh, let's cover a bit of compliance. So, um, I agreed that that's more interesting.
Tobi: So, so let's, let's get started. Dennis, thanks for being here. I'm excited. Thanks for having me. Maybe before we dig deeper, um, let's, let's maybe start a bit with your personal journey, your personal nerd path. Um, so why did you get into technology? What sparked your initial fascination? Uh, why are we here today? Tobi: I guess that was somehow.
Dennis: I was somehow destined to be in tech. My grandfather was an electrician, and I actually grew up in his, in his workshop. And, um, and I was, I was born in 79. And I think in 84 or 85, he just brought the first computer. And back then, there was no screen time. So whenever, you know, people were looking for me, it was like, where's, where's the little guy, I was somehow like close to the computer.
Dennis: And, and in my teenage years, I founded a band. Like a metal band and back then that was in 1993 and 1994. I heard about websites. And no one could actually tell me like how to build one. So I tried to build one just myself and, you know, get all the information that you potentially need somewhere in the internet.
Dennis: Alta Vista was the search engine back then, I think, um, that, that I used. And that was just somehow things came into place. So I like built the website back then in the mid nineties for my band and was always somehow connected with technology. I was always fascinated by, you know, having stuff around that does things for you if you just pilot it well.
Dennis: And in my first job that was in the year 2000, I was an embedded systems developer. Actually, just my plan was to become a rock star. And my mother was not very happy with that and she actually forced me to go to an IT school or tech school back then and I did that and I don't know if you remember if you're old enough to remember that in the 1999 and 2000 roughly there were a lot of.
Dennis: Um, um, informatics students that actually dropped out of university because they had a job already that gave them just a lot of income. And so it was during that time, basically, when towards the end of the tech school that I attended, the companies actually. I came to the school and presented themselves and we're looking for young talent and that was my first job then in the year 2000 as an embedded systems developer in c i sucked at it like hard and um, directly ran into the dot com bubble so all the people in my first company were actually let go but all the experts back then, We're told before they leave, tell Dennis how he does it because I was the cheapest guy in the company.
Dennis: So Tobi: a lot of Dennis: people like great mentors, basically. Um, so you took over 10 jobs at once. Exactly. And that is where, where like multiple technologies then came together for me, not only like C development, what I, what I was actually hired for initially. But Linux administration, um, or systems administration as such, PHP, like all the scripting languages that we had back then, Perl and all these things, and had like a phase of roughly a year where it had like many hats on.
Dennis: And, um, from there on, that was just like, oftentimes in all the companies that I, that I attended or that I worked for, um, I had like this role of the guy who was like doing everything like the technical or purpose weapon somehow. Um, And I did that for quite a while until 2015, 16, roughly. And that was when, um, when I joined Solaris back then as a Greenfield project, um, there were less than eight people working in tech back then.
Dennis: And I was the first guy who was actually professionally, because that is actually where my passion lies, the infrastructure development or systems development. That was where I was focusing on from 2009 on 2008. So I think I don't know when the term DevOps actually came up, but I think I did DevOps already before it had a name Tobi: early in the game.
Tobi: Exactly. Dennis: Just like getting somehow the, the, the, um, the requirements from product development and somehow translating things into systems that work that also make it easy for me to actually as a, um, oftentimes being alone for myself on a specific topic on this infrastructure topic, um, to automate things as much as possible.
Dennis: Cool. And ideally just like creating a cockpit that was oftentimes, um, the, the, the goal that I had, I am not really succeeded in all the cases only in one case, um, where I had like a lot of automations put in place already, but having this close. Relationship with product development and understanding what their needs is and what their needs are.
Dennis: And that was always something that, that, that I enjoyed doing because, you know, but people were happy. I could be happy and success. That was great. Yeah. Then at Solaris, I basically like focused entirely on like building up the. foundation of a, of a freshly started company. Tobi: Yeah. Interesting. I have a few fun questions, uh, about your, your journey. Tobi: So, um, looking back at like early HTML times, uh, what was your favorite tag? Was it center, blink or marquee?
Dennis: I would say center. Center and IMG because you know, everything was gifts, so Tobi: Yeah. And then like TA tables, tables were puzzled, like images puzzled into tables, et cetera. Like Yeah, exactly. I remember that. Tobi: Yeah. Yeah. And then links, links below, et cetera. , Dennis: and, and then came dh, TML, right. somehow like also connected with Java. You can make
Tobi: it move. Um, and, and then you also mentioned Perl. So, uh, I guess you also know the, the good old flat file databases then. Um, what was your favorite delimiter then? Oh my God. Tobi: Pipe. Don't, don't do this. This is too long ago, please.
Tobi: So for, for me, it was pipe, I think. Excuse me. For me, it was pipe. I think the pipe. Okay. Like a semicolon straight line. Yeah. Yeah. Or semicolon. Yeah. Well, semicolon is you use it in text too often. So Okay. Um, so yeah, then let's, let's maybe talk about, um, organizational growth and, and, and, and, and tackle the different growth stages.
Tobi: So I guess, you know, that situation that I don't know, to, to business students, um, just graduated approach you and tell you, Hey, I have this great idea. I want to build this startup. Uh, I don't have any clue of digital products or, or technology, but I want to do it. Like, can I just hire a freelancer to do all the work for me? Tobi: Uh, what, what do you reply?
Dennis: You can. The question is what your goal is. If you just want to like put something there and just try out whether it works and then throw it away and do it right. You can of course do this, but in general, I'm convinced that if you like in particular, if you, if you want to create a digital product or a technical product, you ideally you get someone in like early on who has skin in the game, who like for themselves has a, has an intrinsic interest of building something that.
Dennis: That, um, eventually will also like be a good foundation for further development, which doesn't mean that you don't throw away like your first version, because that at least like by the book, this is what you should do. Right. Um, I don't know whether this is really oftentimes the case that it happens. I have seen too many MVPs in production, but in general, um, a company nowadays who wants to be successful, I'm convinced that in to one degree or another, it needs to be a technical or tech company as such, even if it really starts out very small.
Tobi: So if you start off with an agency, let's say you're below 10 employees, you start off with an agency or with a freelancer and the MVP is built. And maybe even like the core product is maintained by an agency still, you would advise to hire a senior engineer at a certain point who can, or, or. Not necessarily team lead, right?
Tobi: Like someone who can grow into team leading, uh, who can, who can then take it over skin in the game. Also, not necessarily in terms of money, but in terms of like who has an interest to build a long term vision and product and to actually drive that. Dennis: Someone who has an interest in first of all, just having a good job, having a job with impact, having a job where you can actually influence the decisions.
Dennis: And if you're the, if you're an engineer, um, at a very early stage at a company who wants to build a technical product, you're the expert in the room. You're also to a certain degree, even if you're not necessarily a managing director or like a co founder or something, um, the, the voice that you have is of course, like a voice that is crucial, incredibly important when it really comes to what is even feasible or what is possible, how fast can we be in building something or how Complicated is it to do certain things so in particular for like companies at the early phase of like maybe when you're like touching the seven eight nine people one hundred percent make sense to have at least like one person in there who who has experience with technology and how to build products.
Dennis: And then that person can of course i mean it really depends then on the personality of that we've all we we all are different right there are some people who really want to. Experts really want also to stick to the code and by their hands work actually contribute to the success of the company, but there are also others, um, who, who have the interest, maybe to, to, to like also build a team and grow the function and to make sure that also over the next couple of growth stages of the company, um, you're still having a tech function that is coming up to the requirements that the company has.
Tobi: And to actually drive the, not output, but outcome, right? To actually drive, like, let's say, early revenue, um, in the interest of the company and not against, not acting against the interest of the company, right? Like, if you hire a freelancer, then it's basically billable hours. If you hire an agency, it's even worse, right?
Tobi: Um, so there's no interest to keep the. Keep the, the, the, um, tech debt, the future tech debt low, um, and to just drive revenue or just drive the, the MVP to a certain degree, um, maybe to keep the company alive, but not much more, right? Um, so that's, I think early, like, very important to mention that, um, You have to jump off if you, if you actually work with an agency. Tobi: And even
Dennis: like in, in, in regards to tech debt, I would even say that, um, the amount of tech debt that is acceptable for you is something that actually comes from your, from your current requirements, from what you actually want to achieve. If you really want to be fast, if you really want to be just, if you really want to build just like a prototype of something, It doesn't matter.
Dennis: You just accept, you like cut all the corners that are possible to like put a specific function out there. I think what is, what is, what is, what is maybe the, the, the, the stronger like take on that for me is the, the strategic interest in the company because eventually tech that is something that you, that we want to have.
Dennis: We just don't want to have it like in an uncontrolled manner. Right. Or in a manner that is like, it doesn't matter. Like, you know, I don't know whether my contract will be prolonged in six months from now. Maybe I'm not here anymore. And tech debt is like, I don't know, like 50 percent of this whole thing needs to be, needs to be rewritten at a certain point.
Dennis: If someone doesn't care about this. Or if someone has not no intrinsic motivation to care about it above the three months or six months time period, then this might be problem. This is where I see like a permanent employee or someone who really is involved in the in the company's goals. is really necessary.
Tobi: 90 percent 99 percent of the companies, maybe if they are not like specially regulated, can basically give a shit on compliance at this time, right? 100 percent I mean, and should.
Dennis: I mean, it depends, of course, right? The second that you really start like processing, for example, PII data, like personal data, it doesn't really matter whether you're like, Three people or one or ten the second that you're processing personal data from people out there you have to at least like apply a certain amount of due diligence of like, you know, certain level of security or like common sense just to make sure that you're not running into into into into fines at some point in time if for whatever reasons, um, the data would.
Dennis: breach or something like that. But in general, of course, I mean, the smaller you are and, uh, the more uncertainty you have, whether your business model actually works, the more freedom I would personally take to just try things out and see how it works. And, but the bigger you Tobi: get, of course, these things get more important.
Tobi: So, yeah, let's jump on the next stage. 10 to 50 employees. Um, you have maybe technology has grown. You may be like a seven people engineering team. Um, And you have a small product team, uh, like let's say the co founder takes over product. Um, and, and you as one of the founders, you're responsible for tech.
Tobi: You have two different teams, backend and frontend, like typical, typical setup. And your, your co founder friend, uh, maybe has a designer in the team. Um, is that how teams can long term work? Like first question, like, uh, you, you separate. back end front end to separate product, uh, like under different founder, like, does it ring a bell or what, what, what do you think?
Tobi: Like, is it, is it something that is sustainable and well performing or multiple ways? How's that all, all the streets need Dennis: to roll, right? Tobi: There, there is no silver bullet. Exactly. Dennis: Um, so, um, of course, I mean, that, that could be a good setup. I can also imagine, um, I think, um, What what what what's the name again of the mobile cto daniel david david david yes he was also at your podcast right and he exactly and he was actually cpto.
Dennis: And I think that also works in particular when you're, when you have someone who really knows how, uh, the, the, the development of digital products works, someone who can actually structure these things, people can also like combined or like, uh, CPTOs can also work and combine basically the reporting lines under them.
Dennis: Um, in general, like that's a setup that I've seen a couple of times that you have like, uh, a CPO and a CTO or someone who's responsible for product and someone for tech. And you have front and back end, uh, development teams and that works in many cases, right? Um, for me in particular, during that stage, what I would always do is, um, have someone who can really spend their, their time on, um, the internal systems on infrastructure, because, um, as you're growing and depending on like the pace of your growth, Um, You will end up in tooling hell at some point and like how do you actually set up the whole I am in the entitlement system across your company who actually gets access to which tool.
Dennis: And which role do they have in the respective tool? So that is something that might not be like the biggest issue for like a 20 people company, right? You have that one person who then some person from the backend team, most likely you will just like assign all the commissions to people in the founders always get like admin in all the systems, which is something that might work at that point.
Dennis: But, um, for me, um, as soon as, as, as you can tell that you're building a Your business case works or you're making your successful more or less like either way you're gaining more users or you're getting the funding in that you can grow your, your, your, your product base or your, your systems at that point in time, I would definitely have someone who also really takes care of the internal processes of the internal systems who makes sure that you're integrating your, I don't know, Jira with your, with your GitHub.
Dennis: Or that you can like somehow that it's easy for you to track what, what, what you're doing there. Tobi: Yeah. So from that, I have an IDP in front or something, right? Exactly. Potentially. Dennis: Exactly. So, and that would be something that I would consider as really important in terms of, um, growth stage where you're still a, but you would be still able to, to basically manage the people individually.
Dennis: But you need to put the foundations in place that as soon as you're as this kind of work goes out of hand, you can also introduce tooling or automations that would help you do that. Tobi: Um, and, and some, some rules of play already, right? Maybe like early rules of play, like, Hey, this is what, like how we act in AWS, et cetera. Tobi: Um,
Dennis: even this is. It really depends, right? Like, um, um, how, um, how you were setting up then the accesses from the get go. If you just allow your, if you have one backend team and this one backend team is basically just like maintaining this one backend system or this couple of backend services that you have might be okay then.
Dennis: But as you said, I mean, you don't want to have like a bouquet of, I don't know, like 50. Uh different aws applications, uh in the end so just like keeping things a little bit but keep it simple stupid Keeping things really like, um, very pragmatic It's definitely something that will help you later on. Tobi: So I have a vision for, uh, let's say the size of the monolith you want to build. Tobi: Just like a couple of best practices.
Dennis: Just like a couple of agreements. Just like, you know, this is what we're using for that. Yeah. Tobi: Yeah. Yeah. And, and, and then like from a technical standpoint, maybe also start thinking about, um, monitoring and responsibilities. Um, you, you build it, you ship it, you run it, um, et cetera, and, and start like baking that into your teams. Tobi: Right. I mean,
Dennis: ideally you started like at that stage already, right. That the teams just developed themselves this kind of like ownership. And I think that also goes hand in hand. If you give them the. If you give, uh, product development teams, the engineers and the product development teams, if you give them the accesses that they need to provide themselves with the, with the, um, uh, dependencies that they have in AWS, like I need a database, if you give them a possible possibility to create this database, and if you're not like segregating this, I'm having an operations team, the operations team is now like responsible to like provide you with the database that you need, which It's like the more quote unquote traditional way, how like companies have done it in the past.
Dennis: Right. If you're not doing this, but if you provide them really with all the needs that they have to really build a cool product, this kind of ownership, the sense of ownership develops usually more or less naturally within the teams. And then it's also like, um, More of no brainer for the teams themselves that they're like, okay, let's deploy prometheus or like put some some monitoring in place so that we actually like detect when something goes south if you start this very early then that's cool one hundred percent.
Tobi: And if you don't depend on slow Dennis: if you're not you have a lot of conversations you have a later stage. Tobi: Okay. Um, how do you think about like things like, like, uh, let's say modern setups, infrastructure and code, should this be built? Like would you introduce it early as a CTO? Um, or is it more like a, a wet dream of, of, of a DevOps department? Tobi: Uh, how do you see that?
Dennis: It's actually, because you mentioned, right, um, uh, working for Bursar Stuttgart, which is a regulated, uh, institution, um, I used to work for Solaris, which is also regulated institution. Um, so it's not only like the wet dream of, of some DevOps dudes, but it's actually like of all the control functions, all the security people and so on, they all also want to, they sometimes don't really know that. Dennis: Infrastructure in code is what they're looking for. Tobi: Yeah,
Dennis: but it's definitely something that, um, I would early on always, um, at least state as a goal that we need to have. We need to be able to, to, to automatically like rebuild the system and it's not only rebuilding the system is also that you have a transparency on the, on the changes. Tobi: Yeah, Dennis: right.
Tobi: But would you do that in a regulated company or would you do that in any company if you would start from scratch now and you would build like a social network? Uh, would you do it from the start or not? I Dennis: would, Tobi: if Dennis: I could, I would, I definitely would. I would like, I'm actually just like, you know, chewing off the ears of people like all the time, which is like, look, is it Terraform?
Dennis: Is it Terragrunt? Is it, you know, we can do this because it's easy. We don't want to have like, you know, people just like. Consolidate all the stuff that they want to have just in one dashboard i want to have it in a file and i would as early as possible try to also like get this into the culture of your how you're doing things the second that you try to introduce things later. Dennis: It's always more complicated.
Tobi: Yeah, I agree. I also asked it in a bit of a provoking way, because I right now have discussions with, like, at SAS Group with my infrastructure team about making it a standard. And I mean, we buy companies, and those companies, like, none of them has that, right? Naturally. So can you make it a rule that this should be there?
Tobi: Um, I think you can't because you basically like if you, if you would force companies to do that, um, or if you would, um, make it a compliance rule, then like everyone would stand still for half a year, right? Uh, like you, you wouldn't be able to, to introduce it. And also, even if someone helps you and let's say delivers you the full fledged system and like, uh, like leaves it at your, at your doorstep, like you have to.
Tobi: Go through this mind shift of realizing, Hey, this is why it's so important. This is why we do this. And then you have to do it step by step and you have to own it. There's, it's not, you, you can't, you can't have it like let it, um, delegated to, to some, some, some team that, that does it for you. That's my perspective. Tobi: Right.
Dennis: Right. From my experience, it actually needs to be part of the culture. Like this is how we, like the self understanding of how we want to work. It's infrastructure or how I used to call it in the, in the, in the regulated context is compliance and code, right? So you, you can basically prove what changes went into the infrastructure as well, and that you have approval processes around this and all these things, but this is also true for, um, how do you monitor your services, right?
Dennis: Having just like, we, we know this and I've seen this also. I had a team, um, When I was responsible for, um, the, um, the platform team at Solaris, we introduced, because we built this centralized platform where you have like all your, uh, build, test and deployment pipelines, and we started to, like, the, the idea for me behind the platform is basically that you're introducing standards, you're defining standards in a central, in a central system, and you have also ways to increase the standards.
Dennis: By adding more or specific tests, be it like security tests or, um, actually like feature tests, like does your service actually have a health endpoint or not? That was like the easiest test that we introduced very early on at Solaris in 2016. Right. Um, and we had a couple of teams back then who already built stuff and that was more or less manually deployed, um, in an on prem data center.
Dennis: Right. My team was basically responsible to automate all these things and to centralize it. And one of the requirements that we introduced was all your services need to expose a health endpoint. And this health endpoint needs to check the database and whether the actual service is up, like the actual application is up.
Dennis: What one of the teams did, they just created a health endpoint that would always return an HTTP 200. Classic. Even better, like, you know, like how it looked below it, it was just like, the lights are on, but nobody's home. That was what actually happened there. That's something that is also like a cultural thing.
Dennis: If you, if you get people again back to the ownership, if you give them the ownership and the tooling, I'm a big fan of APMs, that you have like, you know, application process monitoring, that you, that you have insights into what is actually happening within your services. If you give people the access to tooling like that, Um, and if you basically also get them to understand that they are part of the solution, if you want to have a high quality product, it's not only about the features that you're putting out there, right?
Dennis: It's actually really about, do you have like a product out there that can also like weather a storm? And this is something that only the teams themselves can actually resolve. Like, if you try to bolt it on from the outside, it doesn't work. People need to understand what automation brings you, what monitoring brings you, how easy it makes your life, actually, like both of it.
Dennis: It's like a, Quite a hurdle in the beginning, because there is a lot of stuff that you need to know and a lot of stuff that you need to like really like plug in so that everything works together. But eventually the goal is. Do you have more confidence in the integrity of your systems of your build assets of whatever of your products actually as such and this is something that if you start later in the process you have many people already who got used to a specific way of working and changes hard.
Tobi: Yeah, I'm also a big fan of APMs, um, but you have to use them really right and have to understand their value as, as you said, otherwise you just pay a shitload of money to Datadog or others. Um, uh, so, so, so yeah, understood. Um, and, and, and then we, let's say we grow a little further. Uh, 51 to 200 FTEs. Um, what, what does become important then?
Tobi: I mean, if you introduced like infrastructure and code, et cetera, early and, uh, like an idea of, uh, like defining SLIs and SLOs, et cetera. Um, does that change? Like, is there any change at that size? Dennis: Many of the processes that you initially came up most likely. Um, in the beginning of your organization won't work anymore, at least in my experience, right?
Dennis: So you have certain manual processes, oftentimes also in like non tech functions. And for me, it is honestly, um, I think product development is such. Struggling a little bit with actually it's not hard actually if you you know keep a couple of things in mind and if you're open if you do for example your rate drops and if you're just verifying like how you've been doing in your last sprint or iteration of whatever you will improve and nowadays most of the of the development teams are actually used to these agile ceremonies that you're doing that are all aiming to do the right thing.
Dennis: Thank you. And to improve that is not necessarily true for like functions outside of product and tech, HR, finance, and all these things. And oftentimes, um, in particular, when you're like breaching certain amount of people, they have manual processes in place that don't scale with people. Right? And then the question is.
Dennis: Do you just leave them there and just, you know, basically leave it to them to, to come up with like better, if there is anything like better manual processes, or whether you're actually making tech, um, an enabler and a proactive function that really starts to, to improve things within the company. So for me, it's more like the whole internal processes that, that significantly change and where tech plays an entirely different role all of a sudden.
Tobi: Maybe IT comes into play, right? Like even in modern organizations, like let's say, um, you're remote first, um, and, and IT doesn't mean like, uh, Wi Fi. Um, but, but security and on and off boarding, um, like taking on and off boarding seriously from my perspective, um, is, is really getting more, more important by then, or maybe if you pass the 200, like you have, let's say three, four starters each month, um, and two, three people that jump off, um, you, you need to automate that, right?
Dennis: Absolutely. And you have to, and this is the, so the actual challenge here, I think is also not a technical one. So the challenge is that as your company grows, um, you have this organization that has like different teams and functions and responsibilities and all these teams and functions in order to, to live up to their responsibilities, they need different kinds of accesses to different tools.
Dennis: Yeah. So you need to set up some kind of like an, like, like an entitlement system, which is more like a concept. And this concept is your roles and responsibilities, like broken down technically somewhere. So your IAM system. Or your skin system like um is is able to automatically provision for example accounts in jira or in slack or in whatever tools you're using in github.
Dennis: I'm at solaris for example we had people from from the second line of defense so basically control functions teams that their sole purpose is to actually like. Assess certain risks. And verify that the teams who are implementing solutions, um, are mitigating these risks they had, they had to have read access to some repositories in GitLab, making sure that they don't that just for the sake of this example, making sure that they don't lose the access because they are actually not active in, in, in, in GitHub.
Dennis: Because they were actually not really active in there. And there was another process that was just verifying whether we are just paying too much and whether people are actually really using it. So making sure that they are not losing access was actually really vital for like certain. Compliance relevant processes and this is something that is exactly what you said like making sure that from security perspective first of all you can
Dennis: assign the right responsibilities to the right people when they come in where your individual management of people doesn't work anymore so you need to have groups groups that somehow mirror also the real the actual groups that you have within the company embedded in some teams. Right. Could be like two or three groups in one team, depending on like how you're combining a team.
Dennis: Um, and the whole on boarding, off boarding change of teams. So it could be that you also have conflicting permissions. In particular, in a regulated environment, there are certain, certain accesses that a single person shouldn't have at the same time. Right. And you need to make sure that this is actually in place.
Dennis: So what you're doing is basically, you're coming up with this role based entitlement system. That's all that always needs to be in sync with like the teams that are created or that are moved from here to there or the people who are then moving from one team to another you have this entitlement system and you need to have a technical implementation that automatically first of all creates users and that also disables users at the point when they're leaving the company.
Dennis: Exactly. They're changing, changing teams or MDM that you just have the possibility to just nuke one of your, one of your laptops in case that it was stolen or lost. I had some people who like lose their laptops like twice in like their time at a company and you're like, what? Tobi: Right. Then there's this guy.
Tobi: Um, Who traveled to Turkey, who took his, it's a freelancer working for your company, maybe for, for longer already, uh, lost the laptop in the cinema in Istanbul. Um, like what do you do there? Like, how do you make sure that this actually doesn't happen or that this doesn't ruin your company?
Dennis: And that is as more people as you as you have in your company, the higher the likelihood that you have like candidates like this, right, which is like, somehow losing the stuff frequently, or then also again, because oftentimes, I think security is is is considered as something that is like protecting yourself from the bad players out there, you know, like malicious players in in in suspicious countries, but There is of course also the risk of of like in an internal bad player right and that is something that also comes very like critical at company sizes or at engineering or tech team sizes from a certain degree on depending on like how you're actually implementing your your privilege access management like how like what are the ways for for engineers to actually access your production systems or even systems that.
Dennis: Would allow, uh, for a certain like knock on attacks where you're just gathering information within the company, like put it out there and someone else can actually use it, um, to do spare fishing, for example, just like internal information that's actually really important. And what if maybe as a last thing, um, the more.
Dennis: Buzz you make out there in the market, the more well known you become, the more interesting you also become, and the more of a target you become, of course, also for, for malicious players. And there are certain, um, services that I really came to love in the last couple of years, which is like brand protection or like threat intelligence and all these things that would actually automatically also take down some Websites that like fraudulent websites that are copying, mimicking your website and try to actually lure also your customers into giving away their credentials.
Tobi: We just briefly touched the nice term BYOD. D. And I guess you as working for a bank, you hate that. Um, or you don't allow it. Um, like even for like a, let's say a freelancer. Oh, so you allow it. Um, Dennis: no, that's true. Tobi: Ah, that's two phones. Ah, okay. I know. I love you. Two phones. Yeah. I love you. Okay. Okay. Sorry.
Tobi: It's still too early. All the Glühwein is too heavy here. Um, so, um, but if you wouldn't work for a bank, you would have only one phone, I guess. Even if your company is like 250 people plus, um, in most companies, like how do you ensure That you're still like, let's say on an okay level compliant. Dennis: I would actually like, I wouldn't be okay.
Dennis: And I think it's 100 percent right to, because we just spoke about the whole laptop situation, right? To not allow private laptops because private laptops is. Like a different ballgame from my perspective, you do significantly more with your laptop than you do with your mobile phone, even though your mobile phone might be just like closer to you than your laptop, but the stuff that you have on your on, on, on your laptop is, is significantly more and maybe also there is more that is more critical.
Dennis: Um, so I would definitely go for. Um, actually enforcing company owned laptops with an MDM installed. Um, that gives us the possibility to, to remote wipe. The device for a phone. There are ways also to, to, um, protect more or less the data on a mobile phone on Android. At least you have this like dedicated profile that you can that is then created basically by the MDM. Dennis: And for iPhone, I think that I was never an iPhone user. So, um,
Tobi: it exists too. Yeah. You don't have this, Dennis: this, this, this additional. Profile if I'm not mistaken, right? It's like Tobi: you, you can install profiles. Yeah. Yeah. You can, you can ensure that a profile is installed and then you can make sure that the, the, the iPhone is properly encrypted and certain security features are enabled.
Tobi: Um, but, but going back to the MDM, I think the laptop is more important. Like, um, so even if you would, wouldn't, wouldn't be in a bank, you would, you would introduce that at a certain point that even like a freelancer. And Spain is not able to use his private laptop, um, but, but needs to have a second laptop.
Dennis: If I wasn't working in a regulated, uh, at a regulated company, it would most likely depend on the kind of work that the freelancer does. If this, if this freelancer does like design for me. I'd be like, okay, use a laptop, just, you know, I don't know, we would most likely be working with Google or something like this.
Dennis: So this person would have just like a Google account from the company and exchange would happen there, right? Um, if it was a person who has more critical data, say in finance or engineering, um, I would definitely like go for the solution where we provide you a laptop just to be on the safe side. You know, then we have the possibility to just, you know, in case that you lose it, um, to at least protect us or, um, um, a certain set of data that is on there.
Dennis: What about you? Would you do it? Tobi: I'm a bit torn to be honest. Like, um, I think it really depends on the case. Like the, the, the, the real answer is it depends, right? Like for, like, if I was working for, let's say Zalando. I would absolutely do it because then the attack surface is very wide, right? Like, um, most likely like if you have like, let's say one central service, which is shared by many engineers, then it becomes impossible to control.
Tobi: Yeah. While if I look at my, Portfolio of 20 different companies. I think if you work in a central function, so if you work in finance, um, then yes, if you work as a DevOps engineer and a central team that supports all the, all the companies, then absolutely. If I work for a 10 company. company inside of that company, I would, I would say, I don't care.
Tobi: And, um, I would understand if like, I personally would, for example, yeah, I would love to use my laptop for everything because, um, I, I just like, like it to have just one laptop and to focus on one laptop and maintaining it. Um, while, yeah, I, I, And I wouldn't understand if I work for a small company inside the company that I have to use a different one.
Tobi: Um, so, so yeah, it depends. Yeah. Um, what about I guess like you're working for a bank, then like, I don't know, GPR is very, very, very critical. I saw at a certain point comes drops in maybe even earlier. Um, how do you shape team dynamics and responsibilities around that? And, and, um, how, how important from your perspective is it to get, get certified at a certain level?
Dennis: As a financial institution, it is very important to, to adhere to certain standards. And, um, in terms of what this means for team structure, right. Or basically the, I think this is what you mean, right? Team structure and, and how you're distributing the work between the teams or the responsibilities between the teams.
Dennis: Um, at Börse Stuttgart digital, we are subject to multiple regulations, um, like to the regulation that was, um, or that is, that is put out from, from the German Baffin, There is a MECA regulation that is for cryptocurrencies. Um, there is a SOC 2 certification or a NIST certification that, that, that is definitely like of, of relevance for us.
Dennis: And from, from that perspective, um, there is a lot of work that goes into, actually understanding what the requirements are, creating gap lists, just like from a sheer technical perspective, creating gap lists of what we actually have in place. And, um, then at the moment, there is also like a project that is ongoing, um, where we are introducing, uh, uh, sys controls actually from, from NIST, right.
Dennis: Just to make sure that we have like a technical monitoring, uh, in that sense, um, whether we are still compliant or not. Um, What it actually means for a team structure for me, it is. like regulation as such, or these standards as such are not too far away from what if you really want to do things right, you would actually do things like that.
Dennis: This is more like detailing out oftentimes, what the specific requirements are for specific fields that you have, like BCM, be it what kind of regulation, um, Observability or visibility you need to have within your internal systems or the systems as such that, um, you need to have a team in place, uh, you need to have a security team that, that is taking care of specific security standards in your software development process.
Dennis: Or also like in your IM or or your, your entitlement system, for example. So in terms of team structure, for me, this actually means that you need to be very specific. In regards to the regulations who require certain functionalities to or certain responsibilities to exist so you need to like build up a matrix with like different responsibilities like where you can show how the segregation of beauty of beauties the segregation of duties is actually is actually set up in your case.
Dennis: Um, and. According to this, you can actually build the teams according to your needs. What I'm currently doing with Börse Stuttgart Digital is because, um, within Börse Stuttgart Digital, we have a couple of companies. We have Custody, like, um, a custodian basically for, for cryptocurrencies. We have a broker system, which is also the, the back end system for the, for the Bizon app.
Dennis: That, uh, many people know out there and we have an, and the Bison app itself, and we have an MTF, which is, uh, a marketplace. Basically, this is actually like a stock exchange where, um, multiple players can, can trade, uh, cryptocurrencies or digital assets. So it's actually like four ish companies within Börse Stuttgart Digital.
Dennis: And what we are currently going through is a, um, A change where we are consolidating all the responsibility for the infrastructure in a central platform team where we are setting up a central enterprise it team so a team that is responsible to make sure that all the different systems are actually like well connected that the I am is in place that we have this skin provisioning that we have automatically creating accounts here and there also revoking access again to two specific tools and The goal is to have also here, um, specific teams who are responsible to define the standards, which is actually like part of all the different requirements that you get from, from the regulators, like from the European regulators, but also from the, from the national regulators.
Dennis: So that you have like a team that's responsible for, for the standards for basically to, to define the requirements for us. To deploy changes into production, and that's something that we need to hash out in more detail, which will start now from January on, we will basically change the type of access that the product development teams have, because as of now, it is quite segregated in terms of the product development teams are required.
Dennis: Doing their work and the it ops team is making sure that the changes are rolled out. It is not as strictly like segregated as it sounds right now. So there is of course, like they have like the same repositories that they're looking into. Right. And they look into the same tickets and all these things.
Dennis: But, um, the vision that I have is, um, that we have a, basically a system build that allows us to do this in a more. Fluid way so that the teams have done the possibility through infrastructure in code to configure the changes that they need in AWS and that the platform team later on will basically be the reviewers for that.
Dennis: They will sign this off, but they are not the ones who need to do the implementation because then you have this bottleneck, then you have basically no real visibility of like when things will happen. It is way more transparent in this regard. And by doing this. You are increasing. Also, I mentioned it earlier, the integrity of your changes.
Dennis: And this is where all the regulation and also all the standards actually aiming for, right? That you have that, that you know what, that you know actually what in particular you are rolling out and who approved these rollouts, who was involved in the changes so that you can ensure this segregation of duties that not someone who is actually not the entitlement to really do a change. Dennis: Had the possibility at some point to actually sneak something in.
Tobi: So for a bank, infrastructure and code is a requirement starting very early. Then if I, if I stand it correctly. Um, And, and, and actually having a platform team, like how big is your, your IT organization now, or your whole organization maybe?
Dennis: Um, so Börse Stuttgart group as such is, um, roughly 780, 800 people. Yeah. Um, within Börse Stuttgart group, we have Börse Stuttgart digital. That's around 180 people, 170, 180. And, um, tech, everything in tech, basically, um, without products. product owners, it's roughly 75 as of now.
Tobi: That's, that's nice. So relatively controllable, but, uh, well, I mean, the overall organization is also, uh, I guess, and then something that you have to look at, uh, and, and make sure that, that nothing happens that, that can, can somehow sneak into the systems, right. Tobi: Uh, or it can somehow sneak into the processes. There is, there is
Dennis: a collaboration in between the group. And, and, uh, uh, digital services is what we share in particular, like for the shared services. Like good exchange. Tobi: So, and if I want to like, let's say, let's say spawn, um, a new service as, as an, like normal engineer.
Tobi: Do I have to approach the ops people then or is there some sort of a self service that you um Encourage people to use Dennis: that's quite diverse at the moment Okay, we have uh, we have some teams who by themselves can configure Um the changes in kubernetes, so everything is pretty much Kubernetes based, um, at the moment, primarily running in an on on prem data centers.
Dennis: And this is also something where we have like a, um, strong push, um, to move some of the things into AWS over the course of next year, but at the moment is primarily in, in, in on prem data centers. And. Some teams are able to configure actually just like basically new parts and then they get the approval to actually pull request review from from the IT ops team and then this is rolled out there are other teams who actually need to create a ticket.
Dennis: For the the same it ops team and that's what I was talking about My goal is that we basically consolidate everything really one system So that everyone can benefit from from infrastructure. Yeah, Tobi: and then you have you fully communicating through pull requests, right? It makes it makes sense. So that would also be the thing you would change if you would start from scratch, I guess Dennis: Yeah, absolutely.
Dennis: I mean, um Again, I mean, there is a, it would be very early on. I don't think that at the, at the earliest stage, you actually need to put a lot of effort into like building a system that is already scalable because you, or you don't know at that point, most likely whether what you, what you want to build will actually be successful.
Dennis: But the second that you make this decision of like, yep, let's continue doing that. Then I would definitely like pull in, um, like all the beat ansible, right? I mean, if, even if you start with that, that gives you already like, um, huge lever to, to, to bring in some standardization. Tobi: So introduce that early. Yes, would be your message. Dennis: 100% , but that's, I'm also an infrastructure guy. Like what am I just, Tobi: yeah. I enjoy
Dennis: doing that. I'm, I have this for my computer. Right. So that Tobi: Okay, understood. So take it with a grain of salt, but do it early. So I still have a little surprise for you. Um, so, um, it's also my, my, my, my outro question. Um, you worked for a company called Neo4Need JMBH, um, I think in 2014, and I actually know the founder Helmut Hofer von Ankershofen, uh, from back in the days, and he actually gave me.
Tobi: Um, the secret version of, of, of, uh, your, your search, uh, your search solution, um, back in the days. Uh, he's, he's quite a, quite a, quite a crazy, crazy guy. I guess you remember him. I never met him. I never met him. You never met him? No, no. Oh, Dennis: I think he was not with Neo4j anymore when I joined, was only there for one and a half years.
Tobi: Okay. Okay. Um, yeah. And he gave me that version. It has a secret time machine feature. And now I have that on my laptop, that old software. Um, it's some, some hacked solar um, uh, version, uh, from, from back in the days. And, um, I started up and I can now type in Dennis Winter and November, 2014. And we see. Yes.
Tobi: Like travel back in time and see yourself working as a systems engineer at Neophonie. Um, you were really like deep into the systems performance and, uh, and, and security. And um, you now have the chance to whisper something into young Dennis ears. What would it be? 2014? Yes. What would I tell Dennis: myself in 2014?
Tobi: Well, I guess you're working for a broker, um, and you're trading Bitcoin. So most likely, uh, one thing you could whisper, but it wouldn't be that wise. So maybe you whisper something wiser. Dennis: Yeah. But it is still very tempting, Tobi: especially these days, Dennis: because I was very critical in regards to, to, to, to cryptocurrencies.
Dennis: For me, it was like for a very long time, I was like, you know. As a, as a software engineer, you know, how wrong things can go and I didn't trip the world. This is just gone. Like, um, what would I tell myself? Um, honestly, I think, um, I was not a very secure person in particular during that stage, because at Neo4j, I actually Noticed how little I know even after like 14 years of working as an engineer because they had like 80 different projects and 80 projects were like set up in different way that's maybe why nowadays why i'm so like after standardization because that was like really.
Dennis: Really complicated to like get into, um, I would say in the meantime that, you know, back then I was, I was quite insecure in like what my, what my capabilities were, like whether I was really good in what I was doing. And in hindsight, I would say, you know, all the stuff that I actually saw there. Was done because people just did things to the best of their knowledge and that's something that.