The Dev is in the Details
This podcast is about the world of Software Development in particular and technology in general. Here, you will find thoughtful discussions about tech leadership, AI, the future of technology, and success stories told by the people who made them happen. Your host is Lukasz Lazewski, a seasoned software engineer, tech leader, and entrepreneur.
The Dev is in the Details
Charging Innovation: Matthias Laug on the Power of Self-Managed Teams | The Dev is in the Details #13
► How do self-managed teams fuel innovation?
This episode explores how empowering autonomous teams can drive rapid growth and innovation in tech-driven organizations. Maintaining agility and accountability becomes crucial as companies scale–but what’s the secret to making it work?
Matthias Laug, seasoned tech leader and CPTO at Enter, shares his firsthand experience scaling high-growth companies like Lieferando.de, Takeaway.com, and TIER. We discuss how self-managed teams influence scalability, leadership, and the evolving role of technology in fostering independent, high-performing teams.
► Our guest 🌟
Matthias Laug 👉 https://www.linkedin.com/in/matthias-laug-202279226/
Co-founder of TIER, former CTO of Lieferando.de & Takeaway.com, and an expert in scaling tech organizations through self-management.
► In today’s episode:
- The origins of Matthias’s belief in self-managed teams and how he first implemented them.
- Striking the right balance between autonomy and accountability in fast-growing companies.
- Real-life examples of how self-managed teams drive breakthrough innovation.
- Leadership qualities and cultural shifts necessary for success.
- The role of technology (DevOps, automation) in enabling self-management.
- Common pitfalls and advice for companies transitioning to this model.
- The future of self-managed teams and their evolving impact on tech leadership.
Matthias’s newsletter: https://www.leancpto.org/
► Decoding the timeline:
00:00:00 - How Self-Managed Teams Can Transform Your Organization
00:03:35 - What Makes Self-Managed Teams So Effective?
00:07:18 - Real Lessons from Implementing Self-Management
00:12:24 - Scaling Without Losing Agility: What Works
00:17:57 - Building Trust & Leadership Without Traditional Managers
00:23:40 - How to Improve Decision-Making & Accountability
00:29:50 - Hiring & Onboarding: Setting Teams Up for Success
00:35:45 - The Best Tools & Metrics for High-Performing Teams
00:41:30 - Mastering Feedback & 360 Reviews for Growth
00:47:10 - Applying Self-Management Beyond Tech for Bigger Impact
00:52:40 - How to Convince Leadership & Make This Work
00:58:10 - The Future of Self-Managed Teams & Key Takeaways
***
The Dev is in the Details is a podcast where we talk about technology, business and their impacts on the world around us.
Łukasz Łażewski 👉 https://www.linkedin.com/in/lukasz-lazewski/
Write to us 👉 podcast@llinformatics.com
If you can't trust by nature if you're a person who can't give a benefit of the doubt or upfront trust, you're going to suffer in this structure 360s can also then be beneficial. But yes, a lot of times I read through the feedback that has been given and it is mediocre or it's actually just harmful. This is one of the highest principles that I'm holding. If I'm setting something in stone, we either discuss and change it and then stick again to it until we Today.
Speaker 2:We're joined by experienced tech leader, matthias Laug, whose career spans some of the biggest names in mobility and online services. From shaping a Lieferando DE's tech vision to scaling Takeawaycom and later co-founding Tier, matthias has consistently pushed the boundaries of innovation. Now, as CPTO at Enter, he's continuing to drive forward-thinking tech strategies. One of the key pillars of his leadership philosophy are self-managed teams. Today, we'll drive into how this approach has transformed organizations and what lessons leaders can take from it. Matthias welcome. Thank you very much. Happy to be here. If we could start this conversation by actually defining what the self-managed team is.
Speaker 1:Yeah, so the term that I've been come up with lately, um that I'm trying to build all the philosophy around it, is ultimately like managerless, uh, like I'm not. I'm not a native english speaker, so I have no idea if that makes any sense to me. It makes sense, um. It says um, teams do have managers, teams or organizations do have managers, but as little as possible and as many as needed, so to speak. So when it comes about self-managed teams, it's a team that can't first of all have the expectation that there is a big org of head of directors, vps and so forth that divide the entire organization into certain splits, but it's actually that they own and being responsible for a specific topic and they can't hide behind a manager.
Speaker 2:How did you start implementing something like this? Do you build a team from scratch, or did you try to do it in an existing setup?
Speaker 1:So I've been going through various stages and evolutions over the time. I think what the result that it has come towards is ultimately representing also my value system. I'm blessed to work in an area where predominantly engineers, but also product designer, product managers, et cetera that they, those are smart people and it always came a little bit botherthumb to me saying like why do I need to put people in front of them and shield them or give them guidance, et cetera? So the history was that I tried that already at Leigh Ferrando. The way that I've structured my team was the absence of managers. I just they were like what are they needed for? We were at some point like 20, 30 people.
Speaker 1:And I never felt like there would need to be anyone else but me to really be the manager. But while I enjoyed giving people all that freedom, it missed the accountability, it missed the structure, it missed the clear framework. So I confused liberties and self-managed teams a little bit with anarchy. So it failed when it comes to the org structure org structure and I struggled and suffered also a lot under that. Things were just coming to me and I always needed to give direction again and changing course etc. Because everyone needed to be reminded in which direction to go or how to behave or how to act and how to structure themselves.
Speaker 1:When I went into tier it's I felt, hey, not gonna repeat this mistake. I'm a grown up. Now we are about to build a big company, we're quite confident around this, and boy have we been right. But I said like I need managers right away, I need the VPs, I need the directors and, yes, the organization that I was leading in the end was in the ballpark of 380 people, like hardware, software, supply chain, et cetera. So I really felt it is important that I have those VPs and those VPs need the directors and the directors need the head boss. And while I felt that I was in control. I lost completely the oversight and also the touch to the entire organization. So many layers were put between me and who put those in Myself, and that didn't feel good in the way that I performed the best, and that is I am a leader who is happy to give responsibility and tasks to people to freely act upon those, but at the same time, when shit hits the fan, I'm rolling up my sleeves. I'm also going down into the machinery room. I like to help out and I also believe, with the engineer at heart, that only when you really understand how things are happening in the machinery room that you can make good decisions that shape the technology strategy and that also shape the product in the end.
Speaker 1:So that also failed for me and I was so disconnected from the entire organization and it came with a lot of downsides. And that is specifically that I felt that um, a lot, a lot in my organization is irreplaceable. If I pick this particular part out, everything is going to fall apart. So I was very, very hesitant to also do changes and um, when, uh, we went with TIA into like earlier than expected, but also the needed like the downsizing, and made sure that the organization is more set up for profitability. I was not well informed. What can I change? Where can I cut things out? And I needed to talk now to my VPs, and even the VPs were not completely on board of that, and so they needed to talk to the directors. And it went further and further. So I had control, so to speak. There was always someone I can address for a certain topic, but never was I able to solve it in the same meeting, nor did it really felt that we truly had a punch, that things were moving forward and that everyone was aligned and on the same path. So I said that failed also for me.
Speaker 1:So previously I did it very value-based, um. Then I did it very much by the book, putting in those managers and everything, and, um, both of those didn't feel right and I've spent a couple of months reflecting on that, like shortly after tia was on the sabbatical and really tried to understand what is it that is right for me? And this managerless approach through self-managed teams was always something in the top of my head. But whenever I was talking with people about it, they're like, yeah, self-managed team, there's no accountability, you don't get them on the right direction and I got a lot of negativity actually around this. But I felt like if I want to function in the next company as a CTO, cpto, c-level, c-suite, etc. I need to figure this out for myself and to put it in a nutshell, it was then eventually stating yes, I don't want managers, but I still need structure, and this is where I'm putting a lot of thought in right now.
Speaker 2:Fantastic A lot of these things that you already touched base on I have later in my questions as well for the discussion here. But help me understand one thing. From what I understand, is this related to the size of organization. Do you think that there is some sort of a glass ceiling towards which this methodology will stop scaling up, because you actually need that kind of corporate structure?
Speaker 1:Yeah, that's actually truly one of the first questions that I've usually been encountered with when I'm joining any meetups, whether it's CTOs, of which companies and they run again like an organization of 100 and above. This is the first question that I also get like, yeah, okay, that works for a small team, and I fully agree. Reason that I knew that not only through my ambition, but also through the need of the company and the stage it is in and where we want to be with the company in the year's time. I also understood, okay, yeah, I can try this out there without hitting this impediment. I'm not 100% convinced yet, I would say, but I'm working towards that that I have the confidence. Um, I truly believe that there's a ratio of one to fifty.
Speaker 1:so for people that um that uh question like okay, what could I gain with this? Or how uh would that ultimately look like? And a lot of people have this uh thing in their mind. Yeah, okay, each person can have 7 to 10 reports. Until this point it's going to get crunchy and I say it's 1 to 50. And if it's done well, no glass on ceiling?
Speaker 2:no, absolutely. It almost feels like there's this old world definition 1 to 7, 1 to 10, like you said, I think Bain came up with this in some research in late 90s, early 2000s. And then you have people like jensen right running, nvidia with with flat structure, right with hundreds of people, and my understanding my understanding is he goes to all of the kind of meetings and deep dives with every single engineering team hands-on, exactly what you're talking about. It's very dear to me, it's very close to me to to have this kind of connection to problem at hand as well it's funny that you bring this up, because I doubt that he's deep diving in every single topic.
Speaker 1:I think, um, the structure that I'm specifically proposing and trying currently is not for everyone.
Speaker 1:Um, you need to be of a certain mindset. If you can't trust by nature, if you're a person who can't give a benefit of the doubt or upfront trust, you're going to suffer in this structure Mentally and physically. It's going to be terrible for you, like, it's going to be terrible for you, um, because otherwise you do have the urge to go into every single topic and you will just not find the time. And then this ratio comes back okay, so that I don't need to trust and I have full control and I can deep dive into everything. Then I'm putting up all those managers again so that they, in my name, can deep dive and go on every topic.
Speaker 1:Um, so this is something that is truly required of a person that tries to run this um, that they should not trust blindly. And um, there is, there's methodologies to um to address, but you need to start with the trust and you need to always assume good intent by your people. So if you see something going wrong by the outcome, you still need to assume with the information at hand, they did the best possible and thought that was the right direction Because, again, otherwise you have mental breakdown eventually.
Speaker 2:I can totally understand that. Sure Okay. So what's your perception how Jason does?
Speaker 1:this. I think he's picking his battles. He is, first of all, hiring people that he spends potentially the first weeks very closely with, gives them clear guidance, gives them clear idea and principles that's at least how I do it that can survive the time. If I onboard someone and give them 20 tasks to do and give them a roadmap, I need to spend some time with that person again in two weeks because they're running out of tasks and they can't pick themselves the next task or the right next iteration um. So you need to give people something of a guidance in the direction that um sustains. Time needs to be durable, needs to be something that um is not just time bound to the next two weeks and then it needs to be updated, but something that is correct today, in two weeks, then in four weeks and then, yes, you need to have the people that are able to derive from that the right next tasks.
Speaker 1:As an example, like in principles in the tech strategy that we've set out at Enter, I've always made clear that the highest responsibility of the tech is that a team by itself is independent. We've structured things in a way that the team can take an entire vertical and within this realm they can make decisions and they still depend on, they're still dependent on other teams, because the user journey obviously goes beyond just one single team, yet they need to be able to achieve as high independence as possible. So, instead of telling people like you're using Kafka, using event-based, you're using that, and that, I say like, does your decision comply to that principle? Are you equally or less dependent on others? If that's the case, you're doing a right decision and we've put metrics for this in place and that allows them to also see are they performing, are they doing better, and that sustains the time. But yes, you need to put some more thought into this in the beginning and also need to put some more thought into this in the beginning and also need to stick to it.
Speaker 2:That is a very strong message. It resonates with me really well because I used to say when people come for advice, like should we use Kafka, rabbitmq or anything else, I'd say it's your choice, because you're going to be leaving with it. You're going to be the ones who will maintain and grow on top of that decision. So I'm not the one who will force you one decision left or right on the choice, even if I have a strong opinion and preference, because I'm not the one who will be hands-on on that from day one onwards. So totally get it. But I only did it in the vicinity of 20, 25 people maximum and if I may, like the example that you've taken.
Speaker 1:I know you're saying now it resonates with you and a lot of people give the same feedback, but applying this then into reality is actually a whole different beast.
Speaker 2:I can imagine.
Speaker 1:Like a lot of like.
Speaker 1:You're saying, hey, I don't want to influence your decision to go in with Kafka, but still you need to be telling people if their decision is right or wrong.
Speaker 1:And that, I believe, is the fundamental difference between what I did at Lieferando and what I'm doing now. At Lieferando, I would have told like, hey, that's your decision because I want you to be accountable, right, but then I didn't give any constraints, I didn't tell the playing field, I didn't tell the direction, give any constraints, I didn't tell the playing field, I didn't tell the direction. And wondering then why everyone does it a little bit differently and everyone does a different decision. Because they say like, yeah, but you told me, this is the liberties that I have. I was like I hope you figured out by yourself that that is maybe a terrible decision, that this team is going with RabbitMQ, this team is going with Kafka, this one is going with a different solution, and all of a sudden we have this mesh of systems that are not aligned at all, and that is this is something that still needs to be given.
Speaker 2:Yeah, okay, so one standard, set of standards within the company. I guess, cohorts, if you could walk me through it, what's the balancing act between autonomy and accountability actually? Or, as you put it, giving the playing field? And direction yeah.
Speaker 1:I would say something that I specifically learned at TIA consequences, as harsh as it sounds, when people, consistently, are failing to deliver on their metrics, deliver on the objectives that have been set, breaking the principles, they're just not fit and probation time is for that cause. And probation time is for that cause and as much there is the need for people that are performing very well to see that their good performance or high performance has been obviously put in context and has been rewarded. And, yes, it has also been rewarded when there's consequences for others, for low performance. Um, so that people see, uh, yes, I'm giving liberties, I'm constraining them by clearly giving direction, at what point in time it's offside, so to speak. Right, and if people are constantly going offside and therefore make us lose the game, this is the point where I'm having conversations with people. And how does this happen? Sorry, matthias, how do you know?
Speaker 2:that they're offside or not, I don't know. You have a five-people team and they're collaborating between two, three different domains product people together with coders, three different domains product people together with coders. Where is the line that someone says we have to work it out to have an agreeable path moving forward, versus oh, I've done it a thousand times, we do it this way, and then everyone gives up their own accountability because it's on that guy or that girl to go on and implement it the way they just said? How do you structure this? Because consequences they understand, but they come after. And then how many times do you structure this? Because consequences I understand, but they come after. And then how many times do you give that chance for that to reiterate and fail again before you restructure the team, for example?
Speaker 1:Now, first of all, it always depends. People can fail four times and there's no consequences because once you have the conversation with them and you truly understand that, yeah, that failure wasn't their mistake, so to speak, it was external factors, maybe even the wrong direction from my side, and so forth. So I want to be clear that this is not a cutthroat approach. It's always a token of conversation, but that conversation needs to be built. But then how do I do this? I put qualitative and quantitative metrics in place, which again is quite a controversy in the tech sector, because everyone believes like you can't really measure what tech is doing and how they're performing, and I fundamentally disagree to this. I think that, for example, the DORA metric scientifically proven, is actually quite a relevant metric to measure output and actually the quality of that constant output. So this is what I'm measuring, what I'm actually putting on the team and saying, like, as a team, I want you to be compliant to the targets that we're setting.
Speaker 1:But now to the principle. Like I've mentioned, the independence, and the independence can be measured in a certain way, and that is first of all quantitatively. We look at how many calls, like http calls, one team does to the other domain. This is ultimately tightly coupling themselves and something is not going well. So if this is constantly increasing, it's definitely a token of conversation where I look into this and saying like, hey, you might have a hard time. The other part is if their contracts constantly fail, so meaning they are serving something to another team and they're constantly failing to provide on that, we have monitors on our contracts and if they fail then USLO is going down and so forth. It's another token of conversation.
Speaker 1:But then also qualitative metrics, and the easiest one there is, surprisingly, for the tech leads. How many meetings do the product managers of two different teams have to align on a certain topic? And if that's the case, and if I've been brought into, we have once a week in alignment meeting to actually figure out dependencies, which are normal. Dependencies exist. But if there's one team where consistently and recurringly one product manager is requesting support by the others otherwise they fail to deliver on that, their tech lead is not doing a good job.
Speaker 1:We had that case. Somebody claimed consistently and saying like I can't figure it out, this is, I need support from this team. And they tried all models and C-level said it's priority. So it's also an attitude thing, quite frankly, and it resulted ultimately that we had to part and there was no personal issue. I liked that person a lot and they were energetic and they really wanted to move something forward, but this particular part they struggled to figure out and they also struggled to figure out, to create or to translate this, to put accountability on their own. Tech leads Like dude. You need to figure this out for me and you're not, and I'm calling you out on this, which is, by the way, another thing people taking each other also accountable, and it's not only me going to them or a manager going to them.
Speaker 1:Yeah that's a whole different topic as well.
Speaker 2:OK, that's great, and it almost feels like you need to educate them, um, I mean the the tech folk, uh, to be a bit more business savvy. Right, because they need to understand all the wise and rather than quite, um, exaggerated, you know case of developers saying like, oh, just give me a tickets and describe everything. Perfectly. Right, because fully agreed.
Speaker 1:Um, you say, uh, educate them. Um, a hire for this. I call it for a reason product engineering. Um, we, we're not doing rocket science. Um, we are not building yet another AI model or another queuing system or a cloud interface. We're building products for end consumers, and if you don't understand the business, you're a terrible product engineer.
Speaker 1:You will be working along what has been told to you and you will hold this as a truth, but you never truly understand who your target group is, why they love or hate it and act accordingly. But then those are the same people that eventually say I can't decide on anything. You need to tell me more of the why and all this nag. So I put a lot of effort onto hiring those people, and actually one thing that I test, not only in the interview in the first week, is that I am, first of all, challenging people. Are you comfortable with running an entire project? So it has been clear what the problem is. It has been clear what a potential solution is, but 20% is probably still missing in the details based on the user feedback and so forth. Are you comfortable running this by yourself, not hiding behind a product manager? If the answer is yes, that's the first checkmark, because everyone loves it. Yeah, I want to be close to the business. Then I usually ask them hey, can you describe a scenery where this happened in the past? When they can't tell me one, then I ask them why didn't you claim it? Because you say you love it when you love it, why don't you demand it? And this way, even if they did it like this before, I can still figure out whether they just hear liberties and freedom, or if they also hear accountability, responsibility, which they're joining the company.
Speaker 1:One of the onboarding topics is that they need to pick a project that they are leading, and the challenge and the fun part of it is I am not telling them which one it is I expect from people, because I've briefed them about it I expect you to lead a work package during your probation time. And if they don't pick up on one by themselves demanding it, it's a token of conversation. Again, right, and again I want to be emphasized it's a token of conversation because, yeah, sometimes there's also a product lead that says like no, no, no, no, no, no, no, I want to have this one. Like do you need to do a couple of user feedbacks there? Oh, it's all German, and they might be hesitant to give people early on this because they don't want them to fail, because they fear it comes on them. Yet this is then again for the person to demand it and say like no I want one, I want to take it.
Speaker 1:This is a perfect example, a perfect project where the problem has been clear. So a product manager can't provide additional value through research and experiments and interviewing and mocking things and fake door tests and all the yada yada, but it's actually pretty clear already what the problem and the solution is, and I think an engineer can completely take and must be able to completely take the lead there.
Speaker 2:Absolutely. But now, then, I understand much better what you meant before, in our earlier conversation as well, when you said it's not about the structure, it's not about convincing management, it's mostly about the culture in the organization, because you want a specific mindset first, all and I need it.
Speaker 1:It's the backbone of it.
Speaker 2:Like you describe this person that waits for a ticket won't know, of course, because yes and and I, and, as I said, it's an extreme negative example which I, um, I'm not, yeah, accepting I don't think it's a negative example.
Speaker 1:I think it's a perfect example for a lot of engineers that have learned to work in the past 20 years with product management established.
Speaker 2:So I guess I'm somewhere in the middle right I'm not there yet of what you're describing, and what you're describing sounds amazing, but I'm also not in a stage where I would allow a behavior where someone is actively working for work, stage where I would allow a behavior where someone is actively working for work, because there is a backlog of topics and code that we rounded up and is now becoming adept or something, and someone could just revisit that. So there's plenty of places right, and startup is a constant under construction building site, right, work site. You could just really put your hands wherever you like, and I have seen examples in the past where people who are coders became an amazing data analyst and data experts and edl experts because they just got dragged into, you know, from ruby to python, from python to c++, to build these systems and they have, you know, uh, flourished.
Speaker 1:So it can be done now, what you're describing is like an engineer has been asked to transition from being a math teacher to a religion teacher and start teaching it next week, like I'm ultimately asking. You still be an engineer, you still build things, but you should care for whom you build it. You should care, uh, for the reasons why it has been built this way, and you don't need it to be mouth fat like expecting a meeting and to be on boarded and getting a kick off so that other people tell you what the truth is. It's okay that you figure this out by yourself and spend some time reading it yourself.
Speaker 2:Super, and how do you expect them or encourage them to demand answers and question, question, question till they're ready to start their own initiatives and accountable actions? Items on their to do list.
Speaker 1:It's a good one. With the, with a clear look on how they act during the interview, you get already some insights. Again, the way that people behave in the interview is obviously always a little bit different from how they're acting in the company, but there are certain signals that are really really hard to hide, okay, such as when I do the interview, I always split it in half and then I hand it over to you and say, like, okay, you can ask any question, because this is a cultural interview. We would like to understand if you're fitting inside of the company, and this is a two-way street, so it's not only me making a decision whether you fit. You also need to make a decision whether you fit, to make a decision whether you fit. So ask me your questions.
Speaker 1:And then there is the category of people that feel very comfortable of saying I have no questions. Okay, right, this is, uh. This is the people that like um, please, you need to pitch me your job, which is, which is fair, but I just did that, right, and now, uh, maybe, uh, pitch yourself or ask questions at least. Then there's the group of people you see it in their face because they're looking up, they're not looking down on their notes, et cetera. They're looking up and they're able to come up with questions on the spot. It's like, okay, not a red flag, also not loving it, yes. But then now those people are like, yes, all right, and they get out, out and they prepared themselves, so they put um, they put value into the time they're spending with you and also, without being briefed, that they will be able to have a lot of time for questions themselves, actually have questions themselves and what I absolutely love, um, the majority of time, I always make sure that I have no appointment after an interview, not only to put out the scorecard right away so it's fresh up in the mind but more so often, um, that I can allow a candidate to ask for more time, because if they are with questions and then we're running short in time, see, like, okay, it's a five minute um signal, as I, like I would have a couple of more questions, and I always can. In the majority of times, I can say like, surely, because this is what I've given to people, so I've creating already for them, there is the space for it and there's also the time given for it if you need additional information, which rounds back to.
Speaker 1:It's not for everyone. It requires patience and it requires you not going into a meeting with the attitude of like trying to crawl from the beginning out of the meeting again. If a meeting overruns for good reasons, it's okay. If a meeting is done before time, that's also okay. But cutting a meeting because someone still has questions can't start from the get-go in the interview, because, yes, here I'm obviously also pitching the company and those are the strong green flags for me. This is a person. They are demanding their time, they want the information so that they can make a good decision, and if they're making good decisions for themselves and they're feeling integrated into the company, they will start to apply the same process in making good decisions for the company.
Speaker 2:Okay, and yeah, that's fantastic. I took tons of notes from that, thank you. What is? Do you feel there is a particular technology or set of you know, uh, tools that help you with all of that like on a daily basis, or maybe educational materials, or like how do you do you think that there's enough people like that out there for hiring on the market, especially if you want a hybrid or in-the-office experience as well, or is it more of a training element? Have you ever had a success?
Speaker 1:with retraining.
Speaker 2:I'm sorry, let's pause and go back to tools and software first.
Speaker 1:On tools and software. I don't put much thought into it anymore. I wasted too much time in my past on having conversations whether we should use this tool or that tool, like. Whenever there's no decision, I usually say, like I probably can do it with an Excel sheet, right? So like, oh, we need to put the data together. Oh, yeah, that takes some time until we have it in Metabase, so we still need to put the flows and inject this. There's other priorities. It's like put it in the Excel sheet.
Speaker 1:I don't know when it comes to the size of the market of this kind of characters. I think it's spot on, it's not big. I think it's spot on, it's not big. The majority of people have also gotten used to the structure that the product manager is the de facto team lead, the communication shield, and they got very comfortable with that as well. So they train certain behaviors which are like Okay, I will check with the product manager to figure this out, or this needs to be clarified by the product manager, the retrospective led by the product manager, and I think there's a lot of those people, but it is changing now. At least I can put it from this perspective. I've previously mentioned it. When I ask people and describe the environment to people, to engineers, they're delighted and they're like, oh, this sounds amazing, etc. So there is at least a wish to be in this. So again for the liberties, probably Now if I'm getting people also to thrive on the accountability part and yes, that has been a lot of times an educational part, but it's not that hard.
Speaker 1:I've mentioned earlier consequences give instantly the impression to the company. Consequences give instantly the impression to the company if I'm here, I am doing a good job, because I know that people are leaving involuntarily due to bad performance. Please don't get the wrong impression that I'm making an example of people just to give this in, but that is indeed really, really, really helpful. And the second thing is that I give them objectives and that I've spent time with them to um to put this objectives together. And when it comes to the educational pieces, I'm a big fan of books out there.
Speaker 1:When when people tell me um, oh, but it's going to be hard to measure, and I was like, no, that's bullshit. You just don't know what you need to measure or you don't know what you're caring for. The moment you care for something you should be able to observe, something that you would like to see more often and that you can put a measurement on. Is it a proxy? Maybe? I don't care, as long as it's directional and the same for, but I can't have all those one-on-ones. It's like, no, you don't need to have one-on-ones with people first of all. You can tell them demanding and asking that they put a one-on-one, uh optionally in with you, uh, when they need it as much. You put one in when you need it and then bring forward and talk about the goals. I have constant, constant check-ins, but I always open in the same way. I open my Notion page. Okay, tools again.
Speaker 2:Right, but I open my table.
Speaker 1:And I open up the objectives that I've agreed and set with a person and I ask them okay, how are you doing with that? And I can give you a very concrete example. I'm currently working with our data engineer, who is responsible for all the flow, all the data flow between the teams, knowing that there are dependencies and one of their objectives. They are currently working on an event registry and the objective is not build the event registry. The objective is twofold. The first one, quantitatively I want to see that 80% of the CPT org is on a monthly base using this tool, so that we have a monthly active users of 80% of the CPT org, because that's a representation for the value of the tool that has been introduced.
Speaker 1:And the qualitative measure is whenever we see a Slack conversation where the answer would be in that tool, it's a negative signal because people have not used it. And it's a double negative signal. Somebody asks and nobody references, saying you could see this here. Why are you asking me about this event? Here it is. You could have just searched for it in the registry. So maybe there's a different solution to this and he needs to do something completely different. But we've been agreed. There needs to be some kind of tool and that needs to be regularly used and we should see a decrease of Slack conversations without reference regular use and we should see a decrease of Slack conversations without reference or at medium with reference to the tool and, at best, eventually none.
Speaker 2:Because people self serving Fantastic. I really like this because you even can tell that after trying the solution, you can figure out that there is a better solution, like for the example you gave, like chatbots or something. If that's what people prefer, because we are wired differently, then 100% Going back to 101 and retros, and all of that when you remove product or nominated leader, let's call them. Just so I can visualize this also for our audience. If I have five people team or whatever 10 people team, how do you run one-on-ones? Who is running them? I mean, I know I can ask you for one-on-one, but why would I ask you and not someone else next to you? Exactly, exactly, okay. Or how do we run retro? So it's not a chaos and a big discussion over one another and who is moderating this?
Speaker 1:Beautifully. And one key aspect which is not strong in the ecosystem is the ability to give feedback. Because that's the point when I'm the only person that is supposed to give feedback, my time has been completely drained, supposed to give feedback, my time has been completely drained. But furthermore, with the setup comes a limited touch point with each and every person and, as a result, out of that, how should I give you valuable feedback, the best feedback you get from your peers, and for this there's not only the ability to listen like it starts with that but it's also the people being able to give feedback give like truly constructive feedback. And it's always such a difficult topic because a lot of times people are actually just criticizing, like this is not going well, this is not going well, this is not going well, you should do this better. This is not going well, this is not going well, you should do this better.
Speaker 1:No-transcript education you need to and put into people. You're expecting a lot, right, you're expecting a lot from every single individual, which would otherwise be substituted by a manager, a manager the ability to give feedback. When, in an organization, there are trainings for feedback, in 80% of the cases they will go to managers, because managers are supposed to be the one that make you better as my report. Instead, I would like that those that have actually constant interactions, that they feel comfortable to address feedback for one another and talking through that. This is one reason why I got less reluctant and actually very, very supportive of hiring people from like Boston Consulting or McKinsey, because there they do it at prime it's industry, leading how they are doing feedback and the structure they have been given. And we have a couple of folks there from those companies at Enter and I've been highlighting a lot of times that I would really like them to role model this and see how valuable it is when you give someone feedback and how 360s can also then be beneficial.
Speaker 1:But, yes, a lot of times I read through the feedback that has been given and it is mediocre or it's actually just harmful you can just throw it away is mediocre, or?
Speaker 2:it's actually just harmful. You can just throw it away. When Daniel Zeiss if there's a five people team and they are giving each other feedback, at which point do you step? In actually, when you say I'm reading that feedback and it's a trolley, or I'm reading that feedback and it's mediocre, oh, so there's a guarantee in our structure that I do this at least half a year.
Speaker 1:So every half a year, everyone is in the Legitable for 360. Every year, everyone is a Legitable for a performance talk to discuss salary adjustments. Now, this is the point where I'm doing it together, where I is the minimum point, where I'm spending time with them. Now, there's people that I have a lot of touch points where I have a more active role in the conversation. Otherwise, and this is also how I prime people towards those sessions, if you want this to be a valuable session, you need to collect the feedback, you need to digest it, you need to prepare it and you need to make recommendations on how to improve on it, and I be your sounding board. If you come into the meeting and and yeah, here's the feedback I was like jump, if I read that feedback, I don't know how you feel about it and I don't know how valuable.
Speaker 2:Daniel Zeiss understand most of the time right, like if it's the first time they see it and the first reaction is emotional. Yeah, I feel you. This is great idea. That's a great hints in there that they collected, they digested and then they presented high expectations Fantastic. I love it. Do you have playbooks in your organization for all of this? Yes, playbooks are my managers.
Speaker 1:I spend a lot of time in writing things. I spend a lot of time in providing people with clear guidance when it comes to um, like we call it, the playbook running a work package so that I, as an engineer, or I as anyone in the cpt or org, when I'm the right fit, should be able to lead a work package. When I'm leading a work package, there's a certain set of expectations towards me and that clearly pointed out. I'm the point of contact for any communication, which also means gravity. It's not just I hope people recognize me and I hope people are approaching me. It's like no, if people are defaulting towards the product manager again and addressing them on a certain work package, then I actively step in and say like I'm going to take this answer, I'm leading this work package, et cetera. I'm accelerating. Now you don't need to stomp your foot on, but that product manager sees behaviors that makes them comfortable. That they recognize people are leading a work package is actually stepping up to the job and they're not in the end again responsible for it.
Speaker 1:So we have clear playbooks with clear expectations that also constantly change. We have a playbook on the employee lifecycle which goes beyond the alumni, goes through the hiring process, what people expect in the first months, in the first three months, in the first six months, in the first 12 months and beyond All of those things has been clearly, clearly, clearly pointed out. And I'm not deviating a bit. This is the one of the highest principles that I'm holding. If I'm setting something in stone, we either discuss and change it and then stick again to it until we again discuss it and change it. But until we don't see a reason to change, we stick to it to the bone.
Speaker 1:I don't negotiate with people. There is no negotiation. I don't have time for that and it's never a fair result and it's never a fair result, fascinating and brilliant at the same time.
Speaker 2:I love it. Okay, so if you have a bigger, team now 20, 30, 40 people and those work packages come in. How do the team and people decide who is the person with the right expertise to assemble the squad? Let's call it to tackle the particular problem at hand.
Speaker 1:So there's never a lot Like, given the team size. A team can usually not carry more than two, max three, work packages.
Speaker 2:Work packages Okay, and how many members Like five, six people inside of a team.
Speaker 1:Currently, okay, but now put it this way again Also in the role description it states what is a good work package for you, such as a work package where the problem is unclear and the solution is unclear.
Speaker 1:It's a product lead Because I want the product managers I call them product lead inside.
Speaker 1:I'm using product manager here so that everyone understands me and we're not having any conversation about the role description now, but I put a product manager on top of it when the problem and the solution is unclear, because then we need to do investigation, we need to do interviews, we need to define for whom we're solving this target understanding the problem truly, then doing the solutioning, trialing it out until we have confidence or not, and then building something around it to get more confidence and then eventually building it and being happy with it.
Speaker 1:This is where a product manager is truly value at and I want them to focus on this, and this only. Then there is a topic where the problem is pretty clear, the pain point is pretty clear, the solution is unclear. This is a perfect fit for a product designer, because it's all about solutioning and trying things out, but I just need to have interviews to validate and to confirm. I don't need to have conversations with people or even doing active outreach, because it's usually a pain point that the customer is already facing, so I can have a conversation with the customer where I actually had it, when the problem is unclear.
Speaker 1:I don't even know who to talk to. And then there's the things where the problem and solution are really really clear and the devil just sits in the details. There is an engineer perfectly fit Directly as a leader. Directly as a leader. I can also give you a perfect example of that. Like we've tried at the beginning, when I joined Enter, a different way on how we're going to our um, our results, to our homeowners, and previously we did screenshots and put them in the slide and that was really manual job and it also looked terrible. We sometimes just did screen sharing with the um, with the tools that we used internally, which looked terrible and it wasn't it. It was not just assumed, it was clear, it was a bad experience.
Speaker 1:So we experimented and created a nice slide deck and let two, three consultation run with it and figured, yeah, this is beautiful. Like the homeowner liked it more, our consultants liked it more, so it's a win-win for everyone. So let's automate this, let's make it scale and make a front-end around it. At the moment that the data has been collected, the page, the slides, are available right away in an easy-to-distribute format, maybe the web, and this is the point where I gave it to one of the front-end engineers and said like here's the slides we tested and they work. Now it is for you to build this and whenever you have issues or whenever you find problems or see improvements, we want you to do those improvements. And it worked. That person picked up the job. They replicated more than they did further investigations, so they were not too strong on finding additional issues. Like you could say that could have been done better, but they allowed the product manager to stay on course for their own subjects and they just let that topic themselves.
Speaker 2:So when you have these three kinds that requires research with a completely unique thesis that you have before this proof because you don't know, as I understood it, then you understand the problem but you're seeking the solution, or you do understand both. Do you put deadlines in these three categories, like, do you give people like don't spend more than a week on this yeah, how do you know how to erect a deadline for something like that between these three categories?
Speaker 1:We have a playbook for that. So I give people the guidance that when they are getting deadlines from stakeholders that this is not. For some it's a management tactic Like I know that Right, like what is that law again, where you say like, okay, it otherwise consumes the time that has been given to it. Parkinson's law.
Speaker 1:Exactly Parkinson's law. So, yes, you can do a management tactic around this. But I'm saying like, hey, people are telling you this with an intent. So if a stakeholder comes in and says I need a solution for this and is pushing towards four weeks, this means it's worth for them four weeks. So instead of saying like four weeks is unreasonable, et cetera, it's like okay, I got it Four weeks, let me figure out if we can get you a solution in four. What gives, which is usually quality. And then everyone is surprised that it looks um, so this is the guidance that I'm giving people. Or um, the other guidance is hey, it's okay to build scrappy when we have low confidence on the product. Specifically again with this conversation, if somebody tells you can we figure this out in a week? They usually also have a very low confidence and they're like I don't want to put your time for four weeks on it because I don't even know if it works out. They're like got you, I build it scrappy, let's validate, and I put a week on it and then let's see if we're continuing.
Speaker 1:If you have a high confidence product, so you're asking someone and say like, are you confident that it will deliver the 50 million you're promising, right. So you, as a decider for the priority, say yes, I believe it brings us 50 million in additional revenues in the next 60 months. I commit my worth blood on it, like all right, then let's figure out what the right scope is and we tell you then how long it's going to take, because you have high confidence in the product. It will yield um, most likely the profits because you're supposed to be an expert. If you fail to do your promises for the past a couple of times, you're probably not with the company anymore.
Speaker 1:So you either have the benefit of the doubt, trust, trust to try it at least once or you have a proven record in the past that in 80, 90% of the cases you have been pretty spot on, and just in the other 10 to 20% you have just deviated slightly from the projected targets. So there is a playbook and guidance for the team to use this in a conversation and I can continue on this when it comes to tech debt and so forth. There's a clear guidance on how to address tech debt, because I don't want to have the conversation, we're never having the time for test cases, we're never having the time for this and that when you don't have the time for test cases, you're not upholding one of the tech strategies principle, and that is quality is baked in, meaning you're not giving a ballpark estimate for a high confidence product without quality baked in because you want to deliver it quicker. That's your responsibility and your mistake. You failed on it.
Speaker 2:Fair enough. Yeah, I like that Cool. And how does all of that apply to different teams beyond tech, product design and quality assurance? Like you know, would that work in marketing or sales? I strongly believe.
Speaker 1:So yes, that this is not specific to tech. The only thing and I don't want to mean a disrespectful is, yes, it's highly educated people that you're working with, which, at the same time, also bring a high demand for the liberties and freedom of how to do their work, where to do their work, etc. Surely, if you have a 150-people sales team, you need a little bit more control Because also, at least from my experience, those people are not necessarily in the. I want to improve myself on a personal level, et cetera. I want to get the numbers and I want to get my profit, and that's fine. I'm not judging on that, but I would question whether it would work there, because the people probably not interested in that and actually that might not work. So it's not based on the function, it's based on the people in the function whether they would favor such a system.
Speaker 2:I guess it goes without saying that for your partners, founders, you would expect the same value system to be self-developing, right, because then they can propagate this down to their. The reason why I ask this because that kind of sounds obvious from what I'm hearing is because I'm curious how do you convince existing leadership teams to actually try something like this?
Speaker 1:When I joined Enter, top one raiser for making a decision for a company was do I like the founders? Because the one group I cannot change. So, yes, that's obviously a hard one. But most importantly is for me, I'm driving, I'm running. I'm not running a comfy org, I'm running a performance orientated org and that resonates with any value system that a founder has. So when they have a different value system, they might question it, and it also happens. I see it coming forward.
Speaker 1:Why is that person not here? Are they really working? Are they pushing the boundaries here, et cetera, and all those anecdotal conversations. They went earlier on holiday. Why are they always leaving at 6pm, etc.
Speaker 1:I look at the numbers and again like it's a fine example, for it is not for everyone Like if I would truly be concerned about people stopping their work at 6pm.
Speaker 1:Remote work is the worst setup for me and I think it's also one of the most honest answers for people that are calling people into the office because they want to see that people put their time for the company beyond 6 pm and they are measuring and comparing high performance with those that are leaving not earlier than any of the founders. A very Japanese style and while to some degree that also might be true that you can squeeze performance like this. I would also say people that are forced in the office and been expected to be longer there. They're probably just on Facebook in the end and already doing their private stuff, but just in the office and people adapt to this. So if I would truly care for this, but the performance this. So if I would truly care for this, but the performance, if somebody's so brilliant and so good that they can get their job done in five hours a day and I've measurably have this in the performance and it brings the company forward and the targets are being hit, why the fuck should I care?
Speaker 2:apologies yeah, absolutely like it's. It's. At the end, it's all about the result. I agree 100% with that. Awesome, I really really like this conversation. Matthias, thank you for your time. This is fascinating and I think I would love to try it right away.
Speaker 2:It must also be amazing, right, Because it's such a reputation game. Once you establish this in the market, in the meetups or anywhere at the conferences, when you talk about it, it will be very magnetic for people who value other high performance, high level of thinking, freedom and accountability individuals. They will be clearly attracted to a company like that, right.
Speaker 1:I agree, but it's also like this podcast is also a starting point for me to really advertise this In a couple of years. I think I need to make for myself a decision Do I start a company again or am I doing like fractional CPTOing? And this is definitely what this is for, those conversations and the newsletter that I've put up, where I'm talking about, like, how do I do this setup? Because I think there's ultimately two groups out there who might be very interested in it and I'm trying to figure out who's the most suitable one. That's, on the one side, establish profitable companies that need to make cost savings. I say it as blunt as it is, because if I'm going in with previously you did one to seven managers, now you did one to 50, and I guarantee you you're at least not performing worse. I'm actually confident you're performing better. But why should I oversell? I'd rather overdeliver.
Speaker 1:The thing is, those companies are big legal frameworks and discussions around how it would actually be set up, so there's a lot of red tape. And then there are startups. Startups where, in my opinion, there's a lot of times a highly energized, great CTO in there. It is not a CTO, it's an excellent engineer and usually never the person that performs beyond a team size of five, six people, where the cohesion of the team comes from sitting in the same room or sitting in the same meeting remotely, it doesn't matter, and it just goes forward. That's usually not the case. So I could bring in a very lean approach to building a team from the get-go and get them then the right person that's actually able to handle that to take over them in the end.
Speaker 1:So there's a bit the idea that I have going forward what I would like to do in a couple of years. And yeah, it's probably easier to get into the startups, but they probably only pay with shares and that's obviously then always a bet for the time you put into it and man got to eat. And at the same time, surely you can go for the big companies who are probably easy to convince to do it. But then it's a lengthy process to actually get into the flow and get the mandate. As beautifully as it sounds for a company, uh, the moment that I'm actually telling them yeah, okay, we would transition, um, like a solid, 40, 50 managers uh out, um, it's like alarm bells and um yeah, but to be honest, we're in a economic, economical circumstances in which people, all people, all individuals need to step up their game in order to be more competitive.
Speaker 2:Right, it's a tougher times, but it's also going to produce better results, better people, right, personal growth and all of that. So I think there's a great opportunity for this just naturally. Could you share with us the newsletter that you mentioned? I would be delighted to put this into a photo notes of this episode for everyone who is listening.
Speaker 1:If you wouldn't have asked, I would have demanded Fantastic.
Speaker 2:What are the best means of contacting you for our listeners? If anyone wants to ping you, what would be the best? The best means the.
Speaker 1:Yeah, I'm not. I'm not a big social media person, so the best chances are on linkedin. This is the one social network that I'm still maintaining.
Speaker 2:Other than that, yeah, like I think, linkedin is super, so we'll put both the newsletter and the linkedin in place.
Speaker 1:Yeah, that will be appreciated.
Speaker 2:But yes, thank you so much. It's been. I don't even know when this one hour went. I feel like I could go on for an hour still, you know. So thank you so much. It's been great fun for me and a wonderful topic.
Speaker 1:So yeah, likewise, thank you, good luck.
Speaker 2:And I wish we connect again in a year or two to speak about the next steps development. Who knows, maybe by that time you'll be releasing a book or something, so I'll be happy to learn more.
Speaker 1:It's a bit the idea. I would currently only call it a series of blog articles, but who knows, maybe this emerges eventually into the size of a book. But yes, I'm publishing currently either like a topic or a playbook per week.
Speaker 2:Beautiful, super. Looking forward to actually subscribing myself. Dear listeners, thank you for tuning in to this episode of the Devs in the Details podcast. If you found today's conversation valuable, be sure to subscribe and leave us a review Until next time.
.png)
.png)