How to Manage a Dedicated Development Team: Cadence, Metrics, Health Checks

Start with who owns what

When a dedicated team underperforms, the root cause we find most often is not skill. It's an ownership gap: a decision that both sides thought the other one was making. The client assumed the vendor's tech lead would push back on a risky deadline. The tech lead assumed the client had already accepted the risk. Six weeks later, everyone is surprised.

The cure is boring and works: write down who is responsible for each recurring decision, before the first sprint. Here's the split we use as a starting point for a team that has a vendor-side tech lead and project manager. R is responsible (does the work), A is accountable (has the final say, exactly one per row), C is consulted, I is informed.

Two rows cause the most trouble. Estimates belong to the people who do the work. If you set the deadline and the team “agrees”, you've moved accountability for the date to yourself without noticing. And individual performance goes through the vendor. You give the feedback (specific and written), the vendor acts on it. The team members are the vendor's employees, and the vendor has the tools to coach, move or replace them.

If you don't have a CTO, that column doesn't disappear. Someone has to be accountable for architecture. Either the vendor's tech lead takes it explicitly (and you get an independent review once or twice a year, like our tech troubleshooting engagements), or you hire a fractional CTO.

The first two weeks set the tone

Onboarding is part of management, and the habits formed in the first sprint tend to stick for the whole engagement. Teams that get access on day one and ship something small in week two come to trust their client. Teams that wait a week for a VPN learn that waiting is normal.

1. Day 1: access and contextRepositories, cloud console (read access is enough at first), CI, error tracking, the board, chat channels and a 60-minute product walkthrough by the product owner, as a user would see it.
2. Days 2–5: environments and a first ticket eachEvery developer runs the project locally and picks up one small, real ticket: a bug, a copy change, a missing test. It flushes out every broken setup step.
3. Week 2: first release and first planningThe small changes ship to production. The first proper sprint planning runs on refined backlog items, with the team estimating.
4. End of week 2: the first retro and a written working agreementMeeting times, response expectations, definition of done, how to escalate. One page, agreed by both sides, revisited at month three.

A meeting cadence that fits your overlap

Most dedicated teams run on two-week sprints with the standard Scrum events. That works, but the events have to fit inside the hours both sides are awake. A team in Poland and a client in New York share about three to four working hours a day. A team in Poland and a client in California share one or two, if somebody stretches.

The question isn't whether to hold these meetings but how many of your shared hours they consume. Use the planner to check your setup. As a rule of thumb, if live meetings eat more than a third of the overlap, the team will spend its most valuable hours (the ones where it can ask you questions) talking about status instead.

The communication-paths number is there for a reason. A team of six plus two people on your side has 28 lines between people; a team of ten has 66. This is why the Scrum Guide suggests ten people or fewer, and why we split teams before they hit that size. More on that in dedicated development team structure.

Async by default, live for decisions

With a team in another time zone, writing is management. A ticket that says “fix the export” costs a day of round trips; a ticket with acceptance criteria, a screenshot and a named person to ask costs none. These are the working rules we agree with clients in the first week:

• Every ticket ready for a sprint has acceptance criteria that the QA engineer can test without asking anyone. If refinement can't produce them, the ticket isn't ready. A business analyst on the team pays for themselves here.
• Questions get an answer within four working hours. This is the single rule with the biggest effect on throughput, and it binds your side, not the team's. A developer blocked overnight loses a day; blocked twice a week, they lose 40% of their sprint.
• Decisions go in a decision log, one line each: date, decision, who made it, why. It ends the “I thought we agreed” conversations and makes onboarding new people much faster.
• Status goes in writing. A weekly update from the vendor PM: what shipped, what's at risk, what they need from you. Five bullets is enough. Status meetings are for when the written update raised a question.
• Demos are recorded, so stakeholders who couldn't attend can watch at 1.5× speed and comment.

What to measure, and what to ignore

Hours logged tell you the team was present. Story points tell you how the team estimates. Neither tells you whether the money is producing working software. The metrics below do, and most of them come straight from your repository and board with no extra reporting effort. The first four are adapted from Google's DORA research, the most widely used benchmark for software delivery performance.

A forecast accuracy of exactly 100% every sprint is not good news. It usually means the team commits to less than it can do. Healthy teams miss sometimes and explain why.

Don't use these to rank individual developers. The moment a metric becomes a personal target, people optimize the number (small, safe commits; trivial bug tickets) and the signal is gone. Use them to compare the team with itself over time, and to start conversations.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Real estateModernizing a Multi-Service Real Estate Marketplace→FinTechAndroid application for FinTech industry→Pharmacy · DACHRedesigning and modernizing an Online Pharmacy mobile app→

Talk to the people who build it. Tell us about your project — get a free estimate of scope, timeline and cost.

Get a free estimate →

Run a monthly health check

The engagements that fail rarely fail suddenly. The same signals show up for two or three months: demos get shorter, the weekly update gets vaguer, a senior developer stops speaking up in planning, hotfixes become routine. A 30-minute monthly review with the vendor's tech lead and delivery manager catches this while it's cheap to fix.

Go through the list together. Each unticked item is an agenda point, with an owner and a date. Your answers are saved in this browser, so you can come back next month and compare.

When things go wrong: symptoms and fixes

Every long engagement hits rough patches. What separates the ones that recover is a quick, specific diagnosis instead of a general feeling that “the team is slow”. Pick the symptom closest to yours.

Scaling, replacing and handing over

Scaling up works best one or two people at a time, with at least two sprints between additions, so each new person is productive before the next one arrives. Adding four people at once to a team of four usually halves output for a month. Give the vendor four to six weeks' notice for senior roles; good vendors can do it faster, but you shouldn't plan around that.

Replacing someone should be uneventful. Give specific feedback through the vendor, agree on what should change in two to four weeks, and if it doesn't, ask for a replacement with an overlap. Don't wait until the end of a quarter. A mismatch rarely improves by itself.

Scaling down or handing over needs a plan from the start: documentation that lives in your repository, infrastructure in your accounts, and knowledge spread across at least two people for every critical area. If you plan to take the product in-house later, say so early. A good vendor will help you hire and overlap the new people with the team. Our article on moving from staff augmentation to managed services covers the other direction: handing the vendor more responsibility as trust grows.

FAQ

Where Gilzor fits

Most of what this article asks of you, our teams do by default: a tech lead who owns code quality, a project manager who writes the weekly update and raises risks early, QA that tracks what comes back, and a delivery manager you can call when something isn't right. That's how we keep 98% of deliveries on time and why 85% of our clients come back.

If you're running a dedicated team that isn't performing, or about to start one, talk to us. We'll look at how it's set up and tell you what we'd change, whether or not you end up working with us. You can also read how we run project management and development support.