← InsightsSchedulingOct 2, 2026Chris Cohen

Building an onsite schedule around an engineering team

How I pick days, hours and rooms for a software team, so the schedule survives release weeks instead of fighting them.

A weekly onsite schedule only works if it survives the calendar it lands in. For a software team that means standups, sprint boundaries, release weeks, and the fact that a fair number of people won't be in the building on any given day.

Most onsite programs are designed on a whiteboard and then handed to a team lead who has to make them fit reality. I would rather start with the constraint.

Start with the calendar you actually have

Before I propose days, I ask for two things: the recurring meetings nobody moves, and the two or three people whose presence decides whether a session feels like a room or a corridor.

Software teams cluster their meetings. In most companies there is a day when the office is full and a day when it is a ghost town. Coaching belongs on the full day, even when that day is less convenient for the coach.

Then the hours. The protected hours on a software team are usually early morning and the hour after lunch, because everything in between is a wall of standups and reviews. An eleven o'clock slot looks free in a calendar and is the worst time in practice: it's the buffer before lunch, and nobody gives up a buffer.

Two days beat five

A pattern I have come to trust: two onsite days with four to six hours each, rather than a thin spread across the week.

Two days means the same coach is present when the team is present, there are enough slots to book ahead, and someone who misses Tuesday can be seen Thursday instead of waiting a week. Five thin days creates the illusion of coverage: two hours here, two hours there, and a coach who is never around long enough for anyone to stop thinking of them as a visitor.

Make the room boring

The best space I have coached in was a converted storage room with a table and a chair. What made it work is that it never moved.

When the coaching space changes weekly, the program becomes a search problem. People who can't find you in week two don't look in week three. Book the room for the quarter, put a sign on the door, and let the schedule settle.

The slots

One-to-one sessions are 25 minutes, the same length at the same times, bookable two weeks ahead, held by calendar invite rather than a portal login.

Twenty-five minutes is enough for a warm-up, a review of last week, one coaching conversation and one specific change. It's short enough to take between meetings without rearranging the day.

Group sessions sit outside those hours: Stretch and Roll, the Vitamin D Walk. The point is that attending a group session never costs somebody their one-to-one slot, so nobody has to choose between the two.

New hires are the cheap win

The highest-value thing an onsite program does for a software team is catch people in their first month. Once somebody has settled into a rhythm, a midday session is an interruption. In the first weeks, it's just part of onboarding.

So I ask for a standing slot in week one or two, and for the new-hire list each month. It's the least glamorous request I make and the one that shapes an engagement more than any exercise prescription.

When the team is hybrid

Hybrid teams break naive onsite scheduling, and pretending otherwise wastes money.

Two things work. Anchor the schedule to the days people are contractually in the building, and check that assumption every quarter, because it drifts. And give remote people a written plan with a monthly review instead of a slot they can't use.

What doesn't work is a coach sitting in an empty office on a Tuesday because the office policy changed and nobody told the vendor.

Release weeks

Every software team has weeks when coaching is the wrong priority. I would rather hold the schedule at reduced volume than pretend a release week is normal: keep the group session, keep two hours of one-to-one, give the rest of the day back.

A program that insists on full attendance during a crunch teaches people that the program doesn't understand their job.

How to tell it's working

Not attendance in week one. Look at week six. Are slots booked before the day arrives? Are there people who have attended four or more times? Has anyone asked for something specific, like a plan for a shoulder or a routine for travel?

If the same names keep appearing and the numbers haven't halved, the schedule is doing its job. If attendance has collapsed, the schedule is fighting the calendar, and the schedule should be the thing that changes.

What I'd ask before you build one

Which day is the office actually full? Which hours are genuinely protected? Who books the room? Who owns the new-hire list?

Answer those four and the rest is arithmetic.