Back to Blog

Why your team gets slower every time a senior leaves

Their workflow left with them. Here’s how to keep it.

September 24, 2026
3 min read
Jordy van Vorselen
Engineering LeadershipDeveloper ToolsAI Native EngineeringDeveloper ExperienceAI
Image showing stressed engineers because their senior is leaving

Your most experienced senior engineer has just put in their resignation.

The person who helps others understand the business context while at the same time implementing wizard-like AI workflows into the teams’ day-to-day work.

Friday is their last day, and on Monday the team will have to do all of this without them.

Stressed about it?

Most of us would be.

It’s because the team doesn’t own its workflow. And now one person will take it out the door with them.

Every team member has their own way of working set up with AI. Their own prompts. Skills. Hooks. Rules. Memories.

All gone eventually.

By the end of this post you will know how to prevent this for the next person who leaves.

I write for founders and CTOs of AI-native teams. Subscribe for free to get the next post.

Subscribe on Substack(opens on Substack)

Take ownership of your knowledge

Within the infrastructure community, years ago we discovered that knowledge and definitions about how the infrastructure works is best captured in version control.

Nowadays every professional uses Infrastructure as Code to set up their environments.

All of this knowledge is stored in version control.

The same principle applies to AI workflows.

Instead of treating it as a fully personal workflow that each developer has in their own home folder, it’s best to create a shared definition and commit it to version control.

A change to a rule goes through a pull request, and is reviewed like any other code.

Then the most important rules, memories and skills can be shared and improved upon by the team.

The team owns the workflow.

Create a shared understanding

A very important distinction to make here is that this does not restrict engineers to use a certain model or harness. Neither should this take their ability away to install or use their own custom skills.

The focus is creating a library that captures the teams’ shared understanding of what good code looks like.

A shared understanding on .rules that perfectly captures the teams’ conventions and agreements is an enormous enabler. Review time will be cut down significantly as routine conventions are followed automatically for all engineers.

Having shared skills to automate boring things like creating reports, releasing or creating work items in Jira saves loads of time.

Time the engineers can spend on building features or fixing important bugs.

Agents don’t care about your instructionsJordy van Vorselen · August 22, 2026Put the code up for review and you still end up reviewing, reworking and refactoring the code three more times after your coworkers’ AI agent puts around 10 review comments on your PR.
Read full story
Agents don’t care about your instructions

How to start

It’s easy to start with this nowadays. There is tooling available, that can be installed and configured in less than an hour.

It will support everyone’s agent harness and models, and let engineers work in whatever harness they prefer.

Using Cursor? Fine. Claude code? Codex? Or a Pi fan like me? All good.

Microsoft has an open source project for this called Agent Package Manager. I’ve been using it for a while now and it works very well.

Work goes on as always

So now when that senior has their last Friday, momentum is kept.

The work continues on Monday. Work keeps the same quality, the same rules and the team still has their same workflow.

Because the team owns it.

Don’t leave your AI workflow in home folders. DM me SETUP and I’ll send you how to structure shared rules, skills and hooks in one repo.

Related Posts