(00:00-00:13) Daria Rudnik
Hi, Sebastian. It's great to have you here. I'm very excited about our conversation today. Thanks. Before we jump into the questions, and I have some very interesting questions for you, do you mind sharing something about you yourself and what you do?

(00:14-00:40) Sebastian Gerhardt
Yeah, sure. So, yeah, I'm Sebastian, the founder of Flea. We started our business, what is it, almost one and a half years ago. And yeah, we're building a developer experience platform. So that is we help CTOs identify the friction points in their developers' daily work and this helped them to enable their teams to ship better software, faster and happier.

(00:40-01:02) Sebastian Gerhardt
And my background, surprisingly, is not in tech, but in business. I started working on the project, more coming from the people side, but then the iterations have shifted into the developer focus. But I think there's some questions coming up in that area as well. But yeah, that's sort of a little bit about what we do and where I come from.

(01:02-01:18) Daria Rudnik
Well, thanks so much. It's very interesting. And you mentioned that you have this business background. And I see you have a lot of kind of entrepreneurial experience, both from being a founder and consultant. Like, tell us about that. How did you end up with being an entrepreneur?

(01:18-01:40) Sebastian Gerhardt
Yeah, right. So, I mean, I was coming from a quite entrepreneurial family as well. And so my goal has always been to become an entrepreneur, really. I wasn't really sure about being an entrepreneur in tech when I was younger. But that's the way I think where it is today. And then, yeah, after university, I started working or I actually studied a dual program where I was working for a bank.

(01:40-02:07) Sebastian Gerhardt
So in a very corporate job and I very, very quickly realized that this is not the right setting for me because I'm just too free minded and creative and wanted to achieve more faster. And it was just the wrong environment for myself. And then started a master's program in innovation, strategy and entrepreneurship. We went to the Silicon Valley so that further increased the fondness of working in a startup and becoming an entrepreneur maybe one day myself. And then I joined a startup in the

(02:07-02:35) Sebastian Gerhardt
a fintech startup in germany they're called finance guru which is a multi-banking app and there i was able to to bring my finance background together with the entrepreneurial ambition for the first time was sort of an entrepreneur in residence there's kind of the assistant to the to the two founders um and from there on really fell in love with the with the startup scene even more and um and becoming an entrepreneur then learned um how to build startups uh in a company builder here in berlin

(02:35-03:00) Sebastian Gerhardt
so where we helped a couple of corporates build startups themselves or at least innovation projects and i joined one of those companies was the head of venture development there and responsible for building new products features ideating with customers and it was quite exciting so the next step to becoming a founder and then yeah realized some issues that in that company when it comes to to people leadership

(03:00-03:29) Sebastian Gerhardt
And I thought, okay, hey, this is actually a topic that's close to my heart. And now I feel ready to jumpstart the entrepreneurial career. And that's how it went. And now we're here sitting together talking about how we've come. So it's actually quite a nice path. So tell me, you said about people development and how people operate in organizations. And your product is about building better teams and better experience. Tell us, what is it about? What does FLEE does?

(03:29-03:52) Sebastian Gerhardt
Yeah, so as I quickly mentioned, it's a developer experience platform that probably, I mean, gives an idea, but nobody knows. I mean, even in my sales calls, it's still a pretty new topic for CTOs as well. But if you want to look at it from a very, yeah, historic point of view or so, in the end, what we do is,

(03:52-04:20) Sebastian Gerhardt
we help software engineers become more productive. And the traditional way to improve developer productivity or to measure it in the first place, you know, you only can improve things that you can actually measure. So how do you measure developer productivity or developer satisfaction? And the traditional ways to do this have been really heavily focused on understanding metrics, right? And I always like to think of an example or to give a more plastic example is...

(04:22-04:41) Sebastian Gerhardt
thinking about a writer so like shakespeare or goethe right so the traditional way of measuring developer productivity was to count the lines of code that the developer would write or the uh the number of changes they they did to their code right so but imagine shakespeare being being evaluated not on the

(04:41-05:00) Sebastian Gerhardt
the output that he created or the value that it brought the joy that it brought to people but rather the the lines that he wrote the first is that he wrote how oftentimes he changed them it doesn't really tell you a lot about productivity right so the next step then was to look at science and what does what the science say how you can improve developer productivity and then you get

(05:00-05:18) Sebastian Gerhardt
to dora metrics i think this is for now or similar to the space framework it's another framework that is science-backed you're looking now at a bit more of a flow or process topics stuff like throughput and code quality have become more important but again

(05:18-05:34) Sebastian Gerhardt
a sort of measuring metrics a only gives you information that is lagging because you can only count the measure the the metrics right once once code has been written and stuff has been done but also it gives you only a limited visibility into

(05:34-05:59) Sebastian Gerhardt
the actual coding work that is done by developers. But where we come from and we believe in this is that developer productivity is actually much more impacted by the things that also happen outside of the actual developer work, right? So software engineering is not a new topic. So how to code, how to do code reviews that has been done over and over again and people are quite smooth in it.

(05:59-06:18) Sebastian Gerhardt
but where real friction occurs is oftentimes in the in the surrounding factors right so if you think about having unclear goals or whether the um when the product the the requirements that come from product are not clear there's no user feedback developers don't really know hey how are our users actually engaging in our product right

(06:18-06:41) Sebastian Gerhardt
not having all of these information or having unclear information about that is actually blocking a developer much, much more because he needs to think, okay, so if the requirements are, let's say that there's spots in the requirements, right? They need to go back to product or they need to think about it themselves. So then they build it. Then they build the wrong thing. They have to restart again with all of that stuff, right? And so what we believe in

(06:41-07:10) Sebastian Gerhardt
is that simply put developers know best what is actually blocking them from doing their best work. And this is what we try to uncover and to do so, we use developer feedback. So we directly ask developers about a variety of topics that we also derived from science and looked at what are the most common factors that prevent developers from doing their best work or that impact developer productivity. And then we proactively ask them, hey, is any of these things really blocking you?

(07:10-07:39) Sebastian Gerhardt
and what those that nudging process also helps them to to really think about a whole environment and come up with with the things that really block them and maybe to give a some concrete examples so the the biggest developer productivity blockers according to science are job enthusiasm so if you're just on a general level you just don't feel as enthusiastic about your work as you could be and then obviously that has different root causes but that is sort of this bigger signal

(07:39-08:02) Sebastian Gerhardt
Career development has the strongest impact on retention, for example. So if I'm unhappy with that, that's a big topic. Then how is the team working? How fast do we resolve conflicts? Those are big topics. And then on a process level, as I mentioned, maybe it's unclarity about goals, about timelines, roadmaps, having unclear requirements.

(08:02-08:24) Sebastian Gerhardt
When the code review process is having hiccups, those are big issues. And then obviously if they have the wrong tooling and stuff like that. And I think those examples already give you an idea. You know, looking at the developer environment or the developer experience as a whole gives much, much more visibility and options to actually improve

(08:24-08:54) Sebastian Gerhardt
a developer's daily work. And now to close the round, if you look back at Shakespeare or Goethe, so it's tough to measure them according to how much they write, how much they change their writing, but giving them the setting where they can fully work in a deep work mode, maybe with the right pen and paper back in the days or with proper lighting, those are all scenarios where you can make sure that at least they have the right setting to be their best. And this is what we focus on.

(08:55-09:18) Daria Rudnik
Well, that's great. So you're right. So basically not so much as measuring their productivity, but you are measuring the environment they're in. And if organization can improve those factors that influence their productivity and satisfaction, it means they'll get, they'll be better in what they do. Is that so? Yeah, exactly.

(09:18-09:40) Daria Rudnik
I am curious. Let's say you have two developers and you have improved all their factors in terms of goals and communication, understanding their stakeholders. Is there a way to understand who is performing better and to measure their productivity on that level? So this is exactly what we want to avoid. Can I say if you bring it up? Because I mean...

(09:41-10:01) Sebastian Gerhardt
That's where metrics are for, right? And you can measure individual productivity. But how would you feel as a developer, as any other employee, if your boss suddenly starts to measure you according to your individual performance? I mean, in terms of a performance review cycle, this is what you want, right? And you want to receive feedback. But again...

(10:01-10:19) Sebastian Gerhardt
there are some metrics maybe where you can judge a person on the individual productivity or performance correctly but most oftenly I mean as we just discussed in the examples right just the lines of code it's a super toxic measure to measure performance

(10:19-10:34) Sebastian Gerhardt
But measuring sort of outcome or output, you know, outcome-based measures is much, much more important. And then looking back at how did an individual person contribute to that outcome, maybe is the better approach.

(10:34-11:02) Sebastian Gerhardt
And then again, we believe that coming from a bottom up approach, and this is actually what our early customers really say that, hey, since we implemented Flea, we have created a much, much more open and strong team culture, people speaking up more, feeling more engaged, feeling more responsible for their work because they're suddenly part of improving their day, their work environment, their job, and not being sort of monitored from top down.

(11:02-11:23) Sebastian Gerhardt
and feeling you know that they have to defend themselves and and i mean once you're attacked or measured by by metrics right what what happens you get frustrated you take a step back you don't feel inclined to push your fullest you don't want to contribute as much you don't feel like it's hey it's it's our baby it's my project but you actually create that uh

(11:23-11:48) Sebastian Gerhardt
that front between sort of the the company on the on the one side on the higher side and the and the developer working for the company and especially in in tech this is such a prone thing to happen because everybody is just complaining about how engineering is too slow how delivery is too slow how the roadmap is too long and nothing gets done and that is just and measuring individual performance is just another factor to create a toxic culture

(11:49-12:09) Daria Rudnik
Yeah, I mean, I do remember in my organizations I've been working for saying, hey, our developers are not working. They're not fast enough. They're not good enough. But it happens that they don't have enough information. And by measuring how clear the goals are, how communications are flowing, that thinks that organization needs to improve in order for them to develop.

(12:09-12:29) Sebastian Gerhardt
I mean, sadly, developers are just in the, if you look at the conveyor belt, right, the developers are sort of at the end of the game. So that's where all the blame in the end pops up. Right. But oftentimes the problems, they start much, much earlier with unclear goals, unclear requirements, a lack of user feedback, developing the wrong thing in the first place. Yeah. Great.

(12:30-12:55) Sebastian Gerhardt
Do you want to share some stories from your customers about how, like you said, the culture is changing and what effect did it have on the organization? I mean, it's super fun reading all the feedback that we get from the developers in the surveys. Of course, we're super stoked at the beginning when we started building the product and people actually used the product as intended.

(12:55-13:17) Sebastian Gerhardt
I mean, till this day, we have over 90% fill out rates on our surveys because developers say, hey, it's finally a survey that actually speaks to me, that touches all the important parts of my work. Unlike, you know, the regular HR surveys that get, I don't know, like 30% fill out rates. And yeah, there's a lot of stuff that we read regularly.

(13:17-13:44) Sebastian Gerhardt
in there. I mean, from people becoming parents struggling with shifting kindergarten work and work. So it's super incredible that even such personal topics pop up. I remember one employee saying, hey, the air quality in the office is too bad and that's preventing me from doing my best work. So I don't know, just put an air purifier next to the guy for a hundred bucks and he's more happy and whatever. So it's like those simple things

(13:44-14:04) Sebastian Gerhardt
But then oftentimes it's also bigger things like psychological safety that we see that are blocking people. I remember one guy recently said that he feels like he lacks knowledge of the system and thus is preventing himself from actively taking part in team discussions. So a huge problem.

(14:04-14:33) Sebastian Gerhardt
blocker for for his individual productivity maybe in the end but also for the team right you hire the smartest people you can get to work together and then somebody saying hey i feel like i don't want to contribute because i i have this feeling that i don't know enough and i mean without our survey that wouldn't have been popped up right and person would have stood on the sideline but apparently we have designed our surveys in such a nice way that the person felt i mean was nudged and felt safe enough to to share that

(14:33-14:53) Sebastian Gerhardt
And now the CTO in that case was able to ask, okay, so where do you actually feel that you miss knowledge and how can we help you to get that knowledge fast so that you can contribute, right? So that's on an individual level. And then for on a team level, I think in the last survey that...

(14:53-15:10) Sebastian Gerhardt
The last conversation that I had with one of our customers about the recent survey, they identified two or three key issues. One was that within the new set of features that they had rolled out, they were missing documentation.

(15:11-15:40) Sebastian Gerhardt
And that documentation actually led to a loss of velocity or speed in code reviews because the testers didn't really know how the feature was supposed to work. So they couldn't evaluate whether it actually worked. So then they had to go back to the developers and the PMs who built the feature, creating a lot of overhead and just slowing the whole process down big time. Another topic was related to tech debt.

(15:40-15:46) Sebastian Gerhardt
So they had a substantial amount of tech debt. And...

(15:47-16:16) Sebastian Gerhardt
Yeah, didn't really know how to tackle it or where the biggest problems were. And so they now found a way to spot where the most urgent part of the tech debt was. They created a process now to better track tech debt on a continuous level. And they're now including it into their regular OKRs to ensure the tech debt stays at a certain rate. And yeah, so it's stuff like that. What was the third point they had?

(16:16-16:35) Sebastian Gerhardt
I don't know. But I mean, those are sort of another one was, yeah, no, I remember. So career development was a big one. And that was actually also a fun conversation with the CTO there. So first he said, hey, I actually also wanted to implement a career framework so that I can better put developers into place and, you know,

(16:35-17:01) Sebastian Gerhardt
have a have a proper framework in place but he was a bit anxious because he thought the team wouldn't like being you know clustered more strongly into a framework but then actually the um the feedback from our survey was that uh roughly a third of the engineers were unhappy with not having clear clear career framework and they didn't know what they needed in order to to achieve the next level right so he said hey amazing feedback for me

(17:01-17:21) Sebastian Gerhardt
Now I can actually do what I had intended and I'm sure that the team will perceive it in a positive way because I have now black and white the data and don't have to trust my gut feeling or anything. And then similarly, that company switched to being remote. And so I think it's now one, one and a half years ago that they made the switch.

(17:21-17:34) Sebastian Gerhardt
And now people are starting to say, hey, we're feeling a bit disconnected and that is actually affecting us. And so now they're actively ideating ways on how to get people more engaging despite being remote.

(17:35-18:05) Sebastian Gerhardt
You mentioned two frameworks, Dora and Space. Is it something you're using in your assessment? Tell us, like, what is it? So right now, we don't use any external frameworks. So Space, for example, is just a very high-level framework that actually doesn't give you specific metrics to track. They just tell you, hey, you should track satisfaction of your developers. That's where the S comes from. A is the activity of your developers, for example. So they just give you sort of rough ideas on what you should track.

(18:05-18:09) Sebastian Gerhardt
but then the right metrics to track in the end

(18:09-18:38) Sebastian Gerhardt
There's no real guidance on that besides maybe Dora. And that is actually where the problem comes from and why. There's a big problem in tech that you cannot measure developer productivity properly. There's no trusted approach to do so. Dora maybe is the best or the thing that comes closest. But in the end, it's four metrics. Again, measuring throughput, like the deployment frequency. So how often does the team actually deploy a new code and then

(18:38-19:04) Sebastian Gerhardt
on a quality basis maybe the lead time how how fast um do they go from a comet that they make a code commit to pushing it into production so it's giving you information on speed velocity and maybe the the quality uptime and stuff like this but it doesn't really give you information on a more holistic level so let's say if our lead time now goes up or down

(19:04-19:30) Sebastian Gerhardt
I don't know why that happened, right? So I don't know where to sort of what to tackle in the tech org to actually improve those metrics. And this is why we come in with a more qualitative approach because that actually gives you the context on why things might be good or might not be good. And that actually allows a CTO or an engineering leader to tackle that at that point specifically.

(19:30-19:53) Sebastian Gerhardt
Maybe you could say actually that we have our own framework. It's derived on 46 productivity factors, as mentioned earlier, that we derived from all the studies that are out there. And yeah, 46 might sound like a lot, but we've created a really lightweight survey design where the engineers just really have to tick boxes on whether that specific impact factor is affecting them.

(19:53-20:09) Sebastian Gerhardt
and then in a second step for only the the factors that they seem are important for them or are not going as well in the company we ask them for qualitative feedback and that way we get both a holistic view very quickly on a quantitative level

(20:09-20:38) Sebastian Gerhardt
you know so we can we can tell you based on scores which blockers are most prominent in your company and then for those blockers you would get qualitative feedback from your team on why those are actually yeah why they are impactful right now what specifically is blocking them oftentimes developers already suggest solutions on how you can solve them and then our tool we already we also give them recommendations yeah so so but yeah

(20:38-20:47) Sebastian Gerhardt
We have our own framework in the end. We don't have a fancy name for it yet. And it will probably, we're still adapting it. But this is what it looks like, yeah.

(20:47-21:17) Daria Rudnik
From what you're saying, I hear a lot about communication. Again, understanding goals, communicating the specifications for the feature. It feels like when you have a smaller team, it's easier to communicate and there's less friction in terms of understanding what to do and how to do that. Whereas in the larger organizations, you might have more problems. Do you see that? What's the difference? Do you see if you see any difference between small teams, small organizations, and bigger organizations?

(21:17-21:44) Sebastian Gerhardt
i mean what we see is i mean the the organizational structure obviously affecting affecting our results if we have a small team with six engineers so they're all working together as one product team so they have the same problems right but then if you look at bigger organizations where they have dedicated front and back end devops teams so you have various problems in those teams but then you also have common issues or common

(21:45-22:08) Sebastian Gerhardt
what is the English word now, commonalities across the whole organization. And this is what we see there. We again, maybe the, so you have differences from that point of view, but then if you look at it on a way, how it is handled. So for a bigger organization, like the engineering manager or a director who is overseeing

(22:08-22:33) Sebastian Gerhardt
two teams let's say so he is discussing with these two teams which specific problems they have and how to solve them and then the cto might only look at sort of the high level stuff that is affecting the whole organization and in the smaller organization you know the cto is having his one or two teams so he's looking at do the same stuff that in the bigger corporation maybe the engineering manager or director would look into actually

(22:33-22:57) Daria Rudnik
Besides the organizational structure, we do, as of now, not really see any bigger differences in sort of the issues that pop up. Like you mentioned, there are different types of org structure. There are product teams and there are front-end, back-end teams. Can you see which structure is better for an engineering organization? Do you have anything?

(22:59-23:28) Sebastian Gerhardt
I mean, we don't have hundreds of customers yet to make a valid, to make a resume. But then, I mean, we already see that some companies that have a squad system in our user base are not using the regular structures. But we don't actually have, so I don't have any strong data on saying, hey, we have a belief that this team works better than this. What we see is, though, that there's different cultures in different teams. So the one, the teams where

(23:28-23:57) Sebastian Gerhardt
The CTO is much, much more involved or is having a strong sense for developer experience, for communication, for people leadership. There we see that the feedback that the teams share is much stronger, is more open. People share more personal stuff. So there we can see that the eagerness of the CTO really plays a role in how successful our product is, but also in general, how the communication in the company works.

(23:57-24:07) Daria Rudnik
If you were to say, I don't know, three to five factors of a great developers team, engineering team, what would they be?

(24:08-24:34) Sebastian Gerhardt
what would be the best factors i mean obviously open communication i mean this is why i started the company and what i learned from from my own personal experience and i think open communication i mean it like in every good relationship can can solve everything right so because that helps you to first surface then discuss and resolve the issues so that would be number one number two is obviously having a value-driven or an outcome based approach

(24:34-24:55) Sebastian Gerhardt
So not focusing on just doing the output or doing things, but actually focusing, hey, are we actually doing the right thing or are we building the right thing? Which impact is having or is feature A having over feature B and why should we decide this? Because this also creates much more alignment within the tech team, right? Developers are very prone to

(24:55-25:19) Sebastian Gerhardt
develop stuff that isn't used in the end right and so they have a lot of resentment when they when they're not feeling convinced that the that the features actually will actually be being used to be valuable so that will be that will be something and then obviously the uh in in companies or in our in the companies that use our tool where the cto is in charge of both product and tech and we see that those teams

(25:20-25:47) Sebastian Gerhardt
Yeah, tend to perform better or at least the processes and the communication there is better because otherwise you have that silo, right? Tech is always fighting against product. Product is fighting against tech. And the moment you have aligned leadership on both, you have somebody who can mitigate there and who ensures that the processes there are well interconnected. And that is also a huge success factor. So I think those would be the top three out of my head.

(25:48-26:08) Daria Rudnik
Well, that's, I mean, communication is obviously number one, unless you start talking to each other and telling you what you want and like giving feedback that is developmental feedback that helps people grow and helps organization grow. I mean, developers give feedback to organizations by filling in this survey. So unless you have that, no one, no one is possible.

(26:08-26:28) Sebastian Gerhardt
Exactly. And I mean, you create that the moment you invite people to not only communicate or share feedback, but with their incentive system suddenly is aligned in developer experience compared to other traditional metrics when it comes to the CTO, engineering managers and devs, right? Everybody

(26:28-26:46) Sebastian Gerhardt
So the CTO might want faster delivery, but he can achieve it by unblocking his teams, right? The teams, they want to have a nice working environment. So they are incentivized to share what is blocking them quite naturally, right? And I think this is also something very unique that we experience that isn't there otherwise.

(26:46-27:06) Daria Rudnik
You mentioned there are tensions. There could be tensions between various departments and organization. And if they are working together, it's easy for them to collaborate. But obviously, like engineering units, they communicate with products, finance, sales, with every other team and organization.

(27:06-27:21) Daria Rudnik
How do you see this should be, I don't know, how is your product maybe helping in this cross-functional collaboration? What do you see organizations need to do in order to create this collaboration cross-departments?

(27:21-27:47) Sebastian Gerhardt
I mean, that's more of an organizational, psychological question, maybe. But I mean, coming back to or connecting that to our topic, I think what definitely helps is alignment and clarity of goals, milestones, roadmaps. And I mean, that starts with the CEO understanding, hey, what is the strategy that we want to pursue? Then product, you know, understanding, OK, how can we

(27:47-28:11) Sebastian Gerhardt
from a from a feature from a product perspective best support that strategy what within each feature is actually helping us achieve that strategy be it financially be it retention based and then having a clear understanding and evaluation system that they can then use to to ideate new features talk with with the devs and as i just mentioned

(28:12-28:42) Sebastian Gerhardt
Or for them, it's super important to have clarity on are we actually developing the right thing to achieve our goals? I mean, there's nothing more distracting or annoying than shifting priorities, building a feature that in the end isn't even shipped or isn't even pushed live. So creating alignment between the company goals, the company strategy, and how that drills down into the specific features and also the success metrics of those features. So for example, maybe another example that was quite...

(28:42-29:00) Sebastian Gerhardt
Crazy to read. Within one company, having unreliable success metrics and user feedback was one of the biggest issues. And one developer even said that they had been in his team working on one feature for six to nine months only to realize after it's been shipped,

(29:00-29:26) Sebastian Gerhardt
that it was only built or only ideated around one specific customer and so the whole feature wasn't applicable to all the other customers so they basically just developed something for like an individual feature in over six to nine months right so not only the frustration for the individual developer but also the costs for the for the company and and i think this this perfectly shows how impactful having aligned goals and then a success metrics can be

(29:26-29:56) Sebastian Gerhardt
I mean, it's kind of basic to have aligned goals. And I'm curious why... Everything is basic. Also, collecting feedback from your team sounds super basic. And why would I need a tool for this? But the reality is in daily work, it's super tough to ensure that it actually happens. To stay true to your goals. To have proper requirements. To actually understand what are the success metrics of each specific feature, product. Yeah, you'd be surprised...

(29:56-30:03) Sebastian Gerhardt
About the reality in the trenches. I'm not surprised at all.

(30:03-30:28) Daria Rudnik
I see that. Yeah. But it's great that you have kind of a framework. I mean, it's always easy when you have a framework, when you have certain steps you need to take, because like we all know communication, collaboration, feedback, goal setting, but it's just so huge and vague. But if you have a framework, like 46 aspects that you measure, that's much easier to execute and then act upon the results of the survey. Yeah.

(30:28-30:45) Sebastian Gerhardt
So what's your, what's the plan? What are the plans for FLEA? Yeah, what are your, what's your ambition? Yeah, I mean, what we are really good in right now is surfacing the friction points in tech teams. That is where our customers currently get the most benefit and that they appreciate.

(30:46-31:13) Sebastian Gerhardt
But then surfacing is only maybe a quarter of the real success, right? You can only improve once you put stuff into action, once you implement solutions. And this is where we want to focus on next. And our approach there is to support or to intertwine with existing meeting rituals that happen already in tech teams, right? So maybe, for example, on a more individual level, as I mentioned earlier, the topic...

(31:13-31:30) Sebastian Gerhardt
that popped up with, I don't know, combining private life, the kindergarten situation with work or the one developer saying that he lacks knowledge of the system and thus is hesitant to share individual issues that will pop up like this.

(31:31-31:56) Sebastian Gerhardt
We want to push them into the next one-on-one meeting that the respective developer is having with his CTO or engineering manager so that they can discuss it there. And for more holistic problems like the tech debt or the documentation issue, the plan is to either, you know, with generative AI, create an agenda for a team retro that the team that...

(31:56-32:17) Sebastian Gerhardt
is affected by that issue can talk about it to prepare q a sessions for the cto about the career paths to you know already based on the information that we have on the on the specific company already suggest a career framework and put the employees into place then again push that into a red road to discuss overall push it into into a 101 meeting

(32:17-32:29) Sebastian Gerhardt
to discuss with the individual developer whether they see themselves being put in the right place and what are their career goals actually and how they affect them so yeah making the whole process

(32:29-32:58) Sebastian Gerhardt
or closing the loop from identifying, analyzing, taking action, and then monitoring whether improvements have actually had the success that was wished for. And so far, we're already supporting the 101 workflow. So we have an included 101 tool in our product that is being used really nicely. And then the next steps will be to think about the right methods to tackle the team issues. And then after that, the next step is to also improve

(32:58-33:14) Sebastian Gerhardt
the recommendations that we give. So we already do so in a beta. But then the real goal for us is to have a proper maturity framework where we can say, hey, the level of the level how you measure success metrics at the current state is maybe a

(33:14-33:43) Sebastian Gerhardt
four out of ten so in order to get to a five or to a six out of ten these are the next best steps that similar companies to you or that the the current best practice is on measuring success metrics and that way we can help a company then on a continuous level within their existing mode of work so without super much additional workload to sort of level them up and become an ever better organization so this is kind of what we have in mind for now

(33:43-34:00) Daria Rudnik
Well, that sounds amazing. I mean, you're building the infrastructure for great, creating great cultures, assessment, action steps on individual team and organizational level. Good luck with that. I mean, a lot of work. It will be a lot of work. A lot of work. Yeah, but it's so much fun.

(34:00-34:27) Sebastian Gerhardt
I mean, I recently said to a friend, being an entrepreneur or building a business is 10 times harder than I ever thought it would be. But then when we read the feedback from the team and they actually openly share how they feel about their work, what is blocking them, but also contrary, what is already working really well and just seeing how our product is being used and how much it helps. That's just, it just feels so amazing.

(34:27-34:54) Daria Rudnik
So it's well worth it and makes us excited for what's to come. Cool. So from what I see, the workplace is changing a lot. Like movement, offline, remote, back to offline, hybrid, diverse teams. I mean, economy influences the way we work together. What would you advise to your organizations? How they need to change to be ready for the future of work?

(34:54-35:04) Sebastian Gerhardt
Yeah, I think two things here I would say is, A, moving from top-down monitoring, obviously, to more of an inclusive, bottom-up approach, taking...

(35:05-35:34) Sebastian Gerhardt
Yeah, as I said earlier, right, for me, it is really startling that I hire people, pay them a lot of money, and then I just tell them top down, hey, do stuff like this and this, this is how I measure your performance. But instead, not using the holistic power of that team, make them feel valued, included, have them be part of the solution discussion, and just really create that

(35:34-36:00) Sebastian Gerhardt
Yeah, that teamwork that every company needs to be successful, right? So just making sure that you are a team, that the team is part of the solution. So I think this is a key because we're still in an employee market, I would say, and I think it's not changing anytime soon. And we definitely see the smartest minds leaving companies where they're not hurt, where...

(36:00-36:18) Sebastian Gerhardt
um yeah where they're just used as a as a as a number and not as a for for the intellectual curiosity or power that they have so that that would be number one and maybe also connected to that something that i i read recently in an hr newsletter

(36:18-36:43) Sebastian Gerhardt
is that yeah companies need to shift from sort of a superficial interest in their in their employees so if you look at current engagement surveys they're super high level nothing really happens afterwards it's just sort of a vanity thing so so that management can say hey and we have a survey we listen to you but in the end it just creates much more frustration and so i think

(36:43-37:06) Sebastian Gerhardt
And that was also the resume in that newsletter companies or HR teams need to start honestly or seriously figuring out what their developers or what their teams in general really need in order to do their best work. I mean, it sounds weird to say that this is something where the industry needs to change to because it's like at

(37:06-37:29) Sebastian Gerhardt
it's the most obvious thing i want people that i pay money to to do their best work for me so why the hell do i not focus on making it as easy for them as possible to do so yeah so i think we'll see a change there well yeah let's hope for that you worked like you worked towards that goal i worked towards that goal like we can do that

(37:30-37:52) Daria Rudnik
It can only be better. Yeah. Okay. Well, thank you so much, Sebastian. It's a really interesting conversation. I was really interested to learn about the tool and how you see the future of the work and what it's like, how's it different for developers and that they need kind of different types of assess, different types of surveys to be able to perform better.

(37:53-38:11) Sebastian Gerhardt
100%. I mean, there's such a misconception, right? Everybody says developers are so silent, they're remote, they're always at home, they don't want to communicate. But in the end, you just need to nudge them in the right way and ask them. And they are the most amazing people to work with because they have that...

(38:11-38:37) Sebastian Gerhardt
You know, they have this urge for doing the right thing, for figuring out the truth. And they're just really not heard and they're not asked. And it's just such a waste of potential, both for a company, but also for the individuals. Yeah, anyhow, I'm probably away. How people can find out more about you, about FLEA, where they can find information about you?

(38:37-39:03) Sebastian Gerhardt
Yeah, so I mean, they can check me out on LinkedIn. Just search for Sebastian Gerhardt and FLEA, that is F-L-E-A, or on our website, obviously, HelloFLEA. Yeah, well, there will be a link to your website and your LinkedIn profile down in the bottom of this video. And super happy to chat. We give out free trials. So there's no strings attached opportunity to just try and see whether it works for your team or not.

(39:04-39:13) Daria Rudnik
Oh, cool. They just write you on LinkedIn or through the website or what's... Hit me up and I'll set it up. This has been for you, Tom.