When a nearshore team disappoints, the diagnosis comes quickly: distance, culture, skill level, time zones. These are comfortable explanations. They put the problem on the other side of the Mediterranean.

In most of the cases we see, the problem lies elsewhere. It lies in a question nobody asked at the start: who decides what?

A team in Casablanca or Rabat that has to wait for Paris on every call is not a team. It is a queue. And a queue, even one made of excellent engineers, delivers slowly, learns little and eventually leaves.

The symptom: everything goes up the chain

A team without decision rights is easy to spot.

  • Questions pile up in a chat channel and wait for the next day's meeting.
  • The local lead passes requests on but settles nothing.
  • Priorities change without the team knowing why.
  • The best people ask fewer and fewer questions, then start looking elsewhere.

That last sign is the most expensive. A senior engineer accepts a salary, a project, an employer. They do not accept for long being irrelevant to the choices that affect them. We have written about retention: keeping your team is the real nearshore risk. Lack of autonomy is one of its first causes.

The cause: execution was moved offshore, accountability was not

The pattern is almost always the same. The French company defined a scope, hired a team, set up the tools. It transferred work. It did not transfer decision-making power.

This is not bad faith. It is a cautious reflex: you do not know the team yet, so you keep control. The problem is that the reflex lasts. Six months later, the team has proven itself, but the organisation has not moved. Decisions keep going up out of habit.

The result: the manager in France becomes the bottleneck. They spend their days answering questions they should never have received. And they conclude, wrongly, that the team lacks autonomy.

The method: write down decision rights

The fix is not a workshop on trust. It is a one-page document, written before launch and reviewed every quarter. For each type of decision, it answers one question: who decides, who is consulted, who is simply informed.

1. List recurring decisions

Not the big strategic choices. The everyday ones:

  • choosing a technical solution within a given framework;
  • reorganising the week's tasks;
  • accepting or declining a request from an internal user;
  • hiring, evaluating, giving a raise;
  • releasing to production;
  • committing a small expense (a tool, a training course).

Twenty lines or so are enough. The exercise takes an hour. It saves months of misunderstandings.

2. Put each decision in the right place

The rule we apply is simple: a decision is made as close as possible to the information needed to make it.

Choosing a software library belongs to the people who will use it. Trading off between two customers belongs to the people who know the customers. Hiring a developer in Rabat belongs to the Rabat lead, with input from Paris, not the other way round.

For each line, one person decides. If two people decide, nobody does.

3. Appoint a real local lead

A "coordinator" who forwards requests is not enough. You need someone on site with authority over how work is organised, over hiring and over the team's day-to-day. They report to Paris on results, not on every choice.

This is often the most important hire of the whole project. It deserves more time than the others, and it should come first.

4. Define what goes up, and only that

Some decisions must stay at headquarters: the overall budget, product priorities, contractual commitments to customers. The document says so explicitly. Anything not on that list is decided locally.

That short list protects both sides. Paris keeps control of what matters. The team knows exactly where its autonomy ends, and can move forward without asking.

5. Widen the scope on a fixed schedule

The document is not set in stone. Every quarter, you look at what worked and move one or two decisions to the team. It is a simple progression mechanism, and a strong signal to people: trust is earned, and it shows in concrete terms.

What it changes for the manager in France

The role changes in nature. They no longer answer questions. They set direction, explain context and check results.

Three rituals are usually enough:

  • a short weekly review of results, blockers and decisions made locally;
  • a monthly review with the local lead on the team, hiring and scope;
  • regular time on site, in Morocco, not just on video calls. The time difference is small and the flight is short: that is precisely the nearshore advantage. It would be a shame not to use it.

The rest of the time, the team works. That is the point.

What we have seen work

At Ippon, the team in Morocco was built in under six months. For Financia in Rabat, it took nine months. In both cases, hiring speed mattered. But what held the teams together afterwards was giving local leads real authority over their scope, early.

A nearshore team is not an extension of the Paris office. It is a team in its own right, with its own leaders, decisions and results. Companies that treat it that way get what they came for. The others get a queue.

---

Building a team in Morocco, or does the one you have send everything back to Paris? Write to us: we will look with you at how to allocate decisions.