The company had a distributed development team and a CEO with a very specific vision for the product. But somewhere between that vision and the implementation, expectations were getting lost. Features weren't matching what leadership expected. Completed work was being rejected and redone. Frustration was building on both sides, and delivery had nearly stopped.
I was brought in to understand why the team wasn't delivering. It would have been easy to conclude that the developers were the problem, or that outsourcing was. What I found instead was a breakdown in how requirements were communicated, agreed upon, and changed: a capable team working without a reliable way to establish what had actually been agreed — while what it was being asked to build kept changing, and nothing in the process made that visible.
It looked like a people problem. It was a process problem.
From the outside, the symptoms looked like a capability gap: the team kept delivering the wrong thing. But when I looked at how work actually moved from idea to implementation, the pattern was different. Requirements changed daily. They were communicated in ways that left room for interpretation, while the expectations for the finished feature were very precise. The developers would build their best understanding of what had been asked for, and by the time they delivered it, the request had moved.
Distance made it worse, but distance wasn't the cause. With the team working hours apart from the business, a question asked at the end of one day might not get an answer until the next — and by then the requirement it was about could have changed again. Every round trip was a chance for the gap between what was wanted and what was built to grow. The same thing happens to a team in the next room if requirements move faster than anyone can write them down.
What I changed: written stories, signed off before development
The change I made was simple to describe and harder to get adopted. Every piece of work became a written Jira story, and the CEO signed off on each story before development started. Nothing went to the team as a verbal request or a message thread. If it wasn't in an approved story, it wasn't the work.
That one rule changed the nature of the conversation. Before, a developer would finish a feature and hear "that's not what I asked for," with no way to show what had been asked for. After, there was an agreed description everyone could point to. Requirements didn't stop changing — but a change was now a new decision, made explicitly, instead of a silent contradiction of work that was already done. The team could build with confidence, because the target held still long enough to hit it.
My role in that process was to stand in the middle and translate in both directions. I turned the CEO's requests into stories the team could implement, and I made sure she understood what each story meant before she approved it. For the developers, that meant one clear source of truth instead of a moving stream of instructions. For the CEO, it meant visibility and a concrete way to know her requirements had been understood.
Sign-off doesn't stop requirements from changing. It makes every change visible, discussable, and owned.
What happened next
The team got back on track to delivery. We moved from repeated disputes about what had been requested to a process where completed work could be evaluated against an approved story. The same developers were now shipping work that was accepted, because they were finally building against something that stayed put. The credit for that belongs to them; what changed was the structure around them.
What began as an engagement to restore delivery eventually grew into broader engineering leadership, and I was brought on as Director of Engineering. The experience reinforced something I've carried into every leadership role since: sometimes the most important engineering improvements happen outside the codebase.
Distributed teams need leadership, not supervision
There's a lazy conclusion people draw from stories like this one: that offshore teams can't be trusted and need someone local watching over them. I don't believe that, and it isn't what happened. Offshore engineers can be senior engineers, architects, and technical leads; geography says nothing about anyone's ability. Distributed teams don't need someone watching over their shoulders. They need the same things any effective engineering team needs: clear ownership, timely decisions, trusted technical leadership, and the freedom to execute against agreed requirements.
The mistake isn't hiring engineers in another country. It's assuming that hiring a development team eliminates the need for product ownership and engineering leadership inside the organization. You can outsource implementation, and you can delegate substantial technical authority. But you cannot eliminate the need for accountable product ownership, clear decisions, and a shared definition of done. Someone inside the business has to own that, and when no one does, even an excellent team ends up guessing.
You can outsource development. You can't outsource accountability for what's being built.
Signs your team has a process problem, not a talent problem
- Finished work is regularly rejected as "not what I asked for" — and no one can point to what was asked for.
- Requirements arrive as conversations and messages instead of written, approved work.
- Changes to a feature in progress aren't recorded as changes; they just replace the old request.
- Developers wait a day or more for answers to questions that block their work.
- There's no one whose job it is to translate business goals into buildable, agreed requirements.
If several of these sound familiar, replacing the team usually won't help. The next team will inherit the same process.
There's a related leadership lesson here. In Your Best Engineer Might Not Be Your Best Team Lead, I argued that being the strongest individual contributor and making an entire team more effective are different skills. This experience was a practical example. The answer wasn't for me to write the code faster. It was to remove the obstacles preventing capable engineers from doing their best work.
What I took away
The most important engineering work I did there didn't involve writing code. It was building the structure that let other people's code land: written stories, explicit approval, and a single person responsible for translating between the business and the team. A senior engineering leader's job isn't only to turn requirements into software. It's to create the boundaries, accountability, and trust that let a team deliver — even when the organization around it is struggling.
When delivery stalls, look at how decisions are made before you look at who's writing the code.
Engineering leaders who want to see more of the systems I've designed and built can find my engineering portfolio at josephrounds.dev.