Building software factories and making the transition from a pre-AI to post-AI world as a large company w/ Zohar Einy #271

The best way to build a company that can go, go, and run fast is to believe in people with very high potential. So this is an element of our hiring process. And it's not just about age. It's also people that had a specific career transition or career process. And now they want to take another step and they want to pivot their career. You give them a chance to recognize their potential. I love to give them the chance because it's a win-win. They are excited about it and it's a win-win for us. Hello and welcome to the Engineering Leadership Podcast, brought to you by ELC, the Engineering Leadership Community. I'm Jeremy, founder of ELC, and I'm Patrick Gallagher, and we're your host. Our show shares the most critical perspectives, habits, and examples of great software engineering leaders to help evolve leadership in the tech industry. So far, welcome to our show. I was really looking for this day to hear from you face-to-face about your perspectives and your experience in the world of software building. Can you tell us more about who you are and your past experience? Yeah, first of all, first of all, thank you for having me. I'm excited to be here in San Francisco in this beautiful office. So I started my journey as a software developer and a researcher. Before I was a thing, I spent most of my time mainly in the cybersecurity cyber security area. Thereafter, I spent time in the venture capital as an investor. I joined one of the portfolio companies as one of their first employees. I wanted to get the look and feel of a startup, which was really exciting. The company got acquired to Dynatrice. Port is my second company. The first company I started called the Aporia, which got acquired to Coralogix. And we started port around five years ago, and yeah, super exciting. And I love everything about developers and their experience. Five years can mean a long time, especially in the past to us three years. But everything is so accelerated. What is your biggest focus right now? You're a building and company. Five years old, I'm sure you have customers to support. Finding a way to get adapted to this world of AI, especially how repollation is the way of software engineering. So maybe you can tell us more about port, what does it do, and what's your current focus right now? So my biggest focus right now is actually right before I came to meet you. There was like a big, big noise about the software factories on X and on LinkedIn. And now Gardner also published a new category. So right now my biggest focus is to build this category and to work with the industry towards software factories. So this is my primary focus right now as this category is starting. There is a lot of conversation about software factories, but there is still a lot of open questions about what it is. Software factories in simple words means we are moving from an era where we are using AI as a coding assistant. And starting to use AI as an engineering led methodology where AI is taking all the work across the SDLC. And the humans are operating it and working alongside it and not as a coding assistant. So eventually I think it's the moment where all the industry waited for right where AI is taking the lead and we are managing it. How does that mean differently today for people building software for engineers, for product managers? I think that for couple of months or like maybe more than one year, the industry was all about, okay, developers are now going to be the operators, approving, declining, be a human in the loop. But we believe that the new role of engineering will be maybe 10% of that. 90% of their time will be building the factory. It means building the system that writes the features and not writing the features on their own. What does it mean? It means that they need to be very good data engineers. They need to understand how to architect context. They need to measure the quality of the factory. They need to be able to set the right guardrails. They need to be really software factor engineers rather than just writing the features themselves. Well, that's fascinating. So you take away what an engineer used to focus most of our time like writing software or writing code. Now they are focused as an engineer who has been most of the time building the so-called factory. How do decompose the factory into a stream of works that engineers should start going out? The way we think about the factory and actually when we wanted to understand ourselves at port, we actually went to do a real tour in a real factory to get inspired by what it includes. So we imagine that the software factory, just like any factory would have workers, would have machines, would have work manager, would have some analyst to see what is the efficiency of the factory, would have also trucks to ship the factory. So what does it mean for software factories? It means that the workers themselves are the agents. They are the ones writing the code, reviewing, deploying, driving the trucks to deliver the software. They are the workers of the factory. The machines are all the tools that you are already using, the CI/CD, the observability tools, GitProvider, these are the machines. So we have the tools, the workers, then we have the managers. Now these are the humans, right, like the engineering themselves looking across the factory, making sure that everything operates as they would expect, giving some comments to the workers, and then you have the factory manager, the one that is looking at a bird's eye view of all the factory operations. These are the VPR and these, the CTOs, getting the visibility on top of all the factory itself. And yeah, I would visually imagine the factory. It's the same. They did it before us. All the traditional industries figured it out before software industry did. How does the impact, how organizations are organized? So team structure, for example. So we are seeing a couple of models. The one that is gaining more traction is you'd have the DevOps team. They are super critical in this era. We can talk a little bit about it. But they are the foundation, they are the prerequisite for your software factory. Then you have the engineering team. And in the middle, you have the platform engineering team to basically give the engineers the tooling to build the factory and making sure that those tooling are well connected to the DevOps tools. The platform engineering team will own the context lake, will own the workflows, tools, will own the guardrails and they will make sure that the developers are using it correctly. So they will be the providers of the factory foundation. And they will work with all the tools that DevOps are responsible for. So you have DevOps developers and in the middle you have platform engineering team that are responsible and own the factory platform. You mentioned a few examples of what the platform and engineering team are going to provide for the actual developers. The data lake context layer, what data goes to that context lake. Yeah, so eventually what goes into the context lake is the semantic of the engineering organization. So for example, all your microservices, what's their names, who owns them, who is on call right now, where they deployed. Think about the tribal knowledge that goes through in the engineering organization. You need to teach the agents how you speak and what do you mean by a microservice? Why do you mean by an environment? An environment can be name specific Kubernetes or it can be a VM, right? Like you need to teach them what it is. So eventually it will have all your, all the semantic layer of the engineering. So when you ask an agent a question like who is on call right now for a particular service, they would know exactly what you mean because they speak the language of your organization. Otherwise, they will guess and they will often get it wrong. So this would be the first, this is the bare metal, like this is the first place where organizations start. Then the second part is managing all the skills and agents and tools in one place on the plugins. So what happens at scale is that developers are starting to create their own skills. At the beginning, it's nice. They share on select the files or put it on a Git repo. But very quickly the organization start to have a skill sprawl and agents sprawl and duplications of work and inconsistent standards across them. To be able to scale the factory, you also need to maintain a unified registry of all those assets and making sure that there is an owner to it, making sure that it's meeting your minimum requirements for a production ready skill, production ready agent, making sure that it's audited. And that whenever someone is using this skill, you see the usage. And so this is also important to scale the factory itself. And this is why companies are creating this marketplace of collaboration and certification for those assets. You mentioned certification. So what does the certification mean in that context? Yeah, so imagine that in your organization, you want to define minimum requirements for a production ready skill. So basic example, every skill must have an owner. If you don't have an owner, human owner assigned to it, it's not ready for use. Not because the skill is not good, just because when something goes wrong, you need a lineage of accountability. This would be an example of a self-defying a skill from an ownership perspective. It can also be the way you structure the skill itself. How do you structure skills according to your standards? So you'd want to write a set of rules that are relevant to your organization. So you know that every skill loaded to any agent or any developer's machine, it's signed by your minimum requirements. We had a context like we had the agents here as an MCP registry, then we have the human in the loop element. When you start building the factory at the beginning, you can put the human in the loop before it goes to production, right? Or to put the human in the loop to review the code. But you can put human review on every flow, right? Because when you scale it across thousands of agents on thousands of engineers, you very quickly end up in a bottleneck. And we see those PR gems in companies that are trying to understand, yeah, we're using AI, but now we're still moving at the speed of human because we have PR gems. I'm afraid to click approve without, you know, without reading the code. So I don't think that they need to read all the code and review all the PRs, but they also don't need to, you know, not review it. The truth is, some. somewhere in the middle. The way to overcome the PR gems is to always comes down to the business impact. You should prioritize or define human in the loop when the risk is high. So how do you decide whether it requires a human in the loop or not? For example, if the pull request is touching a microservice that is marked as tier one, you would not want it to be down. So if it's a pull request that is touching a sensitive code area in your tier one service, you're in the loop. But if you're changing the title of your email in the email service, we can trust AI to do that. And it goes back to the context like, right? Because once you have the context, you can make risk-based decision because it has the lineage of your services and your customers and your products, and only you know what business criticality means for you. But the agents won't understand at all unless you tell them. Any best practices or common pitfalls that our audience trying to figure out how to scale our teams through agents, what this should be aware of. The first element that is important is not trying to build all the factory at once. Because the factory goes back to Agile, it's all the same principles that needs to apply today. We need to be agile. We cannot do it in a waterfall. So when you start to scale your AI's of the factory and taking more AI-led workflows, choose a very specific flow. It can be a very specific label in your Gira, just the bugs that are small bugs that are coming from customers that narrow it down to something very specific and scale this type of work slowly. When you get it right, start and add more types of work to the factory, managing incidents autonomously, fixing vulnerabilities autonomously, taking bigger features autonomously, but starts more. For two reasons, one, learn the technology, like learn how it works, but also, and even more important, because we need to build trust in the organization. We need to show people it's working, and we need to give people the excitement to go and build more flows in the factory. Many times it can sound like science fiction at this point, and people are a little bit, you know, some are big believers, some are not, and you need to prove it. You need to show it's working. So start small. This would be my main tip for what time thing is working. The second tip is we see usually companies are rushing to implement even if they are starting small, but they think about functionality. They don't think about how to make sure they meet their standards at scale. They don't think about scale from day one necessarily, and it's because usually it's starting from the engineering. Imagine you're super style engineer. They probably are the ones that started to build an initial flow, and it looks amazing, but individual contributors will probably not start with making sure that it meets your standards around security, compliance about the standard that you have internally. The things that are, you know, the boring things, but the important things. So the tip is not to do it as an afterthought. To think from day one, how do you make sure that standards and production readiness is infused from day one in everything that you build in the factory? Because otherwise, you need to go back to the beginning and rebuild it from scratch. This is another overlooked element of scaling a factory, and you hit this wall very quickly. What does mean to go back and rebuild everything? Building it from scratch means that if you started to build without keeping standards and production readiness in mind from day one, it will require you to build it again, because you did not embed standards and production readiness element into the flow itself. Usually, developers would build and all the standards will be an afterthought, and it's very hard to add visibility, to add a certification, to add accountability after you already built the flows in the factory. And it's because developers are building, and then you need to chase them. You want to be in a position where they build, but they are building with your platform. Yeah, you have fuckin' show, you know, there's nothing that could not go wrong, and that confidence is really important. Exactly, so that means you may start slow. Yeah, the faster option is not necessarily scaling. You need to architect a platform that you give developers to build, but you get the visibility, you get the control, you can set permissions, you can set the gadgets for them. Rebuilding from scratch is rethinking how you approach stuff of factories, and how do you stay in control as developers are running fast, because you cannot catch them. They are too fast now with AI. Right. It sounds like there could be multiple factories in the organization. In the organization. Correct. What does the example of, in what case is it qualifies to have a factory? What's that? What are boundaries between factories, different teams, or different services? If we think about large companies, they have different business domains. Every business domain will have their own factory, just because they operate like as different organizations. Like a company versus sales. Those are two different domains. Even one step higher, which is like an entire business domain that includes its own sales, agile, engineering, for the large, the Fortune 500 companies. They have companies within them. So each one would have their own factory internally. Different teams might have different factories as well, but they would often work out of the same foundation, the same context lake, and they will enrich it to their semantic, and they will add on top of a shared language. But you do want to give them the ability to branch from your core factory, because they have different requirements, they have different flows, they deliver software in a unique way. So for a business unit, you will have the core platform, the core foundation, and on top of that, you can have a few factories and a few flows. And that's fine. You have different needs. Right. So for example, the company-wide factory may be talking about the culture of the company and mission, and things that can help make decisions very high level. If you go to the even departments, then it becomes more specific. And then your culture could be not entirely the same as the company culture. There's some more specific to engineering, even though it inherited the kind of higher level culture that there's an alignment, but there is also more specific. So we can have building that on top of the more foundation layers. And how is the factory in place? So their company are starting fresh so they can start building new factories as the companies start to grow. That's easier, but for large, established companies where there's a lot of tribal knowledge, there are a lot of cultures, norms, and so you mentioned it starts small. So do you have examples for those large companies, how the transition from pre-AI to post-AI world? Yeah, you know, surprisingly the large companies are the ones that are prioritizing even higher than the smaller companies and take it very, very seriously. They identify the champions that they would like to start with internally, they distinguish them engineers and those ninjas that are the influencers internally, they will build with them. They would also make them out of the project. They would make them excited about owning it. And this is how we see the fly will affect once they are successful with the small group, but it would it's a it's a top-down project for the large companies. They are moving pretty quickly on adopting it and promoting it internally, but it's a process, it's not in one day, it takes time. Yeah, we had a conversation with many and your leader at a different company of different sizes, like job box or talk with signs. So every company, clearly there's common theme in terms of the flow and the steps, but every company will have something very specific. So sharing that is also just another validation. Every company is a snowflake, right? Every company will have a different factory. And it's important that the company will not be locked to the way the factory is built. They need to be able to architect their factory to their needs and to their DNA. And you started building port before AI, agenda coding existed. I guess you are rebuilding it now or has been rebuilding it with AI. So maybe use your company as example in terms of illustrating how that transition works. How did it work in the past and how do you navigate your team through that transition? So as a company, we were really lucky to see a transformation of our product and the way that our customers are utilizing it. If we go up, step back into the history where we had the DevOps evolution, it created a lot of cognitive load on engineering, being able to fund the way around with so many tools and so many moving parts, like Kubernetes and Teleform and CI/CD and then platform engineering emerged to consolidate and create standardization for developers. And it rings a bell because it's the same thing that agents need now, they need standardization and they need a one place to operate from. So around one year ago, we figured out not ourselves by the way, by our customers that our tool is no longer being used by the developers, it is being used by agents. And when we realized it, both me and Jonathan is my co-founder and the CTO, we understand that we need to evolve the company and evolve the product to a new era where we are no longer solving the cognitive load and standardization problem of the developers, we are solving it for the agents. It takes time to explain to everyone where the world is going and to educate everyone because we are already near 300 people and we are growing very fast. So that was one year ago, 300 people. Yeah, we were 200 people around one year ago and we understand that to really show the company where the world is going and to have everyone seeing the future, we need to repeat it a couple of times. We need to say it in every all-hands, in every company meeting, in every monthly, in every opportunity that we have to educate and to explain where the world is going. And in the past, the pace of change was was normal. Now the pace of change is so high. So you need to teach and to iterate things couple of times very, very fast. And the people in the company also started to pick up things so much faster. And they came so curious about every new innovation, every new technology. So I think this is something that really helped us to make the transition is to have a very efficient way to have everyone aligned on every new innovation and every new decision that we are making as a company. It's something that was very different from more than one year ago. Was it because of reaction when they first heard of the new direction? The first reaction was excitement and confusion at the same time because it makes sense. But what does it mean? What do we have to do now? How do we translate it into action items? So everyone understands that this is where the world is going and they understand how we are positioned to be the system of record and system of action for agents. But we are doing a preemptive on the market. So now, when we see everyone are talking about software factories, it makes sense. But when you as a startup company and as a company in general, you have to make preemptives. You have to take risk. You have to operate two steps into the future or three steps into the future to make sure that you are not losing the market. Yeah. So you have to because of the technology, the markets and they are so fast. So you need to be able to have more in-depth insights so that you can kind of predict in the trend. So getting the team ready before the reality hits. Yeah. If you are not afraid about the decisions that you are making, it means that you are making them too late in my opinion. So it's a compass that within myself that I'm looking for excitement and a little bit of fear when we take decisions because it means that we are leading the market and we are not following the market. And it's been the state of mind from day one for us. There are more decisions like that. A moment like that where you feel the fear of making decisions. Every day, really every day, from the product decisions to the way that we choose the messaging, to the way that we are hiring, we are managing risk all the time. What that's true? The way you approach hiring, the way you approach other components of other parts of the company makes you feel scared. Port is a relatively young company in terms of the average age. And we believe that the best way to build a company that can go, go, and run fast is to believe in people with very high potential. So this is part of the core of our hiring process. And you give them a chance to recognize their potential. But it means higher risk because you invest. How do you, if I may go specifically on that, maybe there are often times we heard the question about in this very eye, what top talent really means? What kind of talent do we need? So in your case, you're being audacious to higher, high potential, hungry young people. What has been working well so far? You found to generalize, those are the traits of the new way the talent looks like that we need to optimize for. So first is go-go-go. We want things to be shipped now. The time between a decision and having it running in production should be very quick. It's a personality. It's a people's personality, be a go-go-go person versus taking it a little bit more time. We don't have time. We need to run super fast. And people that are excited about delivering and about shipping, it's something that we look for, this hunger and relentless people. Yeah, recognizing this is probably the best time of the world to be a beater. Yeah. So if I talk to someone and then it doesn't let me finish the sentence because it's like, you already want to continue. So I love it. This is the type of things that I love. The second thing is direct people. Being direct is a big part of what we are looking for because we need to understand quickly what's not working and put it on the table and making sure that we can switch and change and let's focus on the work. Let's talk about the other things. Yeah, let's move as fast as possible. Let's be direct. Tell us what's not working. That's fine. I have people reaching out to me can be a nice in the company, a developer, someone from support, from a job. This is not working well. We need to fix it. This type of types of things I would look for. And the last thing is looking things from another angle. Like we would always challenge the playbook on. For example, how does the first day looks like for you in the company? So the traditional playbook is, I have my computer. I have some welcome card. How can we change the way it's working and do it in a different way? It goes back to the product, to our marketing side, to everything that we do. I think that there is so much place to innovation because most of the things are pretty boring. So I would like to see how can we add spice to it? How can we make it more exciting and different and create it and experience for people? That's very spicy. But in fact, another thing you mentioned, I did wear an area where a bit scared making decision is around products. What does through me want to product decisions that they feel at the moment scared to make? So imagine that both, we have hundreds of customers already and big enterprise companies that are using both. And when you are starting to build your product towards AI, you need to run extremely fast. So striking the balance between supporting the features for your existing product versus evolving them to the future was a big decision that we've made. So we were pretty open about it with everyone saying like, we are evolving the product and we need to invest in those areas for innovation. I was maybe like not afraid, but kind of cautious on the reaction. But actually we got the opposite one. We got it like, yes, like this is exactly what we want you to do because we support you and we need you to be the most innovative product in our tool set because you are mission critical for us. So it's very innovative. Well, we even miss some of the largest companies in the world. We think that they want stability, but actually they want innovation when it being disruptive. Yes. And I was surprised by it because they have a big company, but they want to be the forefront. Yeah. So one thing I want to share my personal experience is a lot of those cars, large companies. The fact they are number one on their big. They are trying to hold onto the number one spot. By doing that, it would be innovative. They have more to lose by not even innovating. I guess that's probably something ties to the fact that they're more open to experiments and new things and new tools. Yeah. I'm meeting CIOs from 100 companies. And you know, I remember that the meeting CIOs when we started the company, you know, they were very cautious. They are being pitched a lot. And now they are like seed stage entrepreneurs. Tell me what you have. Like I want to learn. I want to understand like it's different. And they are also became builders. They understand that. Yeah. That's why again, going back to the point that right now is the probably the best time to build. Yes. Because we are willing to make a change. They are willing for change to happen. And then that's why a lot of AI companies, this is how they were able to scale their revenue really fast. Because enterprise, which typically means 12 to 18 months of the old cycle, not being compressed to a very short amount of time. Anything you have done wrong in that transition, what advice do you give to our audience? I tried to shift all the company at once, back to the tip about being agile about 200 people a year ago. Now, okay. So everyone wants to be there. But moving to 100 people at once, it's not easy because there are many people, many processes. So what we did to fix it, we did pretty quickly is taking it as task force. Internally, we built a mini company within the company, built from like a full-step company, sales engineers, product, working together as a task force. There were a port 2.0. And then they started to move extremely fast together, working with me and Jonathan a few meetings every week. Very quickly when we did a few first cracks, after just a few months, we started to bring more people in to the company, like a black hole, and then all the company made the transition. So for me, it was a big lesson. What's the use case for that first experiment, like the factory, the first factory? Do you pick a scenario, do you pick a workflow, do you pick a, you know, a product area? So we started with the customer meetings. We took our most innovative companies, before we touched the product, we started to like do some research. And then we tried to identify like the MVP for a workflow in the factory. And it all came back to the context like, which is the foundation for the factory. So this is where we started when we, when we evolved the product towards a software factory platform. This was the first thing, but it's everything from sales deck, discovery, playbooks, everything was really written in a few months. Now, companies have kind of figured out how to start small building factories, and things that are more autonomous, agents are getting more involved in a software development life cycle. But how do you measure the ROI? Are we really creating more value for the company? Are we really creating more value for the customers? Since it's still early days and then maybe by the time we published the episode, things will change. But I think that the value and the ROI of the software factory is given. If we have a software that operates at scale, it's clear that we, that we will see productivity gains. And I think that we are not still yet there. Only a very few companies running AI at scale. But I think that what we should start measuring before we measure the full ROI is quality and efficiency of the workflows of the factory. So by quality, I mean, I mean like what would be the change failure rate for fully led AI led decisions were made. Did it impact MTTR or even NPS core from developers about autosanalysis report that I generated. So to start with like input KPIs or proxy metrics to quality and also to efficiency. And by efficiency, I mean the cost with respect to the quality. And to measure what is the average cost of a bug to get from ticket to production. And then to see how can you optimize the quality and the cost with one another. And then I would say you can measure the ROI because the ROI is like a big jump. And I would start by measuring quality and efficiency metrics in the factory at the beginning. - It's a more practical approach. - Yeah, there is like the metric of when a new developer is onboarded, the time to 10 PR. So for an agent I would like to see the quality of the of 10 PRs, right? So I would think about quality metrics to see, okay, if I get out of 100 tickets, I get one ticket cost the whole back. Am I ready to scale it to 1,000? To 10,000? It's a matter of like what is blocking you to scale from a quality and efficiency perspective. And then when you get there, you can go and measure the ROI when you have a good enough scalable factory. - And then for true company, after the early experiment and validation of software factories has been established, how they should think about resource allocation. Like platforming, you mentioned there's DevOps and there's the platforming team, there's the actual builders built into products. So once the factory has been established, where do you deploy resources? Like you didn't plan for like, now we're getting to Q4, 226. When you do a planning for 227, like think about high counts, where do you put resources? - So I think that we need even more engineers than ever in experienced ones because as an engineer to build a software factory, you need to really understand all the architecture, all the components, you need to be critic about the decisions of AI and to know what to optimize by being a contrarian to the decisions made by AI, you need to be a data engineer, you need to be an architect, you need to be security engineer, you need to be basically a lot of things because you are building the operating system of your software delivery. So I think that you need highly skilled people that are all around players to build a factory, and I think that you would need to also have highly experienced engineers that can be the operators of the factory, the ones that are poor decline and are the human in the loop, because now every review by the human is not a PR, they will review 100 PRs that represent one change, and they need to understand what services are impacted, what did it change? Did it change the right configuration file? The base configuration file or it changed all the config files that are overriding the base config file? You need to understand how configuration management works and you need to understand how your code base and how your architecture operates to be able to put comments on big changes made by AI, because they are changing a lot every task. - Where do you find those world-rounded talent that feel like impossible to find? - I think every company has those all-rounders, and I think that companies should use those all-rounders to train more all-rounders with them, and I think that the salaries are going to go much higher to get those people, they are highly skilled people. - They are out. - And so these are where you find them. It's hard, they need to be really skilled and have a lot of verticals in their knowledge, but we'll have a major problem and challenge to find this kind of talent. - Yeah, because the young people as you mentioned, need to have experience, but to have experience need to have opportunity to work for someone, right? Yeah, yeah. Before we wrap up, I hear almost contradictory insights from in terms of how we look at talent. On one side, you mentioned your buys for those young talent and they're hungry, they want to move fast and they're passionate. And on one side to be able to build a software factory, you need to have the well-rounded scouts as you have that established experience. Does that come flexing to each other? - It does, and I think that when I say people that are like, you know, like to move fast and they're like, "Go, go, go." Those people, when they will understand or when they will come across the need to go deeper, they will go deeper and they will learn the internals of the bare metal. And I think that with the transition to a software factory, they will understand that they will need to go deep and learn it because they will not be able to achieve their goals if they will not do that. So I think that there is some conflict because those people that are like moving fast and we see this type of talent, usually they have the tendency to skip the depth and to run fast and this is a quality. But I think as the role of engineering is now being shaped around the software factories and building the software factories, they will realize that they will have to learn and go deeper and to be more critique and to understand the wider picture. And they will do that because they will want to deliver fast and they will understand that they need to go deeper on their skills or understanding the architecture, data modeling, everything around it and they will do it fast. - As long as you have someone more experienced or guide and to coach. - Yeah, the more experienced person needs to be an enabler. We cannot stop them, this will be a disaster. They need to give them the knowledge and to help them move fast and to be an enabler and to trust them as well. So both sides will need to make the shift one towards another. - That's all my questions. Now let's go through our rapid-fire questions. What are the things you are reading all this year right now? - So now I'm reading a book called "The Cell Speech" by April Danford. I really like the way she articulates thinking about how to sell your product but as a plastic advisor, not creating a cell speech but rather a buyer's guide to help your customers make a decision for themselves and not pitching them your product. I really like it because it's value-first. - What is a tool of framework that has a big impact on you? - So the start with the why is a big one. I keep memorizing it. Sometimes I forget, but I meet this methodology and everything that I do even when I'm in the Netherlands with all the company, when I'm writing an email. I'm always focusing on starting with the why. - Is there a trend that you were seeing that has not hit a mainstream yet? - Before today, I would say a sort of factor is, but as I came to this interview with everything like it's going on in the past few days, it's crazy. And now the time for a trend to a mainstream is so small. So this is the trend time thing that there are no trends almost. - That's very matter. - Yeah. - Last one. What is a coat or mantra do you leave by? - There is a one mantra that says success breeds complacency and complacency breeds failure only the paranoid survive. So I'm really always paranoid even if I sit in the board meeting with our board members and really like the company is doing very well and everyone are happy. I'm not happy. I'm always thinking about, okay, what could go wrong? What are we not seeing where the market is going? Are we hiring the right people? Like always, always paranoid and it keeps us sharp. Like making effort to do that or it's just natural. - Unfortunately, natural. - Great. Well, that's our conversation today and thanks so much for joining us and really enjoyed our conversation. I learned a lot about self-reflecturing and how to build one and how a company transition from pre-AI world to a post-AI company. We're having you, thanks for joining us today. - Yeah, thank you so much. - If you're listening to this and you're wondering, how can I connect with other engineering leaders in my city, pull up your phone right now and go to ELC.community, click our chapters page. You can see that on the menu on the left. Find your local chapter and click join. We're hosting virtual and in-person events all the time and this is the best way to help you get involved, expand your network in your city and support your leadership and career growth. So pull up your phone, head to ELC.community, join your local chapter and get involved. A huge thank you to all of our local leaders who made community happen and thank you for listening to the engineering leadership podcast. (upbeat music)