“I don't think we can go to another year where people or engineering leaders are saying to themselves, ‘Maybe I can get along without measuring.’ You can't optimize what you're not measuring

2025 will test every assumption about how engineering teams work.

With the new year fast approaching Ori Keren, CEO of LinearB, has some bold predictions that might surprise you, like why developer productivity could actually go down in 2025.

Yep, you read that right.

As AI tools flood the market, we might see a dip in both productivity and creativity before the long-term benefits kick in. It’s a wake-up call for engineering leaders to rethink how they lead their teams.

Ori dives into the trends that’ll dominate:

  • AI’s rise
  • the ever-growing need for cybersecurity
  • how DevEx and developer productivity are heading for a showdown

His advice? Stop flying blind. “You can’t optimize what you don’t measure,” he says.

If you’re leading an engineering org, this episode is your 2025 game plan: a mix of data-driven decision-making and people-first strategies to stay ahead in a year of change. Don’t miss this insightful fusion of qual and quant.

Show Notes:

Transcript

Ben Lloyd Pearson: 0:07

Hey everyone, I'm your host, Ben Lloyd Pearson, and today I am delighted to be joined by Ori Keren, co founder and CEO at LinearB. Thanks for joining us today, Ori.

Ori Keren: 0:18

Hi Ben, it's great to be here. Thanks for having me.

Ben Lloyd Pearson: 0:21

Ori, as always, it's really great to have you on our show. and Andrew, I want to welcome you to your first ever episode of Dev Interrupted.

Andrew Zigler: 0:28

Thank you, Ben. I'm really excited to be here.

Ben Lloyd Pearson: 0:30

We've actually dedicated some time next week to introduce yourself to our audience. So, definitely want everyone to tune in next week to wrap up our season with us and get to learn about who Andrew is and what role he's going to play in Dev Interrupted moving forward. but today I want to focus on what we've come here to talk to Ori about, and that is predictions for the year 2025. we're rapidly approaching the end of the year, and, you know, as we reflect back on all the things that have happened here in 2024, figured this would be a good time to start thinking about what What do you think software engineering is going to look like in 2025? So just at a high level, Ori, like tell us, what do you think are some of the biggest trends that you see shaping software engineering in 2025?

Ori Keren: 1:14

Yeah, sure, so I'm going to surprise you and start with AI, which I think is like the biggest trend, that everybody's trying to wrap their head around. How, how will it look? I think in two kind of separate tracks. There's one, where, uh, You know, all the IDEs and the place where you get assistance, where it's not still like agentic, it's not an agent. I think these technologies will mature. We can speak later on like who's more benefiting from, from them and like has a better match like to utilize them. But, you know, as we spoke to leaders this year, It was hard for them still to, quantify, if they get productivity gain from this, and what is it exactly? And it seems like it's in early adoption. I predict that 2025, these technologies will mature and will become more, ingrained into, like, the day to day of, a lot of the developers. By the way, I think mainly, junior developers, but not only. And then you have the other side of all the agentic AI and AI agents that, can pop in and take JIRA ticket and issue a pull request based on JIRA ticket and all that. I think this, it's almost like in, phase before. This will be experimentation year for these type of things. There's a lot of like obstacles still like to overcome in order to embed this thing. So my prediction is that it's gonna be an interesting year with AI agents in SDLC, but it's still be more of experimentation this year.

Ben Lloyd Pearson: 2:46

Yeah, you know, honestly, I don't think we can get through an episode anymore without talking about AI because I mean, it truly is like dramatically changing everything we know about how you know, and it's not just software developers that are feeling this impact. I feel like it's, it's all people who do, informational work. You know, we're all being impacted by this. It's just like software developers seem to be one of the first big waves that it's really becoming mainstream and taking off. that's probably going to have a big impact on engineering organizations in this next year. do you think today is when they're going to start seeing like those huge impacts, or do you still think there are other tools out there that engineering teams, should be looking to adopt over the next year?

Ori Keren: 3:28

You're asking if there are more, like, technologies and more trends that will be, like, impactful in 2025, or is it still Let's talk specifically about AI.

Ben Lloyd Pearson: 3:36

like what tools are going to have the biggest impact over the next year? Is it AI or is it going to be AI's impact on the other tools they use? Or are there still other tools out there that we should be thinking about so that we're not completely focused on this one?

Ori Keren: 3:48

there's other things that are going to happen, other predictions that I have, like, you know, in other areas, but just to put AI, like, to bed for a second. I think it's about how you integrate this thing into your existing tool chain. Everybody talks about, hey, what it will replace, what it won't replace. I think, it will still take time to understand how do you orchestrate all of this? How do you embed these technologies? When do you apply the human resource? When are you, Letting, like, agents go and do their thing. so, in terms of, like, affecting, the tool chain, I think it's more about how you combine and how they live side by side. some other interesting things I think are going to happen in, you know, in 2025 or some other trends that are relevant like, well, I'm not going to surprise anybody, but cybersecurity is still going to be something huge. I think you can see it from the macro level, like the world is shaking from, any angle that you look at it. So it just raises more cyber threats and, cybersecurity definitely, going to still play a major role in everything companies do. the two that I'm. I'm really excited about our developer productivity and developer experience and what do we do in these areas and but I don't know like I'll let you lead and when do you want to talk about these topics?

Ben Lloyd Pearson: 5:07

Yeah, those are definitely some topics that we want to dive into. and I love the cyber security example, because, when I was, getting into the profession, I remember, ScriptKitties used to be like a term that was used almost in a derogatory way to people that would like copy scripts off the internet and use them to maliciously attack organizations. But now, I mean, you could theoretically have like AIs That teach you how to, to build this stuff, you know? kind of does illustrate, I think pretty well, the impact that, that these tools are going to have, like across the space. how do you think all of this is going to impact the role of software engineer in 2025? So I think, you know, historically you think about a software engineer. There's somebody who. Is responsible for building things and coming up with novel and creative solutions to very concrete examples. how was that going to change? as generative AI, changes the ecosystem.

Ori Keren: 6:01

it's really interesting because, I remember when I was like, young developer, there's this, spark of ideas that you have that is sometimes coming top down. Hey, I have an idea and I'm going to work on it and I'm going to implement it. start somewhere, you write something and then ideas. You know, come to your head as creative ideas as you, oh, I build this, that probably means I can build something that does this thing and I can build an entire application. I have concerns that, you know, how we'd like, um, when iPhones were introduced and we saved all our contacts, we just forgot all the phone numbers and the navigation systems that were introduced and then a lot of people just can't navigate if they don't have like, Google Maps or Waze or something. I think it's very important for developers to, not be fully dependent on, these codices, et cetera. They're very important to increase the productivity, but people still should learn languages. So this is, true and entire potential, so we don't lose this big, big creativity spark that we have. So this is like a first comment that I have, like, uh, regarding the roles. I think it's more maybe on leaders or, the industry to think how do we preserve this creativity that's, again, sometimes it's a fire that lit from, like, bottom up. but when I think about the roles of, like, developers and how the roles of developers will change, I kind of, like, divide it into two. I think, junior developers that will know, how to utilize this, like, you know, IDE boosters, whether you use Copilot, Cursor, whatever you use, like, there's gonna be a gap if. You know how to use it, it will increase your productivity dramatically, and if you don't know how to use it, you're just going to stay behind. That's kind of what I think about, you know, people who are starting, you know, the first, you know, two, three years in development. I think the senior developers are very interesting because these folks, if they are able to, leverage the entire potential that, AI has to offer here, they could become small teams because they could say something like, Okay, I'm going to deploy my energy on only on these specific reviews. I'm going to have one agent that does like, Basic code reviews. I'm going to have one that just sits and look for I don't know what's wrong with my developer development pipeline What's broken? Where do I have maybe flaky tests that I can come in and fix? Where do I have long build times? and people that can leverage this technology can become like almost like full teams with a lot of potential so Again, I started and I said it's still going to take time because I think these technologies are in experimentation. but that's, the direction that I think like, uh, the industry will go,

Ben Lloyd Pearson: 8:53

you're highlighting a really prevalent thing that we've seen a lot in the difference between like how junior developers versus senior developers are leveraging these tools. You know, you think about like a junior developer, they may see efficiency gains from like, adding endpoints to like a standardized API, right? it's something that's repeatable and just takes like a little bit of for lack of a better term, intelligence to figure out how to replicate it versus like a senior engineer, like they seem to benefit more when you have The ability to like ask, have like a conversational interface into a complex code base because then they can, decipher things that are maybe outside of their expertise a lot more rapidly, you know?

Andrew Zigler: 9:33

Yeah. So, so far we've, we've covered topics that I know are top of mind for a lot of engineering leaders, a lot of people that work in software, things like how AI will impact their work and how it could change their role and cybersecurity is a topic that we're going to continue talking more about, but I'm curious, what is maybe a challenge that you think engineering leaders are underestimating or not noticing going into next year?

Ori Keren: 9:58

the first one is maybe what I spoke about. How do you maintain like this creativity spark and ability to, Build innovative products and innovative ideas. Again, sometimes they come top down, but a lot of the times, like the best companies in the world were started by developers, started with the ideas that people set and like teach stuff with their hands. And then the ideas like propagate from there. So I think people need to, leaders need to maintain it. I think there's two other aspects of, A small trend that I see that these, there's converges of technologies and they're becoming more homogeneous, if it makes sense. And then in the sides, you gotta maintain, like, diverse, like, skill set. there's languages that people paying less attention and all of a sudden they're saying, things are ramping up again. It's not always easy, like, to find your next job, but there are languages that, I know that people are looking, and it's hard to find, like, talent there, so I think leaders need to pay attention that they still have, like, a well diverse, skills in their teams, etc. The next thing is, like, humans. Don't forget you're working with people. so easy to forget like this framework when I was an engineering leader and I spoke to my managers and say like all those things like, people process product, and people it's like, we're working with people, you got to pay attention that they're in a risk of a burnout. what are you asking them to do? they're feeling threatened right now, by the way, by technology, there's a resistance. so if this role, by the way, I think, uh, engineering leaders, the toughest role that exists out there. I was an engineering leader. I want to say that being an engineering there is harder than, Being a CEO, still think about it if it's still right every now and then, but it is a very hard role. So I think those are like the things that leaders have to pay attention to.

Ben Lloyd Pearson: 11:58

we've been hearing things about like, we have a round of layoffs that happened at a lot of organizations early this year. There's been a return to office mandates like all over the place. There's, a general sense, I think In the engineering space that it's hard to know where, professional growth, like how how does that happen? You know, so it really does feel like there's a lot of things that are. putting like a downward pressure on DevEx. and I think that leads into like really the core of what we wanted to ask you about today, and that's, you know, really developer experience and how it connects to overall developer productivity, which I know you, you have some issues with that phrase that we'll get into a little bit. but in terms of DevEx, so what are some emerging tools or practices that you're seeing out there in the engineering space that, that gets you excited?

Ori Keren: 12:49

the term that I have a challenge is developer productivity and we'll get to it later, hopefully, but developer experience is really interesting. I think it's kind of in a, it's rich, like, Like this interesting crossroad right now, because, I think two challenges. First of all, it has like, um, passive part of what do you measure? It's a lot about what do you measure? And also there's even arguments on how do you measure, first of all, I think it's time for developer experience to move from, in the, how do you measure, and then we'll talk about ActiveParty, how do you measure to move from, just relying on these like, almost semi academic surveys, and to, uh, get them to the next level where it's a combination of measuring qualitative and quantitative things because And in qualitative, I think it has to be much more embedded into the day to day of developers. Again, it's really hard, I remember myself as a developer, to sit and like answer like this, again, almost semi academic thing that asks me now questions. But hey, ask me one second after I just completed my task about what was my problem, etc. And you'll get a lot of insight. so I think developer experience has to solve this measure problem and to get to an understanding that you gotta measure these qualitative things, but combine it with quantitative things. There are things you should be measuring. You should be measuring your build times. You should be measuring your stability of your CI and how much, you know, deterministic it is, like, the most The most irritating thing as a developer is like you run a test, it fails, you run it, it fails, you run it again with the same condition and it succeeds. Now you know, okay, next time you won't trust your, test suite. So, fixing those type of things, measuring how much you have done, test environments, um, adoption of like, AI tools and, and the impact of them. So again, I, I, I was starting with the measure part. I think, we got to jump to the next level where you combine, qual and quant. And then I think the, the biggest challenge and the biggest and the biggest potential of like innovation and, and things like the developing developer experience is okay, now that we got to some consensus on what we should be measuring and how there's a huge opportunity to fix these things. and there's, almost a thirst, like, to platforms that, you know, fix these things for me. and it's not that complex. I think, all the problems, all the challenges, all the things that we just mentioned, like, again, if I see, If the build time is too long, we can, again, deploy very interesting technologies now, like to shorten them. Um, if my tests are not stable, we can deploy agents like to fix these bugs. So, I think like, um, What, what excites me? I think there are good frameworks inside the developer experience. There is the SCI, the SCI space, software engineering intelligence, there's IDPs, there's surveys, there's all these avenues that you can get the understanding about the developer experience. We believe, and I believe, In not just showing you where the problems, giving you tools to actually go and solve these problems. and I think that's like the, the leap that the, the developer experience movement will probably make this year.

Ben Lloyd Pearson: 16:15

at the core of a lot of this problem is a lot of engineering organizations have this constant struggle to like justify investing in developer experience. You know, you've got this business that's always asking to like produce new features and help us close deals and all that stuff, but you know, developers want to make their lives easier. And, you know, I think some organizations are starting to get pretty good at articulating, why we need to push back against business priorities sometimes to invest in developer experience. and I think this segues nicely into, into a question that you have, Andrew, about an issue that we're, we're starting to see relatively frequently.

Andrew Zigler: 16:54

we hear a lot, when we talk with folks about developer burnout and the experience that they have within their platforms, within working every day, creating the software they do. And, something we hear consistently is, That it's more about, we're wondering, you know, is it about like the workload or is it about the way the developer's time is spent? And oftentimes you, you hear anecdotes about, particularly frustrating things for them that are specific and maybe that you're referring to are solvable. And so how do you think leaders can address, that imbalance for that experience for them?

Ori Keren: 17:29

I think you're touching a good point, like, There are people all the time. Again, it's this triangle of like, how do I make sure that I have the right people and I keep them happy and I keep them productive? How do I, have the right processes in place and how do I make sure like I'm creating the right product? That's like I think the, for engineering leaders. comes to Burnout, a lot of times it will be like kind of like together, unfortunately. Like somebody will say, Hey, I'm like burning out. And probably, probably they're working too much. And probably my, the reasons that are working too much is because, uh, executing simple tasks, is not easy for them because they're waiting for an environment to come up. Or the waiting for the CI to complete and then after one hour it failed and they're like, oh, I need to wait again

Ben Lloyd Pearson: 18:16

we've all, we've all been there.

Ori Keren: 18:18

Yeah, and so it's almost like, there's a strong connection between those, unfortunately, that comes together because you asked if it's like more the time spent or the workload. Unfortunately, um, it comes together and then people and it's like a bad snowball effect, right? Because we talked about. before like companies need to invest more in developer experience. It's hard for them sometimes to see that it will bring, better productivity. so to your question, I always think it's a combination or it's a combination of the both, like, you have committed people, they want to complete their tasks. But it's taking very much. Then they're working, they're just compensating with it on it with like a lot of hours. and that's like a vicious cycle that they're in. Pardon the interruption, but did you know tomorrow's the big day? On December 11th, Dev Interrupted is taking over The Melody in San Francisco, an evening crafted by us for engineering leaders just like you. We're hosting top minds at CircleCI, MongoDB, Syngenta, and LinearB as they tackle the challenges keeping teams up at night, quite literally, scaling and driving impact at the enterprise level. Check out the registration link in the show notes and grab your spot before they're gone! We'll see you tomorrow, December 11th, at The Melody.

Ben Lloyd Pearson: 19:47

before we get into our central topic on productivity, I want to ask you about the concept of, balancing developer freedoms with more of a standardization and, and compliance sort of posture, because I think this also plays a big role in developer experience, you know, cause you can think about like, let's just use generative AI as a, as a good example of this. organizations who are providing more freedom to developers. Yeah. Maybe seeing more experimentation and new use cases emerging. However, the organizations who actually approach it in a much more structured and, and standardized like rollout approach, are actually like leveraging bigger benefits from it because everyone sort of understands. Specific to their organization, like how generative AI can impact it. you know, when we think about like this balance of freedom versus standardization, like how do you think companies should be like focused on that over the next year?

Ori Keren: 20:43

I think companies need to define their philosophy, first of all, like, uh, like think about it, dedicate time to thinking about it, come up with a strategy and your philosophy and the things that you believe in. when I was a young manager, I always like, I always wanted to like think about how to. You know, after you do the first mistake and you fix a problem for your developers instead of letting them, like, learn on their own. It's the same with raising kids, rather than fall. So, uh, you gotta choose where you, focus on. So I think one of the recommendations I have, I think we touched on it, but, all these changes will bring a lot of, like, compliance requirements. Thanks. like to do the analogy to like autonomous cars, maybe the technology there, but there's a lot of like, regulations that are not solved. Here where it's like software, I think the technology will come too fast and you'll have to have some orchestration and compliance around. Why do I allow and why do I don't allow? And then companies have to have like a strategy and a philosophy on. Okay, in these areas, it's okay that we use different technologies and we try different things. but I don't know when things go through the development pipeline. At the end of the day, we gotta meet some compliance requirements. We gotta go through SOC 2, whatever like, our processes. Then it's okay to have more uniformity in those areas. Like these are the checks that are being done. And this is technology that we're using to, then I think it, creates a good balance where like when things are moving through the pipeline in CI, CD, et cetera, it's okay to have standardization and rules. And there are some languages that even let you run, write rules and program your pipeline. We know some of them, uh, some, uh, great products that do Over the IDEs and, you know, while I'm building my code, et cetera, I would still allow like for, um, more freedom, because again, it has less implications, uh, same goes for like, When you deploy stuff and you, you, at the end of the day, you can't, you kind of gotta have uniformity, but choose the areas where you allow some innovation and try new, new things where it's less risky. Going back to the example of where to follow. When I was a young leader, if I saw like a, hey, a big mistake and I gonna impact us dramatically, I wouldn't let it happen. This is one out of 10, nine out of 10 let the mistake happen. It's fine. Like this is how people learn and how they improve.

Ben Lloyd Pearson: 23:20

Yeah. I'm pretty sure my kid's school calls that a natural consequences for living with natural consequences. Yeah, it's actually a great learning technique. let's get into the topic of productivity now or developer productivity or software engineering productivity. This is, this is kind of a loaded term because, you know, I think a lot of organizations realize they need to focus on it. But it also is a term that kind of feels like you're going to start spying on your developers and potentially firing them if they don't have the right numbers. given that, like, what are the big challenges that you think that the engineering teams are facing now relative to the concept of developer productivity?

Ori Keren: 24:00

Yeah, I would start with just adding something again, like to what you said, it's a loaded term because I think I spoke about it before, but it's like, I don't like, well, it is what it is. This is the term, it's here to stay. But if you do an analogy to sales. For example, and people use a sales efficiency. So two things like, they use the word efficiency and sales. It's like the action that you do. It's not like, uh, the people who do it. So it's how about, how do we improve the process of sales? And unfortunately here, not only we didn't choose the action, we choose people. And instead of choosing plural, because I think development is team sports. You work together. Everybody does. We choose in this term and I say we like the people chose this term, single developer. So it's kind of a loaded term because when you say developer productivity, Oh, what do you mean? This is the thing that you measure the developers and you stack rank them. No. So this is why I think people get need to go, uh, see beyond the term, the term developer productivity to mirror presents. How do you increase the efficiency of the development process? So that's why again, if you could like turn back time and invent a different term, it would be great, but we can't, and it's here to stay with us. I think what the theme that I'm seeing in the, in, in developer productivity that is really interesting is all these contrasts. I think you spoke about it, like all these, um, on one hand, you have, hey, we got to apply AI and because everybody's talking about the big, big, big promise that it, it brings. Yeah. On the other hand, it's like, how do we put controls on it? And how do we, um, not forget about our people and like apply the human factors? That's a big challenge for developer productivity. Uh, you talked about you know, these two movements of like, Working hybrid and going back like to work from the office offices still again two big big contrasts and strong uh if the word didn't have enough polarity They're bringing this to, uh, developer productivity as well. Oh, five days at the office. No, hybrid. So and again, like, uh, we talked about, like, uh, your question about uniformity of like, hey, we're using the same tech stack for everybody. That's what we do. Uh, there's a lot of developer experience team that way we're doing centralized tooling and the purchasing like for the entire organization, et cetera, versus like the freedom, to choose. Uh, so I think the biggest challenge, the theme is this contrast and how you do balance all these, uh, contrasts. that's I think the biggest challenge of, developer productivity. And, because you have all of that, I think you don't have any other leaders, don't have any other choice, but to decide what is important to them. measure it, measure it so they can optimize it and they can start improving it. Like, I don't have to attack all the problems at once, but measure the things that are important to you. Again, like we said, you find your philosophy, your strategy. Where are you in all these contrasts? What is your choice? Because not choosing is the worst. is your approach in all of this? Then make sure you're measuring the right things to improve productivity. And also choose frameworks that not just let you look at them and what you measure, but also give you means to drive improvement with developer productivity. I hope it makes sense.

Andrew Zigler: 27:27

I really like how you framed the discussion as being polarizing. And oftentimes when you go down the list of things that we use to define developer productivity, they're divided into two camps that people find themselves in the whole way down the rubric. And you touched earlier on the human factor of working with other people and communicating to each other. Do you think that that is the real secret sauce here to developer productivity? Is it about finding that common ground between these camps and understanding that the shared goals that You have? And, and how would You recommend someone in either one of those camps, maybe it's someone who's more, IC oriented or someone more, manager oriented. How would you, give them advice to try to find, a common perspective?

Ori Keren: 28:15

I think leaders have been living this reality for a long time, like Engineering leaders have seen this, almost parallel universe. We call it sometimes the dual mandate, for years now. You have, like, uh, you turn left and you speak to your engineering organization and it's one language of how do we, I don't know, decrease the time, like, that we deploy to production, deploy more times. It's, uh, what do we need to improve? Like, how do we improve developer experience, our development pipeline? Like, where are we in the cloud, you know, cloud native development like Kubernetes adoption, all fascinating topics. Then you turn to the other side and you speak to the business and they don't, it's like

Ben Lloyd Pearson: 28:58

have no idea. they have no idea

Ori Keren: 29:00

they don't need, it's like, yeah, any of it is. So I think for leaders for a long time, they had to do this trick where. Connect the dots trick. I always like to say, Hey, put some key metrics, take some key business metrics and just draw a line between them. So, uh, the business understand, but it's an art. You gotta be great at this. So I think, same goes here. It's like, at the end of the day, that's the human charm, like, uh, good leaders. It doesn't have to be like engineering. There's good team leaders. Good tech leads, good developers can bridge between like these, these can find like the, path of like, what do we take from this? even if you look at like, I don't know, a hybrid versus, there's a middle ground here. Maybe you work two days from office. I'm just throwing an idea. Um, I think that's the, that's the key.

Andrew Zigler: 29:54

another question I had, this is related to my own experience, you know, I onboarded for a new role recently, and something that was really fascinating for me was onboarding and kind of like, uh, in the middle of the AI transformation of a lot of tools people are using. That actually helped expedite a lot of things for me. I had almost like a personalized assistant that I could ask questions to for lots of different resources and tools that I was added to. It was quick to jump in on context of things that was going on around me. And I'm wondering now, having gone through that experience and learned at a more Maybe what's some advice that you would give to somebody who's maybe finding themselves in like a newly promoted or newly hired like engineering leadership role? They're, they're hungry and they're excited to go in next year. Maybe they're taking over a new team or a new project. You know, there were opportunities for me to take advantage of new tools. What opportunities do you see for them to, uh, maybe be, um, you know, a better leader going into next year?

Ori Keren: 30:55

Yeah, for engineering leaders, I'll go back to the things that are, I think, uh, especially Okay, I acknowledge this, dual mandate, acknowledge the fact that it's two different languages, master both of them. the best leaders that I've seen, like, could speak on like an architectural problem and, with the engineers, and get fascinated about it and offer their opinion. And by the way, the greatest leaders, like also know how to remove themselves, like from some of the discussion, because, or speak last, because if you come and then your opinion, everybody will align with you. And on the other hand, you can't, you can't not tie everything that you do like to business objectives, because this is, this is the time, like you can see, like the, demand, like the, at the executive table, like to, uh, they're asking these questions, um, you need to be prepared to answer them. How do you allocate your, uh, resources? Where do you invest time? And why did you choose? just don't forget about that. That's my, uh, First, suggestion, measure the things that you believe in. Choose what you measure and, and, and, but the things that you believe in. And, you know, some people's styles like, okay, collaborate with a team and decide. Some people say, okay, uh, on some things I am going to collaborate, but here are the top things that I'm measuring. I don't think we can go to another year where people or engineering leaders like saying to themselves, yeah, maybe I can get along without, measuring. You can't optimize what you're not measuring. I have examples where I've seen like, people in the past saying, we measured a bunch of things. We know where we are now. We're good. so we're going to put the focus on other things, not measuring. I always tell them, can you imagine a VP of sales? Coming to a, board meeting or a staff meeting, on Monday and saying'm gonna say, Listen, I got this funnel thing going, like, I don't need to see the funnel. I know, I know where the problems are, we measured it, so I now know where my problems are. I'm gonna stop measuring, so I don't, I won't know how many opportunities we have. I won't know, like, where do I have bottlenecks in my funnel. We need to get to that level where people understand that, like, this is uh, basic level. I think people need to require more from systems that help them do that. Okay, once you help me measure and see the problems, offer me solutions, give me frameworks, give me Languages almost like to to fix my pipeline where I see problems. and then I will go like we talked about define your philosophy, invest, invest in that. Go, go speak to other leaders, to the people that report to you, to your peers. we're getting close to the end of the year.. So it's a good time. Like prepare a strategy for the, for the year with all the challenges that we spoke about with all this polarity, with all this, Hey, you can go, maybe you believe that everybody should come back to the office, have a discussion, see what, what the impact will be. Uh, if you do that, choose your philosophy. Go with, your strategy, and. Deploy it. And then don't forget at the end of the day, it's still this framework of people, process, product. So don't forget about the people element. I'll keep mentioning it.

Ben Lloyd Pearson: 34:17

Wonderful. So you've shared lots of great advice for engineering leaders going into next year. I've just got one more question for you before we head out. do you have any bold predictions for next year? Like things that, that you really want to just stand out?

Ori Keren: 34:33

Yes. Here's what's going to happen. And it's scary. I predict that productivity will go down next year. It will decrease.

Ben Lloyd Pearson: 34:41

Wow.

Ori Keren: 34:43

I think, if you can, again, it's, you don't have a single metric. You're measuring a bunch of things, but at the end of the day, it will, it will actually, uh, decrease a little bit. Why? Because in every change that you go through, We talked about it, like people still experiment here, experiment there. There's gonna be a lot still like moving parts. And every adoption of a new technology or change, like you first go through this like dip where, should I really do this? Like, how does that work? Um, you'll still get the resistance. There's a lot of resistance, by the way. Developers are worried. So you still get this resistance. people will need to feel comfortable with it. So I actually predict it will take sometime and then it will, climb back up and then this change will be amazing. Then you'll get this like, uh, 10x promise or, or, or, but it won't happen overnight. I don't think next year will be like, uh, great. Hey, with the same amount of people, let's say you have 100 developers in, uh, 1, 000 developers in your organization with the same amount of people you can do. It won't happen. It maybe even go down a little bit. That's my bold prediction before people know how to embrace, adopt these technologies, combine like the human factor in them and, and then grow from there. Then you'll get this like a productivity gain. So yeah, also we need to manage the expectations around that. but that's my bold prediction.

Andrew Zigler: 36:11

You know, we've asked you a lot of questions today, and I'm wondering, based on our discussion, if you had to ask our audience or our listeners one thing about their own engineering practices, what would it be, and why?

Ori Keren: 36:25

I would ask them one thing. Hey, are you data driven? Data driven, it doesn't mean, hey, do you have the right metrics? data driven means like, did you adopt technology that helped you map exactly like we spoke, like how, you know, Salesforce and sales are mapping the funnel, the pipeline, map your pipeline, it will, Pay your dividends as you, as you go forward, because that's where you can press with your eyes, like detect bottlenecks and then deploy AI applications and a lot of advanced things to fix the problems that you see. But this is a time for transformation because, People that will be data driven, and invest in it, they will harvest the fruits of that, like, in the coming years. So that's the one question. Hey, are you, you become data driven in your R& D organization? I think that's the one question to ask.

Ben Lloyd Pearson: 37:20

Wonderful. Well, thank you so much for joining us today, Ori. it's always a pleasure to have your insights to share with our audience.

Ori Keren: 37:27

Yeah, probably, I got a lot of things wrong, so, because I'm not a prophet, so I'm just using my insight. But thanks, it was great, just being here, great questions. Thanks.

Ben Lloyd Pearson: 37:37

that's it for today's show. thank you to our audience for joining us all the way to the end. if you like this show, the best way to support us is to go and rate our podcasts on your platform, whether that's Spotify, Apple, anywhere else, if we got a bunch of stuff that you think is wrong, go out there and tell us about it. but more, you can even go out and tell us that on LinkedIn, you can connect with Andrew, Ori, or I on LinkedIn, or just join the conversation on the Dev Interrupted LinkedIn page. And lastly, if you're looking for more insights from engineering leaders, head over to the Dev Interrupted sub stack, where you'll get weekly deep dives into articles and our favorite episodes, just like this one. So thank you everyone. We'll see you next week.