Managed engineering squads: how they work day to day

A managed engineering squad is a small, complete team, made up of a squad lead, developers and QA, that joins your workflow and takes responsibility for day-to-day delivery. You decide what matters most. The squad lead turns that into a sprint plan, keeps the work moving and tells you what shipped. You pay a flat monthly fee for the squad, not hourly bills for each person.

This post covers how that works in practice. If you are still choosing between a squad, staff augmentation and a fixed-scope project, start with our comparison of the three models.

Who is in a squad

Every squad has three kinds of role. The mix of skills changes with the work.

• Squad lead. Runs sprint planning, code reviews, coordination and progress updates. This is your single point of contact, so you manage priorities rather than individual developers.
• Developers. Engineers who have delivered together before and follow shared coding standards, so they start with one technical direction instead of several.
• QA. Automated tests and reviews are part of every sprint, not a separate phase before release.

Specialists join when a piece of work needs them, for example DevOps for a critical release or data engineering for a reporting project. We manage their handover in and out of the squad.

Common squad setups

• MVP foundation: a part-time squad lead, full-stack developers and QA automation, to build and launch the first version of a new product.
• Growing product team: a squad lead, senior backend and frontend developers and a QA engineer, for a live product that needs new features and better reliability.
• AI product team: an AI architect, ML engineers and a data engineer, for adding RAG, fine-tuning or LLM features to a product you already run.

What day-to-day work looks like

The squad works inside your tools: your Slack, Jira, GitHub and meeting rhythm. We keep at least four hours of overlap with your working day for the conversations that need to happen live. Every sprint follows the same pattern:

• Daily stand-up in the overlap hours. It is short and focused on blockers and on decisions the squad needs from you.
• Sprint planning at the start of each sprint. You bring priorities. The squad lead brings estimates, risks and a proposed plan, and together you agree what goes in.
• Code review on every change. A second engineer reads each change and the automated tests must pass before it is merged.
• A demo at the end of the sprint. You see working software, not a status slide.
• A retrospective. The squad looks at what slowed it down and changes one or two things for the next sprint.

Sprint length is agreed with you at the start. Consistency matters more than the exact length, because your team learns when to bring new priorities and when to expect a demo.

What you own and what the squad owns

A clear split of responsibilities is what makes a managed squad different from a group of contractors.

• You own the product vision, the order of priorities, acceptance of finished work, and access to the people who know the business.
• The squad lead owns the sprint plan, who works on what, code quality, coordination and raising risks early.
• The squad owns building, testing, reviewing and releasing the work agreed for the sprint.
• Coretus owns selecting the right people, replacing anyone who isn't the right fit with a planned handover, and adding or reducing specialist support as your priorities change.

How progress is reported

The squad lead sends regular progress updates in a format you agree at the start. A useful update is short and answers the same questions every time:

• What shipped since the last update, with links to the tickets or release notes.
• What is planned next, and whether the current sprint is on track.
• Risks and blockers, and any decision needed from you.
• Quality signals, such as open bugs, failed builds or test coverage on new code.

Because the work happens in your Jira and GitHub, you can check progress yourself at any time. The update saves you that effort. It doesn't replace your own view of the work.

How the flat monthly fee works

You pay one fee per squad per month. There are no timesheets to check and no bill that grows because a task took longer than expected. The fee is set by the squad setup and the skills it needs.

This changes the conversation in a useful way. Instead of debating hours, you and the squad lead talk about scope: what fits in this sprint, what should wait and what is worth doing at all. When your needs change, you add or reduce specialist support rather than renegotiate the whole arrangement.

You own 100% of the code, designs and IP, and that is written into the service agreement. We can sign an NDA before you share anything sensitive.

How to start a squad

1. Team fit review. We look at your technology, roadmap and working style and suggest a squad setup and skills.
2. Meet your squad lead. You agree communication, working hours and how the squad fits the way your business works.
3. Join your workflow. The squad gets access to your tools, with clear responsibilities for each person.
4. Start delivery. Agreements are signed, access is ready and the first sprint plan is underway.

Three things help before the first sprint: a prioritised list of the work you want done first, one person on your side who can answer product questions quickly, and access to your code, environments and documentation.

When a squad is not the right fit

A squad works best for a roadmap that keeps moving. If you have one clearly defined deliverable with a fixed end date, project delivery is usually a better match. If you need direction more than capacity, such as an architecture review or a technology roadmap, start with a fractional CTO and add a squad once the plan needs hands-on work.

Where to start

List the next three things on your roadmap and who on your side would own each one. Then book a free 30-minute call. After the first call we suggest the right squad setup and give you a rough quote range. The full details of the model are on our managed engineering squads page.