Transcription
Oh, why don't you introduce yourself?
I'm Eigor. I'm co-founder of Kodig and Kodig we're building retrospectives and catalog for product teams, product engineering teams who are building at scale. So when they need to collaborate between 10 to 40 teams, that's what we do.
Great. And I can at least introduce to the audience the way that we got to know each other is we used your tool in the last organization that I worked at. So I also had a nice interaction with you and your company in that time. So yeah, I'm really looking forward to this interview together.
Let's go.
Great. So when you think about your product stakeholders, where do engineering managers sit and what made you recognize them as more than just users?
Well, engineering managers are the primary champions and heroes for us because we treat team as the most important unit in the organization. They are the closest to the product. They have the knowledge. But engineering manager is very special because uh they still are very hands-on. They know what is happening but they have so much business context and they are connected to other teams in the organization. So they are mediators. So for us, if we want to achieve any kind of positive change in the organization, we have to have EM on board and teams with them.
I know that this is not one of the questions that I shared, but I just know it uh from looking at engineering manager positions in different companies. The term engineering manager has a different meaning in so many different organizations. Even when you're applying, you really have to look into those credentials, what they're looking for, because it could be that one really matches you and another one doesn't. Does this affect, let's say, the usability of your tool, having engineering managers as your stakeholders?
I would clarify that usually the difference of the definition is whether you have a very technical background or not. In our case, it's not that important because we will help people learn the technical part. There is no no problem. What the real mission and challenge is is communication between teams, communication within the team and that part should be managed by both people, both people types. Yes.
Nice. And engineering managers, they operate at the intersection typically of delivery people systems where the product manager for example uh figures out what to deliver, the engineering manager makes sure it is deliverable. Um, how do you identify and honor those distinct needs when shaping your product?
Well, we look at this from the following perspective. There are our internal surface, the way we operate, the way what tools we use. It's how and how we deliver stuff and then there is what we deliver to the market, our sales, our uptime and other things like quality. And both two worlds have to be represented. So we make sure that teams have ability to visualize, discuss and track both of these things.
Nice. Nice. And what changed in your product thinking once you started working directly with engineering managers in real environments?
Well, we when we just started, we had a different understanding of of the real problems within the company. But after the real engagement with customers and seeing this in action, we realized that the biggest friction point is cross team collaboration because on the scale of of the team, six people, 10 people, doesn't really matter, it's more or less smooth operations. But when you're trying to build a product at scale and collaborate like 60 CH chefs in the kitchen, that is the real problem. So that changed our product approach. that changed our what we ask people what we try to dig into.
I'm I'm curious what let's say signals did you get that there needed to be a shift or change?
So the way we see it teams are important organism they have highest knowledge they should have highest ownership and autonomy. But for them to get that they really have to own their business outcomes and business context without that there the company will not trust the team enough. So through our interviews we just noticed that there is there is definitely a pain point there that we as proud professionals want to do more in our in our company but we are limited by constraints because there is not enough trust. So we've seen that in repeat calls in repeat interviews and that's that was the signal for us that yes this is definitely the space that we should go into.
Oh nice that you were flexible like that going with the need rather than just the idea. Um, so leadership needs often don't show up as clean feature requests. How do you uncover the real needs beneath what uh for example the engineering managers initially ask for?
Good question. It's for us we see that real pain points people people don't share them because they have fear. They have fear for job security for because these are usually associated with communicating with leadership communicating with leaders from other teams and so on. So there there is a lot of hesitation of sharing this kind of information. But if you're having a real conversation with person be it in a physical meeting or a video call you see that this hesitation and then you see this across all your community. You start digging you understand that this is a repeatable process problem of trust and you start digging with more questions.
And do you notice a difference for example between different cultures and how you would approach them in these rooms trying to dig to those real fears like the approach?
It's in general like engineering culture and product building culture is more or less monolithical in the world but cultural differences are definitely there. for example in what we see in in Europe that people are more hesitant to compare and measure and in US market it's more common that yes it's normal practice that we compare and measure so there are like different approaches to what is accepted norm but the problem is the same for everyone so it's just a matter of how we solve it so the conversations are pretty much similar.
Okay, so it's it's more about having flexibility and how you would show data or show the results that you're gathering.
Yes, it's because when you're having a conversation with uh people, they tend to offer you solutions on how they would solve that. They name the problem and they give you list you like one two three you can do and they reach out for instruments that they're used to like if you're used to solving problems by comparing that's what you suggest. But you don't have to take that and build that immediately. You can listen and you can figure out what the real problem is. Offer a solution that would not be harmful for the culture.
And what patterns or signals help you distinguish between urgency, noise and deeper systematic pain?
Well, community really because if you're only focusing on a single customer on a single culture, then you would not be able to distinct between. And then if you have a larger community of similar companies in our case scaleups and unicorns see that okay uh a person shared a piece of information with us thank you and then we would co-design the solution by going to other companies and digging with the same question. If we see that it's repeatable then it's definitely a systematic issue in our work environment in general.
Yeah, I see that also in engineering solutions. It can be that only one customer has a particular need and if you rush too quickly to develop that, it could go against what all other customers need. So yeah, there there has to be this way of recognizing is this a customer benefit or market benefit overall. And if it's really a special need for one particular customer, you may still decide to develop it, but then you have to uh find a way to present it so that it doesn't affect all other customers.
Exactly.
Did you ever have such a situation?
In the early days when we were only focusing on analytics, we had such cases. But since probably last year when we started getting more and more people to our product, we realized that this is no way for us to build and develop the product. So we mostly avoid these kind of situations without any sacrifices so far.
That's amazing. And actually that's the gen general trend um that I've seen over the years where companies tried to make specific solutions for each customer. In the end it's usually not a cost benefit. It it becomes a problem. So it's nice that you've been able to recognize that so early on. Can you share an example where engineering manager feedback revealed an organizational issue rather than a tooling gap and how you responded to that insight?
Yes, there is a very good example for that. When we started working with scaleups unicorns, you you understand that you want all the teams in the same system because there is an obvious benefit to that because you can see general trends in the organization. What are the general pain points? But people were hesitant to call other teams because they just wanted an account for themselves because of the trust issues. They didn't had enough trust to invite other teams who are the same level as them but it's just like because of unresolved uh tensions. They they were scared that information will be visible to everyone and so on. So this it was a product problem for us that we solved but it was very interesting to discover that this is this was not a direct feedback. This was not a feature request or something like that. You just see behavior of people and then you start questioning why and then you realize that there is a huge problem with trust between different levels and different departments within the same company which is weird because we treated here's your company account. you're the single entity with high trust internally and that's not the case.
Yeah. And I'm curious maybe because I'm always curious about solutions that how did you resolve that particular issue?
So we started focusing on that quite early on because we obviously needed people to call other people's for growth. That's our survival. But yeah solution was fairly straightforward. We create safe spaces for each team inside the team. We have high trust and we see all the data. We see all the notes that we've taken. But between the teams and for leadership we just show things that matter and if we need to show something that was originated from the meeting inside the team then we anonymize it. We show that there is a trend let's say that developers are not happy with CI/CD or they're not happy with tooling. We showed that 10 teams are worried about that and 60 authors mentioned that X times, but you don't need to know who exactly those people are.
Oh yeah, that's I I like that. That does feel more safe. I noticed that also when I'm a facilitating retros that one of the most unsafe things that a scrum master or coach or a facilitator can do is to call out somebody when they have um feedback like I I don't like the way conversations are in the team. Let's say that's the feedback and then the person says oh I see that somebody in the room doesn't like how the conversations are in the team. Who who wrote that? And you can't believe how many times I've seen that happen. and you can see that person's like face like dread either there's silence in the room if you can read people you usually can see who is the person that that wrote that but you also at least I notice is you see a general trend that from that point forward people are less likely to share it's like they start protecting themselves.
It's we as people we so fast to switch into problems solving mode like oh there is a problem let's call it out let's let's solve it but we don't necessarily have the tools not just like software tools but tools as our capacity as humans,
Emotional intelligence.
Emotional intelligence. Thank you. To handle this situation correctly.
Yes.
Absolutely.
And something that is I mean you you you see the facilitator and you see they mean so well, you know, and uh it you just see it crumbling in the room. You're like ah.
So yeah, I've called that out a few times when I've seen it. Not in front of everyone too on the side when when they feel more safe. But um yeah,
You'll teach me how to handle that correctly after interview.
Yeah. So, how do you think about supporting double loop learning? Um, maybe I can explain to the audience what double loop learning is rather than single loop learning. Single loop learning is when you let's say let's say you want to speed up your process of getting ready in the morning. And so you you get up out of bed and you go and brush your teeth and then you go down the stairs and you prepare yourself breakfast and you eat breakfast and then you go upstairs and you get dressed and you're you're going back downstairs to make your lunch etc. And single loop learning would be uh focusing on the single parts of that and being like okay I want to speed up the process so I'm going to use a different type of toothbrush which is faster when I'm brushing my teeth so that I can save a little bit of time. So the whole process is not looked at but single parts of the process. Double loop learning is taking a look at the entire process and thinking maybe there's something not so fast in or maybe maybe I'm wasting time or I'm not doing it in the most effective way. Let's change the process. So instead of going up and down the stairs, how about we do everything that we need up the stairs first and then when we're finished getting dressed and everything, then we go down the stairs. Maybe we have our toothbrush next to the sink downstairs so that when we eat our breakfast, we can brush our teeth immediately and then go out the door and then you actually make big improvements. So that's is the difference between single loop learning and double loop learning for teams. So I'll go back to the question. How do you think about supporting double loop learning where teams don't just improve actions, specific actions and what they're doing in the teams but also question underlying assumptions of let's say the entire process.
Yeah, again good question. Two things. First part, this is zoom in, zoom out. Are you hyper optimizing a tiny bit of the process that doesn't really like not much savings? Zoom out to see the whole picture.
Yes, exactly.
So, and this is very important because teams as founders, they shift so many things in their head like what we're building, who what's the value stream, who are we connected to and so on. So, they need ability to zoom in and out literally. That's why we give them uh tools like catalog so they could actually visualize different parts of their processes or the product that they're building and discuss that. Then there is the question of who has ability to review those things because if uh your processes and metrics are hidden in the office of the CTO then only CTO can review them and contribute to what's actually happening. If you openly share data with your teams, your team members are super smart. You're giving them ability to engage their minds and question like why are we still doing that? This is no longer like we we like this is no longer a priority. We should stop doing that and stop wasting our time because a lot of metrics have limited use. For example, if you're optimizing for deployment time or cycle time, something like this, once you reach a certain point or get an answer, you may stop doing that. Stop stop wasting your time and focus on uh other priorities.
Like the 80% instead of trying to get 100% because that last 20% takes a lot of time.
Yes. Yes. Or maybe we've achieved the purpose of measurement and we should just stop and move on to something else. Yeah.
Yeah. And what I specifically am also thinking in my mind when you talk about the catalog is in many organizations I've worked for especially product companies they split up their product organization in a lot of let's say mini products that support the end customer solution. So you'll have like the the payments part of the product, the advertising part of the product, the customerf facing part of the product. So like all different parts and very often you know teams were very focused on what we do. So you're maybe focused just on payments and not really thinking about the collection part of fintech or something else. And what I find is for upper leaders, it can be very hard sometimes to make those kind of fixes overall, you know, like fixing the entire process because maybe there's something which payments is doing which can solve what other teams are doing or there's something which maybe they don't even need to have one of those subproducts anymore and there should be emerging you know maybe there's a lot of wasted energy or too many people put on something. So there's a lot of things that by zooming out and this I think is what you offer with the catalog and you look at the entire let's say organism rather than just the elemental parts of each quark within the system. You can start to say bust the complexity of the overall organism and how it works. And so I'm curious like how you do that and keep it safe. This is such an important conversation and we should definitely record just another hour podcast just about that.
Yeah.
But in general uh the way we see it is that okay you have a large product with 20 teams building individual parts of it. We are the owners of these 10 elements but we have to be aware of what others are doing. If we're changing API, if we're introducing a new thing like we're doing discounts, how does this affect other teams who are also maybe they have to adjust to our innovation that we're doing? Maybe they have to consume a different service. So this is very important for ability to innovate within your organization and move forward because otherwise you're just in maintenance mode and yeah, I hope I answered your question but.
Yeah, um, kind of well not really it was more about how how does the catalog and maybe it's not the catalog but how how does this element of your solution help let's say top leaders uh in making sure this organ organism is uh working more effectively the the complexity is has been busted out of the system.
Yeah, I think it helps both the leaders and the teams because almost no companies have this visibility. They cannot uh know that we are building six services but nobody knows the complete picture of how it's all inter how teams interact what value streams they they service and so on. So just by giving ability to for each team to add their stuff and connect to to others, you're getting a very valuable information for learning and for thinking about innovation because now now you see it because otherwise you're just doing a heart surgery through a peep hole.
Yeah, exactly. So I I know because I had the the rights of seeing the whole system also. I wasn't just looking inside the individual teams and yeah, it's exactly that you have this overall view of the entire catalog and if maybe you see a lot of repeated parts or things which don't make any sense um it could be a subject for a future retro on the top level if you want to.
Yep. Yeah.
Nice. And what helps prevent retrospective tools from turning into compliance rituals instead of spaces for reflection and growth?
Yeah. Um, thank you for the question.
This is a very important question.
It is and it's what was one of our fundamental design decisions. Retros turn into meaningless rituals only if trust towards the process is lost. And people lose trust when they see that their work, their feedback, their ideas is lost and not tracked and abandoned. then what's the point of me sharing my intellectual work if it's still if it's just going to be waste nothing is changing so why why waste their effort so our job was to provide the teams with absolute guarantee that their contributions will never be lost forgotten or abandoned and if there is progress you'll see it that is our contribution to maintaining the trust towards the process and then the real outcomes of course depend on the quality of the people who participate in the meeting.
I'm really curious because I remember in one of our meetings together um I mentioned how helpful it would be to have the actions for example synced together with Jira and you mentioned that that would be something you would be adding to the tool that we at least could keep track of what we said we would do within our sprint. Did you end up implementing that?
Yes. Yes, we did.
Nice. And do you see it's something that other teams are able to use?
Absolutely. Yeah, this is this is quite popular because some teams see action items as separate from their work tickets and they're okay with storing that in a different system. Okay, that we'll we'll use Kodichi for that. And some just culturally think about their outcomes of their retrospective as part of their work tickets and they want to mix that with Jira. So yeah, it's just catering to different cultures.
Nice. Nice. And um I am also a little bit curious because I am all about diversity inclusion. How do you in these retros support uh different learning styles? You have some people which are more visual, some people that uh need time to prep and read in order to get somewhere. Some people are more action focused. How do you support the different learning styles of people in teams?
Well, first of all, teams we have to admit that teams are under a lot of stress. So, first thing that we need to provide them so they would be able to have a conversation about learning and reflecting is ability to have a little bit of fun and switch to very serious things uh when they need to. So, shifting between fun and reason within seconds. So that that is the core and then yes people do have different learning styles. So if they need to go deeper with data to compare data they're data absolutely datadriven people they can do that they can configure that okay in our team that we're we're using this template and we're able to dig deeper into data. Some people focus more on conversation alone and then they maybe add data to support it. So it's this flexibility to cater for different teams was from day one because we know that okay you have 40 team themes but they're very different. Some focus on platform some teams focus on trust some teams just have different people inside of them and that's why they prefer to have a conversation differently. So yeah no standard even within the single organization.
I remember you provided quite a few templates or even the ability to build own templates because of this and you gave options for people that maybe don't have a lot of experience with retros and don't know where to start. This was helpful. So many teams struggle with the tension between learning and measurement. How do you offer measurability without triggering metric pushing or fear-based behavior?
So metrics are something that exists whether you like it or not. It's just whether you're aware of it. So em are a good example because they have to balance between business outcomes and internal metrics like health check and and how easy it is for developers to push code to production and things like that. So and they have to keep an eye on everything. And if it's up to the team to decide whether we want to measure things or not, we just provide the ability. But in general, we advise team to start discussing their business outcomes and business context along with their health metrics because in the end of the day, the company will be making decisions on your promotions based on those results. And in this situation at least you have control and contribute uh towards a positive result without making the situation really bad. So it's at least having an honest conversation.
Yeah. And as a a leader myself, it helps us to decide where to put our budgets based on what teams are producing more value, what teams are producing less value. also how to switch our team topologies, how to support the team in different ways. It doesn't mean you go in and you micromanage the specific house on how to let's say uh improve team dynamics within each individual team, but you do do need to have some overall information so that you know as a leader where uh more focus needs to be put or less focus or more money or less money or these kind of questions. I think in general things in the current state of the industry people want to have more responsibility and more be more useful. That's just you're a proud engineer, you're a proud designer, you want to do that. And I think having visual metrics and let's say we delivered an experiment, how many signups, how many incidents we had and so on. This is important for our pride but also an opportunity to really improve if if we see that a result that is not satisfying for us. Let's have a conversation about that.
Oh, I absolutely love that. Taking the monkey out of the engineer, they want to succeed as you said and using these metrics to ask better questions so that you have better experiments moving forward is an absolute gold mine to be able to have this ability. Um, what kinds of data do you intentionally not collect because they might undermine psychological safety or distort behavior?
There are so many unhealthy requests that we collect.
Okay, I'm really curious about this one. I This is the the gossip side of me now.
Yeah, it's it's a lot of things to be honest from asks to collect how many lines of code code was was committed. That was a thing a few years ago. Everyone was asking for that. But we we work in this space and we understand that the thing is if you start measuring and you start doing the results on things like that, you get nothing. The outcome of this measurement is nothing. It's bad decisions and if it doesn't solve your problem, why build it? And it can even result in really bad effects because I know from having been an engineer in the past, some of the best code uh has less lines but more thoughtful than code that has I don't know four or five times as much lines but it's just crap. Like half of it you can delete because it's even causing errors or something like this.
Oh, a lot of requests for uh toxic metrics come from leadership frustration with current business outcomes and they're in fear mode and they're just trying to do something and they think more control like very direct control will give them that. But that's not the case. The only long-lasting solution that we've seen is that you transition towards teams that are autonomous with high ownership that are aware of their business outcomes and context. With context, you use the full potential of the person and they can contribute to okay here is really what we can do with with engineering. Here's really what we can do with product. Not just following exact task that was given to you by someone and you don't know the reason why. These kind of teams, fully empowered teams, they can produce the result that leadership needs and then there is no question about control metrics.
Yeah, exactly. And I bet as a business, you need the pockets of the leaders, right? In order to succeed as a business yourself, you must be very good at having courageous conversations with them because you're pushing back and telling them no. Yet, you're also wanting to have their support in continuing to buy your product. How do you have these conversations?
Before starting the startup, I was doing a lot of workshops for consulting and it's really about conversation about what it is that you want, what the end state that you wish to achieve. And once you pivot the conversation from specific ways of solving things into what is the outcome that you're aiming for, then I become that enabled person who can offer you XYZ ways of achieving that result.
Yeah, I've been on the other side of uh people that ask good questions and how they pivot even my own biased thinking towards the actual problem I want to solve. And I have to say it feels so good when somebody asks those kind of questions because it's like, oh, thank you for taking me out of this bias I was getting stuck in and yeah, this is actually the real outcome I want to go towards. So, it's nice that you have had this experience.
Yeah, it helps helps a.
What's the best pivot question?
Pivot question? Let me think. I'll get back to you on this one.
Okay, I'm really curious. I will try not to forget. So, how do you help leaders interpret signals as invitations to curiosity rather than verdicts on performance?
This could be the pivot question. Yeah, a lot of changes in the industry happened that for us to to get here, but essentially metrics are cool, but in no way they should be served as instructions. And this is just a quick way for you to see the overall picture. But the real power is AI and ability to process multiple conversations because teams are so different. They have different purposes. Some teams are there to serve market needs and some teams are there to enable to build trust to build platform and so on. You cannot measure them on single scale but with AI text processing we're able to show trends and dynamics within your your organization that are much more nuanced.
Oh, nice. So you actually use a lot of AI in your in in your product.
Fair amount. Fair amount. Yeah. So then I I know this is not a question that I prepared for before, but as AI is a very important topic for most companies these days, how do you as an organization um take care of AI result quality that it doesn't start to veer off towards not at the beginning when you work with a prompt or something it can be very healthy but then over time it becomes less healthy. And the next question, who is accountable for those results? How do you handle that within your organization? What's the governance around AI and the way that you use it?
So with AI, it's fairly simple for us because the way we use it is very suitable for technology itself. We don't try to push things AI is not capable of. What we need is we need generalization of conversations and it's very good at generalizing. So what we need is just to understand how many how many people have the conversation approximately about this problem. So we can summarize that this is the trend. So that's.
So it's like data matching um counting that type of part of using AI not not necessarily context making or.
We don't try we it's not exactly generative it's the core AI functionality ability to summarize and ability to generalize things and we work with text so it's it it is very easy for us and in terms of accountability and owning the outcomes when we roll this out we try to understand first on our own data sets and so on. Is it producing useful result? Is it actionable? Is it not harmful? So, a lot has went into design of the system prompt and then you continuously check because you.
Yeah. So, you have checks every once in a while to check on the quality that it's still okay.
Yeah. But for us, it's again fairly simple because every time this uh functionality is used, we upload a data set that is custom for this request. here is the conversations that we had in quarter X and use the system prompt to generate a trend report and things like that.
And how do you keep it uh GDPR compliant?
Well, there's a lot goes into that. You have to how you anonymize data, how you handle data, how you transfer it, what vendors do you use, what agreements you have with them because.
AI if you don't check the box, don't use this data for training, it's going to be used for training. And so you have to you have to spend time into understanding how to set it up safely.
And I know that too from myself from the AI solutions I've developed is uh it's really important not to have in the prompts customer information or any anything specific that could identify who this person is and and then it's usually pretty safe.
Yeah. You have to anonymize sanitize the data a lot just to avoid having a very embarrassing conversations later on.
Yeah. Exactly. Nice. Comparing teams through metrics is tempting but also often harmful. Why does it fail so consistently in complex systems?
Complex systems are made of people usually and from our side as vendor it looks like that director of engineering or head of product someone comes in and says I have a problem please give me ability to compare teams and they're talking from their perspective from their background and from the knowledge silo that they operate in and the request that they suggested might be reasonable for them but you have teams as I said who are maybe they're doing features for for the actual users. Maybe they're enabling team that are building the infrastructure or trust or something like this and they have different outcomes and diff different reasons to exist. How do you compare a staff engineer with a front- end engineer like their jobs are different like their outcomes are different and you're asking to rate everyone on the same traffic light? Great. So yeah, this is this is the reason why it usually fails.
Yeah. Yeah, exactly. I once worked for a leader that did this quite consistently but in words like this team is having these results and this team is having these results and so often as a leader myself. I had to remind him that he was comparing on stuff which didn't make any sense because as you said one team is working with maybe more outdated database software maybe another team is um having let's say the latest type of solutions or software but also you have different personalities in the teams. Some teams focus more on um maybe having a campfire fire type of conversations, more experiments, more let's try to break this and fail and learn really fast. And other teams have different ways of measuring and moving forward. So as soon as you start comparing between teams, it creates a kind of like toxic space, you know, like triangulation or something and it's not based on real progress and it can it be very frustrating to be judged in this way. And that's the easiest way to lose most talented people in your organization because there are let's say you have a person in the team who is unofficially a team lead. Nobody has given him permissions. Nobody has that you're a leader. Now he really uh spends a lot of time into helping others. Now in metrics this would look as oh you're underperforming.
Yes.
But you extract that person from the team and the team stops delivering.
Yeah. The way you say this, I love that you recognize this. It's a problem so many managers miss. As I was speaking with Michelle last week in our last podcast, is you can inadvertently remove the glue from your team because you're looking at the wrong thing. You know, it can be this person is making sure everyone else is empowered and learning and and yet they are maybe less self-focused and making sure that they are I don't know showing off or something like this. So they look like they're not that important but by removing them everything collapses.
Yeah. And I think we are getting better at understanding this not just Kodigy but industry as a whole. Uh because technology now allows us as I said AI gives you an understanding of nuanced context more than just numbers which is great. And then you can start looking at social dynamics who interacts with who who and so on. you can start to see those influencers inside your organization.
Yeah, exactly.
Just have more information.
I'm even picturing it because I I'm picturing your solution. Um, there can be people that are maybe involved in many different retros throughout the organization rather than just the ones inside of their team. So you can see that they uh are reaching far beyond the the small uh parts. So it's even something you might see in the tool. In your view, what does meaningful progress look like when comparison is taken off the table?
Good question. So, comparison is a tricky thing because comparing to what? If you're comparing to your past self, then it's an instrument of reflection. It's not exactly a comparison. So, even even if you don't compare teams to each other, because apples and oranges, you can compare to your past self. That's definitely something that is important. So progress is exactly that ability to see yourself in the past and to understand if we have achieved our desired state, are we happy with ourselves?
Yeah, it's it's fairly simple.
Yeah, it's very it's very deep. Learn from your past. Don't be attached to it. Live in the present. But also reflect on it. You may think that by getting that job you will be super happy, but are you actually reflecting on it? Did you get super happy after you got it? So it's nice that that kind of insight is built in the tool. What role does leadership behavior play in whether tools become instruments of learning or control?
Leadership can request control metrics out of fear. So depending on the state of where they are now, whether they had a conversation about what they want to achieve, are they happy with the existing situation, it can be very very negative or very positive of course. But then our job is to make it very hard for leadership to use the information as a punishing tool.
Yeah. So you're more in the prevention of making that possible. Instead of depending on having highquality leaders that can do this already or leveled up leaders, you just make sure with your tool that it's not possible to do this.
Yeah. Essentially, it's translating our conversation into product decisions. What data is visible alongside like do you show the name? Is it anonymized? Can you compare? It's all these decisions piled up into are you able to do destructive actions within within the within the tool. That's one thing. And what actions you promote like what thinking do you promote? Are you thinking more about outcomes and results or specific data points that we don't see the reason why you would need this data point?
Yeah, exactly. So, let's move on. We still have a couple more questions and time is moving, right? So, uh how has collaborating closely with engineering managers shaped your own understanding of responsibility, ownership, and impact as a product leader?
Good one.
Maybe it's helped you within your own organization.
It did. It did because essentially once once we recognized the pattern that majority of teams struggle with ownership autonomy and outcomes because of lack of context we ourselves started practicing more an open approach like what's the situation with business what customers are we getting and so on and what are the challenges so that we as founders would not be the only ones thinking about priorities and possible solutions to the situation. You have smart people let them participate.
Yes.
You'd be surprised.
Yeah, I love that conviction that you have. You hire a whole bunch of smart people, but you don't let them, I don't know, lead the way. It's I find it ridiculous like then why hire smart people, right? So, and I like that you as a company are learning from your own customers. It's a it's kind of this this great loop for yourself to make sure that your product is always better, too. It does feel sometimes very loopy because you're seeing multiple reflections of reflections of reflections and we are building and we are self-reflecting using our own tool and it's just uh Yeah, but it is an interesting experience.
Yeah, I can imagine.
Yeah.
If more product companies treated engineering managers as true stakeholders, what do you think would shift in how teams experience change tooling and trust?
It's treating the team entity as a stakeholder because the way we see it, they have the highest knowledge of the space that they're responsible for. They're smart. They have all the cross functional abilities to build and deliver things. And if they would be given trusted with business context and outcomes, then we would just have faster uh and more adaptive organizations. and uh it just would run way smoother and we would have way more business success.
And how do you hope your product contributes to healthier learning cultures, not just faster delivery?
Well, I think it's all about business and faster delivery is nothing bad. It's fine, but there are different modes, different modes that we go through. Sometimes we really need to deliver something fast. Sometimes we have to go back, stabilize, patch things up and reflect. Ability to go between different modes is a decision that you base on data that you have where we are at in our journey. Have we achieved our goal? Is it now time to stabilize and patch things up? Do we see indication of our business performance that require our attention elsewhere? It's as I said speed and desire for speed is nothing inherently bad about it. It depends on whether you're able to shift to a different mode when you need to.
So healthy culture is being able to switch between different modes.
I would say that.
I love that. That's one of my favorite answers. So last question. If your product had an inner dragon, we have to talk about dragons, right? If if I'm in the room, what would it protect teams from and what courage would it help them reclaim?
A very good question. I would say that it's all about ownership and autonomy. Ability for individual professionals who are assembled into a team to contribute more than just uh completing tasks that they were given to explore options of how they can achieve the result. So empowering that is our mission.