How to choose a software development partner / Work together well
How to work well with an embedded development team
The best partnerships feel like one team, and that does not happen by accident. Share real context, decide fast when the team brings you a decision, and measure the work by outcomes. Do those three things and an embedded team moves as fast as your own, often faster.
Published July 27, 2026. Editorial.
Key takeaways
- Give the team context and the reasons as well as a spec, so their judgment works for you.
- Decide fast: a partner waiting on you is the most common reason good teams slow down.
- Measure by outcomes, not hours logged or tickets closed.
- Treat them as one team with your own, with shared tools, standups, and definition of done.
Hiring a good team is most of the work, but there is more to do. How you work with them decides whether you get their best. The teams that get the most from an embedded partner do a few specific things, and none of them are complicated.
Share context as well as instructions
The most important thing is context. A team handed a spec can build the spec. A team handed the reasoning behind it, the constraints you are under, and the parts of the plan you are unsure about can build the right thing and catch mistakes you would have missed. Tell them the reasons. Tell them what is fixed and what is flexible, what you are worried about, what the business actually needs. This is what turns a vendor relationship into a partnership, and it costs you only some openness.
Decide fast
The most common reason a good team slows down is waiting on you. When an embedded team brings you a decision, they are usually blocked until you make it, and a decision that waits for a week is a week of progress lost. Decide promptly, even if the decision is imperfect, because most decisions are cheaper to make and adjust than to delay. Protect the team's speed by being available and decisive. As we argue in the founder's job is to remove ambiguity, removing obstacles is often the most useful thing you can do.
Measure outcomes, not activity
Judge the work by whether it improves the outcome, not by hours logged or tickets closed. Activity metrics are easy to count and easy to manipulate, and they push a team toward looking busy rather than being useful. Outcome measures keep everyone honest and focused on the same goal. We wrote about why in measure engineers by outcomes, not output. This also changes how the team behaves: measured on outcomes, good engineers will tell you when a requested feature is not worth building, which is exactly the judgment you hired them for.
Treat them as one team
Do not separate your people from the embedded team. Two versions of the truth, connected by status reports, is slow and error-prone. Give the partner your tools, your repositories, your standups, and your definition of done. Let your product managers talk to their engineers directly rather than through a manager in between. The closer the two teams work, the less coordination overhead you pay, and coordination is where most of the cost of software actually comes from. Our staff augmentation and full product build engagements are both built to work inside your team this way.
Handle difficult periods openly
Every engagement has a difficult period: a missed estimate, a decision that turned out wrong, a week where work runs late. How you handle it decides how the relationship goes. Raise problems early and directly, and expect the same from the team. A partnership where both sides can say "this is not working, let us fix it" without it becoming an argument is a partnership that lasts. The teams that hide problems until they are expensive are the ones that fail, on both sides.
The result
Do these things and the embedded team stops feeling like an outside vendor and starts feeling like the strongest part of your own team. That is the whole promise of a partner: senior people who own the outcome with you and work closely with your team. The work of choosing well, covered across the main guide, only brings value if you then work with the team you chose in a way that lets them do their best.
Common questions
How do I get the most from an embedded development team?
Share real context and the reasoning behind the work, decide fast when the team brings you a decision, measure the work by outcomes rather than activity, and treat them as one team with your own by sharing tools, standups, and your definition of done.
Why does a development partner slow down?
Most often because they are waiting on you. When an embedded team brings you a decision they are usually blocked until you make it, so a decision that waits for a week costs a week of progress. Being available and decisive is the main way to keep the team fast.
Should I keep my team and the partner separate?
No. Separating your people from the embedded team creates two versions of the truth and heavy coordination cost. Share repositories, standups, and the definition of done, and let your product managers talk to their engineers directly.
How should we handle it when an embedded team misses an estimate?
Raise it early and directly, and expect the same from the team. A partnership where both sides can say this is not working, let us fix it, without it becoming an argument, is a partnership that lasts. Teams that hide problems until they are expensive are the ones that fail.
Why does deciding fast matter so much with an embedded team?
Waiting on you is the most common reason a good team slows down. When an embedded team brings you a decision they are usually blocked until you make it, so a decision that waits for a week costs a week of progress that a faster answer would have protected.
What does treating an embedded team as one team actually look like?
Give the partner your tools, your repositories, your standups, and your definition of done, and let your product managers talk to their engineers directly rather than through a manager in between. That closeness cuts the coordination overhead that otherwise drives most of the real cost of software.
Why is sharing context more important than writing a detailed spec?
Because a team handed only a spec can build the spec, while a team handed the reasoning behind it, the constraints, and the parts you are unsure about can build the right thing and catch mistakes you would have missed. Context turns a vendor relationship into a partnership.
How should I measure an embedded team's performance?
By whether the work improves the outcome, not by hours logged or tickets closed. Activity metrics are easy to count and easy to manipulate, and they push a team toward looking busy rather than being useful, while outcome measures keep everyone honest and focused on the same goal.
Related reading
How to manage an external development team so it feels like your own
Managing an outside team goes wrong when you count hours instead of outcomes. Here is how to guide a team that delivers, instead of closely supervising one that makes no progress.
You cannot measure engineers by how much they produce
Lines of code, tickets closed, and hours logged all measure activity rather than progress. Here is how we think about engineering output without numbers that only look good.
More in Work together well
How to scope the first project with a new partner
Most projects fail in the scoping, not the building. The first project with a new partner should be small, aimed at a clear outcome, and planned to let both sides learn fast. Scope for the outcome you want, not for a document you can refer to later.
Software development pricing and engagement models
The engagement model shapes how a partner behaves, so it is worth understanding. Fixed price feels safe and makes every change costly. Time and materials serves the outcome when you trust the team. The right model matters less than whether the incentives reward the result you actually want.