A two-hour meeting with three developers does not cost two hours. It costs six hours of delivery capacity and a day of broken focus. When your lead developer is also your project manager, meetings have a direct cost that shows up in delivery timelines.
Small teams cannot absorb that cost the way a large consultancy can. There are no spare developers waiting on the bench while someone is in a call. This post covers how we structure client communication at Two Red Kites to keep projects moving without letting anyone fall out of the loop.
Why Meetings Go Wrong on Small Projects
In a large consultancy, there are dedicated project managers and business analysts whose entire job is communication. The developers code, the PM handles the client. Clean separation.
On a small team, that separation doesn’t exist. The lead developer needs to be in the meeting because they’re the one who understands the technical constraints, the current state of the codebase, and what’s actually feasible this sprint. But every meeting they attend is time they’re not building the thing the client is paying for.
This creates a tension that most small teams handle badly. Either they over-communicate (daily calls, lengthy email threads, constant Slack messages) and lose productive hours, or they under-communicate (heads down for two weeks, then a surprise demo) and lose client trust.
The solution isn’t fewer meetings or more meetings. It’s the right meetings at the right cadence, with the right preparation.
The Three-Tier Cadence
We’ve landed on a structure that balances alignment with productivity. Three types of meetings, three different frequencies, three different purposes.
Weekly: Status Updates (15-30 Minutes)
The weekly meeting is short and operational. What got done, what’s coming next, what’s blocked.
The key to making this work: run it from the agile board, not from memory. Pull up the board, walk through what moved from “in progress” to “done,” point out what’s coming up, and flag anything that needs client input. This takes 15 minutes if everyone is prepared, 30 minutes if there are decisions to make.
Send the agenda beforehand. Not a formal document — a few bullet points covering what you’ll discuss and what decisions you need from the client. This lets the client prepare, which means faster meetings. If a question needs internal discussion on their side, they can do that before the call instead of saying “let me get back to you” during it.
The weekly meeting replaces the need for constant ad hoc communication. If something isn’t urgent enough to warrant an immediate message, it goes on the weekly agenda.
Monthly: Strategic Alignment (45-60 Minutes)
The monthly meeting steps back from the day-to-day and looks at the bigger picture. Is the project heading in the right direction? Are priorities still correct? Has anything changed in the client’s business that should change what we’re building?
This is where you discuss feature trade-offs, revisit the roadmap, and address any concerns that don’t fit into a 15-minute status update. It’s also where the client can raise things they’ve been thinking about — ideas for new features, feedback from their users, shifts in their market.
In larger companies, there’s usually a Product Manager handling strategy and a Project Manager handling execution. On a small team, these roles collapse into one or two people. The monthly meeting is where you explicitly put on the product hat and think beyond the current sprint.
If the client needs to discuss priorities internally before committing, the monthly meeting is the right place to set that up. They take it back to their team, align internally, and confirm decisions before the next weekly.
Quarterly: Roadmap Review (90 Minutes)
The quarterly meeting is a mini kick-off. Review what was delivered over the past quarter, assess what worked and what didn’t, and plan the broad strokes of the next quarter.
This is the meeting where you zoom out far enough to ask whether the project is delivering business value. Not “did we complete the tickets” but “is this software making a difference.” It’s also where you recalibrate estimates, discuss budget allocation, and set expectations for the coming months.
Quarterly meetings are worth the longer time investment because they prevent the slow drift that happens when everyone is focused on weekly execution. Without them, you can deliver every sprint perfectly and still end up somewhere the client didn’t want to be.
If this cadence sounds like what your project needs, we should talk. Book a free 30-minute call → — no pitch, just a conversation about how we would structure communication on your project.
Making Each Meeting Work
A few principles that apply across all three tiers:
Preparation beats duration. A 15-minute meeting with an agenda beats a 60-minute meeting without one. Send the agenda at least a day before the meeting. Include any decisions you need so the client can think about them in advance.
Decisions get documented. If something was agreed in a meeting, it goes into the project management tool immediately. Not in a follow-up email three days later. Not in someone’s notebook. In the system of record, where the development team will actually see it.
The board is the source of truth. Status updates should come from the agile board, not from a developer’s recollection of what they worked on. This forces the team to keep the board current, which has the secondary benefit of making status visible between meetings too.
Handling No-Shows and Deferred Decisions
Clients miss meetings. It happens. The question is what the team does next.
Our approach: send a written summary of what was discussed (even if it was just the internal team reviewing the board) and what decisions were made or deferred. The team continues working on the priorities already agreed upon. Anything that genuinely needs client input gets flagged in the project management tool with a clear description of what’s needed and by when.
We don’t stop work because a meeting was missed. We act in the best interest of the project based on the information we have, and we document that we did so. This keeps the project moving and gives the client a clear record of what happened in their absence.
The same principle applies to deferred decisions. If the client says “let me think about it,” that’s fine — but the item goes on the next agenda with a note that it’s pending. Nothing falls through the cracks because everything is written down.
Why Written Status Matters More Than You Think
Meetings are ephemeral. Written status is permanent.
We’ve learned (sometimes the hard way) that getting better at documenting status pays for itself many times over. When a client asks “what happened last month,” the answer shouldn’t require someone to reconstruct it from memory. It should be in the project management tool, in meeting summaries, in the commit history.
At Two Red Kites, this is built into how we work. The senior engineer in your meeting is the same person writing the code — there is no telephone game between a project manager relaying requirements and a developer interpreting them second-hand. We use project management tooling that gives you real-time visibility into progress, so written status is not something we produce separately; it is a byproduct of how we deliver every project.
Written status also solves the “will the client pay for meetings” question that small teams quietly worry about. When meeting time is visibly productive — clear agendas, documented decisions, updated boards — clients see it as part of delivery, not overhead. It’s when meetings feel disorganised and repetitive that clients start questioning the bill.
Good documentation also protects both sides. If there’s ever a disagreement about what was agreed, the written record settles it. No “I thought we said” conversations. Just “here’s what we documented on this date.”
Book a free 30-minute call → — no pitch, just a conversation about how we would structure communication on your project.
Frequently Asked Questions
How often should a small dev team meet with clients? Three tiers work well: weekly standups, monthly strategy sessions, and quarterly roadmap reviews. See the cadence breakdown above for timing and format.
What should be on the agenda for a client status meeting? Walk the agile board, flag blockers, and confirm upcoming priorities. Send it a day ahead so the client arrives ready to decide.
What happens if a client misses a meeting? Send a written summary, keep building on agreed priorities, and flag anything that needs their input in the project management tool.