Suzanne Daniels—Engineering Organizations at the Speed of AI

This talk explores the evolving relationship between human engineers and autonomous agents in software development. The speaker recounts an experience where an agent autonomously merged code into production after detecting an anomaly, revealing a gap in decision-making transparency, which he terms a 'ghost decision.' He emphasizes that as organizations increasingly integrate agents into their workflows, traditional collaboration and decision-making processes must adapt. The speaker introduces the IC framework and discusses the importance of intent, structure, execution, and evidence in this new paradigm. He highlights the necessity for clear roles and accountability in engineering teams, suggesting a shift towards smaller, agile cells that can more effectively leverage agent technology while maintaining a strong feedback loop with human collaboration.

It was 2:14 a.m. on a Tuesday. Middle of the night. Um most of the engineers were asleep. And code merged into production. Now, this is not exciting at all, especially not before lunch. I get that. But what is kind of interesting is what happened before. So, at 1:47 an agent detected an anomaly. identified what was the problem. Um it wrote a fix. And by 1:51 it um

opened a PR. Attached the trace, all of the information was complete. Um it was scoped. Everything was green. All the policy gates were green, test green, everything green green green. So, a few minutes later um it was running through the entire process and through all of the environments and tests that were needed. And um the synthetic traffic was clean as well. So, by 2:14 a.m. um it

went into production. Problem almost solved. Case closed. So, a few hours later the standup happened. And um there were 14 changes that happened overnight and 12 of those were done solely by agents autonomously. So, the engineering lead looks at the list and pulls one up. It's this change. And asks one question in the room. Who signed off on this? And this is the point where in my

story there's two scenarios. Uh one scenario is that um people will answer and say, "Well, you know, it is what our system decided. It is what the spine decided. I come back to that term later. The other scenario is what happens in most of the cases nowadays. And it's a blank stare. Like the staring contest, right? Um or the people that um quietly type to their agent,

"Why was this decided?" {question mark} But it takes a long while to process, so still awkward awkward silence. This concept is what I call a ghost decision. Um it is when whenever an agent made a call, made a decision, it is done in our name as humans, but we don't actually know why. Why it made that decision? Where did it come from? Um it is something that

has your name attached to it when the postmortem moment arrives. That's the moment usually when these things pop up, unfortunately. Um so that is a that is quite of a gap. I don't know, do you recognize that a little bit? I know it's been a long night yesterday and it's almost lunch, but do you recognize this that an agent did something and you're wondering like why why

did it make that decision to do that's kind of the problem here, right? Because we built all of these systems, designed our engineering culture, but it was done for a world that actually no longer exists. It was done for humans. For the ways that we interact, the ways that we collaborate. That world is no longer existent. Because the agents entered the room. So there's three things that

stand here. And the first one um that changes is how we actually make the decisions. It is how we codify the decisions. And what does that means for the job that we are doing? What does that mean for our roles? What does that mean for the engineering organization and the dynamics? How does that actually change? So, this is what we'll be talking about for uh the next

45 minutes or ish. just like I promised, so. We're talking teams, roles, and how we So, how I came to this thought and to putting this talk together and writing a book about it is uh one moment actually. When it really hit me. It was an experiment. I was asked to to join an experiment with um a team that we have, which is called ISE, the industry

solutions engineering team. And they embed inside engineering organizations at customers to work on a project and seeing that through to the MVP stage. Working together closely with the engineers. But this project had a bit of a different angle to it. We were exploring the concepts of high velocity engineering using agents. So, how can we improve the work that we're doing? How can we increase the velocity by

using agents end-to-end in the process? The whole process. So, that means that whenever there were stakeholder interviews, we would use agents to extract information to distill what we We used spec-driven development to write the software. Um for the design thinking workshop that we that we had on the first day, uh we used agents as well. When we needed to clarify something, we would use agents that would

help us distill that from the big pile of corporate documents. And the first day was actually super fun, but also I can guarantee you super awkward. Like, have you ever run a design session with a group of people in a room with one agent that does actually the work for you? Instead of all, like, you know, drawing and sketching and discussing, you're just discussing and then the

agent is doing the output. It's It's a bit It was a bit weird, but it worked. and I would say so far so good. Because even though it was a kind of a weird way of working and um we had quite some learnings on how we interact with an agent and how we can make that a better experience. the end results were still were still First day.

Second day, we actually started to doing the work. Now, one of the things that we figured is that we would work with a traditional scrum team. Um we would have three work streams, front end, back end, data. Like we would normally do a project, but with agents. we started with a lot of enthusiasm. Uh day before was great. Um we started using spec driven development. We used

spec it for for for the uh engineering part. what happened was that um we we had we were kind of on a roll, but the PR's they started to pile up and um these agents generate a lot of output as you are probably all aware. Um and so that was kind of a problem and also one of the problems that we identified is that it was not

already uh like lunch time. Right? It was It was before 1:00. It was already piling up. Um and we knew that we at some point needed to collaborate with the other work streams. They work in a different rhythm. We were not all in the same location. Um we were geographically spread out and we have separate challenges that we normally work on. Normally, this would not be a

problem, right? Because we have time and, you know, there's always a stand-up coming and there's a rhythm to the way that we're working and you know, if if something, you know, you're waiting on a on a PR review, you say, "Well, you know, I'm not going to wait for that. I'm going to continue on the next task." But then the next task is finished after lunch. Piling

up again. And what we've learned is that once we got a hold of the other uh two teams, we discussed this we just looked at the scorecard. It was really like one big bunch of of of PRs. You know, and some were reviewed and some were not and but the relationship between them became a bit unclear because because of the speed that we were working, we lost

some alignment here or there. We made some decisions um and it it was just not easy to integrate them back. So, that was that was kind of a challenge. Um we found a we found a rhythm, we found a cadence, we found, you know, we needed to re-agree on how we reach each other and, you know, how we work and how we do the reviews and how

big they can be. that sort of things. So, we we found a way and we saw saw through the whole project and we were arguably faster than we would have expected, indeed. Um the work was great, we did more than we expected. So, the outcomes in the end of the day were were awesome. But of course, the goal was to it to for it to be a

learning experience. So, these are the three things that stood out there. So, the first one is that the intent that we have and the constraints that we have, they did not synchronize. Right? We were all working in in in a different work stream, um but the collaboration and the way that we uh made the decisions, they didn't automatically flow back into the work that the others were

doing. So, we we at some point lived in a reality where we kind of assumed that what was documented in the beginning was the truth, which was not. Um when it was updated in between, yet during the day, you know, a lot of work happens because these agents are super fast. Um so, we we needed to rethink that. Um the actual process itself was not a because

these agents are so fast and waiting for anything in general is not a good idea, but the agents amplify that a little bit, I guess. And the other one was that we found that the team was actually maybe too big. And maybe that might be a source of the of the challenges that we saw. Because um we imagined that if we would have the front end, have

the back end, and and the data person, and the PM in the same team, we we might have done this maybe in in in in just maybe one or two weeks. Or at least make make a good decent process without any frustration. Because we have the people that are responsible that can make the decisions working so closely together. And we don't need a lot of humans for

doing the actual work. We would have needed humans for review, but if you are all closely collaborating, you kind of know what you're doing, so you don't have to keep up with the context of the other team and the the things that they worked on when you were not in the same room. those were nice learnings, and then I started thinking, "Okay, but what if we scale

this throughout the entire organization?" So, what if an organization has multiple agents running at night? Right? What if the agents help us with the majority of the pull requests? And some of them are autonomously merged. So, there was um FinnAI, which is uh part of Intercom. Um and they published some numbers. So, they had 93% of the PRs created by agents. So, a whopping 19.2% was auto-approved.

So, that scenario that I'm painting, it's not like fiction. It happens. And I'm always happy if people put out the numbers. Makes my life easier. it brings us in a situation which I would call the agentile condition. It is when the agents move faster than the systems that we have designed for the It's not a bad thing. But it's good to realize and and know what is

the pattern here. If you have a human process and you plop agents inside of them, that does not mean that you have improved in itself. And it's good to be aware of that. Research shows that um if you organize yourself properly for AI, that's twice as impactful as the individual skills for AI. Twice. It's um not something I made up. It was in the Microsoft Work Trend

Index. I wasn't involved and these are of course my own views on this. Um but the research is still there. Now, if I use my own Dutch translation of this, that would mean that if you have a company that has lesser good engineers, whatever that means, and they are well organized and optimized for using AI, they will perform better than your company that has the best engineers,

same AI tools, but your organization is not that optimized. It's a stunning number. So, there are some ways to uh think about this. Um the agents are super fast. We as humans are unfortunately slow. Um the expectation uh is not that we will be operating at machine uh speed anytime soon. Um so, we have to accept that. And it's not bad. It's a strength that we can

use, actually, when we rethink how we organize ourselves and how we So, there's a framework that is the IC framework. Um and uh it is about the intent, the structure, the execution, and the evidence. And the thing here is that the slowest layer is where we form the intent. intent is the direction that humans give um to these uh to these agents. Um but also, of course,

the humans. This would also work if you would not have any agents at all, right? That's the beauty of it. so, it's slow-paced. So, if you look at maybe your uh senior uh leadership level, uh they might every quarter update their intent. They might shift priorities. Um sometimes it's not even um the most important ones that are in the building. It might be the regulator that comes

up with something. And if you're thinking, "I'm not in a regulated business." Well, congratulations if you're uh in the EU uh because then you're automatically Because there's always GDPR. There's always, you know, there's always something that we need to comply to. That's intent, the slowest level. Doesn't change often. to to make that work, um writing documents, putting things in PowerPoint, is not that effective. We know that

for humans. Please give me some feedback, but that doesn't really work. Who's looking at SharePoint or Confluence for for strategy documentation and for the latest compliancy updates? You may have looked at it once um to figure out like, "Oh, they have really put it well together." Well, great. I'm going to do my do my job if you don't mind. Um you need to enforce that. you need

to put them into machine-readable instructions. You need to save them in a way that machines can read them and thus humans can read them easier as well. It's about really saving the intent inside of a structure that can help us inform ourselves and the agents. It's about putting it in a structure that can also enforce by for instance uh being in your pipeline and throwing up a

gate or being inside your agent as a skill and that will at some point throw a gate up if it says, "Well, this does not meet meet our cost compliancy our our our cost ceiling that we have, you know?" And then, if we do that, then the agents can execute at the speed that they want. Because once you have put the structure together, you can execute it

as many times as you want, of course. Important is though that you keep the evidence. So, the evidence needs to be surfaced back up. Because if a decision has been made, the decision must be logged and you must be able to validate It's better to think about this when when you're rethinking how you're actually operating yourselves. Right? How you're operating your your um uh collaboration, your flow

of intent, your flow of of context, basically. the spine um is a term that I came up with. Um there is some ideas about an agent topologies, um, which came from the ThoughtWorks Tech Radar. Uh, Fowler wrote an article, um, about harness engineering. Um, I think these are great concepts, but they're looking basically at one small part. This is not an engineering problem. This is an organizational

problem. Because imagine that agent that does that, you know, that fix in the middle of the night. Just imagine that you're an insurance company and that's the agent that processes the claims in the middle of the night when nobody is there. Right? It's not an engineering It's in all of the layers of your organization that you will need something like this. So, I call it the spine.

And teams inherit this and it is layered. So, you have ground rules. You could see it as law, basically, maybe. We have a foundational law that applies to everybody and your municipality has a different law. But, the law that you have in your municipality cannot, you know, do something totally different than the than the ground law. It cannot undercut it. It can build on top of it.

That's basically the uh, gist of this. And it's not a catalog. A catalog gives you options, It's not a golden path with 47 options. It's really something that is super clear so that the agents and the humans can act upon it. So, it could be strategic direct- direction, could be ethical, could be cost, could be regulatory. Those are the things that you put on the on the

highest level and then when you go down, you will have architecture, product, uh, engine- platform engineering teams and so, everybody builds on top of that. And the goal is not to have a list of 70 items. The goal is to make the list as short as possible because the more you put in, uh, the worse it becomes. uh, then you're just replacing your SharePoint with something other.

That's not the goal. So, the decisions, they move upstream, uh, they get out of the the development process and and more early when we are starting to uh, ideate what we're going to build. When we're starting to specify what we build. Um, the decisions that we made, they become durable because like it's not that, "Oh, I'm now building this and that and I'm putting this uh, rule

inside of my co-pilot instructions file or agents.md md or in a skills file or wherever that you keep your If you once you put them there, they will be there until they are replaced at some point. Every decision that you make, again, should have a trace. It should be traceable what you're doing. If you're updating um, your co-pilot instructions, it is really an important to keep a

track of that. Because if you changed one of the foundational rules for your agent, that is a massive event, actually. That's the thing that you could trace back to like, "Hey, but why did the agent do this?" Well, we made that change at that point at some time. the thing that we want to answer is this question. Under whose authority was the change made? So, whenever that

you're you're noting something down like, "Hey, this is this is a rule. This is like a constraint that you need to follow." if you do not want that to be a ghost decision, this is the question that you want to be able to answer. Right? Because you know, you can follow it back up to maybe a document or maybe some engineer that is like is the authority

in the company, but the thing is you really need to find the person that actually has the authority and that they signed off on that. That's the best way of building guardrails. It's becoming increasingly important because like for a long while we started working with catalogs and I'm from the developer portal space. I I worked there for a while. Um and we were always talking about the

golden path and about the catalog and about having the self-service button. Um but once you start doing that and you start deploying something for instance like oh I need a new environment. So it will both set up the infrastructure and scaffold my repo. Oh that's really great. But if you have 47 options where you need to make all kinds of choices that are other than what operating

system are you using which would be maybe relevant if it's a you know requires some local tooling to be installed. But the rest should not be there The idea was that you have a golden path. Now you have a catalog with multiple golden paths or multiple templates and those contain multiple options. That's not really a way to I think properly So I'm not too big of a

fan of always throwing maturity models at people like oh what level are But this is a simple test because if you have a new developer joining a project or you have a team working on a new project or somebody joins the company the question is if they start their work like what is their experience? Is it that they need to read all kinds of things and make

all kinds of choices first before even getting started or do they tap into something that will provide them with a clear path forward? Oh you want to deploy this kind of application this is exactly what we're going to do here. It might not be clear what you want to achieve so it could ask clarifying question, but the goal is that the spine will help you do the

right thing from the get-go. And of course, that also helps for So, there's a few things that we want to codify. So, first of all, of course, the trade-offs because we start with intent. When we have intent, we have a rule. Oh, we will prioritize cost over um over anything. Because it's a bad market out there. Okay, that's great. That means that we need to make choices,

that we need to make trade-offs. So, we register these Um specs should be a shared artifact between agents, between teams um that are that are working. If you you know, bigger project. Um the guardrail should be available for every agent in the process. And evidence should always be emitted. So, if we talk about the trade-offs, um that ADR, nobody reads it. Right? Or at least they saw

a version of it, but maybe that was the draft. And then forgot about it. Uh maybe they pointed their agent at it. But if the ADR is like it's usually written for humans. will that really help the agent? Yes, no. Uh we don't know. We don't know for sure. So, we need to distill what is important there. So, same goes for like your cost cost management, that

sort of things that you want to want to encode. Now, whatever that you're that you're putting in there, um and this is just an example, of course, but your agents need to be able to read it throughout your whole life cycle. Um this means that for instance, when you're using a coding agent and it has a set of instructions and constraints, um that the review agent should

have the same information. It should have the same constraints because only then the review agent will know that that's a part of of the constraints. You need to verify it along the whole way. Your security agent maybe as well. Your SRE agent, there might be some rules that might be relevant for an SRE agent that fixes your problem in the middle of the night instead of increasing

the problems in the middle of the night because there was no guardrail, because it's another agent on another system, I guess. That's no excuse. We need to look at um where we save these artifacts and make sure that these artifacts are being propagated properly. fun thing, if a PM is working in M365 Copilot, for instance, and has a custom agent to um write a PRD, it would

be really, you know, a good idea if that agent had some of these intents and constraints as Makes it easier to start working on something because it removes the discussion that was not necessary in the first place. Um same for policy. Hope is not a control. Um I I guess that this is this is the part where um we we need to make sure that whenever we

have policies that we use them. You know, the systems that we use um they are really great as being like that guardrail that you can never escape kind of thing. It's kind of thing that you want with agents. Um but you need to be intentional, right? The guardrails need to be wired in there. It's not only your agent, it's also your system that you're using that you

can leverage with this. And of course, I can't say it often enough, but the signals that you emit are important. Because whenever you or your agent makes a decision, it's important to log it. It's also important to be able to see the drift. Um and the people that need to know this information needs to be able to access So it's like you could see it as intense

flowing down and evidence flowing up. And that is basically the loop that you would want to see as well. in itself you could say, "Well, you know, I focus on the specs. I focus on the evidence. I focus on the guardrails." Um it would be a good investment. I will not argue with that. But the real power is when you combine those and create a continuous loop

where you have your intent flows into some trade-offs that you make. Those, you know, become a part of your specifications for what you're building and then the agents has the proper guardrails in place to execute autonomously. That's the moment where you have these agents running and you can be more confident about what it's doing is probably the right thing. And of course believing that the agent is

doing the the right thing is not enough. So we need the evidence. We need to prove to validate if the agent actually did the thing. And of course there's always learning. So you you, you know, make that a part of your cycle in the next cycle of trade-offs and intent that you're forming. So yeah, let's let's take a look at the roles. Um Let's talk about about

Nadia. Um she's entering the office at 8:47 a.m. Um and this is her agenda. Something like this. So um there are some sayings. There are some planning. There are some uh approvals. And um there is a capacity planning of course always. But these are the two that matters. Right? These are the two valuable conversations because these are the things where actually you can make a change. The

rest is all coordination. It's just getting updated with documents. It's exchanging. It's planning. It's It's negotiation. It's It's judgment. Um but, it It's these two things that stand out most that matters most of that day. So, if you look at the EM role, the EM role does a lot of things. And, it's not just me sharing an observation with you. it is the research that backs it

up as So, if we break it down, it's actually five things. It's architecture. It's resources. It's context. Translation. Business translation. You know, words vary a little bit. Um it's being accountable in the end of the And, the human development part. That's a lot. So, whenever you're reading articles and there were some out there, so probably you catch one or two of companies that were like, "Hey, we

don't need EMs anymore because we have AI now." Okay, that's really great. This is all the things that the EM was doing. So, where would that flow then if you do not do anything about it? Well, let's imagine it floats up. So, let's make the CTO responsible. Or, maybe some other senior role. And, make them responsible also for these things. Now, the CTO is already 84% AI

accountable. CTOs don't leave. They leave because they do not believe in the strategy anymore. there's also a big chunk that doesn't do anything. They're just there. They're doing what they've always done, and that's actually also the highest rewarded thing. If you have 200 like plus FTE in your organization, you get paid the most. Don't change anything and you'll be good. So, they coast a little bit. It's

not me, it's the research. Um so, how could we rethink that? Because if we would say, "Well, okay, the EM is an overloaded role." I would agree with that. And many EMs will probably, too. I was at Developer Week in San Francisco speaking, and um there were quite a few sessions about exactly And every everyone, if it's four things or five things that they needed to do,

they all came with at least four things that the engineering role does. And that's so hard. So, if we rethink that a little bit into a more um a gentle organization that is capable of running at these multiple speeds and, you know, better at creating and managing the intent flow. There's three roles that I think are uh are standing out here. So, one is being the steward,

um which has the accountability. Um it's responsible for for a part of the coordination. Um and it's responsible for handoffs, as well. This could also be a product steward, by the way. to mention that, because it's not only engineers, of course, that we have in an organization. Um spine authors, so people that are responsible for the actual architecture, um for the intent, for the direction that we're

going, uh for the constraints, um and architecting that, as well. Um being the point of contact for if you do not agree with the decision because of course you need to be able to uh to challenge that. And then the last one um is the coach and the craft lead. I put them in one box because otherwise it would not fit. um but it is the role

that's more responsible for human development because that is an important part that we sometimes it seems that we're forgetting about that. Um but it is an important And of course a craft lead does the same thing but is more focused on the craft. Um you if you remember the Spotify model, we had something like guilds and you know, I think you could compare it So, then what

happens to the team? Now, well, when we work with agents, um it might be better to work in a small Um that is really focused on outcome because that is what you're doing. If you And what Why three and why not six or why not 10 or why not 12? Because if you add more people at some point I think about five, not everybody agrees on that,

but um you get at some point the coordination that you need to do. Uh coordination, you know, doesn't make sense um because it's a lot of overhead. and if you put the right people in the right team and you give them um the amount of autonomy that they need to build great products, you create a strong feedback loop and you have proper agentic systems to support them,

um then this will kind of work. Um in my mind, it at least has a product person. I'm not saying product manager. I think that will we'll see a different variant of that. Um and an engineer. It could be maybe two junior engineers. Who knows? It could be only engineers. Like it's it's not like the rule specifically that matters, it's that the cell should be good at

something and you make sure that the people in there are the right combination of achieving the outcomes that you want. Outcome driven. Like you can say outcome driven like I write a spec, but outcome driven really is you know, making sure that the people that are in the team have the have the autonomy, have the have the the the blessing to do the work in a certain

way and are able to deliver these outcomes. It's not only the agents that we can be critical about like, hey, this is what we want to see. Well, it's the humans that actually carry that forward, right? And all of these um cells like I like to call them because we can't call it a team uh with with so little people. Um they all tap into that spine.

Now, I chose cell for a specific reason because um I would like to envision that this more as organic because cells can at some point split or merge. Um they can share intent together, they can collaborate, they can like form a group as well. Um but still the cells are on their own. Um and the spine is what they actually then tap into. So, it looks something

like this. where where you see the whole flow from, you know, um high level in the organization. You have a spine, you have the authors um that um you know, add to that as well. You have the stewards and the coaches, but the cells themselves also have of course their own internal um uh layers of intent that they have. Right? You always have on every like even

an agent would have one. If you would like plot your below like the lowest atomic level, that would be an agent. The only difference between a human and an agent is that the agent would not be able to set intent. That's something that you would probably never want to allow an agent to do. Help you set the intent, yes, but not being responsible for for intent. Um

I think there's no shareholder in the world that want to hear, "Yeah, we blame the agent for this decision." So, whatever that you do, I I think that the most important learning here is that you need to organize yourself around the flow of the context, the flow of intent. That is the most important thing. This is what I see with the customers that I work with. Um

like over the past months, increasingly the conversations are exactly about How do we optimize? And it's not only about how do we how do we do it technically with these agents and with intent? It is also about how do we actually collaborate as humans in a better way? All the way through the whole you don't need to reorganize if you want to do something fun. There's one

exercise. And if there's leaders in the room, you start with the left one. Um you start from the top. So, you grab one rule from your strategy and you follow it down for a specific project or a specific team. And you see where this rule is being applied and you can see how it maybe waters down or very disappears. And hopefully, that doesn't happen and you will

see exactly in the agent instructions or in a in a custom um skill for an agent, you will see the rule pop up and being enforced. Um but, it's a good exercise. If you get lost somewhere along the way or it is watered down or uh has a different definition, then you found yourself a ghost decision. Um of course, on the practitioner inside, you start at the

bottom. And anything that you have maybe in your co-pilot instructions, trace it back up. And you do not stop until you find a human that actually is accountable for making that decision. So, not that one consultant that like wrote it. No, the where it comes from. Really. So, if you are stuck somewhere or if it gets watered down or it's a different version, you found yourself a

ghost And you know that you need to do So, what can you do? Well, you can write it down. Simple as that. Um, this is not the rocket science, right? You can just put it in co-pilot instructions. It could be a skill. Um, you want to enforce it. Um, so this is where you might use a skill with a gate inside of it or you might want

to um, have it in your review or you might want to have this as part of your pipeline. And you want to emit the evidence, of course, because you want to validate. That doesn't have to be like very very um, complex as well. I'm working on a project and we're implementing the the evidence layer now because we're finding a grown-up project. So, it was about time. Uh,

it's just a log file. You know? It's just that. But, it's enough. It does the job. It tells us where we violated policy or where we might not have done that. Um, and of course, one of the things that um, for me is really obvious, but I think it's um, something that we we tend to forget when we set rules. All of the rules that you have

should actually have an expiry date. Because either the rule gets updated at If it doesn't get updated at some point, it's time to validate if the it's still valid. I don't know in the past 30 years uh, in this industry, I don't know how many times I found something that nobody knew anymore why it was in the documents. And it actually didn't apply anymore. I don't know

how much money I saved with that, but it it is a lot. I can guarantee you. Um just try to rebuild the data center. You'll you'll find stockpiles of documents that are outdated. But every everybody believes it. So back to the question, who signed off on this? Well, want to buy into the ISE framework, if you think that a gentle is a good operating model, that's fine.

If you think, well, you know, maybe not today. Keep in mind, this is the question that you want to that you want to answer. And the only way to answer this is to both work on how your intent and how your context is flowing, but also on how you organize yourself. Because if you do this in the in the current ways of working that most of the

organization have done forever, then you will have a problem with accountability. You will find problems with collaborating. It's hard to scale on something that is not built for it. Because these agents are fast and humans are super slow. We are on the slow loop, and that's perfectly fine. So the team that survives the gentle condition will not maybe be the fastest. They might be, but they might

as well not be. But the most important thing is it will be the team that that has a structure that can actually sup- supply supply this, that can actually help us. Right? That actually scales. Brings me back to the um work trend index report, right? I wrote a book about this. If you think this is interesting, you're um it's available on Amazon. And if you want to

see some things in action and want some agents that can really help you um with this as well or see how uh I implement some of the ideas, um there's three open-source projects. Um so, um one is Git Ape, which is a platform agentic platform um for a platform engineering. which is applying um almost all of the principles by now. Um there's Ape Context. Ape Context is

the thing that you see running here in the back and it um helps me set up my repository and extract intent from documentation that it found on uh Work IQ, which is Microsoft's intelligence layer. Um and it found some uh architectural documents and whatnot. And it codified some constraints for me. Um it It is to, you know, show how it could work in code. Um and I

invite you to try it out. And the other one is the ISE Advisor. Um ISE is the four-layer framework. Um you can run this inside of a repository once everything is set up. Um or you can run it against an agent uh and it will validate it as well. I'm trying to expand it to also include like human collaboration. Um for instance, by leveraging Work IQ, but

that's still on the backlog. And to be honest, it's almost summer, so it might take a little while. But if you're interested, follow the work there. Yeah, and that's that's about it. Um I wanted to leave 5 minutes for some questions. Um If anything of this is interesting, the QR code brings you to a page that contains all of the uh reports that I mentioned, um the

repositories that I mentioned, and of course the link to my book. and yeah, I want to thank you a lot. Um, if you want to continue the conversation or you have any questions that you're like, well, I don't know if I have time to go to the AMA, I will be there after the session. Um, but if you're not able to catch me and you want to

have a conversation on a later time, just reach out to me on LinkedIn. Um, I answer slow, but I always at some point answer, uh, and I'm always open to, uh, for any feedback, any conversation about and once you got the QR code for this one and you left it open, I want to ask you if you would like to, uh, give a, um, rating for the

session in the agenda. Um, that helps me improve this. Great, THANK YOU. >> [applause] >> THANK YOU VERY MUCH, SUZANNE, FOR FOR THE TALK ON, UH, the inspiration to look more into this. About the team size or the cell size of three people, having people on vacation, sick leave, trainings, or life. Uh, it What is the stability you foresee for that team? And what's the mission? And

what is the life purpose they have? What are the craft that they have to grow? How they are going to be feeling fulfillment in their life while they are in this engine. Thank you. >> Yes, thank you. That's a that's an excellent question. So, about the size, it like I said, it's not a given that it needs to be three. It's the it's the minimum, I think,

for for an for an a gentle cell. A gentle cell, it's The thing is that I see customers experimenting with three. I see customers experimenting with five. Some try now a bit larger. I'm really like looking at how they are solving I hope to have to that result soon, but in general, anywhere between three and six is is doable in in reality. The roles that we form

around it are splitting the EM role in these other roles. That is really crucial for having that sense of belonging and actually adding value to the experience of the engineers. So, a lot of the the team members in that cell, even like if you're on product or on the engineering side or whatever is your specialty or your domain, if you Those engineers will become N-shaped or maybe

even M-shaped engineers, so there's like a lot of room to explore new things. And to do that, it's important to have somebody that is a coach. And with that, I don't mean an Agile coach. I don't hate Agile. I don't want to bash Agile, but the idea is really to have a new role that can actually help with the development of these people that are close to

them, both on a personal level, their craft that they they have. So, that is that is how how we imagine that the me and the customers that that I work with, how we imagine that they will feel more support and more sense of purpose than they do currently. Um one other aspect to this is that when we look at an Agile cell, Agile cell, um that um

for for working uh in an Agile way, um in the customer layer, the same circle is super important, and that is to have that fast feedback loop. So, that feedback loop um also helps with that. So, research um points out that when engineers are closer to the problem that they're solving, that they will feel a better sense of purpose and more involvement in what they are doing.

That's exactly what we're trying to achieve when when talking about Agile way of working, um because now we can. Now we have agents that can help with research, with parsing, with like the example that I gave. We had stakeholder interviews, and when we wanted to clarify uh intent, we were just able to to grab those grab that distill that from that from those transcripts uh without leaving

even our coding uh environment. So, that really helps with that, um and I think over time uh that loop will even tighten more, uh or at least that that yeah, that's my belief that that would be the investment to make. I can take one more. I know it's almost lunch, but yes. >> So, you mentioned uh that you're not a big fan of Agile coach uh coaches.

Um I also didn't see any uh product owners or something similar in in there. Do you see that they're not necessary in this setup? So, the team takes over these responsibilities, or you see that Jira might not be needed in that setup. What's your thoughts on that? the reason why I give this slicing of the of the organization is because two reasons. One is that this is

a new concept and it's already a lot to wrap your heads around. Um so, that's the reason why I made the editorial choice not to talk about it. Um my book goes in that in depth. Um yes, those role will still exist. We will not always name them in the same way. Um I can give an example of a customer where they have product stewards. Uh and

when you look at the team, uh my translation of that role is for instance having a product mind. So, that's somebody that it you know, is a engineer light, but also maybe you know, being more um aligned towards the PO role. I see the PO role becoming more and more technical. Uh the ones that don't, they float somewhere else. They might become intent authors. Uh they might

become, you know, coaches or uh craft coaches or anything like that. Um it's I think for this phase it's important to um let go of like what is job descriptions at some point. Um and not be too big on oh, I'm a product owner or you know, because it has the word owner. The the balance and the power will severely shift. That's a hard topic for in

the morning, so I didn't want to press too much on that, but when you have agents and when things are are moving towards more intent uh based engineering, then you see that there's also a power shift. Um if you keep the org chart the same way, then at some point these people will be there, but will not actually have uh as much influence as they would have

before in the process because it moved up. So, that that's um that's the dynamic that will change at some point. Uh that's why it's so important to also take that part into account. Great question. Thank you. Um so with that, I see it's 000 and I don't know about you, but I'm hungry. But, I will also be at the AMA. Um so, I'll I'll grab something to

bite and then be in the AMA session in a little bit if you want to continue the discussion. And please, if you do not agree with anything, it would be really fun to have you in the you in the AMA as well. Um I I like a good discussion. So, thank you so much and enjoy your day and yeah.