AI Engineer Europe 2026
Agents Don't Do Standups: Building the Post-Engineer Engineering Org
Read the talk
Agents Don’t Do Standups: Rebuilding the Engineering Workflow at PFF
PFF’s two-engineer pilot changed more than coding speed: it moved coordination into design documents, automated status updates and staging QA, while keeping humans responsible for intent and product quality.
From a talk by Mike Spitz
Before you start: Familiarity with pull requests, staging deployments and basic Scrum terminology will help; lightweight design documents and agent skills are explained as they appear.
What if the workflow optimized for agents?
How does an engineering team catch up when it has been building the wrong things quickly enough to stay busy, but not quickly enough to satisfy customers? At PFF, Mike Spitz’s January–March case study began with that problem. The company supplies sports data to NFL and NCAA teams and serves consumers interested in fantasy football, sports betting and simulated drafts. Its engineering team is distributed across India, Spain and the United States.
Spitz reports 100 million annual page views and nine million annual drafts. Yet a company of roughly 200 employees, including about 20 engineers, was falling behind competitors. Engineering attention had gone toward sports betting while many consumers wanted more from the draft tool. Personal experimentation around November, which Spitz associates with Claude Opus, grew into a pilot staffed by the company’s strongest frontend engineer and one of its strongest full-stack engineers.
The organizing question changed from helping engineers produce more to helping agents move faster. Spitz places the Agile Manifesto, software craftsmanship and even engineering perks—from foosball tables to sleeping pods—in a history of optimizing around scarce human engineering capacity. If that bottleneck moves, the organization’s processes need to move with it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
More deployments, then a harder question about output
Spitz reports a 25× increase in team deployment frequency: the two-engineer pilot deployed five times a day, compared with roughly ten engineers deploying once every five days. The arithmetic compares team delivery rates, not individual productivity. He explicitly attributes an unspecified part of the difference to the smaller team: small groups already move faster. The pilot still had to coordinate its deployments with the larger team, so it had not escaped the surrounding organization’s coordination costs.
Deployment frequency is visible, but useful output is harder to measure. Counting pull requests or lines of code does not establish that customers received something valuable. Using a blend of ticket counts and code complexity, Spitz reports 10× output per engineer. The slide labels the result per engineer; the talk does not supply the weighting formula needed to reproduce that measure.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Finishing sooner releases capacity sooner
For the feature set discussed in the talk, Spitz reports completion by two engineers in under two months, against an estimated four months using the previous approach. That comparison is an observed delivery against a planning estimate, rather than two executions of the same project. The more consequential change appears inside the schedule: one engineer became available for other work in under a month, whereas the old plan would have kept both occupied for three months.
The capacity gain begins before the project ends. Once one engineer is unblocked, the next piece of work can start while the other engineer finishes the current project. Faster completion therefore changes more than the date on one delivery plan; it brings subsequent work forward. This is the compounding effect Spitz wants the audience to notice.
Neither output nor deployment counts settle whether the work was worthwhile. Spitz reports an average customer quality score of 8.6/10, compared with a pre-AI average he estimates at 7–7.5/10. He describes the surveys as statistically significant, but does not provide sample sizes, questions or statistical methods. The result matters to his account because the pilot was meant to close a gap between what PFF built and what customers wanted.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Replace ceremonies with a shorter feedback loop
Scrum ceremonies did not survive the pilot. Spitz removed the project-manager role from this workflow and reduced the handoffs through which requirements and feedback could become a game of telephone. This was a change to the team’s operating process, not a rejection of the Agile Manifesto’s values. The replacement was deliberately small: huddles every other day, lasting roughly half an hour to an hour, with engineers, product and data science discussing what had been built over the preceding days. The team sought immediate feedback and deployed minimum viable versions to production as quickly as possible to get more of it.
Implementation began with a specification, but the agent helped discover what belonged in it. The workflow moved through these stages:
- Interview: the agent questioned the humans to develop the spec.
- Spec feedback: participants reviewed and refined what the team intended to build.
- Lightweight design document: an agent skill produced an LDD, drawing on previous LDDs to preserve the organization’s engineering approach.
- Engineering feedback: the LDD circulated to the engineers before implementation work was generated.
- Tickets and pull requests: the workflow automatically created tickets, followed by PRs.
The LDD was an organizational design artifact, not something specific to Claude Code. Its value came from carrying existing engineering decisions into the next piece of work, then exposing those decisions for review before code generation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Let work events carry the status
Sprint planning disappeared because spending an hour estimating tickets no longer materially helped this team decide what to do. Spitz raises a different possible planning constraint: estimating token expenditure to decide whether a task is worth its cost. That was a future possibility, contingent on his expectation that token subsidization would end, not a practice the pilot already used.
Daily standups lost their status-reporting function because the tickets followed PR events automatically:
| PR event | Ticket update |
|---|---|
| Opened | In progress |
| Entered review | Review status |
| Merged | Closed |
For example, a ticket already linked to a PR needs only the event-to-status mapping below. These are illustrative identifiers for the rules Spitz describes:
typescript
type PrEvent = "opened" | "review" | "merged";
type TicketStatus = "in-progress" | "in-review" | "closed";
type Ticket = { id: string; status: TicketStatus };
const statusByEvent: Record<PrEvent, TicketStatus> = {
opened: "in-progress",
review: "in-review",
merged: "closed",
};
function applyPrEvent(ticket: Ticket, event: PrEvent): Ticket {
return { ...ticket, status: statusByEvent[event] };
}
const ticket: Ticket = { id: "DRAFT-42", status: "in-progress" };
const updatedTicket = applyPrEvent(ticket, "review");
// { id: "DRAFT-42", status: "in-review" }
This automation was possible before coding agents. Spitz’s claim is that it has become easier to put in place, making a meeting to reconstruct the same information less useful.
Refinement moved into the spec and LDD. Generated tickets were structured to avoid blocking one another where possible; dependencies that could not be removed were flagged explicitly. The aim was to expose coordination needs before parallel implementation ran into them.
The replacement for a scheduled retrospective was a combination of customer satisfaction, customer surveys, normal delivery metrics such as deployment frequency, and immediate escalation by engineers. Problems were supposed to be raised when they appeared, rather than held until the sprint ended. That timing matters: feedback delivered after the relevant work has moved on can feel stale or unheard.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Start with people who know where the system bends
The first participants should be the engineers with the strongest system knowledge: the people colleagues already consult when something is stuck. Spitz recommends expanding access in phases rather than immediately giving everyone coding assistance. His own preparation involved roughly two months of small, non-critical proof-of-concept features pushed to production. Those experiments attracted little usage, limiting the consequences of mistakes before the approach moved to the heavily used draft product.
Spitz compares the transition to driving a sports car: not everyone can immediately handle the extra capability, and that is not a reason to pretend everyone starts from the same place. He expects curious engineers to thrive—people willing to investigate how unfamiliar code works when they do not yet understand it. Engineers accustomed to receiving a fully prescriptive specification may find the shift harder, because the new workflow asks them to help establish intent and resolve ambiguity.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Automate verifiable work; preserve design judgment
Agent work needs verifiable, deterministic tasks. Tests are one part of that boundary, but checks also need to reflect the product and organization. At PFF, examples include feature flags for trunk-based development, generating interactive elements, and generating analytics for those elements. These are recurring obligations that can be made explicit rather than remembered anew during each implementation.
PFF’s agentic code review targeted a narrower responsibility than replacing an engineer’s review:
- Agents: variable naming, style compliance and other opinionated details that engineers often dislike receiving feedback about.
- Engineers: system design and the larger implications of a change.
Offloading the smaller criticisms reduced their emotional charge and preserved human attention for the big picture. PFF did not rely on agents to supply its system-design judgment.
Human involvement was therefore concentrated heavily in the spec and LDD, where the team decided how the system should be built. It also remained necessary at the product boundary. Spitz uses the idea that anyone can create something in an hour to describe how low the barrier to generating an application has become; the failure mode is a product that feels generically produced by Claude Code. Engineers still had to spend time making the result feel like the company’s other products. Generating a feature does not settle whether it belongs in the product.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Compose the workflow, then test the result
Spitz’s model for the development lifecycle is a factory with small, composable operations. A car factory separates building a door from fitting a steering wheel. Engineering can similarly separate branch naming, creating a feature flag for trunk-based development, and building an API according to the organization’s chosen design pattern. Each repeated operation becomes a skill that contributes a specific part of the result.
Composition only helps when the pieces agree. A third-party skill may carry strong software-design opinions that conflict with the team’s own. Importing it can introduce inconsistency even when the individual skill appears useful. Spitz’s requirement is that the skills remain compatible with one another and with the engineering organization’s conventions.
He describes the spec–LDD–ticket–PR path as largely autonomous, alongside the human feedback already built into the design stages. The implemented QA sequence extends that path into a running environment:
- A PR is merged.
- The merge automatically deploys to staging.
- After the staging deployment completes, a QA agent examines the relevant tickets and their acceptance criteria.
- The agent checks the deployed work against those criteria and flags items that fail.
The ordering matters: acceptance checks run against the staged result after deployment, not merely against an agent’s description of the code it wrote.
The next step was still planned. Spitz wanted another agent to inspect unmet acceptance criteria and automatically create corrective PRs over the following couple of months. That would turn failure reporting into a repair loop: QA identifies a gap, a repair agent proposes a change, and the change can pass through the delivery workflow again. At the time of the talk, automatic corrective PR creation had not been implemented. He connects that proposed self-healing behavior to greater trust in agents and the ability to pursue more work in parallel.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make guardrails work before expanding autonomy
Agents still take shortcuts. Security therefore remains a human concern, along with product feel and whether the scale of the implementation fits the task. Spitz points to sprawling, thousand-line implementations and unnecessary complexity as familiar failure modes. A sufficiently prescriptive LDD can constrain those choices before coding starts, instead of leaving reviewers to unwind an overengineered solution afterward.
For the next stage of adoption, he recommends beginning with boring, repetitive work—especially work engineers dislike—because removing it creates immediate buy-in. Process deserves the same scrutiny as code. A meeting retained for decades still needs an answer to a concrete question: what does it help the team accomplish? That question provides a basis for removing redundant process without assuming every existing practice has become useless.
The organization’s engineering culture then needs to be encoded in its skills. PFF’s concrete API example is the service–repository pattern: the preferred structure should travel with the task instead of depending on an engineer repeatedly restating it. Functional guardrails must precede autonomous operation, and the strongest engineers should establish the initial workflow.
Giving everyone Claude Code or Codex and running a hackathon is not sufficient onboarding. Teams have different engineering styles, and a working transition needs time to absorb those differences. Spitz contrasts expanding the approach across PFF’s roughly 20 engineers with doing so across organizations of 100, 1,000 or 10,000. The small organization’s advantage is not simply access to the tools; it is the smaller coordination problem involved in changing how people work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Move urgently, at a pace engineers can sustain
A phased rollout does not mean waiting indefinitely. Other companies are moving quickly, and Spitz says he had already felt a few months behind. His earlier capacity argument becomes a competitive warning: if one team starts subsequent work sooner, its advantage can continue to grow. He illustrates that risk as a gap of a few months becoming six months and later twelve, rather than presenting a measured forecast.
The constraint on speed is feedback from the engineers doing the work. They should determine whether adoption can expand faster or needs more time. That leaves the organization with two responsibilities at once: take the compounding opportunity seriously, and expand only as the working process supports it.
Spitz closes by inviting the audience to try the features through an on-screen QR code. The talk has explained the delivery system and its reported outcomes rather than demonstrated the features themselves; the invitation brings the discussion back to the product customers actually use.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The original four values of Agile software development, emphasizing collaboration, working software and responsiveness to change.
Further reading
- DORA’s software delivery performance metricsDocumentation
Definitions and measurement guidance for deployment frequency, delivery throughput and instability.
A companion session abstract from Mike Spitz about PFF’s organizational changes, adoption difficulties and practical lessons.
Updates since the talk
Current instructions for packaging engineering conventions and repeatable procedures as Claude Code skills.
Read the complete timestamped transcript
- 0:00
[upbeat music] All right, so I'm in the slot before the snacks.
- 0:18
Um, but I'm here to speak about the post-engineering org and a case study we've been doing at, uh, PFF. Uh, started in, uh, January, and we finished it in March.
- 0:29
Uh, PFF is a sports data company. We help NFL and NCAA teams figure out what they should be, uh, doing. Um, and we also have a consis- We also have a, a consumer arm which does fantasy football, sport betting, and for those of you who know American football, there's a draft happening end of the month, and so
- 0:48
allows people to basically play as one of these, uh, teams. We're a fully distributed engineering team, so we got engineers in India, we got engineers in Spain, and all the states in America.
- 1:01
Um, but first, let's get into some kinda stats. So we have a hundred million, uh, page views annually. We have nine million, uh, drafts happen on an annual basis.
- 1:10
It's a fairly, uh, popular tool. Um, and the issue that we had was we were, uh, two hundred employees around, uh, uh, twenty engineers, and we were falling behind, uh, competitors.
- 1:24
We were focusing on sport betting stuff, but a lot of our consumers were actually interested in this. And then with, uh, Claude Opus coming out, I started experimenting around November on a personal level,
- 1:36
and then it got spun out to, uh, two engineers. Um, one of them was our strongest frontend engineer, and the other one was one of our strongest full-stack engineer.
- 1:47
Uh, so really the question I was asking was, instead of figuring out how we can help engineers go and output more, how do we help make the-- how do you help make-- How do you help make, uh, the agents quicker, right?
- 2:00
So I think if we all think historically, software engineering, you've got the Agile Manifesto, software craftsmanship. Um, you've got a lot of good, uh, perks and benefits for engineers from foosball tables to sleeping pods to pretty much every perk that most other industries really don't have, and it's 'cause we're the bottleneck.
- 2:19
And if, like, companies are able to go and optimize for that, it gives them a lot of benefit. But now things are changing. So I just wanna go straight into how the case study ended up.
- 2:30
So we had, uh, uh, twenty-five times more the-- uh, twenty-five times more deploys. So the two engineers were deploying five times, five times every-- five-- were deploying five times every day.
- 2:44
Uh, and the other team was a team of around, uh, ten engineers. They're doing it pretty much one deploy every five days. There is a big obvious caveat here, right?
- 2:52
Small engineering teams are always gonna be quicker than the big ones. So there is an element of that multiplier that is just from it being a small engineering team.
- 3:02
However, that smaller, uh, tiger team still had to coordinate all of those daily dep-- still had to go and coordinate all of those, uh, deploys with the bigger team.
- 3:12
So there was still that-- there was still that kind of issue that was happening.
- 3:16
And this one, this is always hard. How do you validate, like, the output is actually helpful and the number of PRs isn't helpful, the amount of code isn't helpful?
- 3:24
So we basically blended the number of, uh, tickets with the code complexity, and we found that their-- we found that their, um, that their output was at ten X.
- 3:35
Got another slide which might look a little bit hectic, but just bear with me. Um,
- 3:40
so these were the features that we went and, uh, constructed. With those two engineers, it took them under, uh, two month. If we're gonna do this before, we were estimating it's gonna take four months.
- 3:52
Uh, the big thing you can probably have a look in the, in the top half is one of the engineers gets unblocked, uh, in under a month and can then start building other stuff.
- 4:01
Whereas in the old way, they're both blocked for three months. And so you get this thing where you now have a, a compounding increase, where it's not just faster for that stuff, but you're now able to do a lot more stuff than you were able to do before.
- 4:17
And the one thing that I really wanna go and basic-basic go and highlight is it doesn't matter if the output's more, it doesn't matter if the number of the deployments are higher.
- 4:27
What really matters is, really matters is basically if our customers, if the customers are happy. And so we did statistically signi- we did statistically significant, uh, surveys. Uh, and the average quality score was eight point six out of ten.
- 4:42
What was interesting was before AI, we would probably average, uh, seven, seven and half. So we weren't really delivering what the c- what the customers, uh, had been interested in.
- 4:53
So Scrum did not survive. We were l- we were basically having a look not just on an engineering front and all of the delivery gains from that, but also from a process standpoint.
- 5:08
And so no need for a project manager. Uh, we don't need to play multiple, uh, games of the telephone, and everything we were doing was optimizing to be as, uh, quick as possible.
- 5:20
Engineers aren't the bottleneck, so we don't need to have all the old, uh, ceremonies that we had before. So what did we have? It looks pretty basic. We basically had a-- We, we basically had huddles.
- 5:33
So those huddles were basically every other day. They'd be like half an hour, maybe an hour. You'd have the engineers, someone from product, someone from the des-science team, and you would speak about the things you've been building the last, uh, couple days.
- 5:47
You get instant feedback. We were trying to deploy to production as fast as possible in an MVP state and getting as much feedback as, uh, possible also.
- 5:58
And that development flow is we have a spec. I think most of us are probably fairly familiar around this, but we get the agent to go and interview us.
- 6:07
We get feedback on that spec, and then we make a lightweight design document that's done by, that's done by a-the agent. So we have like a skill.
- 6:18
And the, uh, and the nice thing about that is it analyzes how we've done all the LDDs before. And so anything that we're building is in the same kind of ethos as everything else that's been built.
- 6:30
Uh, so it's not a, a Claude code spec-- it's not like a Claude code specific, um, kind of thing. And then those LDDs, they get distributed, and we get feedback from all of the, the engineers.
- 6:41
And then at that stage, uh, we automatically create all, we automatically create all the, the tickets and then the PRs after that.
- 6:51
So sprint planning, we don't have sprint planning anymore 'cause we don't need to have an hour going and basically estimating, uh, tickets 'cause those estimations don't really make any difference.
- 7:02
Uh, something we're not doing at the moment, but we will probably have to do once the s-s-once the subsidiz-once the subsidization of, uh, tokens ends, is we'll probably have to go and estimate the token expenditure to go see if we wanna actually spend this amount of money on it.
- 7:18
Uh, the daily stand-ups we don't have to do 'cause all these tickets get auto-updated. That is, uh, specific to the status of the PR. So, so we've got the PR is open, it goes auto in progress.
- 7:30
If it goes into review, it updates it. If it gets merged, it gets closed. These things were obviously manageable to do before, but it's all been made a little bit easier.
- 7:38
Uh, sprint refinement we don't need to do 'cause that happens in the spec and the LDD, um, flow. And then when we automatically create all of the, the tickets, we structure it in a manner so the tickets are made, so none of them are bl-blocking each other.
- 7:50
And if there are ones that are blocking each other, that information is, um, flagged up and highlighted. And retrospective, th-this one might be a little, like, controversial, but we rely on the customer satisfaction, the customer survey.
- 8:03
That's the main thing really. And then you got the normal development me-metrics like the deployment frequency. We ask all of our engineers to really flag when there is an issue, to flag it immediately until instead of hanging on till the end of the sprint to go and go and f-flag that issue.
- 8:19
Where sometimes I think all of us have probably felt that our feedback hasn't really been heard 'cause it's been a sprint before.
- 8:28
Oops, sorry. So how do we start? You gotta pick the engineers which have the best, uh, system and the knowledge, and I think every engineering, uh, team probably has one or multiple engineers where if anyone ever gets kinda stuck or hung up on anything, they're like, "You should speak to them.
- 8:44
They'll be able to sort it out." The other one is you should s-- you should go slowly. So, um, there is an appetite to give everyone all the coding assistance and open it all up.
- 8:55
But I think, um, with this, you want a slow-phased approach,
- 9:00
and then you should experiment in non-critical systems. So that's what I did in, in the November and the s-- in like the two months before the case study. I was making small proof of concept features going, going and pushing it to production.
- 9:16
Didn't really get much traction, so if there was a bug or a mistake, it didn't really matter. And then we moved it to the thing which gets a hundred million page views, um, after that.
- 9:25
Um, the bi-big thing here though is not everyone can drive a sports car, and that's all right. There's n-- that's not a big issue. But I think w-- I think everyone needs to be a little bit honest around the engineering org and engineering team.
- 9:38
And this new era is gonna be hard for a few engineers. And I think the, the type of engineer where they will really strive is one who is, like, curious.
- 9:49
It's the engineer who, if they haven't figured it out, they're gonna spend a b-bit of time just figuring out how something's been built. They'll be able to, they'll be able to, they'll be able to smash this easily.
- 10:00
The old style of engineer, which needs something really, uh, prescriptive as a spec, I think they're gonna struggle.
- 10:09
So in the engineering side of things, you need verifi-verifiable, verifiable, deterministic tasks. I think a bunch of people have spoken about this today. This ranges from everything from all the different types of tests, but there's also things which are specific for your product or your org.
- 10:29
So for us, it's feature flag 'cause we do a Trunk-based development. Um, or it could be generating the interactive elements, um,
- 10:38
generating the analytics for the interactive elements. Um, next thing is the agentic code reviews. So with us, we didn't really l-like relying on agents to do code reviews for system design and what engineers would usually do code reviews for.
- 10:56
We use agents to do the code reviews that engineers hate getting any feedback from. So that's like, uh, the variable names, this doesn't fit the style or like those kind of opinionated manners is much easier to offload.
- 11:11
Uh, and then you can remove that whole kind of emotional aspect out of it, and then you just allow the engineers to focus on the big picture.
- 11:19
Um, we still need people involved, but it's really heavy on the spec, really heavy on the LDD, the Lightweight design document, where we figure out how we're gonna b-build this.
- 11:29
And the thing I haven't touched on at the moment is the product. We're in an era where everyone's able to create anything in an hour. But a lot of these tools have the brand feel and the product feel of something that's been created by a Claude code.
- 11:47
And so if you really wanna get the best out of it, you really need to make sure that the engineering team is spending time making sure it still feels like, um, basically every other product from the company.
- 12:00
So how would I recommend tackling this? You should go see your engineering development life cycle like a, uh, like a kind of a, like a kind of a f-f-f-factory.
- 12:12
So you should think you're in a factory. How do you break that up into each small composable element? So in a car factory, there's one thing which is building a, building a, building a- A door, another one fitting a steering wheel.
- 12:24
The exact same thing happens for engineering, right? So you have the branch name, you've got, uh, creating feature flags with Trunk-based development. You got the-- If you build APIs with a specific software design, a pattern, you should abstract that into a composable skill.
- 12:41
The one thing I would flag is I'm not a big fan of, um, consuming other people's skills if they have strong software kind of opinions that are in contrast to, to the engineering org, `cause you're just gonna kind of end up in issues.
- 12:57
So you just need to make sure that any skills that are getting composed are still kind of matching.
- 13:04
Uh, and yeah, this is just at the moment, pretty much everything is fully autonomous from the spec LDD, a ticket from the PR. Uh, we have a QA process also.
- 13:14
So what happens is, um, whenever we merge a PR, it automatically deploys onto staging. When the deployment on staging has happened, we will spin up a, a QA agent, which has a look at all of the tickets that have happened, has a look at the acceptance criteria, and it will go and then a QA against that.
- 13:34
And then if everything's passed, I mean, great. And if-- and then if everything hasn't, it will flag what those items are. And the bit we haven't gone and done at the moment, but I'm, um, um, but I'm aiming in the next, um, a couple of months, is to then have an agent have a look at those tickets,
- 13:52
find out where the acceptance criteria hasn't happened, and then automatically create the PRs. And so then you get into this flow where agents can basically, uh, self-heal. And the cool thing about that is it lets us do multiple things in parallel because we're now in a position where we basically trust agents as well.
- 14:09
Uh, where do we still use people? I mean, I've experienced this, but they do like to use, uh, sh-- they, they, they do like to use a sh-- do like to use, uh, shortcuts.
- 14:20
Um, so we got to make sure the sec-- the, the security side of things is behaving. At product feel, I spoke about that a little bit earlier. And then the scale and engineering complexity for the task.
- 14:33
The LDD is really meant to help on this. So I think we've all experienced where it'll make a thousand lines of code or over-engineer something. If you're really prescriptive on that engineering document at the start, you can really prevent that from happening.
- 14:49
So what things should you go and aim for? You should start with boring, repetitive tasks. Ideally, things engineers hate because you're going to get the most amount of buy-in from that.
- 14:59
Remove as much redundant process as is possible. And I know it can be strange when you've been doing something for, like, uh, two decades plus to just chuck it all out.
- 15:09
But I would ask you, what is the purpose of this meeting? What's the purpose of this process? Is it just `cause everyone else has been going in and doing it before, or is it `cause it actually helps out?
- 15:20
Uh, make sure your team's personal kind of engineering culture and the patterns are encoded in skills. So if there are software design patterns that you really do. So for us, whenever we build an API, we focus on the Service repository pattern.
- 15:34
Uh, make sure your guardrails are fully functional before you get into, before you get into an autonomous flow. And you should start out with the best engineers.
- 15:44
Things you should not do is to try and onboard everyone at the exact same time. Uh, I think a big reason why a lot of these things haven't really panned out is `cause we've given everyone a Claude Code Codex and given them a hackathon of like, sweet, we've done everything.
- 15:59
They should now be able to sort it all out. It's just not that easy. Every engineering org is completely different, uh, and every engineering org's style is really different.
- 16:09
And you just need to go and have a slow-phased approach to make sure, uh, that that transition is happening smoothly. And that's why I think those small companies are at a huge advantage over the big enterprise companies `cause it's really easy for me to scale this out when I've got twenty engineers.
- 16:27
It's really hard for me to scale this out if I was in charge of a hundred or if I was in charge of a thousand engineers or if I was in charge of ten thousand engineers.
- 16:34
So, um, but you don't want to be too shy. You don't want to be too cons-- you don't want to be too conservative
- 16:40
because the fact is that there's a lot of other companies that are going full speed. And, um,
- 16:49
for us, even from our perspective, I felt a few months behind, and I was kind of feeling it. And I think if you think about the compounding impact I was talking about at the start, that's just gonna carry on happening.
- 17:00
So, like a few months behind at the moment might be six months behind in a few months, might be twelve months behind, uh, a little bit afterwards. And then again, just, just the, just take it slow.
- 17:11
Uh, it needs a phased, it needs a phased kind of approach and rely on your engineers to let you know whether you can scale things faster or if it needs a bit more, more time.
- 17:20
I know I spoke to you about a lot of features that we built, but I didn't show you any of the features. Uh, if anyone does want to have a play around, feel free to scan the QR code, and then you can have a look at all this stuff.
- 17:31
But cool. Thank you, everyone. [audience clapping] [outro jingle]