How to manage an external development team so it feels like your own

Most complaints about outside development teams sound like a skill problem, but they are usually a management problem that looks like a skill problem. A founder tells me the team is slow, or that the work is not what they asked for, or that they never know where things stand. Then I look at how the work is actually run, and the same pattern is there almost every time. The team is being measured on hours and activity instead of on working software, and the founder is spending their days checking on the team instead of guiding it. A good team run this way will look mediocre. A mediocre team run the right way will often surprise you. So before you decide the team is the issue, look at how you are running it.

Here is how we think about managing an external team, from the side of the company that is usually the external team.

Manage outcomes, not hours

Start with the one habit that quietly causes every other problem. When you hire an outside team, it feels responsible to track what everyone is doing with their time. So you start asking for hours, or daily activity, or a report of what each person worked on. It feels like control. It is the opposite.

The moment a team has to prove its hours to feel trusted, both sides move their effort from making progress to showing activity. The team writes tidier status updates. You get a fuller dashboard. And the product moves slower, because time spent proving work is time not spent doing it. Hours worked, tickets closed, and lines of code all measure activity, not progress. You can have a busy week that releases nothing that matters.

The fix is to move your attention to outcomes. The only question worth asking often is simple: can I use what you built. Was the thing released, is it in front of real users, did it move the number you cared about. We wrote a fuller version of this argument in measure engineers by outcomes, not output, and it matters more with an outside team, because you are not close to the work, so it is tempting to use the easy numbers. Do not do that. Judge the software, not the timesheet.

Get working software every week

Outcomes are only useful if you can see them often. So the single most important thing you can set up with an external team is a short cycle where you get working software, not a description of working software, every week or two.

The strongest teams already work this way. They release in small, frequent steps, because a small piece that goes wrong is easy to see and fix, while a big release that goes wrong hides the problem inside a hundred changes at once. This is one of the most consistent findings in the long-running DORA research on how software teams actually perform: releasing in small increments goes with lower failure rates, not higher. When you can open the product every week and use what the team said they would build, accountability stops being something you enforce and becomes something you can just see.

This also protects you from the worst outcome with an outside team: seeing all the work for the first time at the end. A team that stops communicating for three months and then shows you everything at once is a team you cannot correct. By the time you see the gap between what you wanted and what they built, three months of decisions depend on it. Short cycles make each mistake cheap, because you catch it one week after it was made. If you are still choosing a team, the way they answer "how often will we see working software" tells you a lot; we put more signals like this in how to choose the right external development team.

One clear point of contact on each side

Now the simple practice that saves more projects than any process. Have one clear owner on your side and one on theirs.

Here is the failure it prevents. A decision gets made in a quick call. Someone changes it in a chat channel. An engineer who was not in either place builds the original version a week later. Nobody lied and nobody was lazy, but the decision was lost between three conversations. The more people who can hand work to the team through different channels, the more often this happens, and the harder it is to trace when something is wrong.

One point of contact on each side fixes this without adding extra process. The owner does not have to make every decision. They just have to be the place every decision passes through, so it gets written down and cannot get lost. On your side, that person holds the priorities and answers questions fast. On their side, that person turns your direction into work the team can act on. When those two people trust each other and talk often, most of the coordination problems common with outside teams do not appear. This is part of what separates a real partner from a vendor you hand tasks to, which we explained in detail in software development partner vs. vendor.

Give feedback often and early

Feedback is only cheap when it is early. The most expensive feedback in software is the kind that arrives after the team has already built another week on top of the thing you did not like.

So do not save your reactions for a big review. When you get working software each week, look at it and say plainly what is right and what is wrong, while it is still cheap to change. A short daily meeting stops small problems that block work from turning into week-long ones, and a single longer weekly review is where you look at what was released and decide what comes next. That is usually enough. If you find yourself wanting more meetings than that, it is often a sign the team does not have enough written context to move on its own, which is a context problem, not a meeting problem.

The tone matters too. Feedback given early and directly, against something real you can both see, feels like collaboration. The same feedback saved up and delivered as a list of complaints at the end feels like an unfair surprise, and it teaches the team to stop communicating and become defensive. You want a team that tells you bad news early. You only get that if telling you bad news early is something you reward instead of punish.

Guide a team, do not supervise every step

Put all of this together and it comes down to one distinction. There is a team you guide and a team you supervise at every step, and the difference is not the hourly rate.

A team you guide needs a clear goal, quick answers to its questions, and the reasons behind the goal. Give it those, and it makes good small decisions on its own, hundreds of them you never see. A team you supervise at every step needs the work broken into tiny pieces and checked constantly, because you do not trust it to make sensible decisions where the plan says nothing. That second team is slower and more expensive no matter what it costs per hour, because every decision has to wait for you, and one person has limited attention.

Most of the time, whether a team can work with only guidance depends as much on you as on them. The failures we see most often come from not giving the outside team enough context, not from the team lacking skill. Give an external team the same context and trust you would give your own engineers, hold them to the same outcomes, and something surprising happens: the "managing" mostly disappears. You stop spending your days checking on the team, and you start spending them deciding what to build next, which is the only part that was ever really yours to do. A small, senior team run this way will often build more than a larger one that is supervised at every step, which is a pattern we see so often we wrote it up in why a small senior team builds more than a big one.

The team you hired is probably better than the reports make them look. Change what you measure and how often you look, and you may find you had a team worth guiding from the start.

One question to add to your weekly meeting

If your external team is generating code, and in 2026 they almost certainly are, add one question to whatever you already ask them: who read this before it reached us.

You are not asking for a process description. You are asking for a name. Any supplier can tell you they have a review step, and the ones whose review step is a formality will tell you that in exactly the same words as the ones whose review step is real. A name is harder to produce when there is nobody behind it.

Ask it early, ask it in writing, and ask it the same way every week. It is the cheapest quality control available to you and it takes about nine seconds.

Sources

• DORA, Accelerate State of DevOps research: https://dora.dev/research/