AI Is Changing Your Job. Build Your Second Door.

This is the written companion to Episode 1. It is not a transcript. It goes slower than the video, shows the method in full, and points to the sources so you can check them yourself.

The moment, and the question after it

It usually happens in an ordinary meeting. Someone pastes a request into a tool and reads out the result. The result is not perfect. It is also not bad. It resembles what you would have produced on a first pass, and it took about as long as it takes to make coffee.

What follows is quieter than panic. It is a small recalculation of your position that happens before you have decided to make it. This episode does not tell you the tool is worse than it looked, and it does not tell you your job is safe. It asks a more useful question: what can you do with the lessons those years gave you?

The answer here is not a career plan. It is a practice, and it starts with one sentence.

A second door

A second door is another place where you can use something you know to help someone with a problem. Not a second job. Not a side business you have to name this week. A place where one lesson you already carry turns out to be useful to somebody else.

The five steps

The framework page carries each step in full, with the worked example and a walk-through you can fill in. Here is the shape.

1. Notice. Pick one repeating problem you have actually helped with. Say who faces it and what happens when it goes wrong.
2. Build. Write the questions or steps you use, explain when to use them, and add one filled-in example. Keep the first version small.
3. Test. Ask a willing person to try it on a low-risk task or a past example. Observe where they need help and what the method misses. Record what actually happened.
4. Improve. Change the part that failed. Where practical, let someone outside your usual team try the revision. Record the next result and the limits.
5. Share. Explain the problem, first attempt, feedback, changes and observed result to someone who faces that problem. Ask where the method might still fail.

Maya, and the question her page did not ask

Maya has spent fifteen years helping teams finish projects. A customer asks for a brochure by Friday. The team agrees. On Friday, the printer is still waiting for approved artwork. The person who can approve it has been away all week. The customer needs the brochure for a Monday event.

She recognises the repeating problem: people promise a final date before checking what must happen first. So she writes a page. Version 1 asks what are we promising, who will do the work, when must it arrive, and what happens if it is late.

A colleague tests it by replaying the delivery that already went wrong. Every answer can be filled in: brochure, design team, Friday, Monday event. And then the colleague points out the problem. The page never asks who must approve the artwork. Version 1 would have missed exactly the thing that went wrong.

This is the part worth copying. The first attempt failed, and the failure is what produced the next version. Version 2 adds: what must happen first, and who needs to help or approve it.

Then someone from an events team tries version 2 on a different plan. Chairs must arrive before a room can be set up. They name the supplier, identify the approver, and write Thursday as the delivery date. Then they ask a question Maya had not thought to put on the page: has the supplier actually agreed to Thursday? Maya had assumed someone would make that call.

Version 3 adds that check. They call. Thursday is unavailable. They confirm Friday delivery and Saturday setup before promising the organiser when the room will be ready.

The result is a changed plan with confirmed timing. Not a rescued project, not money saved, not a promotion. A changed plan, and a page that now asks a question it did not ask before. Both improvements came from someone outside Maya's head.

Then you tell someone

Sharing is the step people skip, usually because it feels like self-promotion. It is not. It is how the method keeps improving, and it can be quiet: one person or one group who has this problem. Public posting is optional. Ask permission for anything that identifies another person or their work.

Say what you kept seeing, what you tried first, what actually happened when someone used it, what you changed and why, and what you have not tested. Then ask where it might still fail. That last question is the one that brings the next version.

What can grow from one useful idea

Your experience has now been used somewhere beyond your usual job. And you can do this again. The next time you notice a problem you know how to solve, go through the same process.

Over time you might have five useful ideas. Perhaps fifteen. Each with an example, a way to use it, and something you learned from trying it. You could bring those to a professional group, put them on a website, teach a short workshop, or find that some of them belong together in a book. Start where people already care about the problems you are solving.

Someone might read one of your examples and ask you to explain it to their team. That conversation could lead to another invitation. Perhaps, eventually, a conference. It could happen inside your company too: a colleague uses your method, their manager asks you to share it with the department, and people begin coming to you when they face that kind of problem.

Could that lead to a different role, a raise, or a promotion? Possibly. None of those is promised, and none of them may arrive. What you have either way is work you can show, a sense of which ideas help people, somewhere to develop the next one, and another way to describe yourself. "I help people plan projects without missing the steps that delay them." Your job title can change. You can keep developing that part of yourself.

What the research does and does not say

This part is optional depth. The studies below describe what happened when people used AI assistants at work. None of them tested the Second Door Plan, and none of them says anything about what this practice will do for you.

Read together, they support two things. Visible output became cheap for a wide class of tasks, and the gap between newer and more experienced people narrowed on those tasks. The tool's competence is also uneven and hard to see from inside a task. What they do not support is any prediction about your career. They measured tasks over weeks. They did not measure lives over decades.

Polanyi's older observation, that people know more than they can put into words, is why the Build step asks you to write the method down. Not because the unwritten part is safe from anything, but because a lesson that stays in your head cannot be handed to anyone. Writing it is how you find out which parts you had never actually said.

Start here

Finish the sentence: people ask me for help when. Then write the first question you usually ask them. The framework has the full method and a walk-through you can fill in, and the worksheet is on the site to use, print, or download.

AI may change the work you spent fifteen years learning. Those years also gave you problems you recognise, questions you know to ask, and lessons you can test somewhere new.