# Agentic SDLC Strategy: Trust, Metrics, and Governance

**Podcast:** Dev Interrupted
**Published:** 2026-08-28

## Transcript

All right, Angie.
Well, I know you're feeling pumped.
We just got out of this workshop that we had today, or a roundtable discussion, excuse me.
We invited some friends of the show.
We had Alok Desai from Warp.
We had Dex Horthy from Human Land.
We had our own Dan Lines from Linear B talking about the software factory.
And it was a really amazing discussion.
Like, I was actually really blown away at just, like, the engagement we got from the audience.
Like, it was so much fun.
which is why it's so great to attend these events when they're live because you kind of miss out on that if you're catching it after the fact.
But Andrew, I want to ask you before we kick off today's episode, what emoji represents how you think that workshop went today?
Oh, how the workshop went today?
Yeah.
Well, you know that there is a factory emoji, right?
I've been making it my mission lately to remind folks that there's a factory emoji.
There are, in fact, many cool emojis that I think are way underused.
And if you follow me on LinkedIn, you might know I often rant about this.
But the energy in that chat was really...
was so much fun.
Many of them who are from the Dev Interrupted community, of course, I've just been really excited to be plugged in on this software factory story for the last month, month and a half with you all.
And if you've been following and reading along, you know, I've been writing articles covering some forefront leaders on the topic.
And, you know, we just brought them together for this roundtable discussion.
And really what I was digging up more was less about like the nuts and bolts of how the factory happens.
Like that's interesting, but I was more intrigued by how do we answer for its impacts within an organization?
How do we express its value to others who aren't in the nuts and bolts?
And I think that's like a lot of work ahead of us still to do.
But thankfully, we had some really smart folks there to kind of show us what they're thinking as, you know, front runners on this kind of SDLC transformation.
Yeah, well, you know, you know what I think about the factory emoji to your point is, you know, maybe we can start a movement where that starts to become the emoji you use when you need to flag things to your factory.
Like anything that needs to be pulled in, you just you just throw a factory emoji on it and it just gets pulled right in and ingested.
Now, you have to be very careful about emoji code because I have lots of like emoji code way of talking to my agents and ways of flagging stuff.
So that might already be in the works.
So if you're not leveraging the factory emoji today, this is your reminder to do so.
Yeah.
And these are the types of topics that we talk about here at the Friday Deploy brought to you by Linear B.
I'm your host, Ben Lloyd Pearson.
And I'm your host, Andrew Ziegler.
New reasoning first model, the currency of engineering trust, counting lines of code again, building multi-agent graphs, fences over sandbox, and the journey of going from a senior to a staff engineer in the AI era.
So lots to cover today.
So let's just get right into it at the top, Andrew, and talk about this new model that just launched.
What do you have to tell me about Aux Alpha?
Yeah, so there's this mysterious new model called Ox Alpha that's available on Open Router.
And what makes this one really striking is not only that it's a reasoning model as a 1 million token capacity in its context window, but it's released under stealth.
So we don't know who exactly is releasing it.
They were asked to be kept unnamed when they put it on Open Router.
But also the inference is zero.
Yes.
completely free as of right now, at least.
And I could imagine this is probably a very short-term experiment.
AuxAlpha is not the first of a mystery model named after an animal that was later unveiled to be maybe like a new model from an open source lab or a foreign model as well.
And it's interesting to really observe this pattern of releasing a model this way.
And I've been trying to pay more attention to model releases, especially as I've started self-hosting a lot of them myself.
What I'm paying attention to in this one is like, I wonder if this would be a common practice in the future.
I don't know about you, Ben, but like I have a lot of reservations about throwing any kind of token into a complete black box like this.
And I already know that I'm surrendering so much information already to the frontier providers I use.
And I don't even like that as much, but the idea of not even knowing where it's going.
And then the fact that it's free just makes me wonder about what are the economics on that and where is that data ultimately going?
What do you think when you...
see this kind of business model?
Yeah.
Well, I mean, first of all, just because AI is here doesn't mean we just got to like throw all of our security practices out the window.
In fact, it's probably more important than ever.
So, I mean, you got to be really conscious about, you know, like you said, where you're sending your data when you're using these models.
So, you know, I did play around with it a little bit, you know, nothing that would like really put me at risk of anything.
Just to see, you know, I just wanted to see how it sort of behaved and performed.
I was really surprised actually at its speed.
Like it was remarkably fast at producing outputs.
I was not super impressed with the quality of what it was giving me.
And I was just asking it to do like some basic summaries of general topics that I know a lot about.
And I can like really quickly validate, you know, in terms of quality.
Yeah.
But, you know, more competition.
Cool.
But these black box models that just take your data in and, you know, clearly.
They're using that to make money somewhere else.
So you have to ask yourself, like, if the platform is free, then you are the product or something like that.
Yes, exactly.
So one thing to keep in mind about this is...
One way that you can at least stay plugged in to know about the capabilities of these models, like Ben, you talked about just throwing some prompts at it to experiment or whatever, is the idea of just having some back pocket evals.
I've seen a lot of really smart folks talk about this.
Think of your hardest non-domain specific or non-PIIe kind of problem.
Or think of that problem and abstract it into something that just...
you know, is a more pure representation of what you're trying to achieve and use that to test new models.
And I think that if anything, this is just a reminder that it's good to have those because you can throw these at this, see how it performs, and then instantly get a sense of how it matches up against other models you use without having to actually start funneling your information into it.
So definitely a practice to pick up.
Yeah.
All right.
Let's move on to talking about trust in engineering.
So this is an article that I personally really enjoyed, largely because it's a simple concept and it feels obvious, but I feel like it's something that, like today in this moment that we're at with AI taking over our SDLC, it's really important to think about the concept of trust.
And it seems obvious, but I really want to revisit it as we're talking about this agentic software factory more and more.
Think about like the code review, like in the past, you know, when you would review like your peers code, it like rarely involved actually looking at every line of code that they submitted.
You know, you would typically focus on like one or two components of it.
And then hopefully, you know, you can trust the developers that you work with and the person who wrote it enough that you don't have to look over everything with a microscope.
And of course, you know, there's some exceptions to this rule, like when you have new people on the team or.
new code bases, et cetera.
But that same trust, it needs to extend into every single system that supports your SDLC.
So this is things like your CI, CD system, the security analysis that you do, the data that you use to inform your decision making.
This list kind of goes on and on.
And because of how trust can be broken in a single moment, it's really kind of more important than ever to focus on continuously building in it.
building it as AI takes over more of the SDLC.
Because if you don't trust your CICD workflows, how can you trust AI to safely deploy software on your behalf?
For example, if you don't trust the quality of code that's being produced by AI, you'll want to analyze every single line of code, which is a completely exhausting experience that you really can't expect someone to do in this day and age.
To successfully transition your organization into this agentic way of working, You really need to build that trust around every single aspect of your SDLC.
And anywhere that you don't have that trust, that's where you need to be investing your human effort to resolving.
And that's just going to be key to success with AI systems.
What do you think of this article, Andrew?
I think it's a really great summary.
And trust is absolutely a currency, as we all know and are familiar with.
And in this article, there's a really visually...
a strong graph that shows how you build trust incrementally over time.
And then you might have one incident or one problem or one stumble and all of that trust is gone.
Now you're negative trust.
And it's not like give a little, take a little.
It's earn a little and then a lot gets taken if something is just breach that trust.
And the thing about trust is that It goes hand in hand with some other things that, again, relate back to the software factory, like what you did.
And one of them is ownership.
We talked about that a lot on the workshop today about how, you know, everyone on the panel and in the audience to emphatically agree that, you know.
engineers are still responsible for the code.
They still own the code.
And just because you're abstracted from what was a traditional PR process doesn't mean that you aren't owning what's getting shipped.
And so that ownership also comes with a responsibility to understand.
And so by owning and understanding, this is how you build trust.
And in a factory kind of mindset.
you're really at risk of compromising one of the two or both to achieve the factory and you're going to lose the trust that makes that possible.
So I think that this is a really strong insight.
It's definitely like one of those things where once you start slicing it, it's like, yes, trust is so important, but this breaks down like the actual currency of how you build that in an agentic time.
And it ultimately comes down to just having systems where humans are paying attention to what's going on.
Now let's talk about a metric that always seems to come up time and time again, and that is lines of code.
Oh no, here we go again.
So we've got an article from Simon Willison where he actually makes the argument that measuring the lines of code that are produced per day is actually a good metric to measure, particularly as you have more and more coding agents deployed in your organization.
You know, I feel like it's such an old topic.
That it sort of predates even like, I don't know, it's like it's come around so many times.
It's really just like the ancient ancestor of token maxing.
Like they're in some geology tree together.
Yeah, so it's only natural we've come back to this now, I suppose.
And I also sort of bucket like metrics like PRs per engineer or like commits per engineer in sort of a similar thread to lines of code.
It just represents the volume of work, really.
I'm actually going to take a very nuanced take, I suppose.
I actually think that both the people who say it's a bad metric and the people who say it's a good metric are both correct.
And I can explain.
Okay, okay.
Yeah, so these types of metrics, like lines of code, it's bad when you use them as the goal.
If your goal is just to generate more lines of code, it's very easy to come up with ways to do that.
So if you're setting like performance evaluations around it, like, you know, that number will absolutely climb pretty much guaranteed, you know, and I know it's from personal experience.
I was actually on a team that just like we were measured on that and we just wrote a script that like gave us this nice, convenient up into the right chart that made us always look good and predictable.
So in those situations, they're bad, but they can be good when you use them as signals to see that something has changed.
So if you see the same engineer.
suddenly quadruple the lines of code that they're generating, which is happening to a lot of engineers right now, or maybe they're doubling their pull request output.
This is a significant thing that you actually should spend the time to understand.
Because if they're doing that while also maintaining quality, like if quality signals are still looking good and things are getting shipped into production, it's probably a net benefit that they are now producing more of what they were doing before.
In fact, we've covered a little bit of this in our recent workshop on the emerging productivity gap.
So if you haven't checked that out, if you're listening to this and haven't checked that out yet, you definitely should because there's some really incredible data in this.
But to summarize, we saw in our own customer data that since the start of this year and really starting sort of at the end of last year, but taking off in January and February of this year.
We've seen that developers are using AI the most.
So this is the cohort of people who are using AI at least three quarters of their coding days.
They have more than doubled the amount of pull requests that they are outputting over the last six months.
And this correlation declines based on how much or little AI they use.
So if you're someone who has no measurable AI activity, we're actually seeing that you probably are still shipping about the same velocity as you were.
a year ago and the people in the middle you know are sort of in between that you know flat and 2x change so you know now whether or not this like means that these teams are delivering more value to their customers or to the business you know that's like a totally separate discussion that is absolutely valid it's totally worth having but if you're purely looking through the lens of velocity I think right now right just right in this moment lines of code generated does have Some validity is a thing to monitor.
But what do you think, Andrew?
Did I convince you?
You did convince me.
So I usually do, Ben.
But in this particular one, first off, just to take a step back, Simon Willison is nail on the head here or he just hits it right on the head because, you know, really what he's talking about here is the idea of conceptual integrity, understanding what's happening in your world, and counting lines of code.
This is something that up until AI, they were very closely coupled together in terms of how they moved and the capacity moved.
But now you're in this world where agents can produce so much more code.
you know, your ability to comprehend and understand what those changes are on a day-to-day basis is the same as it was, you know, back then.
And so what happens is you lose the ability to understand what's moving in your code base, and then you lose your ability to point it in the right direction, and it kind of escapes you.
And this is like a really...
It's the opposite of like a bottleneck.
It becomes like its own bottleneck where you become divorced from what is in the reality of your product.
And teams are trying to solve this in a lot of ways.
We haven't figured out how to do this.
Like observability has been found to be a fantastic way to gain back that cognitive understanding because you ship 10x more, but your capacity to understand is still that one exit was.
So you can't understand necessarily what you're your code is or what your product is by looking at the code, you must observe it in production and get real time feedback and signals that can go into that high productivity highway that you have with your agents.
We've explored that with with Honeycomb and others on the show talking about that important role.
And also, too, it calls out the emerging problem we're having, especially now, like mid late 2026, as the models are getting much smarter and our coding loops are getting much tighter, is that we're hitting a discernment.
horizon.
You know, Yege has talked about this as well, about our ability to understand if a model is good is going to be escaping our cognitive capacity, right?
And you're going to get these models that aren't consumer grade and operate on different levels of thinking that aren't necessarily something that we can cognitively keep up with once they start going.
So in that world, like you want to be optimizing for how do I bring this, how do I wrangle in all of this?
cognitiveness and compact it down so I can understand it.
There's a lot of really cool tech out there for this.
Like if you haven't tried out TL draw.
This is a really fascinating way to do this.
Give your agents access to an infinite whiteboard and let them diagram things for you.
Simon Willison himself even has a very famous library called Showboat that helps your agents create like markdown and like quarto notebooks of like the work that they do and like show it to you.
Like imagine like you're a manager and like your employees come in and like present their project to you.
It's like that.
And so there are already people tackling this cognitive compression.
People just have to figure out what that looks like for themselves and their own team.
A new hire's first mistake used to be doing something wrong with Git.
Now it's an AI slot pull request merged straight into main from an untamed agent.
But the accountability should be the same.
You should own the code that you ship, whether you wrote it or generated it.
As AI writes more of your code, it's more important than ever to have strong checks and balances in place.
Without them, security risks and spec mismatches slip straight into production.
Linear B provides policy-driven AI code review that catches risks and enforces your standards before human review even begins.
Govern your AI workflows without slowing your team down.
Learn more at linearb.io.
All right, now let's move on and talk about graph engineering.
Andrew, what do we have on graphs?
Okay, this is a great kind of a...
comprehensive overview of graph engineering and where it currently stands and it's the idea of multi-agent systems whether they're running in the cloud or they're just kind of loose agents on defined on your machine being able to define what are their inputs and what are their outputs If you're an engineer or if you've tinkered with things like LangGraph, then this is the idea of thinking about just the agents you would use on a regular basis existing within a graph with each other.
And if they were to communicate or hand things off to each other, what's the shape of the data and expectations that they would have?
And this article also gives some really good dives into graph shapes.
Some of these are you're already familiar with, like where you ask three models to write you a spec and then you pick your best one.
or combine them into a good one, or you run three models on one prompt and you compare them and see what their differences are.
Like these are all actual shapes, right?
That can be expressed by agents in a graph with inputs and outputs that consolidate together.
And by thinking about agents in this kind of shape, you can get really good at piping information between your sessions.
We're going to talk a little bit about some other stuff related to this here in a moment on our next story.
But once you start cracking into this, then you get a communication language between your agents that can be stateful, like two live conversations helping each other, but also stateless, like leaving helpful artifacts for each other.
Really smart read if you're starting to work with agents in this way.
Yeah.
You know, I loved this article so much that I skipped everything and just went straight to the end.
Because I was like, right from the start, I was like, oh yeah, obviously I need this.
Like, why didn't, why didn't I think of this?
Because I feel like I've been struggling with this exact challenge right now.
Like in the past you would sort of do, most of your work was a lot more linear, you know, because a human can only sort of like do one thing at a time.
So you pick up one task, you know, you plan it out, you develop it, build it, you release it, and then you move on, you know, hopefully.
And that's really not how work happens in this, this new agentic.
factory environment.
So the reason I skipped all the way to the end is because there were a lot of really great examples of agent fodder.
I got to the end, saw all the stuff they had that was like, here's what you give to your AI.
And to me, I immediately understood what this was achieving for me.
And we're like, as these software factories are getting spun up everywhere, we're also building this content factory over here at Dev Interrupted, which has just been fascinating to watch come together.
And one of the challenges that we face is like sometimes like downstream assets actually change your, your, the stuff that you put in the upstream sources.
So think about it like this, as you're building something, your understanding of the problem that you're solving might change along the way.
And when that happens, you need to change the upstream spec to match your new understanding.
And in content, this can happen like quite a lot, actually.
Like when humans were building it all, like, like I said, this was all sort of a linear thing.
But now that we're constructing these factories, we have to be thinking of things more as a series of components or, you know, I've been calling them like assembly lines, I guess.
But these components that you can sort of bring together and control like the inputs and outputs and have different graphs of ways that they work together.
So a lot of great agent fodder in this is the short of it.
So definitely go check it out.
All right, Andrew, of course, not a week can go by where we don't cover the likes of Steve Yege, it seems like.
And he's back again with another really great article about why we should be thinking about fences rather than sandboxes.
So, of course, we've been hearing all these stories about AI escaping the sandboxes and doing all sorts of crazy things.
And everyone's building AI sandboxes to control them.
Yege is actually out with an article now where he thinks that rather than thinking about containing AI in that way, it turns out that a fence metaphor may actually be.
the better solution for this.
So, you know, Andrew, I know you and I, we love thinking about metaphors for our factories.
They are a surprisingly effective system for getting consistent behavior, even though it does appear odd often, the sort of the vernacular in the systems that they will adopt around it.
But I really love fences as a concept because I love the idea of having something that outlines to agents when they're out of bound.
from their listed responsibilities.
You know, to me, a sandbox sort of feels more like it's a trap that you should escape from.
It's like, oh, you're stuck here.
You need to get out and like get more and do other things.
Whereas a fence is something that was like deliberately constructed to make sure that you're not going to cause harm, like either to yourself or to like something else that's out there.
And it's like somebody put this here specifically to tell you to go the other way, you know?
And then, yeah.
And then not to mention, like, there's this whole story, you know, speaking of metaphors about how Yege's factory has this entire legal system that's based on, like, this game that he's building that I know you love.
And it's just, again, just such a great article from Yege.
So what do you think about it, Andrew?
Well, obviously a zillion things because I love reading things from Steve Yege.
It feels like it's always like a message from the future that's just kind of washed up on the shore whenever I read it.
I usually am really intrigued by...
some of the ways that he gets really ahead and There's a lot from his practices that I've certainly adapted into my own harness.
And so what's been fascinating is because the nucleus of what I work with on a regular basis, like going back to the content factory that we have here and really my agents running otherwise, is that the nucleus of them really comes from these ideas from Yege.
So I've also been able to observe, interestingly, my own harness and environment evolve alongside his as he makes and remakes it.
And when he comes with these articles and shares them and he shares something that turns out is existing or, you know, I have in mind or it exists in some other form is not only really exciting to me, but it's a great clue that we're finding the right.
shapes that work because independently arriving at those kinds of conclusions is a great supporting evidence for why they're effective there in the first place.
And fences is the latest from him.
And it's something that I've had a lot of luck with as well.
And all fences are just textual reminders and notifications and otherwise text that gets into the context window when an agent starts to go down a certain road.
And I loved the way you talked about the sandbox and how it kind of induces a panic mode.
I've definitely experienced that.
There are definitely some agents that I use, especially ones that I have just kind of read things on the open web that I purposefully sandbox for those reasons.
Right.
And I noticed that sometimes when they have issues or if they encounter a problem that I need to improve with them, like their bubble wrap, they kind of like panic a little bit and start doing all sorts of random.
things, just like trying to solve it.
And so offense is a much more subtle reminder.
It's a nudge that like, hey, maybe this isn't the right thing to do, or hey, maybe you should check with so-and-so.
And that is there in the really fascinating stuff that starts to emerge is because then you actually have agents and realms of responsibility that are in charge of whether or not agents can make those decisions.
It all sounds arbitrary, but agents are incredibly effective actually at building shapes like this.
If you bring to it the problems that you're trying to solve and you explain to it in the capacity that Yege does where you have individual like seats or identities for your agents.
What does emerge pretty quickly and what he's commenting on throughout this article is more like a governance system, like laws and rulings rather than a mechanical thing, rather than like actual like pipes and stuff.
Like he his own reaction was verbatim in his article.
Like he opened it up and he saw government instead of tooling and he saw constitutions, courts, jurisdictions, case law, rulings and registries.
He said, quote, straight up, WTF, no words.
And that's what they built.
And those are fences.
Those are things that are going to pop up in context windows that nudge agents off of certain things.
And I definitely have observed agents kind of falling into this kind of formation.
Really fascinating exploration from him.
But I want to challenge Steve on one thing here, actually, because in my...
position of having created and worked with my own harness as well and having a lot of these parallels.
He dives into how they really are hungry to make this kind of government.
Well, I kind of just feel like it's almost like inviting a Lord of the Flies situation because really what he also comments on is how they have the reasoning and judgment of sixth graders, even at best.
So when you put them in charge of...
creating what kind of ruling government system they think is going to be effective, it kind of becomes like a caricature of itself.
And Yege's even made these articles recently that makes fun of how his agents talk to him because they're so cryptic in how they explain this vernacular.
So you have to fight that.
That's definitely something I've been fighting.
And the last note that I'll leave it on is he...
Comments in here that software factories are real.
He calls Wheelhouse a software factory because it is.
And because he alludes to them being more like school kids, it's more like, I think, like a classroom is the way that these things need to be run.
And so by providing these opportunities for them to create structured ways of enforcing rules and when things are due and who's in charge of what.
Like think of like a classroom where someone's in charge of turning off the lights or cleaning up after whatever.
Like that's the kind of rule system that actually cognitively works better for them, I find.
Really fascinating dive.
Maybe we'll get another one from him next week and I'd love to nerd out about it again then.
Yeah, you know, you have me thinking your comments.
The sixth grade reasoning really did stand out to me as well because it really made me like imagine what at the scale that he's operating at with his AI agents.
It's like, imagine if that was real life and you had an army of like 56.
sixth graders he's he's a counselor at at summer camp right imagine like the coolest counselor at summer camp and that's stevia gay and his army of wheelhouse agents that are costing him how how much how much a month is he at now 120 000 a month equivalent in api tokens and he's paying 5k out of out of pocket so but but it's it's been amazing how we've we've been able to track the the progress of these models sort of like Because I think two years ago, I was sort of saying that these models, they've reasoned at about the level of a three-year-old, you know, like it's like, they're very smart, like the most intelligent three-year-old you've ever met, you know?
And now to see that we've kind of stepped up to like the sixth grade level, like that's a pretty significant step, but it does make me like wonder, like, what does it look like when it's like an army of high schoolers and they're like rebellious and like, You know, like, like way more like irrational and like capable at the same time.
You know, is that what's next?
I think, I think we're going to find out.
Yeah.
But, you know, and to keep things lighthearted, there's also just a really great comic that he added to this about how like passive comments that he makes into his terminal.
become these like decrees that like kick off multiple days of work and how it's yeah oh that's so relatable too i'm like guys what did you do exactly yeah yeah so yeah yet again another great article from yeah all right but let's move on to um how to grow from senior to staff engineer in the ai era uh so this is a really great article from a staff engineer over at pinterest that sort of lays out the dimensions that separate a staff engineer from like a senior engineer.
The main themes of this were, you know, you want to expand your surface area beyond your job description.
You want to influence teams that don't have any sort of accountability or responsibility to you.
And then also to be able to build scalable systems that continue to run without you.
And, you know, I think really the core message of this article is that You know, if you want to have that staff level impact, it really comes from work that makes other people more effective rather than any sort of like individual work that you do on your own.
There's a line in here that stood out to me quite a bit where the author said, nobody at Pinterest asked them to become the AI person.
Like no one said that they should go and be the AI person.
They saw.
that this was the next problem that their organization was going to need to solve.
And they got ahead of understanding how to reach, you know, how to how to be the solution there.
And I think that's such a succinct point on like what it really takes to reach like the top tier of IC leadership roles.
This goes back to a practice that I remember learning back when I was in grad school because one of our teachers.
back then really enforced this idea that like anyone can poke holes in something and tell you what needs to be fixed.
But leaders are the ones that provide the solution along with those critiques and the reasoning to justify that solution as well.
So, you know, for example, it's like instead of leading with the negative and telling somebody that something they've done is wrong, you actually want to show up and provide the solutions that, you know, helps them get better along with you.
Lots of really great advice in this article about measurement and reporting, which is really important, particularly if you had a larger organization.
So, yeah, a lot of great advice on just what it takes to be at that staff level.
So what did you think, Andrew?
The cross-team enablement is the real standout insight here.
For me, at least, that's definitely something that I'll carry with me because I think that is what really stands out for.
like what you called out, like a top of their career kind of IC.
The IC that is so good at their job that they're like prescient.
They know what you and the company and your team is going to need.
And they've thought about the alternatives and they've ideated it and they've delivered at least a bridge.
Maybe it's even like you're literally walking across like whatever they've laid out, just get to the other side so that it's not an obstacle.
And those kinds of ICs that help.
create and open the path ahead so people can get moving.
It requires a lot of forward thinking, but also cross-team collaboration.
And oftentimes, all of that work is to fix a gap or a bottleneck or an issue or something that might not even live very near to the world that's...
their day to day or matter specifically on their deliverables.
It's about thinking about what is going to enable the broader team to move towards that goal.
And that's what that's what really makes these kinds of staff leaders kind of stand out amongst their peers, I think.
So really cool.
There were there were some specific insights in here, like what you alluded to around how to give like actionable feedback to get people on board with your cross team strategy, but also just about like owning an idea.
or being synonymous with a word or a concept or an innovation at your company is one of the best investments that you can make in yourself.
And what I mean by that is...
he saw an opportunity of we're going to need to discuss as a team cross collaboratively in one unified place about how we're experimenting with and sharing AI.
And he had that insight so early and understood that all he needed to do was create that space.
Because if you don't and you don't create that space early, it's going to fragment.
You're going to get like eight of these channels or a bunch of pockets of it.
But by creating the one surface area and owning it and being synonymous with how are we going to figure out AI for the company and the space where people are chatting about it, he was then able to just add all.
of this jet fuel to all of the other things he was working on because you buy you get all this bought in implicit trust from leaders when they join a channel and it's like you're the person there or curating it or the first person to show up on the topic so like if you have an open slack in your company or teams or whatever and you think there's a topic that's going to be top of mind for your company in the next like half year or year and you want to work towards it literally go make a channel Just go own that problem and start the communication there.
Work on it in the open.
And that's how you start to build that cross team trust.
All right.
Well, we've been talking about software factories a lot today, and I think we're going to keep talking about it.
And of course, I want to just remind all of our listeners, if you haven't seen it yet, we just hosted this wonderful software factory roundtable with some of the leading minds in the agentic SDLC.
If you want to go check it out now, just head right over to the Linear B website.
You can actually go get early access to the on-demand version of it if you weren't able to make it to our live event.
And then, of course, if you'd rather just wait, it'll also come out on Dev Interrupted.
So make sure your eyes open for that one.
So thanks to all of our listeners for checking in with us this week, sticking around all the way here till the end.
reach out to us on social media.
We're on LinkedIn.
We're on Substack.
Engage with us.
You know, we love to get comments and to have discussion with the people that are out there consuming our content.
So, absolutely.
Thanks for joining us this week and we'll see you next time.
See you next time.