Fast Answer

When founders cannot make changes stick, it is not mainly a discipline problem. It is usually caused by a fix that depended on the founder rather than on the week. When the first heavy week arrives, the founder overrides the new routine, and experiences that as personal failure. The first correction is not more commitment, but a structure with a fixed time, a visible finish line and a fallback rule.

Key Takeaways

• Most founders can make changes stick for about ten days. Week two is where effort-based fixes break.
• The fix fails because it lives in the founder, so the first heavy week overrides it.
• Founders then blame discipline, which hides the structural cause and guarantees a repeat.
• A correction that holds has a fixed slot, a visible “done looks like” and a rule for bad weeks.
• A short weekly note on what held and what broke catches the collapse before it becomes the new normal.

Why Do Founders Fail to Make Changes Stick?

It is Tuesday of week two. Last week you protected a 90-minute block, phone in a drawer, and it felt great. This morning an investor moved a call into the slot, a client escalated on WhatsApp, and your ops lead needed “a quick yes” on a contract. The block became “just this once”. By Friday it has quietly gone.

You do not tell anyone. You tell yourself you will restart on Monday. Monday arrives with its own pressures, a Slack thread with 40 unread replies and a dashboard you meant to check, and the routine that felt solid ten days ago is now a thing you used to do.

To make changes stick is to have a new behaviour survive contact with a normal, difficult week. The visible symptom is a routine that fades. The real issue is not inside any single domain. The fix was never built into the operating layer of the company, so the first piece of urgency outranked it, and every domain it touched quietly let it go.

Why Does More Commitment Not Fix It?

The usual response is to try harder. A stricter schedule, a public promise, a better app. Each of these adds pressure on the founder, who is already the most overloaded part of the system.

By 10am a founder has made dozens of small decisions, many of them reactive. A fix that needs fresh resolve every morning has to compete with all of them. More accountability talk does not help either, because talk is not a change to the week.

Time is also against the effort-based approach. Research on habit formation published in the European Journal of Social Psychology found that new behaviours took a median of around two months to become automatic, with wide variation between people. Week two is nowhere near the point where a routine runs on its own. Until then, it needs structure to carry it.

The deeper problem is that the new routine sits on top of an unchanged structure. Meetings still land wherever people ask. Messages still arrive without windows. Nothing in the week treats the new block as real.

The Hidden Mechanism Behind the Week-Two Collapse

The collapse follows a predictable cascade.

1. An effort-based fix is set up with enthusiasm.
2. The first heavy week arrives and urgency outranks it.
3. The founder overrides the fix, because nothing stops them.
4. The pattern returns and the founder concludes they lack discipline.
5. They stop trying, or they try something new and repeat the cycle.

The cause is that the fix has no load-bearing structure. It has no fixed point in the calendar the team can see, no definition of done that can be checked, and no fallback for when the week goes wrong. Cohesion holds when each of the seven domains has structure the founder does not have to carry personally. A fix that lives only in the founder has none, so it shows up as a fracture wherever it lands.

How the Collapse Shows Up Across the Seven Domains

Rhythm. The new block has no fixed point in the operating cadence, so the first rescheduled call takes its place.

Attention. The slot is protected in theory, but WhatsApp, Slack and “can you just approve this” still reach the founder inside it.

Identity. The founder still sees themselves as the person who catches everything, so stepping away from the urgent feels like neglect.

Environment. The defaults are unchanged. Notifications stay on, the inbox stays open, and the easy action is the old one.

Systems. There is no written rule for exceptions or for the shortened version, so every heavy day is decided from scratch.

Relationships. The team was never told what the change is for or what counts as a real interruption, so they cannot protect it.

Purpose. The change is not tied to a decision the company needs, so it loses every trade-off against something that feels urgent.

Why Founders Stay Stuck in the Restart Loop

Pressure rises, so the founder reacts manually. The team learns that the new block is negotiable, because it often is. The founder grows more overloaded, and the fix is judged a failure instead of a design flaw. The structure is never corrected, so the same collapse returns next quarter in a new form: a planning habit, a weekly review, a delegation rule.

It stays invisible because the first week works. Early results confirm the belief that the idea was right and the founder was the weak point. Nothing in the loop asks whether the fix was built to carry weight.

What Changes When the Fix Is Built to Hold?

The new behaviour survives a bad week because it has a slot the team knows about, a result you can see, and a pre-agreed fallback. The founder no longer decides in the moment whether the block is real. The decision was made on a calm day and written down.

Feedback also shortens. Instead of discovering on Friday that the whole week slipped, the founder sees on Tuesday that the block was moved, and decides what to do about it. A protected block is not protected if the team still treats it as available time, so once the team knows the rule, they start defending it too.

Founder Field Note

One founder came in believing she could not stay consistent with a morning planning habit. The real issue was that every version of the habit relied on her remembering it on the hardest days. The first correction was not a better habit. It was a fixed 8:30 slot in the shared calendar, a one-line definition of done (three priorities written down) and a rule for chaotic weeks: do the shortened version, never skip. After three weeks the slot had survived two investor calls. This pattern repeats because founders design fixes for the calm week and then expect them to run in the heavy one.

Common Mistakes When Trying to Make Changes Stick

• Starting with several new routines at once instead of one correction at a time.
• Designing for a calm week and never testing against a heavy one.
• Keeping the new habit private so the team cannot protect it.
• Having no written definition of done, so partial effort counts as success.
• Waiting for the end of the month to notice a slip.
• Treating a missed day as proof of a character flaw instead of data.

How to Start Making Changes Stick

1. Pick one correction. Choose the single change that would relieve the most load.
2. Give it a fixed slot. A day, a time, and a calendar entry the team can see.
3. Write what done looks like. One sentence you could check at 17:00.
4. Write the fallback. What the shortened version is on a heavy week.
5. Report on Friday. Two lines: what held, what broke. Adjust the structure, not your resolve.

Do not try to fix the entire business at once. Start where the fracture is loudest.

FAQ

Why do my new routines fade after a week or two?

Because they depend on you remembering and choosing them every day. The first heavy week gives something more urgent a stronger claim. A routine that holds has a fixed slot and a fallback, so it does not need to win an argument each morning. Until it becomes automatic, which takes far longer than two weeks, structure has to carry it.

Is this a discipline problem?

Rarely. Discipline is what founders use when structure is missing. If a fix keeps failing at the same point, the design is the problem, not the person running it. Look at where the fix broke, which domain it was sitting in, and what in that domain made the old pattern the easier one.

How do I protect a new routine from the team?

Make it visible. Put it in the shared calendar, tell the team what it is for and what counts as a real exception. A protected block is not protected if the team still treats it as available time. Name who can break it and for what, so nobody has to guess.

What should I do after a missed day?

Record it as data. Note what moved the slot, then change the structure: move the time, shorten the version, or add a rule about who can break it. One missed day tells you where the design is weak. Three missed days in a row tell you the fix needs rebuilding, not more effort.

Next Step

If this sounds familiar, do not add another system yet. First, identify where the fracture is actually happening. Take the Founder Cohesion Assessment to see which of the seven domains is creating the most fragmentation in your company and what to correct first.

It did not fail because you are weak. It failed because it was never built to carry weight.

About the Author

Dominik Boecker is the creator of Cohesion OS. He helps founder-led companies identify the fracture lines that create overload, dependency, and operational fragmentation, then install the systems that restore cohesion across rhythm, attention, identity, environment, systems, relationships, and purpose.