Leading a Dev Team as a Fractional CTO: The Weekly Operating Rhythm I Use With Every Client

Most of the engineering teams I walk into as a fractional CTO do not have a process problem. They have a rhythm problem. The meetings exist. The tools exist. The standups happen on some days and not others. Planning is a quarterly panic. 1:1s slip. Reviews pile up. The founder knows something is off but cannot point to it.

What they are missing is not a methodology. It is a heartbeat — a predictable weekly operating rhythm that the whole team can feel, that surfaces problems early, and that the founder can plug into without being in every meeting.

This is the rhythm I install in the first two weeks of every engagement. It is deliberately unglamorous. It works.

The design principles

Before the schedule itself, a few principles that shape it. If you copy the meetings without the principles, you will end up with the same problem the team had before, just on different days of the week.

Meetings serve the work, not the other way around. Every meeting on the calendar has to answer a specific question. If it does not, it gets killed. "Because we always have it" is not an answer.

Written asynchronously, synced selectively. The default is writing. Sync time is reserved for decisions, disagreements, and humans who need to connect. Status updates do not deserve synchronous time.

Protect deep work. Engineers need long contiguous blocks to do real work. The schedule below clusters meetings on specific days and leaves others intentionally empty.

Founders get a window, not a firehose. Non-technical founders need real visibility without sitting in every review. There is exactly one meeting in the week designed for them.

Everything is recoverable from one place. If someone is sick, on vacation, or just new, they can read two documents and catch up. No oral tradition.

The rhythm

Daily (15 minutes max): Async standup in Slack

Not a meeting. A written post in a dedicated channel. Three lines per person: what I did yesterday, what I am doing today, what is blocking me. Due by 10am local time.

Why written: engineers in different time zones, engineers who do their best thinking before other humans are awake, engineers who hate being put on the spot. Written standups also leave a searchable history that a real standup does not.

Why three lines: because anything longer becomes a report, and reports belong elsewhere. The point is to surface blockers fast enough that someone can help before the end of the day.

Who reads it: every engineer on the team, plus me. Founder does not need to read this one.

Monday (45 minutes): Weekly planning

The only recurring meeting on Monday. The team picks up the plan from last week, reviews what did not get done, and commits to the week ahead. Not story points. Not sprint ceremony theater. A list of outcomes the team will deliver this week, written down, owned by a specific person.

Format I use: a shared doc with three sections — shipping this week, in flight, on deck. Every item has a single owner. The meeting is spent removing items, not adding them.

Deep-work rule: the rest of Monday afternoon is blocked. No other meetings.

Tuesday and Thursday: Maker days

No recurring meetings. Period. 1:1s can happen on these days but only before 10am or after 4pm. This is protected time for engineers to do the work they committed to on Monday.

If a founder tries to schedule an architecture discussion on Tuesday at 1pm, I push back. The correct answer is "let's put that on Wednesday at the same time we do the architecture review." Consistency is the whole value of the rhythm.

Wednesday (60 minutes): Engineering review

The core meeting of the week. Half technical review, half product alignment. Structure:

15 minutes — demo. Whoever shipped something the previous week demos it. Working software, not slides. If there is nothing to demo, that is itself information and we talk about why.
20 minutes — architecture and tradeoffs. Anything a team member wants feedback on before building it. Short written proposals, read before the meeting.
15 minutes — metrics. Deployment frequency, lead time, error rate, anything in flight on the SLO side. I will write a full article on which metrics to watch; the short version is DORA plus one or two product-specific numbers.
10 minutes — blockers and risks. What could derail next week. Who needs help.

Founder joins this one. Product joins this one. Sales and customer success are invited but not required. This is the meeting that keeps everyone aligned without pulling anyone into ten other meetings.

Friday morning (30 minutes): Founder + CTO sync

A private recurring meeting between me and the founder. This is where I earn my keep.

The founder talks about what they are worried about, what they are hearing from customers, what they are hearing from the board. I talk about what I am seeing in the team, what is on track, what is not, and what decisions I am going to push on in the next week.

No engineers in this meeting. It is a pressure valve for both sides. When founders do not have a dedicated space to talk to their technical leader, they end up dropping tech concerns into the middle of product meetings and everyone suffers.

Friday afternoon: Shipping and write-up

Unofficial but consistent. Friday afternoon is when most teams ship, tidy up, and write a very short weekly update — 5–10 bullet points posted in a team-wide channel, readable by non-engineers. What shipped, what is coming next week, anything the broader company should know.

This is the single best artifact for keeping a non-technical founder comfortable. It costs 20 minutes. It replaces hours of anxious check-ins.

The 1:1 cadence

I do a 30-minute 1:1 with each engineer every two weeks, plus an on-demand Slack DM policy — my DMs are always open, and I respond within the workday.

The biweekly cadence is deliberate. Weekly is too much for senior engineers who do not need hand-holding. Monthly is too slow for the same engineers when something is actually wrong. Every two weeks hits the sweet spot.

I wrote a separate article on how to run a 1:1 with a senior engineer when you are not technical yourself; link at the bottom. The short version: listen more than you talk, ask about the work and the career, write down commitments, and follow up next time.

What this rhythm replaces

On most teams I join, the before-state looks something like this: daily standups that drift to 45 minutes and cover nothing actionable, a "two-week sprint" nobody believes in, an architecture discussion Slack thread that never converges, a founder who only talks to engineering when something is on fire, and no 1:1s at all.

The rhythm above collapses that into four recurring meetings per week, two artifacts (the weekly plan doc and the Friday write-up), and a 1:1 cadence. Total synchronous time per engineer per week: about 2.5 hours. The rest is maker time.

Counterpoint: "this is too light for a growing team"

I get this one a lot, especially from founders who are used to process-heavy orgs. The pushback usually sounds like: shouldn't we have a retro? a grooming session? a separate architecture meeting? a design review?

Maybe, eventually. But the mistake I see over and over is adding meetings before the basic rhythm is working. A team that cannot hit its Monday plan reliably is not going to be helped by adding a Tuesday retro. Fix the rhythm first. Add ceremony only when there is a specific problem it solves.

I will often add a monthly retro at the 60-day mark once the team is in a groove. It fits on the last Friday of the month in place of the regular Friday sync, runs 45 minutes, and focuses on one question: what do we want to change about how we work next month? One question, one page of notes, clear owners for any changes. That is it.

Counterpoint: "what about asynchronous / remote teams?"

Everything above works on a remote team — in fact, the rhythm is easier to enforce remotely because calendar discipline matters more. The two adjustments I make:

Standups are 100% written, every day. No "optional sync standup" for the people in the office. One format for everyone.
The Wednesday review runs longer by 15 minutes and explicitly includes a time-zone-friendly slot. For a team spanning 8+ hours I will record the meeting and rotate its time every quarter.

Remote teams also need a stronger written culture overall. That is a different article.

What happens in week one

If you want to install this rhythm on your own team, the first week looks like this:

Monday. Write the team a short memo explaining the new rhythm and why. Do not put it to a vote. Lead it.
Tuesday. Get the calendar invites on everyone's calendar for the next four weeks. Delete or decline any existing meeting that conflicts.
Wednesday. Run the first engineering review, even if nothing is ready to demo. Especially then. The meeting is the forcing function.
Thursday. Start the async standup channel. Post yours first so others have a template.
Friday. Run the first founder sync. Write the first weekly update. Keep both short.
Week two. Adjust. The rhythm will need small tweaks. Do not change the structure in the first month, just the edges.

By the end of the third week, the team will forget it was ever different.

The founder's job in this rhythm

This section is for the non-technical CEO reading the article. You have two responsibilities in the weekly rhythm. First, show up to the Wednesday review and ask questions — any questions. "I do not understand that word" is a valid question and you should ask it often. Second, be honest in the Friday sync. If you are worried about something, say so. If you are happy with where things are, say that too. The rhythm only works if the information flows in both directions.

Everything else — the planning, the reviews, the 1:1s, the metrics — is my job. That is what you are paying a fractional CTO to do.

Where I help

I install this rhythm on every engagement. Usually within two weeks. The team feels the difference within a month, and the founder usually tells me some version of the same sentence: "for the first time, I actually know what is going on in engineering." That sentence is what a good operating rhythm buys you.

If your engineering team is busy but you cannot shake the feeling that it is not shipping, it is almost always a rhythm problem. Book a call and we will look at your current calendar, your current cadence, and what is missing. It is the cheapest, highest-leverage conversation you can have this quarter.