WEBVTT
00:00:07.666 --> 00:00:15.666
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.
00:00:15.705 --> 00:00:17.045
Thanks for joining us today, Ori.
00:00:18.250 --> 00:00:19.420
Hi Ben, it's great to be here.
00:00:19.440 --> 00:00:20.489
Thanks for having me.
00:00:21.455 --> 00:00:24.196
Ori, as always, it's really great to have you on our show.
00:00:24.306 --> 00:00:28.592
and Andrew, I want to welcome you to your first ever episode of Dev Interrupted.
00:00:28.760 --> 00:00:29.260
Thank you, Ben.
00:00:29.260 --> 00:00:30.579
I'm really excited to be here.
00:00:30.925 --> 00:00:34.585
We've actually dedicated some time next week to introduce yourself to our audience.
00:00:34.585 --> 00:00:44.615
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.
00:00:44.886 --> 00:00:51.850
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.
00:00:52.350 --> 00:01:05.649
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?
00:01:05.978 --> 00:01:13.549
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?
00:01:14.393 --> 00:01:24.742
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.
00:01:24.802 --> 00:01:26.903
How, how will it look?
00:01:27.593 --> 00:01:30.549
I think in two kind of separate tracks.
00:01:30.560 --> 00:01:40.105
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.
00:01:40.495 --> 00:01:42.995
I think these technologies will mature.
00:01:43.344 --> 00:01:49.314
We can speak later on like who's more benefiting from, from them and like has a better match like to utilize them.
00:01:49.855 --> 00:01:59.250
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?
00:01:59.760 --> 00:02:01.870
And it seems like it's in early adoption.
00:02:01.870 --> 00:02:11.413
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.
00:02:11.513 --> 00:02:15.293
By the way, I think mainly, junior developers, but not only.
00:02:15.943 --> 00:02:24.896
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.
00:02:25.456 --> 00:02:28.197
I think this, it's almost like in, phase before.
00:02:28.967 --> 00:02:32.146
This will be experimentation year for these type of things.
00:02:32.426 --> 00:02:37.426
There's a lot of like obstacles still like to overcome in order to embed this thing.
00:02:37.426 --> 00:02:46.167
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.
00:02:46.802 --> 00:03:00.008
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.
00:03:00.008 --> 00:03:03.609
I feel like it's, it's all people who do, informational work.
00:03:03.639 --> 00:03:05.579
You know, we're all being impacted by this.
00:03:05.899 --> 00:03:11.368
It's just like software developers seem to be one of the first big waves that it's really becoming mainstream and taking off.
00:03:12.174 --> 00:03:17.834
that's probably going to have a big impact on engineering organizations in this next year.
00:03:18.264 --> 00:03:27.570
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?
00:03:28.319 --> 00:03:35.986
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.
00:03:36.269 --> 00:03:39.038
like what tools are going to have the biggest impact over the next year?
00:03:39.038 --> 00:03:42.769
Is it AI or is it going to be AI's impact on the other tools they use?
00:03:42.778 --> 00:03:47.829
Or are there still other tools out there that we should be thinking about so that we're not completely focused on this one?
00:03:48.697 --> 00:03:56.396
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.
00:03:56.447 --> 00:04:01.137
I think it's about how you integrate this thing into your existing tool chain.
00:04:01.717 --> 00:04:05.396
Everybody talks about, hey, what it will replace, what it won't replace.
00:04:05.396 --> 00:04:09.597
I think, it will still take time to understand how do you orchestrate all of this?
00:04:09.606 --> 00:04:11.046
How do you embed these technologies?
00:04:11.056 --> 00:04:13.586
When do you apply the human resource?
00:04:13.606 --> 00:04:17.747
When are you, Letting, like, agents go and do their thing.
00:04:18.156 --> 00:04:23.800
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.
00:04:24.680 --> 00:04:37.781
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.
00:04:38.341 --> 00:04:46.101
I think you can see it from the macro level, like the world is shaking from, any angle that you look at it.
00:04:46.112 --> 00:04:54.632
So it just raises more cyber threats and, cybersecurity definitely, going to still play a major role in everything companies do.
00:04:55.312 --> 00:04:56.262
the two that I'm.
00:04:56.771 --> 00:05:06.591
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?
00:05:07.697 --> 00:05:10.728
Yeah, those are definitely some topics that we want to dive into.
00:05:10.968 --> 00:05:26.237
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.
00:05:26.237 --> 00:05:33.586
But now, I mean, you could theoretically have like AIs That teach you how to, to build this stuff, you know?
00:05:33.937 --> 00:05:40.067
kind of does illustrate, I think pretty well, the impact that, that these tools are going to have, like across the space.
00:05:40.836 --> 00:05:46.177
how do you think all of this is going to impact the role of software engineer in 2025?
00:05:46.206 --> 00:05:48.906
So I think, you know, historically you think about a software engineer.
00:05:48.906 --> 00:05:49.877
There's somebody who.
00:05:50.317 --> 00:05:57.257
Is responsible for building things and coming up with novel and creative solutions to very concrete examples.
00:05:57.266 --> 00:05:58.536
how was that going to change?
00:05:58.586 --> 00:06:00.826
as generative AI, changes the ecosystem.
00:06:01.612 --> 00:06:11.452
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.
00:06:11.543 --> 00:06:14.973
Hey, I have an idea and I'm going to work on it and I'm going to implement it.
00:06:15.336 --> 00:06:18.430
start somewhere, you write something and then ideas.
00:06:18.670 --> 00:06:28.290
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.
00:06:28.932 --> 00:06:44.286
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.
00:06:44.757 --> 00:06:52.016
I think it's very important for developers to, not be fully dependent on, these codices, et cetera.
00:06:52.057 --> 00:06:57.877
They're very important to increase the productivity, but people still should learn languages.
00:06:58.216 --> 00:07:04.387
So this is, true and entire potential, so we don't lose this big, big creativity spark that we have.
00:07:04.387 --> 00:07:08.346
So this is like a first comment that I have, like, uh, regarding the roles.
00:07:08.346 --> 00:07:17.357
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.
00:07:17.826 --> 00:07:25.120
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.
00:07:25.120 --> 00:07:37.514
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.
00:07:38.249 --> 00:07:46.749
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.
00:07:47.209 --> 00:07:54.119
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.
00:07:54.949 --> 00:08:18.360
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.
00:08:18.360 --> 00:08:21.754
I'm going to have one agent that does like, Basic code reviews.
00:08:22.175 --> 00:08:28.745
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?
00:08:28.745 --> 00:08:32.585
Where do I have maybe flaky tests that I can come in and fix?
00:08:32.585 --> 00:08:33.955
Where do I have long build times?
00:08:34.442 --> 00:08:48.822
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.
00:08:49.212 --> 00:08:53.072
but that's, the direction that I think like, uh, the industry will go,
00:08:53.534 --> 00:09:02.399
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.
00:09:02.788 --> 00:09:10.239
You know, you think about like a junior developer, they may see efficiency gains from like, adding endpoints to like a standardized API, right?
00:09:10.239 --> 00:09:32.933
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?
00:09:33.673 --> 00:09:33.933
Yeah.
00:09:33.933 --> 00:09:58.203
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?
00:09:58.869 --> 00:10:00.798
the first one is maybe what I spoke about.
00:10:00.808 --> 00:10:10.318
How do you maintain like this creativity spark and ability to, Build innovative products and innovative ideas.
00:10:10.318 --> 00:10:20.491
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.
00:10:20.491 --> 00:10:23.922
And then the ideas like propagate from there.
00:10:23.922 --> 00:10:27.001
So I think people need to, leaders need to maintain it.
00:10:27.001 --> 00:10:38.032
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.
00:10:38.611 --> 00:10:43.412
And then in the sides, you gotta maintain, like, diverse, like, skill set.
00:10:44.121 --> 00:10:50.480
there's languages that people paying less attention and all of a sudden they're saying, things are ramping up again.
00:10:50.480 --> 00:11:06.947
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.
00:11:07.368 --> 00:11:10.038
The next thing is, like, humans.
00:11:10.368 --> 00:11:11.967
Don't forget you're working with people.
00:11:12.447 --> 00:11:27.941
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.
00:11:28.370 --> 00:11:29.990
what are you asking them to do?
00:11:30.400 --> 00:11:34.581
they're feeling threatened right now, by the way, by technology, there's a resistance.
00:11:35.196 --> 00:11:41.115
so if this role, by the way, I think, uh, engineering leaders, the toughest role that exists out there.
00:11:41.115 --> 00:11:42.615
I was an engineering leader.
00:11:43.115 --> 00:11:52.905
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.
00:11:53.216 --> 00:11:56.928
So I think those are like the things that leaders have to pay attention to.
00:11:58.049 --> 00:12:04.570
we've been hearing things about like, we have a round of layoffs that happened at a lot of organizations early this year.
00:12:04.580 --> 00:12:08.490
There's been a return to office mandates like all over the place.
00:12:08.509 --> 00:12:16.179
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?
00:12:16.590 --> 00:12:19.860
You know, so it really does feel like there's a lot of things that are.
00:12:20.100 --> 00:12:23.419
putting like a downward pressure on DevEx.
00:12:23.769 --> 00:12:36.929
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.
00:12:37.370 --> 00:12:47.779
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?
00:12:49.153 --> 00:12:56.933
the term that I have a challenge is developer productivity and we'll get to it later, hopefully, but developer experience is really interesting.
00:12:56.933 --> 00:13:03.811
I think it's kind of in a, it's rich, like, Like this interesting crossroad right now, because, I think two challenges.
00:13:03.821 --> 00:13:08.615
First of all, it has like, um, passive part of what do you measure?
00:13:08.905 --> 00:13:10.365
It's a lot about what do you measure?
00:13:10.760 --> 00:13:44.918
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.
00:13:45.347 --> 00:13:54.168
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.
00:13:54.687 --> 00:14:00.248
But hey, ask me one second after I just completed my task about what was my problem, etc.
00:14:00.557 --> 00:14:02.148
And you'll get a lot of insight.
00:14:02.837 --> 00:14:13.457
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.
00:14:13.778 --> 00:14:15.427
There are things you should be measuring.
00:14:16.398 --> 00:14:17.878
You should be measuring your build times.
00:14:18.748 --> 00:14:32.528
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.
00:14:33.107 --> 00:14:36.177
Now you know, okay, next time you won't trust your, test suite.
00:14:36.177 --> 00:14:47.020
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.
00:14:47.650 --> 00:14:51.100
So again, I, I, I was starting with the measure part.
00:14:51.100 --> 00:14:55.447
I think, we got to jump to the next level where you combine, qual and quant.
00:14:56.557 --> 00:15:13.467
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.
00:15:14.268 --> 00:15:19.048
and there's, almost a thirst, like, to platforms that, you know, fix these things for me.
00:15:19.350 --> 00:15:21.000
and it's not that complex.
00:15:21.010 --> 00:15:34.846
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.
00:15:35.456 --> 00:15:40.306
Um, if my tests are not stable, we can deploy agents like to fix these bugs.
00:15:40.306 --> 00:15:44.186
So, I think like, um, What, what excites me?
00:15:44.559 --> 00:15:48.330
I think there are good frameworks inside the developer experience.
00:15:48.340 --> 00:16:00.610
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.
00:16:01.306 --> 00:16:08.936
We believe, and I believe, In not just showing you where the problems, giving you tools to actually go and solve these problems.
00:16:08.936 --> 00:16:14.056
and I think that's like the, the leap that the, the developer experience movement will probably make this year.
00:16:15.360 --> 00:16:25.191
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.
00:16:25.230 --> 00:16:34.615
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.
00:16:35.056 --> 00:16:45.938
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.
00:16:45.979 --> 00:16:53.219
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.
00:16:54.135 --> 00:17:03.895
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.
00:17:04.246 --> 00:17:14.181
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?
00:17:14.191 --> 00:17:22.921
And oftentimes you, you hear anecdotes about, particularly frustrating things for them that are specific and maybe that you're referring to are solvable.
00:17:23.221 --> 00:17:28.401
And so how do you think leaders can address, that imbalance for that experience for them?
00:17:29.375 --> 00:17:33.285
I think you're touching a good point, like, There are people all the time.
00:17:33.345 --> 00:17:39.795
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?
00:17:39.795 --> 00:17:45.474
How do I, have the right processes in place and how do I make sure like I'm creating the right product?
00:17:45.484 --> 00:17:47.994
That's like I think the, for engineering leaders.
00:17:47.994 --> 00:17:53.138
comes to Burnout, a lot of times it will be like kind of like together, unfortunately.
00:17:53.138 --> 00:17:55.058
Like somebody will say, Hey, I'm like burning out.
00:17:55.469 --> 00:17:59.078
And probably, probably they're working too much.
00:17:59.098 --> 00:18:10.409
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.
00:18:10.729 --> 00:18:15.858
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
00:18:16.569 --> 00:18:17.569
we've all, we've all been there.
00:18:18.128 --> 00:18:27.545
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.
00:18:27.934 --> 00:18:36.345
Unfortunately, um, it comes together and then people and it's like a bad snowball effect, right?
00:18:36.464 --> 00:18:38.424
Because we talked about.
00:18:38.824 --> 00:18:42.703
before like companies need to invest more in developer experience.
00:18:42.703 --> 00:18:48.104
It's hard for them sometimes to see that it will bring, better productivity.
00:18:48.616 --> 00:18:56.416
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.
00:18:56.791 --> 00:18:58.602
But it's taking very much.
00:18:58.632 --> 00:19:02.882
Then they're working, they're just compensating with it on it with like a lot of hours.
00:19:03.291 --> 00:19:07.614
and that's like a vicious cycle that they're in.
00:19:11.931 --> 00:19:14.820
Pardon the interruption, but did you know tomorrow's the big day?
00:19:15.340 --> 00:19:23.080
On December 11th, Dev Interrupted is taking over The Melody in San Francisco, an evening crafted by us for engineering leaders just like you.
00:19:23.621 --> 00:19:36.320
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.
00:19:37.121 --> 00:19:44.191
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.
00:19:47.556 --> 00:20:08.566
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.
00:20:09.006 --> 00:20:12.326
organizations who are providing more freedom to developers.
00:20:12.326 --> 00:20:12.355
Yeah.
00:20:12.490 --> 00:20:16.101
Maybe seeing more experimentation and new use cases emerging.
00:20:16.411 --> 00:20:28.637
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.
00:20:28.905 --> 00:20:33.586
Specific to their organization, like how generative AI can impact it.
00:20:34.076 --> 00:20:42.685
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?
00:20:43.329 --> 00:20:54.039
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.
00:20:54.853 --> 00:20:59.752
when I was a young manager, I always like, I always wanted to like think about how to.
00:21:00.063 --> 00:21:07.343
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.
00:21:08.282 --> 00:21:11.843
It's the same with raising kids, rather than fall.
00:21:12.012 --> 00:21:15.252
So, uh, you gotta choose where you, focus on.
00:21:15.522 --> 00:21:25.643
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.
00:21:25.643 --> 00:21:25.823
Thanks.
00:21:26.788 --> 00:21:33.867
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.
00:21:34.268 --> 00:21:42.248
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.
00:21:42.248 --> 00:21:44.127
Why do I allow and why do I don't allow?
00:21:44.820 --> 00:21:49.381
And then companies have to have like a strategy and a philosophy on.
00:21:49.675 --> 00:21:56.435
Okay, in these areas, it's okay that we use different technologies and we try different things.
00:21:56.855 --> 00:22:00.355
but I don't know when things go through the development pipeline.
00:22:00.385 --> 00:22:04.506
At the end of the day, we gotta meet some compliance requirements.
00:22:04.506 --> 00:22:07.848
We gotta go through SOC 2, whatever like, our processes.
00:22:08.385 --> 00:22:11.645
Then it's okay to have more uniformity in those areas.
00:22:11.655 --> 00:22:13.816
Like these are the checks that are being done.
00:22:13.816 --> 00:22:25.155
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.
00:22:25.615 --> 00:22:30.401
And there are some languages that even let you run, write rules and program your pipeline.
00:22:30.401 --> 00:23:02.171
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.
00:23:03.381 --> 00:23:05.361
Going back to the example of where to follow.
00:23:05.361 --> 00:23:13.040
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.
00:23:13.651 --> 00:23:17.161
This is one out of 10, nine out of 10 let the mistake happen.
00:23:17.161 --> 00:23:17.611
It's fine.
00:23:17.611 --> 00:23:19.471
Like this is how people learn and how they improve.
00:23:20.896 --> 00:23:21.086
Yeah.
00:23:21.086 --> 00:23:26.517
I'm pretty sure my kid's school calls that a natural consequences for living with natural consequences.
00:23:27.311 --> 00:23:29.231
Yeah, it's actually a great learning technique.
00:23:30.259 --> 00:23:35.699
let's get into the topic of productivity now or developer productivity or software engineering productivity.
00:23:36.088 --> 00:23:42.378
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.
00:23:42.554 --> 00:23:50.034
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.
00:23:50.534 --> 00:23:59.044
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?
00:24:00.038 --> 00:24:09.034
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.
00:24:09.044 --> 00:24:11.094
This is the term, it's here to stay.
00:24:11.743 --> 00:24:14.933
But if you do an analogy to sales.
00:24:15.394 --> 00:24:18.304
For example, and people use a sales efficiency.
00:24:18.304 --> 00:24:22.127
So two things like, they use the word efficiency and sales.
00:24:22.147 --> 00:24:23.647
It's like the action that you do.
00:24:23.728 --> 00:24:26.238
It's not like, uh, the people who do it.
00:24:26.577 --> 00:24:29.097
So it's how about, how do we improve the process of sales?
00:24:29.667 --> 00:24:35.907
And unfortunately here, not only we didn't choose the action, we choose people.
00:24:36.097 --> 00:24:39.857
And instead of choosing plural, because I think development is team sports.
00:24:40.827 --> 00:24:41.728
You work together.
00:24:41.728 --> 00:24:42.307
Everybody does.
00:24:42.877 --> 00:24:47.968
We choose in this term and I say we like the people chose this term, single developer.
00:24:48.278 --> 00:24:51.367
So it's kind of a loaded term because when you say developer productivity, Oh, what do you mean?
00:24:51.367 --> 00:24:56.018
This is the thing that you measure the developers and you stack rank them.
00:24:56.057 --> 00:24:56.357
No.
00:24:56.357 --> 00:25:03.008
So this is why I think people get need to go, uh, see beyond the term, the term developer productivity to mirror presents.
00:25:03.008 --> 00:25:06.417
How do you increase the efficiency of the development process?
00:25:06.417 --> 00:25:14.723
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.
00:25:15.284 --> 00:25:22.374
I think what the theme that I'm seeing in the, in, in developer productivity that is really interesting is all these contrasts.
00:25:22.403 --> 00:25:34.453
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.
00:25:34.453 --> 00:25:34.483
Yeah.
00:25:35.574 --> 00:25:38.773
On the other hand, it's like, how do we put controls on it?
00:25:38.983 --> 00:25:44.304
And how do we, um, not forget about our people and like apply the human factors?
00:25:44.314 --> 00:25:46.503
That's a big challenge for developer productivity.
00:25:47.473 --> 00:26:07.393
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.
00:26:07.542 --> 00:26:09.413
Oh, five days at the office.
00:26:09.413 --> 00:26:10.093
No, hybrid.
00:26:10.093 --> 00:26:18.377
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.
00:26:18.597 --> 00:26:19.538
That's what we do.
00:26:20.153 --> 00:26:28.828
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.
00:26:29.159 --> 00:26:35.209
Uh, so I think the biggest challenge, the theme is this contrast and how you do balance all these, uh, contrasts.
00:26:35.704 --> 00:26:38.625
that's I think the biggest challenge of, developer productivity.
00:26:38.625 --> 00:26:47.896
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.
00:26:49.161 --> 00:26:53.990
measure it, measure it so they can optimize it and they can start improving it.
00:26:54.000 --> 00:26:59.270
Like, I don't have to attack all the problems at once, but measure the things that are important to you.
00:26:59.641 --> 00:27:02.790
Again, like we said, you find your philosophy, your strategy.
00:27:03.316 --> 00:27:05.036
Where are you in all these contrasts?
00:27:05.445 --> 00:27:06.346
What is your choice?
00:27:06.635 --> 00:27:08.425
Because not choosing is the worst.
00:27:10.175 --> 00:27:11.645
is your approach in all of this?
00:27:12.276 --> 00:27:16.288
Then make sure you're measuring the right things to improve productivity.
00:27:16.288 --> 00:27:25.338
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.
00:27:25.338 --> 00:27:26.638
I hope it makes sense.
00:27:27.690 --> 00:27:31.650
I really like how you framed the discussion as being polarizing.
00:27:31.650 --> 00:27:41.980
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.
00:27:42.279 --> 00:27:48.755
And you touched earlier on the human factor of working with other people and communicating to each other.
00:27:48.755 --> 00:27:53.365
Do you think that that is the real secret sauce here to developer productivity?
00:27:53.375 --> 00:28:00.744
Is it about finding that common ground between these camps and understanding that the shared goals that You have?
00:28:00.744 --> 00:28:10.785
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.
00:28:11.035 --> 00:28:14.672
How would you, give them advice to try to find, a common perspective?
00:28:15.858 --> 00:28:22.688
I think leaders have been living this reality for a long time, like Engineering leaders have seen this, almost parallel universe.
00:28:23.417 --> 00:28:26.314
We call it sometimes the dual mandate, for years now.
00:28:26.753 --> 00:28:39.079
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.
00:28:39.079 --> 00:28:41.054
It's, uh, what do we need to improve?
00:28:41.064 --> 00:28:44.253
Like, how do we improve developer experience, our development pipeline?
00:28:44.263 --> 00:28:51.720
Like, where are we in the cloud, you know, cloud native development like Kubernetes adoption, all fascinating topics.
00:28:52.259 --> 00:28:58.940
Then you turn to the other side and you speak to the business and they don't, it's like
00:28:58.965 --> 00:28:59.675
have no idea.
00:28:59.726 --> 00:29:00.215
they have no idea
00:29:00.259 --> 00:29:02.470
they don't need, it's like, yeah, any of it is.
00:29:02.480 --> 00:29:08.349
So I think for leaders for a long time, they had to do this trick where.
00:29:09.434 --> 00:29:10.744
Connect the dots trick.
00:29:10.904 --> 00:29:18.305
I always like to say, Hey, put some key metrics, take some key business metrics and just draw a line between them.
00:29:18.315 --> 00:29:21.125
So, uh, the business understand, but it's an art.
00:29:21.194 --> 00:29:23.365
You gotta be great at this.
00:29:23.365 --> 00:29:25.761
So I think, same goes here.
00:29:25.761 --> 00:29:30.118
It's like, at the end of the day, that's the human charm, like, uh, good leaders.
00:29:30.999 --> 00:29:32.398
It doesn't have to be like engineering.
00:29:32.409 --> 00:29:34.118
There's good team leaders.
00:29:34.368 --> 00:29:42.859
Good tech leads, good developers can bridge between like these, these can find like the, path of like, what do we take from this?
00:29:42.983 --> 00:29:47.550
even if you look at like, I don't know, a hybrid versus, there's a middle ground here.
00:29:47.550 --> 00:29:49.931
Maybe you work two days from office.
00:29:49.931 --> 00:29:51.631
I'm just throwing an idea.
00:29:51.631 --> 00:29:53.641
Um, I think that's the, that's the key.
00:29:54.712 --> 00:30:09.803
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.
00:30:10.142 --> 00:30:12.332
That actually helped expedite a lot of things for me.
00:30:12.372 --> 00:30:18.672
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.
00:30:18.672 --> 00:30:23.192
It was quick to jump in on context of things that was going on around me.
00:30:23.548 --> 00:30:39.282
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?
00:30:39.292 --> 00:30:41.752
They're, they're hungry and they're excited to go in next year.
00:30:42.022 --> 00:30:44.583
Maybe they're taking over a new team or a new project.
00:30:44.833 --> 00:30:47.913
You know, there were opportunities for me to take advantage of new tools.
00:30:48.228 --> 00:30:54.748
What opportunities do you see for them to, uh, maybe be, um, you know, a better leader going into next year?
00:30:55.859 --> 00:31:06.638
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.
00:31:07.286 --> 00:31:17.394
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.
00:31:17.394 --> 00:31:27.884
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.
00:31:28.544 --> 00:31:48.534
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.
00:31:48.574 --> 00:31:51.263
How do you allocate your, uh, resources?
00:31:51.273 --> 00:31:52.433
Where do you invest time?
00:31:52.433 --> 00:31:53.413
And why did you choose?
00:31:53.990 --> 00:31:55.039
just don't forget about that.
00:31:55.039 --> 00:32:00.176
That's my, uh, First, suggestion, measure the things that you believe in.
00:32:00.653 --> 00:32:04.324
Choose what you measure and, and, and, but the things that you believe in.
00:32:04.324 --> 00:32:08.653
And, you know, some people's styles like, okay, collaborate with a team and decide.
00:32:08.653 --> 00:32:14.403
Some people say, okay, uh, on some things I am going to collaborate, but here are the top things that I'm measuring.
00:32:14.804 --> 00:32:22.973
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.
00:32:22.983 --> 00:32:25.114
You can't optimize what you're not measuring.
00:32:25.834 --> 00:32:30.559
I have examples where I've seen like, people in the past saying, we measured a bunch of things.
00:32:30.660 --> 00:32:32.049
We know where we are now.
00:32:32.660 --> 00:32:33.220
We're good.
00:32:33.605 --> 00:32:37.276
so we're going to put the focus on other things, not measuring.
00:32:38.355 --> 00:32:42.655
I always tell them, can you imagine a VP of sales?
00:32:43.191 --> 00:32:52.464
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.
00:32:53.765 --> 00:32:58.095
I know, I know where the problems are, we measured it, so I now know where my problems are.
00:32:58.095 --> 00:33:01.585
I'm gonna stop measuring, so I don't, I won't know how many opportunities we have.
00:33:01.585 --> 00:33:06.204
I won't know, like, where do I have bottlenecks in my funnel.
00:33:06.894 --> 00:33:11.758
We need to get to that level where people understand that, like, this is uh, basic level.
00:33:12.057 --> 00:33:17.321
I think people need to require more from systems that help them do that.
00:33:17.352 --> 00:33:29.412
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.
00:33:30.201 --> 00:33:35.551
and then I will go like we talked about define your philosophy, invest, invest in that.
00:33:35.561 --> 00:33:41.961
Go, go speak to other leaders, to the people that report to you, to your peers.
00:33:42.771 --> 00:33:45.051
we're getting close to the end of the year.
00:33:45.586 --> 00:33:46.606
. So it's a good time.
00:33:46.606 --> 00:33:59.413
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.
00:33:59.472 --> 00:34:02.742
Uh, if you do that, choose your philosophy.
00:34:02.742 --> 00:34:05.224
Go with, your strategy, and.
00:34:05.920 --> 00:34:06.460
Deploy it.
00:34:06.730 --> 00:34:12.579
And then don't forget at the end of the day, it's still this framework of people, process, product.
00:34:12.920 --> 00:34:14.679
So don't forget about the people element.
00:34:14.822 --> 00:34:16.393
I'll keep mentioning it.
00:34:17.409 --> 00:34:17.869
Wonderful.
00:34:17.898 --> 00:34:23.315
So you've shared lots of great advice for engineering leaders going into next year.
00:34:23.585 --> 00:34:26.465
I've just got one more question for you before we head out.
00:34:26.548 --> 00:34:28.579
do you have any bold predictions for next year?
00:34:28.628 --> 00:34:32.349
Like things that, that you really want to just stand out?
00:34:33.115 --> 00:34:33.835
Yes.
00:34:33.976 --> 00:34:35.306
Here's what's going to happen.
00:34:35.356 --> 00:34:36.436
And it's scary.
00:34:37.023 --> 00:34:40.304
I predict that productivity will go down next year.
00:34:40.414 --> 00:34:41.594
It will decrease.
00:34:41.704 --> 00:34:42.105
Wow.
00:34:43.023 --> 00:34:46.708
I think, if you can, again, it's, you don't have a single metric.
00:34:46.739 --> 00:34:53.349
You're measuring a bunch of things, but at the end of the day, it will, it will actually, uh, decrease a little bit.
00:34:54.039 --> 00:34:54.748
Why?
00:34:54.778 --> 00:35:01.704
Because in every change that you go through, We talked about it, like people still experiment here, experiment there.
00:35:02.125 --> 00:35:04.454
There's gonna be a lot still like moving parts.
00:35:05.034 --> 00:35:14.663
And every adoption of a new technology or change, like you first go through this like dip where, should I really do this?
00:35:14.672 --> 00:35:16.262
Like, how does that work?
00:35:16.302 --> 00:35:18.422
Um, you'll still get the resistance.
00:35:18.432 --> 00:35:19.862
There's a lot of resistance, by the way.
00:35:19.862 --> 00:35:21.773
Developers are worried.
00:35:21.882 --> 00:35:24.023
So you still get this resistance.
00:35:24.422 --> 00:35:26.273
people will need to feel comfortable with it.
00:35:26.393 --> 00:35:32.929
So I actually predict it will take sometime and then it will, climb back up and then this change will be amazing.
00:35:33.150 --> 00:35:38.342
Then you'll get this like, uh, 10x promise or, or, or, but it won't happen overnight.
00:35:38.342 --> 00:35:41.702
I don't think next year will be like, uh, great.
00:35:41.702 --> 00:35:49.282
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.
00:35:50.378 --> 00:35:51.088
It won't happen.
00:35:51.088 --> 00:35:52.568
It maybe even go down a little bit.
00:35:52.577 --> 00:36:02.724
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.
00:36:02.775 --> 00:36:05.684
Then you'll get this like a productivity gain.
00:36:05.684 --> 00:36:09.235
So yeah, also we need to manage the expectations around that.
00:36:09.632 --> 00:36:10.902
but that's my bold prediction.
00:36:11.795 --> 00:36:24.425
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?
00:36:25.291 --> 00:36:26.652
I would ask them one thing.
00:36:27.262 --> 00:36:28.481
Hey, are you data driven?
00:36:29.489 --> 00:36:33.349
Data driven, it doesn't mean, hey, do you have the right metrics?
00:36:33.559 --> 00:37:00.568
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.
00:37:01.148 --> 00:37:12.789
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.
00:37:12.798 --> 00:37:13.809
So that's the one question.
00:37:13.809 --> 00:37:17.871
Hey, are you, you become data driven in your R& D organization?
00:37:18.222 --> 00:37:19.472
I think that's the one question to ask.
00:37:20.617 --> 00:37:21.148
Wonderful.
00:37:21.188 --> 00:37:24.277
Well, thank you so much for joining us today, Ori.
00:37:24.315 --> 00:37:27.324
it's always a pleasure to have your insights to share with our audience.
00:37:27.938 --> 00:37:34.179
Yeah, probably, I got a lot of things wrong, so, because I'm not a prophet, so I'm just using my insight.
00:37:34.239 --> 00:37:37.106
But thanks, it was great, just being here, great questions.
00:37:37.106 --> 00:37:37.286
Thanks.
00:37:37.507 --> 00:37:39.086
that's it for today's show.
00:37:39.246 --> 00:37:41.987
thank you to our audience for joining us all the way to the end.
00:37:41.987 --> 00:37:54.664
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.
00:37:54.945 --> 00:38:04.094
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.
00:38:04.414 --> 00:38:14.436
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.
00:38:14.695 --> 00:38:15.956
So thank you everyone.
00:38:15.996 --> 00:38:16.905
We'll see you next week.
00:00:07.666 --> 00:00:15.666
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.
00:00:15.705 --> 00:00:17.045
Thanks for joining us today, Ori.
00:00:18.250 --> 00:00:19.420
Hi Ben, it's great to be here.
00:00:19.440 --> 00:00:20.489
Thanks for having me.
00:00:21.455 --> 00:00:24.196
Ori, as always, it's really great to have you on our show.
00:00:24.306 --> 00:00:28.592
and Andrew, I want to welcome you to your first ever episode of Dev Interrupted.
00:00:28.760 --> 00:00:29.260
Thank you, Ben.
00:00:29.260 --> 00:00:30.579
I'm really excited to be here.
00:00:30.925 --> 00:00:34.585
We've actually dedicated some time next week to introduce yourself to our audience.
00:00:34.585 --> 00:00:44.615
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.
00:00:44.886 --> 00:00:51.850
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.
00:00:52.350 --> 00:01:05.649
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?
00:01:05.978 --> 00:01:13.549
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?
00:01:14.393 --> 00:01:24.742
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.
00:01:24.802 --> 00:01:26.903
How, how will it look?
00:01:27.593 --> 00:01:30.549
I think in two kind of separate tracks.
00:01:30.560 --> 00:01:40.105
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.
00:01:40.495 --> 00:01:42.995
I think these technologies will mature.
00:01:43.344 --> 00:01:49.314
We can speak later on like who's more benefiting from, from them and like has a better match like to utilize them.
00:01:49.855 --> 00:01:59.250
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?
00:01:59.760 --> 00:02:01.870
And it seems like it's in early adoption.
00:02:01.870 --> 00:02:11.413
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.
00:02:11.513 --> 00:02:15.293
By the way, I think mainly, junior developers, but not only.
00:02:15.943 --> 00:02:24.896
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.
00:02:25.456 --> 00:02:28.197
I think this, it's almost like in, phase before.
00:02:28.967 --> 00:02:32.146
This will be experimentation year for these type of things.
00:02:32.426 --> 00:02:37.426
There's a lot of like obstacles still like to overcome in order to embed this thing.
00:02:37.426 --> 00:02:46.167
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.
00:02:46.802 --> 00:03:00.008
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.
00:03:00.008 --> 00:03:03.609
I feel like it's, it's all people who do, informational work.
00:03:03.639 --> 00:03:05.579
You know, we're all being impacted by this.
00:03:05.899 --> 00:03:11.368
It's just like software developers seem to be one of the first big waves that it's really becoming mainstream and taking off.
00:03:12.174 --> 00:03:17.834
that's probably going to have a big impact on engineering organizations in this next year.
00:03:18.264 --> 00:03:27.570
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?
00:03:28.319 --> 00:03:35.986
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.
00:03:36.269 --> 00:03:39.038
like what tools are going to have the biggest impact over the next year?
00:03:39.038 --> 00:03:42.769
Is it AI or is it going to be AI's impact on the other tools they use?
00:03:42.778 --> 00:03:47.829
Or are there still other tools out there that we should be thinking about so that we're not completely focused on this one?
00:03:48.697 --> 00:03:56.396
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.
00:03:56.447 --> 00:04:01.137
I think it's about how you integrate this thing into your existing tool chain.
00:04:01.717 --> 00:04:05.396
Everybody talks about, hey, what it will replace, what it won't replace.
00:04:05.396 --> 00:04:09.597
I think, it will still take time to understand how do you orchestrate all of this?
00:04:09.606 --> 00:04:11.046
How do you embed these technologies?
00:04:11.056 --> 00:04:13.586
When do you apply the human resource?
00:04:13.606 --> 00:04:17.747
When are you, Letting, like, agents go and do their thing.
00:04:18.156 --> 00:04:23.800
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.
00:04:24.680 --> 00:04:37.781
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.
00:04:38.341 --> 00:04:46.101
I think you can see it from the macro level, like the world is shaking from, any angle that you look at it.
00:04:46.112 --> 00:04:54.632
So it just raises more cyber threats and, cybersecurity definitely, going to still play a major role in everything companies do.
00:04:55.312 --> 00:04:56.262
the two that I'm.
00:04:56.771 --> 00:05:06.591
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?
00:05:07.697 --> 00:05:10.728
Yeah, those are definitely some topics that we want to dive into.
00:05:10.968 --> 00:05:26.237
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.
00:05:26.237 --> 00:05:33.586
But now, I mean, you could theoretically have like AIs That teach you how to, to build this stuff, you know?
00:05:33.937 --> 00:05:40.067
kind of does illustrate, I think pretty well, the impact that, that these tools are going to have, like across the space.
00:05:40.836 --> 00:05:46.177
how do you think all of this is going to impact the role of software engineer in 2025?
00:05:46.206 --> 00:05:48.906
So I think, you know, historically you think about a software engineer.
00:05:48.906 --> 00:05:49.877
There's somebody who.
00:05:50.317 --> 00:05:57.257
Is responsible for building things and coming up with novel and creative solutions to very concrete examples.
00:05:57.266 --> 00:05:58.536
how was that going to change?
00:05:58.586 --> 00:06:00.826
as generative AI, changes the ecosystem.
00:06:01.612 --> 00:06:11.452
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.
00:06:11.543 --> 00:06:14.973
Hey, I have an idea and I'm going to work on it and I'm going to implement it.
00:06:15.336 --> 00:06:18.430
start somewhere, you write something and then ideas.
00:06:18.670 --> 00:06:28.290
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.
00:06:28.932 --> 00:06:44.286
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.
00:06:44.757 --> 00:06:52.016
I think it's very important for developers to, not be fully dependent on, these codices, et cetera.
00:06:52.057 --> 00:06:57.877
They're very important to increase the productivity, but people still should learn languages.
00:06:58.216 --> 00:07:04.387
So this is, true and entire potential, so we don't lose this big, big creativity spark that we have.
00:07:04.387 --> 00:07:08.346
So this is like a first comment that I have, like, uh, regarding the roles.
00:07:08.346 --> 00:07:17.357
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.
00:07:17.826 --> 00:07:25.120
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.
00:07:25.120 --> 00:07:37.514
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.
00:07:38.249 --> 00:07:46.749
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.
00:07:47.209 --> 00:07:54.119
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.
00:07:54.949 --> 00:08:18.360
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.
00:08:18.360 --> 00:08:21.754
I'm going to have one agent that does like, Basic code reviews.
00:08:22.175 --> 00:08:28.745
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?
00:08:28.745 --> 00:08:32.585
Where do I have maybe flaky tests that I can come in and fix?
00:08:32.585 --> 00:08:33.955
Where do I have long build times?
00:08:34.442 --> 00:08:48.822
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.
00:08:49.212 --> 00:08:53.072
but that's, the direction that I think like, uh, the industry will go,
00:08:53.534 --> 00:09:02.399
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.
00:09:02.788 --> 00:09:10.239
You know, you think about like a junior developer, they may see efficiency gains from like, adding endpoints to like a standardized API, right?
00:09:10.239 --> 00:09:32.933
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?
00:09:33.673 --> 00:09:33.933
Yeah.
00:09:33.933 --> 00:09:58.203
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?
00:09:58.869 --> 00:10:00.798
the first one is maybe what I spoke about.
00:10:00.808 --> 00:10:10.318
How do you maintain like this creativity spark and ability to, Build innovative products and innovative ideas.
00:10:10.318 --> 00:10:20.491
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.
00:10:20.491 --> 00:10:23.922
And then the ideas like propagate from there.
00:10:23.922 --> 00:10:27.001
So I think people need to, leaders need to maintain it.
00:10:27.001 --> 00:10:38.032
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.
00:10:38.611 --> 00:10:43.412
And then in the sides, you gotta maintain, like, diverse, like, skill set.
00:10:44.121 --> 00:10:50.480
there's languages that people paying less attention and all of a sudden they're saying, things are ramping up again.
00:10:50.480 --> 00:11:06.947
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.
00:11:07.368 --> 00:11:10.038
The next thing is, like, humans.
00:11:10.368 --> 00:11:11.967
Don't forget you're working with people.
00:11:12.447 --> 00:11:27.941
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.
00:11:28.370 --> 00:11:29.990
what are you asking them to do?
00:11:30.400 --> 00:11:34.581
they're feeling threatened right now, by the way, by technology, there's a resistance.
00:11:35.196 --> 00:11:41.115
so if this role, by the way, I think, uh, engineering leaders, the toughest role that exists out there.
00:11:41.115 --> 00:11:42.615
I was an engineering leader.
00:11:43.115 --> 00:11:52.905
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.
00:11:53.216 --> 00:11:56.928
So I think those are like the things that leaders have to pay attention to.
00:11:58.049 --> 00:12:04.570
we've been hearing things about like, we have a round of layoffs that happened at a lot of organizations early this year.
00:12:04.580 --> 00:12:08.490
There's been a return to office mandates like all over the place.
00:12:08.509 --> 00:12:16.179
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?
00:12:16.590 --> 00:12:19.860
You know, so it really does feel like there's a lot of things that are.
00:12:20.100 --> 00:12:23.419
putting like a downward pressure on DevEx.
00:12:23.769 --> 00:12:36.929
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.
00:12:37.370 --> 00:12:47.779
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?
00:12:49.153 --> 00:12:56.933
the term that I have a challenge is developer productivity and we'll get to it later, hopefully, but developer experience is really interesting.
00:12:56.933 --> 00:13:03.811
I think it's kind of in a, it's rich, like, Like this interesting crossroad right now, because, I think two challenges.
00:13:03.821 --> 00:13:08.615
First of all, it has like, um, passive part of what do you measure?
00:13:08.905 --> 00:13:10.365
It's a lot about what do you measure?
00:13:10.760 --> 00:13:44.918
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.
00:13:45.347 --> 00:13:54.168
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.
00:13:54.687 --> 00:14:00.248
But hey, ask me one second after I just completed my task about what was my problem, etc.
00:14:00.557 --> 00:14:02.148
And you'll get a lot of insight.
00:14:02.837 --> 00:14:13.457
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.
00:14:13.778 --> 00:14:15.427
There are things you should be measuring.
00:14:16.398 --> 00:14:17.878
You should be measuring your build times.
00:14:18.748 --> 00:14:32.528
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.
00:14:33.107 --> 00:14:36.177
Now you know, okay, next time you won't trust your, test suite.
00:14:36.177 --> 00:14:47.020
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.
00:14:47.650 --> 00:14:51.100
So again, I, I, I was starting with the measure part.
00:14:51.100 --> 00:14:55.447
I think, we got to jump to the next level where you combine, qual and quant.
00:14:56.557 --> 00:15:13.467
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.
00:15:14.268 --> 00:15:19.048
and there's, almost a thirst, like, to platforms that, you know, fix these things for me.
00:15:19.350 --> 00:15:21.000
and it's not that complex.
00:15:21.010 --> 00:15:34.846
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.
00:15:35.456 --> 00:15:40.306
Um, if my tests are not stable, we can deploy agents like to fix these bugs.
00:15:40.306 --> 00:15:44.186
So, I think like, um, What, what excites me?
00:15:44.559 --> 00:15:48.330
I think there are good frameworks inside the developer experience.
00:15:48.340 --> 00:16:00.610
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.
00:16:01.306 --> 00:16:08.936
We believe, and I believe, In not just showing you where the problems, giving you tools to actually go and solve these problems.
00:16:08.936 --> 00:16:14.056
and I think that's like the, the leap that the, the developer experience movement will probably make this year.
00:16:15.360 --> 00:16:25.191
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.
00:16:25.230 --> 00:16:34.615
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.
00:16:35.056 --> 00:16:45.938
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.
00:16:45.979 --> 00:16:53.219
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.
00:16:54.135 --> 00:17:03.895
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.
00:17:04.246 --> 00:17:14.181
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?
00:17:14.191 --> 00:17:22.921
And oftentimes you, you hear anecdotes about, particularly frustrating things for them that are specific and maybe that you're referring to are solvable.
00:17:23.221 --> 00:17:28.401
And so how do you think leaders can address, that imbalance for that experience for them?
00:17:29.375 --> 00:17:33.285
I think you're touching a good point, like, There are people all the time.
00:17:33.345 --> 00:17:39.795
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?
00:17:39.795 --> 00:17:45.474
How do I, have the right processes in place and how do I make sure like I'm creating the right product?
00:17:45.484 --> 00:17:47.994
That's like I think the, for engineering leaders.
00:17:47.994 --> 00:17:53.138
comes to Burnout, a lot of times it will be like kind of like together, unfortunately.
00:17:53.138 --> 00:17:55.058
Like somebody will say, Hey, I'm like burning out.
00:17:55.469 --> 00:17:59.078
And probably, probably they're working too much.
00:17:59.098 --> 00:18:10.409
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.
00:18:10.729 --> 00:18:15.858
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
00:18:16.569 --> 00:18:17.569
we've all, we've all been there.
00:18:18.128 --> 00:18:27.545
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.
00:18:27.934 --> 00:18:36.345
Unfortunately, um, it comes together and then people and it's like a bad snowball effect, right?
00:18:36.464 --> 00:18:38.424
Because we talked about.
00:18:38.824 --> 00:18:42.703
before like companies need to invest more in developer experience.
00:18:42.703 --> 00:18:48.104
It's hard for them sometimes to see that it will bring, better productivity.
00:18:48.616 --> 00:18:56.416
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.
00:18:56.791 --> 00:18:58.602
But it's taking very much.
00:18:58.632 --> 00:19:02.882
Then they're working, they're just compensating with it on it with like a lot of hours.
00:19:03.291 --> 00:19:07.614
and that's like a vicious cycle that they're in.
00:19:11.931 --> 00:19:14.820
Pardon the interruption, but did you know tomorrow's the big day?
00:19:15.340 --> 00:19:23.080
On December 11th, Dev Interrupted is taking over The Melody in San Francisco, an evening crafted by us for engineering leaders just like you.
00:19:23.621 --> 00:19:36.320
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.
00:19:37.121 --> 00:19:44.191
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.
00:19:47.556 --> 00:20:08.566
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.
00:20:09.006 --> 00:20:12.326
organizations who are providing more freedom to developers.
00:20:12.326 --> 00:20:12.355
Yeah.
00:20:12.490 --> 00:20:16.101
Maybe seeing more experimentation and new use cases emerging.
00:20:16.411 --> 00:20:28.637
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.
00:20:28.905 --> 00:20:33.586
Specific to their organization, like how generative AI can impact it.
00:20:34.076 --> 00:20:42.685
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?
00:20:43.329 --> 00:20:54.039
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.
00:20:54.853 --> 00:20:59.752
when I was a young manager, I always like, I always wanted to like think about how to.
00:21:00.063 --> 00:21:07.343
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.
00:21:08.282 --> 00:21:11.843
It's the same with raising kids, rather than fall.
00:21:12.012 --> 00:21:15.252
So, uh, you gotta choose where you, focus on.
00:21:15.522 --> 00:21:25.643
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.
00:21:25.643 --> 00:21:25.823
Thanks.
00:21:26.788 --> 00:21:33.867
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.
00:21:34.268 --> 00:21:42.248
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.
00:21:42.248 --> 00:21:44.127
Why do I allow and why do I don't allow?
00:21:44.820 --> 00:21:49.381
And then companies have to have like a strategy and a philosophy on.
00:21:49.675 --> 00:21:56.435
Okay, in these areas, it's okay that we use different technologies and we try different things.
00:21:56.855 --> 00:22:00.355
but I don't know when things go through the development pipeline.
00:22:00.385 --> 00:22:04.506
At the end of the day, we gotta meet some compliance requirements.
00:22:04.506 --> 00:22:07.848
We gotta go through SOC 2, whatever like, our processes.
00:22:08.385 --> 00:22:11.645
Then it's okay to have more uniformity in those areas.
00:22:11.655 --> 00:22:13.816
Like these are the checks that are being done.
00:22:13.816 --> 00:22:25.155
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.
00:22:25.615 --> 00:22:30.401
And there are some languages that even let you run, write rules and program your pipeline.
00:22:30.401 --> 00:23:02.171
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.
00:23:03.381 --> 00:23:05.361
Going back to the example of where to follow.
00:23:05.361 --> 00:23:13.040
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.
00:23:13.651 --> 00:23:17.161
This is one out of 10, nine out of 10 let the mistake happen.
00:23:17.161 --> 00:23:17.611
It's fine.
00:23:17.611 --> 00:23:19.471
Like this is how people learn and how they improve.
00:23:20.896 --> 00:23:21.086
Yeah.
00:23:21.086 --> 00:23:26.517
I'm pretty sure my kid's school calls that a natural consequences for living with natural consequences.
00:23:27.311 --> 00:23:29.231
Yeah, it's actually a great learning technique.
00:23:30.259 --> 00:23:35.699
let's get into the topic of productivity now or developer productivity or software engineering productivity.
00:23:36.088 --> 00:23:42.378
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.
00:23:42.554 --> 00:23:50.034
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.
00:23:50.534 --> 00:23:59.044
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?
00:24:00.038 --> 00:24:09.034
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.
00:24:09.044 --> 00:24:11.094
This is the term, it's here to stay.
00:24:11.743 --> 00:24:14.933
But if you do an analogy to sales.
00:24:15.394 --> 00:24:18.304
For example, and people use a sales efficiency.
00:24:18.304 --> 00:24:22.127
So two things like, they use the word efficiency and sales.
00:24:22.147 --> 00:24:23.647
It's like the action that you do.
00:24:23.728 --> 00:24:26.238
It's not like, uh, the people who do it.
00:24:26.577 --> 00:24:29.097
So it's how about, how do we improve the process of sales?
00:24:29.667 --> 00:24:35.907
And unfortunately here, not only we didn't choose the action, we choose people.
00:24:36.097 --> 00:24:39.857
And instead of choosing plural, because I think development is team sports.
00:24:40.827 --> 00:24:41.728
You work together.
00:24:41.728 --> 00:24:42.307
Everybody does.
00:24:42.877 --> 00:24:47.968
We choose in this term and I say we like the people chose this term, single developer.
00:24:48.278 --> 00:24:51.367
So it's kind of a loaded term because when you say developer productivity, Oh, what do you mean?
00:24:51.367 --> 00:24:56.018
This is the thing that you measure the developers and you stack rank them.
00:24:56.057 --> 00:24:56.357
No.
00:24:56.357 --> 00:25:03.008
So this is why I think people get need to go, uh, see beyond the term, the term developer productivity to mirror presents.
00:25:03.008 --> 00:25:06.417
How do you increase the efficiency of the development process?
00:25:06.417 --> 00:25:14.723
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.
00:25:15.284 --> 00:25:22.374
I think what the theme that I'm seeing in the, in, in developer productivity that is really interesting is all these contrasts.
00:25:22.403 --> 00:25:34.453
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.
00:25:34.453 --> 00:25:34.483
Yeah.
00:25:35.574 --> 00:25:38.773
On the other hand, it's like, how do we put controls on it?
00:25:38.983 --> 00:25:44.304
And how do we, um, not forget about our people and like apply the human factors?
00:25:44.314 --> 00:25:46.503
That's a big challenge for developer productivity.
00:25:47.473 --> 00:26:07.393
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.
00:26:07.542 --> 00:26:09.413
Oh, five days at the office.
00:26:09.413 --> 00:26:10.093
No, hybrid.
00:26:10.093 --> 00:26:18.377
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.
00:26:18.597 --> 00:26:19.538
That's what we do.
00:26:20.153 --> 00:26:28.828
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.
00:26:29.159 --> 00:26:35.209
Uh, so I think the biggest challenge, the theme is this contrast and how you do balance all these, uh, contrasts.
00:26:35.704 --> 00:26:38.625
that's I think the biggest challenge of, developer productivity.
00:26:38.625 --> 00:26:47.896
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.
00:26:49.161 --> 00:26:53.990
measure it, measure it so they can optimize it and they can start improving it.
00:26:54.000 --> 00:26:59.270
Like, I don't have to attack all the problems at once, but measure the things that are important to you.
00:26:59.641 --> 00:27:02.790
Again, like we said, you find your philosophy, your strategy.
00:27:03.316 --> 00:27:05.036
Where are you in all these contrasts?
00:27:05.445 --> 00:27:06.346
What is your choice?
00:27:06.635 --> 00:27:08.425
Because not choosing is the worst.
00:27:10.175 --> 00:27:11.645
is your approach in all of this?
00:27:12.276 --> 00:27:16.288
Then make sure you're measuring the right things to improve productivity.
00:27:16.288 --> 00:27:25.338
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.
00:27:25.338 --> 00:27:26.638
I hope it makes sense.
00:27:27.690 --> 00:27:31.650
I really like how you framed the discussion as being polarizing.
00:27:31.650 --> 00:27:41.980
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.
00:27:42.279 --> 00:27:48.755
And you touched earlier on the human factor of working with other people and communicating to each other.
00:27:48.755 --> 00:27:53.365
Do you think that that is the real secret sauce here to developer productivity?
00:27:53.375 --> 00:28:00.744
Is it about finding that common ground between these camps and understanding that the shared goals that You have?
00:28:00.744 --> 00:28:10.785
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.
00:28:11.035 --> 00:28:14.672
How would you, give them advice to try to find, a common perspective?
00:28:15.858 --> 00:28:22.688
I think leaders have been living this reality for a long time, like Engineering leaders have seen this, almost parallel universe.
00:28:23.417 --> 00:28:26.314
We call it sometimes the dual mandate, for years now.
00:28:26.753 --> 00:28:39.079
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.
00:28:39.079 --> 00:28:41.054
It's, uh, what do we need to improve?
00:28:41.064 --> 00:28:44.253
Like, how do we improve developer experience, our development pipeline?
00:28:44.263 --> 00:28:51.720
Like, where are we in the cloud, you know, cloud native development like Kubernetes adoption, all fascinating topics.
00:28:52.259 --> 00:28:58.940
Then you turn to the other side and you speak to the business and they don't, it's like
00:28:58.965 --> 00:28:59.675
have no idea.
00:28:59.726 --> 00:29:00.215
they have no idea
00:29:00.259 --> 00:29:02.470
they don't need, it's like, yeah, any of it is.
00:29:02.480 --> 00:29:08.349
So I think for leaders for a long time, they had to do this trick where.
00:29:09.434 --> 00:29:10.744
Connect the dots trick.
00:29:10.904 --> 00:29:18.305
I always like to say, Hey, put some key metrics, take some key business metrics and just draw a line between them.
00:29:18.315 --> 00:29:21.125
So, uh, the business understand, but it's an art.
00:29:21.194 --> 00:29:23.365
You gotta be great at this.
00:29:23.365 --> 00:29:25.761
So I think, same goes here.
00:29:25.761 --> 00:29:30.118
It's like, at the end of the day, that's the human charm, like, uh, good leaders.
00:29:30.999 --> 00:29:32.398
It doesn't have to be like engineering.
00:29:32.409 --> 00:29:34.118
There's good team leaders.
00:29:34.368 --> 00:29:42.859
Good tech leads, good developers can bridge between like these, these can find like the, path of like, what do we take from this?
00:29:42.983 --> 00:29:47.550
even if you look at like, I don't know, a hybrid versus, there's a middle ground here.
00:29:47.550 --> 00:29:49.931
Maybe you work two days from office.
00:29:49.931 --> 00:29:51.631
I'm just throwing an idea.
00:29:51.631 --> 00:29:53.641
Um, I think that's the, that's the key.
00:29:54.712 --> 00:30:09.803
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.
00:30:10.142 --> 00:30:12.332
That actually helped expedite a lot of things for me.
00:30:12.372 --> 00:30:18.672
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.
00:30:18.672 --> 00:30:23.192
It was quick to jump in on context of things that was going on around me.
00:30:23.548 --> 00:30:39.282
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?
00:30:39.292 --> 00:30:41.752
They're, they're hungry and they're excited to go in next year.
00:30:42.022 --> 00:30:44.583
Maybe they're taking over a new team or a new project.
00:30:44.833 --> 00:30:47.913
You know, there were opportunities for me to take advantage of new tools.
00:30:48.228 --> 00:30:54.748
What opportunities do you see for them to, uh, maybe be, um, you know, a better leader going into next year?
00:30:55.859 --> 00:31:06.638
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.
00:31:07.286 --> 00:31:17.394
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.
00:31:17.394 --> 00:31:27.884
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.
00:31:28.544 --> 00:31:48.534
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.
00:31:48.574 --> 00:31:51.263
How do you allocate your, uh, resources?
00:31:51.273 --> 00:31:52.433
Where do you invest time?
00:31:52.433 --> 00:31:53.413
And why did you choose?
00:31:53.990 --> 00:31:55.039
just don't forget about that.
00:31:55.039 --> 00:32:00.176
That's my, uh, First, suggestion, measure the things that you believe in.
00:32:00.653 --> 00:32:04.324
Choose what you measure and, and, and, but the things that you believe in.
00:32:04.324 --> 00:32:08.653
And, you know, some people's styles like, okay, collaborate with a team and decide.
00:32:08.653 --> 00:32:14.403
Some people say, okay, uh, on some things I am going to collaborate, but here are the top things that I'm measuring.
00:32:14.804 --> 00:32:22.973
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.
00:32:22.983 --> 00:32:25.114
You can't optimize what you're not measuring.
00:32:25.834 --> 00:32:30.559
I have examples where I've seen like, people in the past saying, we measured a bunch of things.
00:32:30.660 --> 00:32:32.049
We know where we are now.
00:32:32.660 --> 00:32:33.220
We're good.
00:32:33.605 --> 00:32:37.276
so we're going to put the focus on other things, not measuring.
00:32:38.355 --> 00:32:42.655
I always tell them, can you imagine a VP of sales?
00:32:43.191 --> 00:32:52.464
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.
00:32:53.765 --> 00:32:58.095
I know, I know where the problems are, we measured it, so I now know where my problems are.
00:32:58.095 --> 00:33:01.585
I'm gonna stop measuring, so I don't, I won't know how many opportunities we have.
00:33:01.585 --> 00:33:06.204
I won't know, like, where do I have bottlenecks in my funnel.
00:33:06.894 --> 00:33:11.758
We need to get to that level where people understand that, like, this is uh, basic level.
00:33:12.057 --> 00:33:17.321
I think people need to require more from systems that help them do that.
00:33:17.352 --> 00:33:29.412
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.
00:33:30.201 --> 00:33:35.551
and then I will go like we talked about define your philosophy, invest, invest in that.
00:33:35.561 --> 00:33:41.961
Go, go speak to other leaders, to the people that report to you, to your peers.
00:33:42.771 --> 00:33:45.051
we're getting close to the end of the year.
00:33:45.586 --> 00:33:46.606
. So it's a good time.
00:33:46.606 --> 00:33:59.413
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.
00:33:59.472 --> 00:34:02.742
Uh, if you do that, choose your philosophy.
00:34:02.742 --> 00:34:05.224
Go with, your strategy, and.
00:34:05.920 --> 00:34:06.460
Deploy it.
00:34:06.730 --> 00:34:12.579
And then don't forget at the end of the day, it's still this framework of people, process, product.
00:34:12.920 --> 00:34:14.679
So don't forget about the people element.
00:34:14.822 --> 00:34:16.393
I'll keep mentioning it.
00:34:17.409 --> 00:34:17.869
Wonderful.
00:34:17.898 --> 00:34:23.315
So you've shared lots of great advice for engineering leaders going into next year.
00:34:23.585 --> 00:34:26.465
I've just got one more question for you before we head out.
00:34:26.548 --> 00:34:28.579
do you have any bold predictions for next year?
00:34:28.628 --> 00:34:32.349
Like things that, that you really want to just stand out?
00:34:33.115 --> 00:34:33.835
Yes.
00:34:33.976 --> 00:34:35.306
Here's what's going to happen.
00:34:35.356 --> 00:34:36.436
And it's scary.
00:34:37.023 --> 00:34:40.304
I predict that productivity will go down next year.
00:34:40.414 --> 00:34:41.594
It will decrease.
00:34:41.704 --> 00:34:42.105
Wow.
00:34:43.023 --> 00:34:46.708
I think, if you can, again, it's, you don't have a single metric.
00:34:46.739 --> 00:34:53.349
You're measuring a bunch of things, but at the end of the day, it will, it will actually, uh, decrease a little bit.
00:34:54.039 --> 00:34:54.748
Why?
00:34:54.778 --> 00:35:01.704
Because in every change that you go through, We talked about it, like people still experiment here, experiment there.
00:35:02.125 --> 00:35:04.454
There's gonna be a lot still like moving parts.
00:35:05.034 --> 00:35:14.663
And every adoption of a new technology or change, like you first go through this like dip where, should I really do this?
00:35:14.672 --> 00:35:16.262
Like, how does that work?
00:35:16.302 --> 00:35:18.422
Um, you'll still get the resistance.
00:35:18.432 --> 00:35:19.862
There's a lot of resistance, by the way.
00:35:19.862 --> 00:35:21.773
Developers are worried.
00:35:21.882 --> 00:35:24.023
So you still get this resistance.
00:35:24.422 --> 00:35:26.273
people will need to feel comfortable with it.
00:35:26.393 --> 00:35:32.929
So I actually predict it will take sometime and then it will, climb back up and then this change will be amazing.
00:35:33.150 --> 00:35:38.342
Then you'll get this like, uh, 10x promise or, or, or, but it won't happen overnight.
00:35:38.342 --> 00:35:41.702
I don't think next year will be like, uh, great.
00:35:41.702 --> 00:35:49.282
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.
00:35:50.378 --> 00:35:51.088
It won't happen.
00:35:51.088 --> 00:35:52.568
It maybe even go down a little bit.
00:35:52.577 --> 00:36:02.724
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.
00:36:02.775 --> 00:36:05.684
Then you'll get this like a productivity gain.
00:36:05.684 --> 00:36:09.235
So yeah, also we need to manage the expectations around that.
00:36:09.632 --> 00:36:10.902
but that's my bold prediction.
00:36:11.795 --> 00:36:24.425
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?
00:36:25.291 --> 00:36:26.652
I would ask them one thing.
00:36:27.262 --> 00:36:28.481
Hey, are you data driven?
00:36:29.489 --> 00:36:33.349
Data driven, it doesn't mean, hey, do you have the right metrics?
00:36:33.559 --> 00:37:00.568
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.
00:37:01.148 --> 00:37:12.789
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.
00:37:12.798 --> 00:37:13.809
So that's the one question.
00:37:13.809 --> 00:37:17.871
Hey, are you, you become data driven in your R& D organization?
00:37:18.222 --> 00:37:19.472
I think that's the one question to ask.
00:37:20.617 --> 00:37:21.148
Wonderful.
00:37:21.188 --> 00:37:24.277
Well, thank you so much for joining us today, Ori.
00:37:24.315 --> 00:37:27.324
it's always a pleasure to have your insights to share with our audience.
00:37:27.938 --> 00:37:34.179
Yeah, probably, I got a lot of things wrong, so, because I'm not a prophet, so I'm just using my insight.
00:37:34.239 --> 00:37:37.106
But thanks, it was great, just being here, great questions.
00:37:37.106 --> 00:37:37.286
Thanks.
00:37:37.507 --> 00:37:39.086
that's it for today's show.
00:37:39.246 --> 00:37:41.987
thank you to our audience for joining us all the way to the end.
00:37:41.987 --> 00:37:54.664
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.
00:37:54.945 --> 00:38:04.094
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.
00:38:04.414 --> 00:38:14.436
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.
00:38:14.695 --> 00:38:15.956
So thank you everyone.
00:38:15.996 --> 00:38:16.905
We'll see you next week.
