Tag: distributed teams

There is a manual for hiring across cultures. It’s only 3 questions long.

Posted on by

Hiring across cultures comes with questions you didn’t quite see coming. What’s expected of you. What’s expected of them. What you can joke about and what you can’t. Whose job it is to flag a problem, and when. Somewhere between signing the contract and the first call, you realise: nobody handed you the manual.

That missing manual is not a small thing. A year of quiet cultural friction can erode the whole business case for hiring across borders in the first place.

So the question surfaces, often quietly: what do I need to know about their culture to make this work?

What the standard answer offers

There’s a body of well-developed models in this sphere (Hofstede, Meyer’s Culture Map among the best known), country scores you can look up, and trainings you can book. None of it is wrong. Each model was built carefully and answers a real question: usually some version of how do these two cultures differ on this specific dimension.

That’s a useful question for some things. But it’s not very predictive of how the next 12 months of working with a specific person will go.

In 10 years of doing this work I’ve never run into a model or framework on this topic that stuck. That isn’t a verdict on the models. It’s a verdict on the question they answer, which sits a layer or two removed from the question that matters when an engagement is starting on Monday.

If you analyse what founders and CTOs actually talk about on X when they describe their distributed teams, it’s almost always about a specific operational incident, not about a dimension score.

What did stick is smaller than a framework. 3 questions, asked early. Together they take less than an hour, and over 10 years they’ve predicted more about how an engagement goes than any country score I’ve ever looked at.

Start with what success looks like for both sides

If you’re hiring across borders, surface what success looks like early, for the person doing the hiring and for the person being hired. What does success look like over the next 6 or 12 months for each of them? Where do those overlap, and where don’t they?

Most engagements skip this and go straight to scope. The cost of skipping shows up later, usually as misalignment that gets diagnosed as a culture clash but is really the absence of a shared frame.

Research shows that when two groups share a goal neither can reach alone, the salience of group difference drops. Shared goals don’t dissolve cultural difference. They make it operationally subordinate to something else.

A 15-minute conversation. One of the cheapest moves available, and one of the most consistently skipped.

Then ask where value differences actually create risk

Once shared success is named, value differences become assessable instead of abstract. The question shifts from do they share our values, which is unanswerable and operationally of limited use, to in this specific engagement, with this specific success definition, where do value differences create operational risk and where don’t they.

In practice, most differences turn out to be operationally inert. A new hire who personally holds different views about religion, family, or political life than the people doing the hiring is, in the context of shipping a feature on Friday or building a payments integration, almost always indistinguishable from someone who holds similar views. This isn’t optimism; it tracks the well-researched gap between what people say they think and how they actually behave in structured professional contexts.

A small subset of differences do matter, and they matter specifically. A team norm of openly disagreeing with the most senior person in the meeting requires a different setup with someone trained in a workplace where deference to seniority is the default. A culture of giving sharp, immediate written feedback requires a different setup with someone whose professional formation taught them to deliver criticism slowly and through indirection.

Most value differences are operationally inert. The few that aren’t tend to be specific, surfaceable, and manageable once you’ve named them. The work in this step is identifying which is which for this engagement, not for engagements in general.

Tell the new hire what they’re signing up for

This is the question that’s most often missing, and it’s the one that holds the other two together.

If part of what counts as success on the hiring side, even implicitly, is that the new hire will shift over time on something specific, the new hire has the right to know that going in. Not as confrontation. As transparency.

The “something specific” is almost never about personal beliefs. It’s about professional norms. A developer joining a team where the expectation is that you push back hard on the CTO’s design choices in the standup may have been trained in an environment where you raise concerns privately afterward, with seniority preserved. That’s a real shift to ask of someone, and it’s reasonable to ask it. It’s not reasonable to ask it without saying so.

Other examples are mundane. A team that operates fully async, in writing, with everything in English, can be a real adjustment for someone whose default working rhythm is verbal and synchronous. A hiring manager who wants problems flagged at the moment they appear, rather than when there’s a proposed solution alongside, is asking for a specific way of working, not a personality.

Naming this stuff up front does two things. It lets the new hire make an informed choice about whether the engagement is one they want; most do, and they’d rather know. And it removes the possibility of the engagement quietly drifting into bridging-by-assimilation, where the new hire absorbs the new norms without ever having been asked.

What this question does, quietly, is treat the new hire as a professional adult capable of deciding whether to take the engagement, which is what they are.

What this comes down to

These 3 questions aren’t much. Not a framework, not a training. They take less than an hour at the start of an engagement and they don’t ask you to walk on eggshells, defuse history, or solve anything bigger than the engagement itself.

What they do is small and specific. They surface what’s going to matter in this collaboration, before the misreads accumulate. What you get back from that, in my experience, is much more than a hire.

When salary data meets real people: navigating African developer compensation

Posted on by

The negotiation that keeps breaking, and what actually fixes it

Every few weeks, we watch the same pattern repeat. A European company quotes a budget based on “Africa rates.” An experienced developer in Lagos or Nairobi quotes something close to European levels. Both numbers make sense. Both feel fair to the person giving them. And yet the conversation stalls.

The awkwardness isn’t about bad faith. It’s about different maps of the same territory.

If you’re hiring developers from Africa, or you’re a developer navigating international opportunities, you’ve likely felt this friction firsthand. One side expects a significant cost advantage. The other expects compensation that reflects capability, not geography. Both are looking at market data. Both are being reasonable. And yet something fundamental isn’t connecting.

That disconnect is costing both sides opportunities they’d otherwise want.

What you’ll find here

Three things we keep seeing in our daily work placing African developers with European and North American clients:

First: Country-by-country salary bands (low, median, high) for the African markets we work in, normalized to EUR per month. Not perfect data, but honest data.

Second: Why purchasing power and lived costs matter more than most salary discussions acknowledge, and why both developers and companies miss this.

Third: What actually creates the premium in distributed work. It’s not “remote work” as a skill. It’s something more specific, and more human.

The pattern: both sides are using different anchors

Here’s what we hear, week after week:

From developers: “A European developer doing my job makes €70,000. If I’m delivering the same quality work, why should I accept less?”

From companies: “Hiring from Africa means more complexity: time zones, cultural navigation, higher risk of mismatch. The cost advantage should offset that risk.”

Both positions make sense in isolation.

The developer is right that capability should drive compensation. The client is right that distributed work creates friction and uncertainty.

And this is where most salary negotiations get stuck: in the gap between what feels fair based on output and what feels reasonable based on context.

What usually happens next

In our experience, there are two paths from here.

Path one: proactive navigation

Our teams step in early. We paint the picture of what the other side is seeing.

To the developer: “Based on your skills and experience, this is what the market will actually bear. You’re competing globally now, not just locally. If you want to push higher, that’s your choice, but understand what you’re up against.”

To the company: “Here’s what this looks like from the developer’s perspective. They’re leaving a stable job to take a risk on you. This rate reflects both capability and market reality. If you want to negotiate down, you’ll likely lose this person to someone who gets it.”

We’re not pushing anyone. We’re showing them what the other side sees. Usually, that works.

Path two: the negotiation “succeeds” but the relationship doesn’t

Sometimes one side feels they got a bad deal but accepts anyway. The developer takes it because they need the opportunity. Our client agrees because they’re out of options.

Then, a few months in, something breaks. The developer feels undervalued and starts looking elsewhere. Or the client feels they’re overpaying and starts managing to the penny rather than to the relationship.

What looked like a successful negotiation becomes an early termination. That’s the real cost.

Why we track this data (and what it can’t tell you)

We track salary data because it gives both sides a shared reference point. Not a script for what to pay, but a map of what’s actually happening in the market.

Country-level bands exist, but they’re wider than most people expect

What this tells you:

  • “Africa” is not one price level. Median salaries differ by multiples across countries.
  • Even within a single country, the spread between median and high can be dramatic.
  • Some markets have tight bands. Others are two-speed: a small top tier prices into international work, while the median remains locally anchored.

What this doesn’t tell you:

  • What’s “fair” for any specific person
  • What drives someone from the median band into the upper band
  • How to have the actual conversation when expectations don’t match

The data is a starting point, not an ending point.

Cost of living reshapes the story more than either side expects

We include purchasing power comparison not to argue that developers should accept less, but because ignoring it creates distortion on both sides.

When you compare salaries in purchasing power terms rather than nominal terms, the distance between “Africa” and “Europe” shrinks materially in lived terms, even when it remains large in nominal terms.

For developers: European salaries look high in nominal terms. But much of that difference gets absorbed by taxes, rent, and local costs. The gap is real, but it’s not as wide as the headline numbers suggest.

For companies: You’re not getting “cheap” talent when you hire senior, production-ready developers. You’re getting access to capability that’s structurally underpriced; but that mispricing is correcting, especially at the top end.

The top end is pulling away from the middle

In multiple markets, the high end is several times the median. This isn’t trivia. It’s a structural signal.

The market isn’t moving as one block. A small share of developers are increasingly priced on international benchmarks, while the median remains locally anchored.

For companies: Hiring senior “global-ready” profiles isn’t about finding a cheap location. It’s about finding scarce capability. You’re competing with other international companies.

For developers: The path to global compensation is real, but selective. The difference isn’t geography. It’s what kind of responsibility you can carry without constant supervision.

What actually determines the premium (and why “remote” isn’t the skill)

We get asked constantly: what makes the difference between a developer who stays at local pricing and one who commands near-European rates?

The difference is almost always this: can you reduce risk and friction for the people around you, especially when they can’t see you?

Here’s what that looks like:

  • You ship and support production systems, not just features. When something breaks, you fix it.
  • You take initiative within boundaries. You don’t wait for instructions, but you ask clarifying questions before you’re stuck.
  • You communicate proactively. You surface problems early. You don’t let misunderstandings accumulate.
  • You structure and document your code so someone else can pick it up.

Put differently: you make distributed work easier, not harder.

This is what clients pay for at the top end. Not the ability to write code remotely. The ability to own outcomes when supervision is expensive and trust is essential.

And this is where cultural adaptation matters. European clients sometimes describe African developers as “passive” or “waiting for instructions.” African developers in turn can describe European clients as “demanding initiative without clear direction.”

Both observations are real. The friction comes from different cultural defaults around authority and autonomy. Developers who navigate this well – who can read context, take initiative when needed, and ask for clarity when it’s not – are the ones who break out of local pricing.

The moment things shift: when uncertainty evaporates

Many of our clients have never been to Africa. They’ve never hired from there. “Remote African developer” is an abstraction, and abstractions are uncomfortable. They don’t know what to expect.

Then the first interview happens.

The camera works. The sound is clear. The connection is stable. The developer speaks fluent English, asks smart questions, and demonstrates expertise.

What the client feared was a high-risk unknown becomes a specific person they can evaluate like anyone else.

That shift – from abstract risk to concrete evaluation – is where the salary conversation often becomes easier. Not because the developer proved they’re “cheap,” but because they proved the client’s mental model was incomplete.

For developers: Yes, you’re proving more than a European developer would need to prove. That’s the reality. But once you’re proven, the dynamic changes.

For companies: That first conversation is your moment of recalibration. If you go in expecting problems and come out impressed, adjust your frame. This person isn’t a compromise. They’re capabilities you wouldn’t have found otherwise.

We prepare developers for this. We always do a prep call; checking technical setup, discussing how to show up professionally, and reframing the stakes: if it’s not meant to be, there will be other opportunities.

Why negotiating for the quick win breaks the long game

Here’s something we tell both sides:

Success is not a quick hit in a negotiation. Success is negotiating for a strong foundation for long-term collaboration.

When a client pushes too hard on price, they might “win” the negotiation. But they lose the relationship. The developer accepts because they need the work, but they’re looking for the next opportunity from day one.

When a developer holds out for a number that’s genuinely out of market, they might feel they stood their ground. But they lose the opportunity. Meanwhile, another developer takes the role and builds the track record that opens the next door.

The goal isn’t to squeeze the other side. The goal is to find a number that both sides can live with and build on.

This is what we mean when we say Tunga is human-first. It’s not soft. It’s structural. Relationships that start with one side feeling exploited don’t produce great work.

What we actually do differently

If a client went to a typical recruiting agency, the salary conversation would be: “What’s your budget? We’ll find someone in that range.”

If a developer tried to negotiate directly, the conversation would probably stall on the first number that didn’t match.

What we do is different:

We show both sides the other side’s perspective

We don’t just relay numbers. We translate worldviews.

To a developer: “Imagine you’re the client. You’re looking at a resume from someone you’ve never met, in a country you’ve never visited. What would you be thinking? What would make you feel safe?”

To a client: “This developer has a job. Would you quit your job on a maybe? What would need to be true for that to feel like a good bet?”

That reframing (asking people to inhabit the other perspective) changes the tone. It moves from positions to problems.

We come with context, not just numbers

When we send a client a shortlist of candidates, we include rates upfront. No surprises.

And we explain how we got there. We show the market data. We explain the developer’s background. We translate between the client’s worldview (risk, cost, alternatives) and the developer’s reality (scarcity, opportunity cost, purchasing power).

We’re willing to walk away to maintain trust

If a developer quotes a rate that’s genuinely out of market, we tell them: “That’s your choice. But you should know you’re competing globally at that price. We’re fine if you don’t want to pursue this, but we’re not going to misrepresent the market.”

If a client’s budget is unrealistic, we tell them the same: “You can try, but you’ll either get someone who’s not actually senior, or you’ll lose the people you want.”

We’d rather lose a deal than lose credibility. That stance, being willing to let the deal fall apart rather than distort the truth, is what makes the trust work.

How to read this market (without losing the thread)

If you’re hiring developers from Africa:

  • Expect meaningful differences by country, and even more by seniority
  • Treat the median as a baseline and the upper band as the scarcity premium for proven capability
  • Remember: you’re not hiring “cheap” developers. You’re hiring capability that’s structurally undervalued, and that mispricing is correcting
  • Budget pressure increases sharply for senior, production-owning profiles. Mid-level hiring still offers advantages, but only if your expectations about autonomy are realistic

If you’re an African developer looking at international opportunities:

  • Global-level compensation exists, but it’s priced on responsibility and reliability, not location alone
  • When adjusted for purchasing power and tax, the gap with Europe is smaller than it looks
  • Only a minority earn at the global top end, and they’re priced on scarcity; the ability to reduce friction and carry outcomes independently
  • Growth comes from moving into roles where you make distributed teams easier to run, not harder
  • The most consistent path upward is ownership: shipping, supporting, and communicating under real production conditions

For anyone trying to make sense of distributed work and fair compensation:

Salary data is necessary, but not sufficient. The numbers give you a map. They don’t tell you how to navigate.

What actually makes these relationships work is the layer underneath the numbers: trust, transparency, and a willingness to see the other side’s position even when it conflicts with your own.

Where this leaves us

The data in this post will be wrong within a year. The market moves. Salaries shift.

But the pattern underneath won’t change:

Distributed work only works when both sides treat it as a relationship, not a transaction.

Salary negotiations are not pricing exercises. They’re trust-building exercises. They’re the first test of whether two parties can navigate complexity, misalignment, and uncertainty together.

The teams that do this well don’t avoid the hard conversations. They have them early, honestly, and with respect for what the other side is actually dealing with.

Why Proficiency Trumps Perfection When Building a Career in Tech

Posted on by

Indeed, the legends are true. Somewhere in this vast cosmos, “that someone” resides. All we know is that they are perfection in themselves in software development. Yes, they are everything you only wish to be as a software developer in your wildest dream.

Remote Team Mania: How I Became a Fan of Remote Work

Posted on by
Remote Team Mania: How I Became a Fan of Remote Work

Remote teams, scrum and IT staffing: Tunga COO Reinier shares some – perhaps unexpected – insights.

Remote Work: Everyone is Talking About it, But is it Really Happening?

Posted on by
Remote Work: Everyone is Talking About it, But is it Really Happening?

People aren’t just searching more for remote work; they actually prefer it. We would take a bet that 8 out of 10 folks will choose to work from home or wherever else they want.