Michael Frembs: Mastering Team Structures - Insights into Platform and Streamlined Teams

This transcription is AI-generated and may contain errors or inaccuracies.

Leszek

My name is Leszek and I will be talking with Michael Frembs about how to structure and lead tech teams effectively foster a culture of trust and collaboration. Michael, you had an impressive career in tech. Can you share a brief overview of your journey and some maybe key milestone that help you shape as a leader?

Michael Frembs

Yeah. Thank you. Thank you for the invitation.

I can do that. I will begin very in the early stage of the course. With 10 years I created my first website and led me to go on this journey into the software development. And also with 12 years I was a football coach for four years. I trained some, some little kids, six years old was, was a great time and then learned a lot of leadership skills in that time. And it also helped me when I get my first professional job at a small consulting company in Munich. I became team lead in less than two years and could build up the seam and work together with them and also in the same company.

I stayed up for seven years in the same company. I built up a new team and a new topic. It was about Kubernetes and API and all this stuff was a cool chance for me to work together with different roles, together with operation guys but also together with sales and marketing to build up this new product we offer. And after that I went to the public utilities in Munich.

So it's Germany would be the. I started there as a cloud architect. For me it was a chance to see if I wanted to go the expert role in this path of material or if I want to go back to the management path because I was the third person in this team. It was a team which was founded newly, really freshly was the third person. I was the right hand of the boss and I knew we were, we would crew up this, this team, we're basically in charge of the public cloud strategy for the public utilities. And in the end we were. The team grew up to 40 people and I was in charge of 20 of them.

And now as we're speaking I'm. I'm enforcing the management path, my career. So it was a good thing for me to do that. And afterwards, right now I'm at Interhelp, I'm head of engineering. I'm leading four teams, also leading leaders. It's the first time for me in this role. But I will also leave this company and move as a director of software engineering to one and one in mu.

Leszek

Nice, thank you for that intro. Let's talk about building and shaping teams. When you're building and managing teams, how do you approach structuring them to be as effective as possible. Prior to our discussion today, we've talked about a little bit about team topologies approach and I'm wondering if you can shed some light on how we structure teams, maybe refer in some way to.

To this framework.

Michael Frembs

Yeah. So to give a brief introduction to team topology, whoever didn't read it, I can recommend to read this book. It's out there for some years and they have four different team types, let's call it team types, and three of them. One of them is a stream aligned team, it's basically a product team and it's an autonomous team who are responsible for the apps, including running them and they are in contact with the end customer. And there's also the platform team and the job of the platform team is to support the stream aligned teams by creating some abstractions for basically the infrastructure layer underneath to allow the cognitive load of these teams. And most of the time they are doing this by offering self services. And the other team is an enabling team, is something like an internal consulting team.

So when you have something new in the company and you want to help them achieving that, this enabling team can go into this team for a short period of time and coach them to get new skills. And when I was at the public utilities and meeting stuff like I mentioned, as I said, we built up a team and our job was to create a public cloud strategy and also to implement it. So basically we were creating landing zones that all the other streamlined teams, all the other product teams can use our landing zone to get paths to maybe create some functions or use the databases, all the stuff that they needed. So we reduced the cognitive load of the other streamlight teams and so we had to build up at least this abstraction layer. And this was a really, really good time to look how the team was growing because in the first phase of the team we hired cloud engineers and cloud architects. So basically everyone had the same role. But the good part about this, that everyone had different backgrounds.

So we had some cloud engineers, they had a background of software engineering which helps us a lot in terms of that. Most of our customers were software developers themselves. So we knew what they need and we can build it up. And also we use infrastructure as code to build all this, all this self service. And it's good to have people who know how to write good code, who's manageable, readable, reusable, all stuff and work with git. And we had other cloud engineers, they had background in monitoring and alerting which helps us to build up a good monitoring system and to have a good overview over all the stuff we did and also to help the other teams out to do a good monitoring and alerting. And we had another cloud engineer and they had all the same role but the good part was a different background.

He had a background in operations and he could help us to keep our landing sound alive and give us a good possibility to make it that it runs all the time. And after that we. So, so the public utilities at Munich is in Germany, you would call it a Kittis company. So we, we had critical infrastructure, we are in charge of water, gas, of the public transport and all this stuff. So we had requirement and security so.

Leszek

That everything is secure, reliability, availability, security, all that things matter.

Michael Frembs

All the things matter, yes, yes. And at that time, so normally at this company you would write a security concept at the time when you push application into production. And I could told one of my cloud engineers to write me such a security concept. But the bad thing about the security concept is it's only at one timestamp. It's at that time when you push it the first time to production. And that was not enough for me. So I searched for a cloud security architect and I hired him and he looked different on all the stuff and he said, well, we're in the public cloud, so we use Azure, but it would also work with one of the other cloud providers.

And he said we get a lot of information from this public cloud about our security level security score which we have there and let's use this information. We have to get in real time a picture and image of the security level of our application. So he tweaked it in this way and it was a good thing to have him on the team because he owned that he was very motivated to do this. And basically all I'm saying about different roles and have some other roles as well is put persons in a role they like to do. So when I use a cloud engineer to do something like a security concept, he will do it. He will do it good, but he won't do it very good or excellent. And also at different roles for gdpr.

One person who made all of the GDPR stuff was amazing because he loved it to look into the law text and translated it for us and we can do it very good. And at that point when we build up the landing zones in the first phase, we worked together with our clients so the other software engineers who use our product and we were kind of enabling team for them. So when we go back to the team topologies, we were kind of enabling team going to them and work together with them on our landing zone. And you can do that in the first phase of building something up because you get a lot of feedback, you want knowledge in those teams but you cannot do this for 10 other teams.

This doesn't scale. So at that point we noticed we have to become better in our self service and the marketing of our sales service and the documentation of of our self service. And that point I learned about a new role. It's called technical editor. It's a really awesome role. Technical editor is a person who talks to us at the team, what are our offerings and he also talks to our stakeholders, to the other stream aligned teams, what they need. And here's the interface between those two worlds in those two teams and he knows which information do they need and in which form.

Leszek

He's a moderator in a way, right?

Michael Frembs

Yes, yes a moderator but he also has output. Well his task is to get the information from one team to the other team and to do a concept and it could be in written form, it could be a conference page, it could be also the git repository as a readme. It could be a video which gives you a tutorial. It could be also a podcast where you share some information. Got was really good that we can scale up in.

Leszek

But I've got a fundamental question.

Michael Frembs

Yes?

Leszek

How do you basically what's the fundamental difference between those teams specifically the platform team and stream aligned team? Like what are your thoughts about it? Is there a different North Star? How do you think about this philosophically? If you have one streamlined team and this platform team, how that they differ? How do they differ like from this fundamental standpoint?

Michael Frembs

Well I think it's two things. Maybe one thing is it's in a different stack. So the streamlined team works directly with the end customer. So I would assume also at times that they also have a web interface or something like that on app or something the end customer can can work with and use it. The platform team is on a lower end, it's in the infrastructure most of the time and that the internal customers can use it. And most of the time they are offering sales services. Well both of the teams have to offer and service which is self explanatory to use.

I guess so for the end customer but also for the platform team. But in a platform team it's more an internal team which helps the stream aligned teams to achieve their goals and don't be stressed too much to run all the applications and help them to do this. So for example we created for some Azure services Terraform modules which were pre configured and they can just use this module and they don't have in mind how to configure all the services in Azure because we did it for them, we did it in an open source fashion. So if they don't want to use our models, it's also fine to use it directly, but they don't have to learn all the details about the Azure platform.

Leszek

If we talk about the streamlined teams and platform teams, how do those differences in those two teams translate into recruitment strategies? Do you look at different kind of mindsets? Are you looking at different skill set? That's kind of obvious, but maybe also do you distinguish the width and the depth of the skill set that these individuals possess? Does it influence how you look and assess the communication skills, all that stuff? How do you look? Basically what I'm trying to ask is if you recruit from platform teams, do you approach the recruitment in a different way than you would otherwise do with Stream aligned team?

Michael Frembs

Well, so the communication part is definitely the communication part. When we were at the public utilities in Munich and we did the cloud strategy we had to talk a lot. So on the one side we had to talk to the other streamlined teams to get them on track, to get the information, how they use it, but also to get the feedback from them. How are we performing with our self service? And only when we do it well, they will use it and only when they use it we did a good job. So when they say what we did didn't help them at all, we didn't do a good job. So it's important to talk to them and to get the feedback in and all this stuff, besides the team topologies stuff, it's also we were in so the public so that the Stadtlohn is a company which is very traditional and to say them to them, hey, we are moving to a public cloud and this public cloud is in the USA and we do it and it's a good, good thing to do.

A lot of people were negative about it because it's at least in Germany it's what do you do with our data? And they are very concerned about it and all this stuff. And so on the one hand and on the other hand is well, what are you thinking about RenderLock? And we are dependent on Azure in our case and how can you do that? So we had to convince a lot of people that we're doing the right thing. So in the hiring phase I also looked into the mindset of the people because we had to be as a team Strong. And we had to be in the same opinion because when we, when we wouldn't be in one opinion in the team, everything would blow up.

And in the IRIG phase, I looked for the mindset and I asked for vendor login. And I asked. Well, I said that vendor login is a bad thing and that we cannot use it because we locked in. And I expect the other person who wants to assign for the job to say, hey, you're wrong. When the booking is a good thing, when you do it correctly. And if he didn't do it, I didn't hire him. But for this job, when you have to be something like an evangelist to convince other people, then it's very, very important that you have this mindset.

I wouldn't say that it's for every Bloodfoot team in this world, but in this scenario it was like that.

Leszek

Got it. Let's talk about culture. Culture is often what makes or breaks a team. And I was wondering, how do you go about shaping the culture within your teams?

Michael Frembs

Yeah, well, basically I want to have an environment where everyone want to work together to achieve a common goal. I like to collaborate. I like openness, I like conflicts. I guess when they lead to a better version of something. So harmony at all times is the best, I think. And to achieve that, I would say I have three things to do. The first one is trust.

I really like a trustful environment. And I think you cannot say to someone, you have to trust me.

That won't work. But you can by example, you can trust another person in the first hand. And in my opinion what is helping is transparency. To give not all information, but most of the information to the team they can work with being honest with the team, being authentic and also accountable. And one thing how you know if you, you're, you're authentic and then all the stuff is you're predictable. I think when the, the people know what you actually will be, then then you are, you're authentic and you, you build trust. And another part about building trust is active listening.

I like to, to, to talk with my guys and listen, ask questions to what, what they think about it. Involve them into decisions.

That helps a lot. And when you lead by example, when you trust them, they will start trusting you and they will trust each other in the team to build an environment by that second point is a real delegation. So I have the opinion that I work together with experts and I'm not the expert. I don't know everything what a team does. In my story, I was first a backend Engineer then I was more in the integration infrastructure style in the front end engineering side. So I've seen everything, but I'm not an expert in everything. That wouldn't be right.

But I have the experts on my team. So I give them all the information I have and I say to them, hey, you decide. And I challenge the decision. And look, if, if we're on the right path or on the wrong path, but basically the team is other person who makes a decision. And this enables also the engineers or the people to grow. So I give them space to grow. I give them space to make mistakes, to make a failure, and to learn new stuff about their technology things.

And the last one, the third one, is enforced intra teamwork, so that the teams work good together and they know what are the stakeholders. And when I make a decision, who do I have to inform or who do I have to ask or involve in all this stuff? And I like to create connections in the style. An example in my job about the public utilities in Munich, we hired all this team for the public cloud strategy. But the company had experts in networking and databases and all this other kind of stuff. So you cannot just go into this company and say, hey, we know everything better and we know how to do it. So we created virtual teams for each topic.

So we created a virtual team for network, we created a virtual team for database and all this other stuff. We had eight or nine virtual teams where we mixed the experts who were already in the company and the experts we hired new and they worked together. And this was one of the best things I could have done at that moment because we get all the information we had in the company and we also got the trust and the acceptance from these guys that we're doing the right thing.

Leszek

That's really nice. That's a new test.

Are you doing it? Was it a one off or is it like something you intend to like, you know, use in the future to mix those teams? If that, if the opportunity comes.

Michael Frembs

When the opportunity comes, I will do it again. At Interhub, I'm in charge of four teams. And we noticed in the later last year, in the beginning of this year, that we had to structure the teams newly because we got new products we had to implement. And I could have let the team stable and just move the topics around, but I decided to move the engineers around so I had a new mixture of these people in this team. So it was also one of the better decisions I had because afterwards they had a network, they had connections to other teams and they could Talk to them more easily. And it trusted the other guys and they had the best ideas from two teams to merge them and to have a really good thing. So I'm, I'm a really fan of collaborating in different styles.

Leszek

Speaking of collaborating, do your teams work remotely or they work from the office or do you use some sort of hybrid mode?

Michael Frembs

Well, it's, it's a hybrid mode, but it's more remote because at public utilities in Munich, it was during COVID and we had to work from, from home. We were all based in Munich, so we could have meet in the office, but we, we had to stay at home. Now in Interhub we have people in Munich, in Berlin, and also we have nearshore partners in Poland and Romania. So we have to, to work remote. And yeah, that's, that's what we most of the time do. But for me it's important that we meet as a team once in a quarter, every three months, come together, connect to see everyone in person. That builds up and let's stick it to them.

That builds up trust.

Leszek

Absolutely. Looking back on your career, maybe also the part of it where you were a football coach, but what would you say are the most significant, significant lessons you've learned about leadership? You know, we, we talked about, you know, being, being honest, being about trust, about all those, those things. And I'm wondering if you could sort of, you know, basically share your lessons learned.

Michael Frembs

Yeah, I think, I think I have three lessons. Let's, let's start with the first one. It's. If you, if something is really important for you, and then something is important for you that it's done consistently, create a role for it. It was with the technical editor or the cloud security architect, because they will do it and they will do it probably. And if quality is for you, very important, create a role for quality assurance. And don't expect that cloud engineer, software engineer will do it within his role.

And it's okay that a person have multiple roles, but create a role and are responsible for it. That's the first one. The second one is treat your colleagues and team members as adults. They will act as adults because when you treat them like children with hiding information and you think you cannot tell them because they will react nervously or stuff like that, they will react nervously, but if you give them the information, if you give them the trust and all the stuff, they will work with it and they will do it good. I think that too many leaders, too many companies are too afraid of the stop of the step. And the last one is don't be shy to ask for advice.

I was very young when I was got, got. Got my first leadership position and I had a lot of engineers within my team who were very experienced, way more experienced than I am. And the key to get the acceptance was to ask them for advice. To ask them, how would you do that? And can you please help me with that? Also, as I said, I'm now in a front end area right now, and the last time I did front ends was, I don't know, 15 years ago. So I don't have any clue about details, what they're doing.

I have a feeling if we were going to the right way or not. Yes. But I cannot, cannot go into detail with that. But when you ask them for advice, how they will do it, they will feel valued, appreciated, and then you will get good work together, a good atmosphere.

Leszek

Got it. Michael, thank you very much. It was a pleasure talking to you. Thank you for your insights and sharing your experiences, lessons learned. It was a pleasure.

Michael Frembs

Nice. Thank you, Lechek. Thank you for the invitation.

Leszek

Follow Matt and Lechek on LinkedIn.

‍