How to Build an Employer Brand on LinkedIn That Actually Attracts Senior Belarusian IT Talent

A foreign CTO got on a call with us last month and asked why his InMails to senior Belarusian engineers were getting a 4% response rate when LinkedIn’s global benchmark for tech roles sits closer to 18–25%. The honest answer: because his message read like every other InMail those engineers had received that week. The seniors he was reaching out to — the ones with 7–12 years on the bench, fluent English, and EPAM or Wargaming or Apalon on their CV — get five to fifteen cold messages a month. Most of them are template trash. The good engineers stopped responding to anything that doesn’t show specific knowledge of who they are.

Generic LinkedIn employer-branding advice doesn’t fix this. “Post employee stories” and “showcase your culture” are fine for entry-level pipelines and not even close to enough for the Belarusian senior market. So below is the playbook we actually run for foreign clients hiring senior Belarusian engineers — eight tactics, in order of how much they move the needle, plus a 30-day starter plan if you’d rather act than read.

Why generic LinkedIn advice doesn’t translate to senior Belarusian engineers

Three reasons before the playbook starts.

The market is small and the seniors know each other

Roughly 100,000 IT professionals in Belarus, of whom perhaps 8,000–12,000 are genuine seniors with 7+ years of experience. They’re in the same Telegram groups. They’ve worked at the same companies. They share notes about employers — including which one is spamming generic InMails this month. Whatever you send today, somebody else is reading by Thursday. Pick a tone you’d want spread.

English is good, but not native

Senior Belarusian engineers operate at B2–C1 — most of the leading software companies mandate English for client communications and many provide internal training. That’s strong, but it’s not the same as native fluency. Generic American marketing copy lands strangely. “We’re a fast-paced team building the future of [generic vertical]” reads as exactly the kind of vapor that pushes them away.

Trust currency is different

What senior Belarusian engineers value, in this order: technical credibility, salary transparency, and predictability. They’re skeptical of performative culture content — ping-pong tables and “we’re like a family” close doors here, not open them. A LinkedIn brand built on the three things above outperforms one built on aesthetics. This is also where the geopolitical context lives, which we’ll come back to in tactic #5.

The 8-tactic playbook

Tactic #1 — Build a Company Page that signals technical seriousness, not corporate polish

Senior engineers don’t read your Company Page like a brochure. They scan it for signals. Who’s the CTO? What stack are you running? When did anyone post anything last? Do your job posts list real salary ranges or hide behind “competitive compensation”? LinkedIn’s own data shows pages with complete, regularly-updated profiles get 2x more applicants per posting — but for senior talent, that 2x is mostly noise unless the page also carries technical credibility.

What to actually do. Pin a post about something you’ve engineered that’s interesting. Link to your engineering blog (or build one). Make sure your CTO’s profile is connected and active. Use real photos of the team rather than stock imagery. Show recent product or technical wins.

What to avoid. Vague mission statements, listicle-style “five reasons we’re a great place to work” posts, anything that reads like it was written by a marketing team that has never spoken to your engineers. Senior readers can spot the difference in three lines and they’ll click away. Our work on targeted IT recruitment depends on this kind of credibility being already in place.

Tactic #2 — Have your engineers post, not your recruiter

Content from individual employees outperforms branded content by roughly 8x in engagement, and most professionals trust content from individuals more than from brands. For senior Belarusian engineers — many of whom are on LinkedIn primarily to follow other engineers, not companies — that gap is even wider.

What to do. Identify three or four of your existing engineers who already post (or would, with light encouragement). Help them write about real technical decisions: “why we picked Postgres over MongoDB for this thing,” “how we cut our API latency in half,” “what went wrong when we migrated to Kubernetes.” Don’t script them. Don’t make them post on a schedule. Let it be real.

What to avoid. Forcing employee advocacy through a content tool, ghostwriting engineer posts in marketing voice, asking engineers to repost corporate announcements verbatim. Ghostwritten content is detected within two lines, and once it’s been spotted, the engineer who posted it loses credibility with their network. That’s a worse outcome than no post at all.

Tactic #3 — Show salary ranges in EUR or USD, with a specific number

This is the single highest-leverage thing most foreign companies still don’t do. Senior Belarusian engineers receive InMails daily. The ones that name a salary range get answered first. The ones that say “competitive compensation” don’t get answered at all.

What to do. In your job posts and your InMail templates, include a number. “EUR 5,500–7,500 gross/month for senior backend, depending on experience” beats anything else you can write. If you’re hiring through HTP-resident outstaffing, be transparent about the model: “EUR 5,500–7,500 gross/month, paid through HTP-resident outstaffing structure, no relocation needed.” That sentence converts because it answers the three questions every senior is asking before they decide whether to reply.

What to avoid. “Competitive,” “market rate,” “DOE,” “based on experience” — every one of these reads as “we don’t want to commit, so neither will I.” Salary anchoring isn’t tacky in this market; it’s table stakes. The contract structure also matters — see our overview of IT outstaffing arrangements for the variations clients ask about most.

Tactic #4 — Optimize for InMail response rate, not volume

Most foreign companies treating LinkedIn as a sourcing channel make the same fundamental error. They send hundreds of generic InMails and watch their response rate collapse. Senior Belarusian engineers are over-sourced. The math has flipped — sending five carefully personalized InMails outperforms sending a hundred templated ones, by a wide margin.

What to do. Read the engineer’s profile. Find one specific thing — a project they shipped, a stack choice, a talk they gave, a GitHub repo, the company they’re at — and reference it in the first line. Mention the salary range in the second line. State your role-specific task in the third. Done. Most senior engineers won’t read past three sentences and will reply faster to short, specific messages than to long, polished ones.

What to avoid. Subject lines like “Exciting opportunity at [Company]”; opening lines that praise generic skills they didn’t put on their profile; multi-paragraph InMails that try to sell the company before establishing relevance. Companies with strong talent brands on LinkedIn see 31% higher InMail acceptance rates on average — but that’s an average across all roles. For Belarusian seniors, the gap between strong-brand and weak-brand InMails is wider than that.

Tactic #5 — Acknowledge the geopolitical and sanctions context, briefly

This is the tactic most global recruitment guides skip and most Belarus-aware foreign companies handle badly. Since 2022, senior Belarusian engineers have heard a lot of vague language from Western recruiters about “the situation.” The good ones have learned to read avoidance as either ignorance or bad faith — and either is disqualifying.

What to do. In your employer-brand content, be specific about how you handle the practical questions. Payment in EUR or USD. Working through HTP-resident structures or Belarusian EOR providers. Tax and contract structure. Sanctions exposure on either side. Don’t moralize. Senior Belarusian engineers don’t need your political opinion; they need to know whether the contract works in 2026 and whether they’ll get paid on time. The recruiting.by piece on hiring blockchain developers in Belarus is a useful template for how to address structural questions without melodrama.

What to avoid. Statements like “we believe in our Belarusian colleagues during this difficult time.” That language reads as condescending and makes senior readers click away. The cleanest tone is matter-of-fact: here’s the structure, here’s the payment, here’s what we expect.

Tactic #6 — Use video, but only with engineers as the talent

Video content is an increasingly strong differentiator on LinkedIn — but the wrong kind of video destroys trust faster than no video at all. A polished marketing-team-produced “life at our company” video performs worse than no video, because it triggers the bullshit filter every senior engineer has running by default.

What to do. Five-to-ten-minute LinkedIn Lives where your CTO walks through a technical decision the team made. Short videos where an engineer talks through an actual project — unscripted, with the rough edges left in. Conference talks recorded by your team. Internal lightning talks made public. Production quality matters less than authenticity; phone-camera footage of a real engineer beats a polished promo every time.

What to avoid. Any video that feels like a recruitment commercial. Anything with a corporate music bed under it. Anything where someone is reading from a teleprompter. The whole appeal of video for this audience is that it’s harder to fake than text — leaning into production removes the only advantage video has over a written post.

Tactic #7 — Build a Careers page that pre-answers the questions seniors actually ask

Your LinkedIn Careers Page and your careers site should pre-answer the five questions every senior Belarusian engineer asks before responding to outreach: (1) what’s the salary range, (2) what’s the contract structure — entity, EOR, HTP outstaffing, (3) is the role remote, hybrid, or on-site, (4) what’s the actual tech stack, and (5) who else is on the engineering team. If those five answers aren’t on the page they reach, the senior doesn’t reply.

What to do. Build a one-page careers site that answers all five clearly and link it in every InMail. Update the engineering team listing every quarter. If you don’t have a careers site, make sure your LinkedIn Careers Page covers the same five with the same specificity.

What to avoid. Marketing-led careers content that’s heavy on culture and light on substance. Senior engineers don’t apply to vibe; they apply to specifics. A careers page full of “join our journey” content with no salary band, no stack, and no team listing is worse than no careers page — it actively signals that you’re hiding something.

Tactic #8 — Partner with someone in Belarus who already has the network

The honest one. The senior Belarusian engineering market is heavily relationship-driven. Recruiting.by’s overview of Belarusian IT job-search platforms confirms what every recruiter in the country already knows: “senior specialists and team leads often find opportunities through networking, LinkedIn, and professional communities rather than through mass job applications.” A foreign company building a LinkedIn employer brand from scratch is starting cold. A Belarus-based recruiter is starting from a network of relationships built over years.

What to do. Use a local recruiter — us, or someone like us — to amplify your LinkedIn brand into the Belarusian senior engineering network. A good local partner does three things you can’t easily do yourself: warm intros to passive candidates, pre-vetting on technical and cultural fit, and translation of your value proposition into something that lands locally. We do this through our IT recruitment service; there are other firms doing it well too.

What to avoid. Assuming a globally-branded recruitment agency knows the Belarus market because they have a Belarus page on their website. They almost certainly don’t. Local market knowledge is built over years and shows up in details — which company is actually a good place to work, who’s been laying off quietly, which compensation expectations are realistic right now.

A 30-day starter plan

If you’re going to act on any of this, the order matters. Below is the rollout we suggest for clients who want to do this themselves.

Most clients who run this 30-day program see InMail response rates move from low single digits to the 12–18% range by the end of week four. Past that, returns flatten — the next gain comes from getting to the engineers who don’t accept InMails at all, which is where the local-network advantage in tactic #8 kicks in.

If your InMail response rate isn’t where it should be

Everything above is what we run for clients hiring senior Belarusian engineers through LinkedIn. The 30-day plan works if you have time and bandwidth to execute it; if you don’t, that’s most of what we do. Tell us the role — stack, seniority, salary band, contract structure — and we’ll tell you what’s realistic and how fast. Get in touch, or browse the rest of our news section while you’re deciding.

IT Outsourcing vs IT Outstaffing in Belarus: A Decision Framework for Foreign Companies

Roughly half the foreign companies who contact us asking for “outsourcing in Belarus” actually need outstaffing. A smaller but expensive subset asks for “outstaffing” when what they really want is fixed-price project delivery. The two models look almost identical from the outside — Belarusian developers working on your software, paid in BYN, billed to you in EUR or USD — but underneath, they’re different products. They split differently on who runs the work, who carries IP risk, who absorbs staffing churn, and what happens the morning a developer decides this isn’t for them anymore.

Pick the wrong one and you’ll feel it within the first three months. Pick the right one and you’ll wonder why nobody explained it this way before. So here’s the framework we walk new clients through before they sign anything.

The two models, in a paragraph each

IT Outsourcing

You hand a piece of work to a Belarusian provider — a project, a feature, a discrete deliverable. The provider assembles their own team, manages it, and ships you the result. You don’t choose the developers (or you choose them once at the start and then lose visibility). You pay for the deliverable, usually as a fixed-price contract or time-and-materials with a project manager sitting in the middle. The provider owns the team and the process. Your relationship is with the company, not the people doing the work.

IT Outstaffing

You select specific developers — interview them, approve them — and they then work exclusively for you, embedded in your team, taking instructions from you directly. They stay legally employed by the Belarusian agency (in our case, through our HTP-resident company), so you don’t deal with payroll, taxes, contracts, or labor inspectorate. You manage the work day-to-day; we manage the employment. The closest mental model: “they’re on your team, on someone else’s payroll.”

Where the confusion comes from is no mystery. Both look like “IT services from Belarus,” both involve developers you don’t directly employ, and the marketing language used by global vendors blurs the line on purpose — outsourcing usually sells at a higher margin. A clean breakdown of the same distinction sits in this hiring guide on Recruiting.by if you want a second take.

Side-by-side: where the two diverge

The differences look small in marketing copy and large in practice. The table below is the version we use on calls — dense on purpose.

When outsourcing is genuinely the right answer

Let’s start here, because if we only sang the praises of outstaffing the post would lose credibility on the second paragraph. Outsourcing wins in three situations.

1. Genuinely fixed-scope projects

Migrate this database. Build this marketing site to these designs. Ship version 1 of this mobile app to these specs and hand over the source. If the work has a finish line and you don’t need ongoing iteration, paying for a managed deliverable is cleaner than running an embedded team you’ll have to shut down in three months. Belarus has a deep bench of providers who do this well.

2. Specialist work outside your in-house competence

You need three weeks of a security audit. You need a Solidity team to ship one smart-contract product. Hiring a full-time outstaffed senior for a three-week need is the wrong shape. Outsourcing it is the right shape — you pay for the outcome, not the people in the team.

3. No engineering management bandwidth on your side

If you literally cannot manage developers — no engineering manager, no tech lead, no product owner who can run standups — outstaffing won’t work. The model assumes you bring management. Outsourcing absorbs that for you. We’d rather tell you this upfront than watch the model collapse two months in.

When outstaffing is the right answer (which is more often than you’d think)

For everything outside the three scenarios above — and “everything else” covers most foreign companies hiring developers in Belarus — outstaffing is the better answer. Four reasons.

1. Ongoing product development

Your product will keep evolving. The team needs to learn your codebase, your customers, your engineering culture. Outstaffing builds institutional knowledge in your team because it’s the same people, month after month. Outsourcing rotates people away from it — they finish your project and move to the next client, taking the context with them.

2. You want to control hiring and culture

You interview every developer. You decide who’s on your team. You’re not delegating that to a provider’s PM. This is the most common reason mature engineering teams pick outstaffing — control. Hiring is a strategic decision, and most CTOs aren’t comfortable handing it off.

3. Your scope will change

Software scope always changes. Outstaffing absorbs that for free because the team is yours — you re-prioritize the backlog and the team executes. Outsourcing fights it because every change goes through a contract amendment, a re-scope, and usually a renegotiation. Three scope changes in and you’ve spent more on contracts than on code.

4. You want HTP cost benefits visible in your invoice

This is the Belarus-specific point and it’s the one most global comparisons skip. When the outstaffing agency is HTP-resident, the social-contribution base is calculated against the country-average salary, not the developer’s actual paycheck. For a senior developer on $4,000/month, that’s a meaningful chunk of cost that disappears — and it shows up in your monthly fee. We run this through our own HTP-resident company at a flat €350/month service fee on top of payroll. Outsourcing buries the same benefit inside the provider’s margin; outstaffing surfaces it. Background on why this matters: outstaffing is on the approved HTP activity list, which is what makes the structure work.

The decision framework: six questions

Run through these in order. Each one narrows the answer. By the end you’ll know which model fits.

1. Is the work scope finite and locked, or ongoing? Finite → outsourcing in play. Ongoing → outstaffing.
2. Do you want to interview and choose the specific developers? Yes → outstaffing. No, don’t care → outsourcing fine.
3. Do you have an engineering manager or tech lead who can run the team day-to-day? Yes → outstaffing works. No → outsourcing, or hire that person before going further.
4. How sensitive is the IP? High → outstaffing through an HTP-resident agency gives you a cleaner IP chain and a stable team. Outsourcing can work too, but only with a bulletproof contract.
5. How much will the scope change in the next six months? A lot → outstaffing absorbs it for free. Almost none → outsourcing is fine.
6. What’s your budget visibility? “Fixed price for the whole project” → outsourcing. “Predictable monthly burn per developer” → outstaffing.

Four out of six pointing the same way is your answer. If it’s split three-three, that’s a sign the work itself is two different things — split it.

Why the choice matters more in Belarus than elsewhere

This is where the Belarus angle shows up properly. Three points that don’t apply (or apply less) in other CIS jurisdictions.

HTP changes the math on outstaffing

Already covered above, but worth repeating because it’s the structural advantage. The HTP regime — extended by Decree No. 8 to 2049 — gives resident companies a reduced social-contribution base and exemption from corporate profit tax. That benefit can flow through to your invoice in an outstaffing arrangement, or it can sit inside someone else’s margin in an outsourcing arrangement. Same developer, different cost to you.

Belarusian Labor Code is restrictive on the employer side

Termination requires grounds listed in Article 42. Severance for dismissals without cause is typically three months. Protected categories — pregnant employees, employees on maternity or childcare leave — can’t be dismissed at all in most circumstances. Both models externalize this risk away from you, but outstaffing makes the cost transparent (the agency is the legal employer; the cost shows up in the monthly fee). Outsourcing buries it inside a fixed price you can’t audit.

English fluency is strong, but management still matters

Both models work in English in Belarus — most senior engineers operate comfortably at B2 or above. But outstaffing benefits more from this because you’re managing the developer directly, not through a translator-PM. Current market data on the senior IT bench: average salaries run between $1,600 and $1,900 at mid-level with seniors well above that. Belarus is also still ranked among the top 30 global IT outsourcing destinations — meaningful depth, especially in backend, mobile, and game development. For broader market context, TechBehemoths’ Belarus overview puts the IT sector at roughly 6.1% of GDP.

A worked example

Abstract framework, meet concrete numbers. The case below is composite — based on the kind of inquiry we field weekly — but the numbers are realistic for May 2026.

A SaaS company in Berlin needs three engineers — a senior backend developer, a mid-level frontend developer, and a QA engineer — to extend their product. They expect the team to work on the product for at least 18 months and the roadmap is going to shift several times along the way.

Outsourced via a managed Belarus delivery shop: roughly €8,000–€12,000/month per engineer including the PM markup and provider margin, plus 2–3 weeks of scoping and contract negotiation up front, plus a project manager sitting between you and the developers, plus a contract amendment every time the roadmap shifts. The amendments aren’t free — usually 5–10% legal and renegotiation overhead per change.

Outstaffed via an HTP-resident agency: developer salaries at market — a senior backend at roughly $3,500–$5,000 gross, a mid frontend at $2,500–$3,500, a QA at $2,000–$2,800 — plus the flat €350/month service fee per engineer. Onboarding runs 1–2 weeks from first interview to first day. Direct management. No PM markup. No margin on top.

For an 18-month engagement on an evolving product, the math isn’t close — and the difference grows the more the scope moves. Caveat: actual rates depend on stack, seniority, and timing, and the numbers above are illustrative rather than a quote. But the shape of the answer holds across most of the inquiries we see.

If you’re not sure which one fits

If you’ve read this and you’re still not sure which model fits your situation, the answer usually takes a 20-minute call. Tell us what the work looks like — scope, team, timeline, what you’ve already tried — and we’ll tell you the model. If it’s outsourcing, we’ll be honest and point you to a partner who delivers it well. If it’s outstaffing, that’s what we do, and we can have first CVs in your inbox within a week of signing. Get in touch, or browse the rest of our news section while you’re deciding.

Top 5 Mistakes Foreign Companies Make When Hiring in Belarus

The Belarusian IT hiring market in 2026 looks materially different than it did three years ago. The talent base has consolidated around a smaller number of stronger engineers. Salary expectations have moved up. The post-2022 macro context has reshaped how foreign companies approach the market, and how the market responds to them.

Foreign companies entering this market for the first time often arrive with assumptions calibrated to other Eastern European destinations — Vilnius, Warsaw, Bucharest — and find that the playbook doesn’t transfer cleanly. The differences are subtle enough to be missed at the planning stage and expensive enough to matter at the execution stage.

What follows is a structured walk-through of the five mistakes we see most often, with the operational signals that indicate each one is happening and the practical fixes that have worked for our clients. The piece is targeted at companies in the early-evaluation or first-hire stage who would prefer to avoid these mistakes rather than discover them six months in.

For readers who want the deeper structural comparison of the legal models behind the choice, our companion article on EOR vs PEO for hiring in Belarus covers that ground in detail.

Mistake 1: Treating Belarus as a “cheaper Vilnius”

This is the most common framing error in our experience. A foreign company has hired in Lithuania or Poland in the past 18 months, the experience went well, and the team assumes the same approach can be transplanted with a downward salary adjustment. It can’t.

The headline numbers do support a cost-arbitrage thesis. Senior IT roles in Belarus sit roughly between $3,000 and $6,000 per month gross in 2026, with specialist engineers in Golang, Web3, and blockchain commonly higher. By comparison, equivalent roles in Vilnius can run 50 to 80 percent above those numbers. On paper the case for hiring from Belarus is straightforward.

The case becomes less straightforward once a company looks at the full cost structure. The employer-side social security contribution in Belarus, known as the Fund for Social Protection of the Population (FSZN), runs at 34 percent of gross salary. Belgosstrakh adds another 3.5 percent for compulsory insurance. A few smaller obligatory payments push total employer-side statutory cost to roughly 38 percent of gross salary before any service-provider margin. Current rates are published on the Belarus government legal information portal and through the Ministry of Labour and Social Protection.

There is a counterweight to that statutory burden, and it is one of the strongest reasons to hire from Belarus rather than from a neighbouring market: the High-Tech Park (HTP) residency regime. Companies that qualify, or that work with an HTP-resident provider, benefit from a 1 percent tax on revenue in place of standard corporate income tax, plus reduced individual income tax on engineer salaries. Foreign companies that overlook this lever are paying the full statutory burden when they could be paying meaningfully less. Our team handles HTP applications for foreign clients setting up their own entity, and our own outstaffing entity is HTP-resident, which means the benefit is passed through to our service clients automatically. Details are on our HTP residency service page.

The talent pool itself has different characteristics than the regional average. Belarusian senior engineers tend to have stronger formal computer-science backgrounds, a legacy of the Soviet-era technical universities that continued producing strong graduates through the 2000s and 2010s. They also tend to have somewhat thinner exposure to certain Western product-management cultures and the modern toolchains that have become standard at venture-backed product companies in London or Berlin. Neither characteristic is universal, but they’re the patterns. A hiring spec written for Vilnius will produce mismatches when run against the Belarusian market.

What works instead. Build the hiring specification specifically for the Belarusian talent pool rather than transplanting a regional template. Run cost modelling that captures total statutory burden alongside headline salary. Evaluate HTP residency or HTP-resident provider relationships as a structural cost lever before signing into a model that does not access them. And consult someone who knows the specific shape of the pool — what is deep, what is shallow, what is overpriced and what is underpriced — before committing to a spec.

Mistake 2: Letting compensation drift quietly under the radar

The second mistake is structural rather than strategic. A foreign company benchmarks salary at the moment of hire, sets the offer accordingly, signs the contract, and then doesn’t revisit compensation for 18 to 24 months. During that period the Belarusian senior IT market continues to move, and the engineer’s salary gradually slides from “above market” to “below market” without anyone noticing.

Belarusian IT compensation has moved between 8 and 12 percent per year through 2024 and 2025. A salary that sat 10 percent above market at signing can drift to roughly 5 percent below market within twelve months. Two years in, the engineer is materially underpaid relative to what they could earn by changing employers, even though their nominal salary has not changed.

What makes this issue sharper in Belarus than in some other markets is the visibility of the comparison. Belarusian senior engineers can compare their compensation, in real time, against equivalent roles in Vilnius, Warsaw, Berlin, and Tbilisi through Telegram channels, IT meetups, and direct contact with former colleagues who’ve relocated. The information environment makes salary drift much easier to detect for the engineer than for the foreign employer who isn’t in those channels.

The operational consequence shows up as voluntary attrition that clusters in the 18-to-24-month tenure window — a globally observed software-engineering pattern that is sharpened in Belarus by the local visibility dynamics. Reactive correction at the moment an engineer is already considering leaving costs roughly twice what proactive correction would have cost, and even then the save rate is below 50 percent. McKinsey research on European attrition has consistently identified inadequate compensation among the top three reasons European workers leave. SHRM puts the cost of replacing a tech employee at 50 to 60 percent of annual salary as a baseline; other industry analyses run materially higher when knowledge loss is factored in.

What works instead. Run an informal compensation health check at the six-month mark and a full review at twelve months, rather than treating compensation as an annual event. Use current benchmark data — Recruitment.by can create IT salary research covering current Belarusian compensation ranges by role and seniority, and we update it on a regular cadence specifically because annual benchmarks are too slow for this market. Build the review cadence into the operating practice rather than treating it as an exception event triggered by a counter-offer conversation.

Mistake 3: Picking the wrong employment structure (and not noticing for a year)

Of the five mistakes covered here, this is the one that compounds. Foreign companies make a structural choice based on what’s convenient at the moment of first hire, then build a team around the choice, then discover — usually at the 12-to-18-month mark — that the model no longer fits.

Four patterns come up repeatedly:

The contractor-creep trap. A foreign company hires its first Belarusian developer on a freelance or Individual Entrepreneur (IE) contract, with the intent of formalising the structure later. Headcount grows. Eight or twelve hires in, the absence of proper employment infrastructure has become a real exposure: misclassification risk, IP-ownership ambiguity, no benefits administration, no statutory contributions, and a team of people who don’t feel like part of the company because they technically aren’t.

The EOR-at-scale trap. A foreign company starts with EOR — the right choice when they have one to three Belarusian hires — and continues paying per-employee EOR fees as the team grows past 20 people. At that scale the cumulative annual fees substantially exceed what running the company’s own Belarusian entity would cost, but the original setup decision was never revisited.

The outstaffing-for-core-team trap. A foreign company uses an outstaffing arrangement for what is, in operational reality, a permanent core engineering team. The engineers don’t feel like part of the foreign company. Retention suffers. The foreign client never quite gets the team commitment they were paying for, and they can’t understand why.

The PEO-without-entity trap. A foreign company is sold “PEO” by a provider without realising that the Belarusian PEO model assumes the client has, or is creating, a local entity. Without one, the structure either quietly collapses into something that more closely resembles EOR or fails to deliver the expected co-employment benefits at all. American readers should note in particular that Belarusian PEO isn’t the same as US PEO; an American lawyer reading the term in a Belarusian contract may misunderstand who carries which risk.

What works instead. Make the structural choice deliberately at the start, based on a 12-to-24-month projection of headcount and operating intent rather than on what is fastest to set up this week. Build migration provisions into the initial contract so that switching models later — which most foreign companies eventually need to do — does not require destabilising the team. Re-evaluate the structure at the 12-month mark, with the understanding that the right answer in month 12 may be different from the right answer in month 1.

Mistake 4: Running fast-cycle screening for a market that does not reward it

Some foreign companies treat Belarusian IT recruitment as a fast-turnaround pipeline and structure their hiring process accordingly: a thirty-minute initial call, a single technical round, a quick offer. This produces a specific failure mode that’s both predictable and avoidable.

The Belarusian senior IT market in 2026 is competitive but not desperate. Strong candidates have multiple options open to them at any given moment, including options outside the country. Aggressive shortcuts in the screening process are read by candidates as a signal that the company is not taking the hire seriously — which produces self-selection. The candidates willing to accept a rushed process are often the ones who themselves are not being selective. The candidates who would have been the strongest hires politely decline the offer.

There’s a second-order issue. Cultural fit, communication style, and English-language proficiency in working contexts can’t be reliably assessed in a single thirty-minute call. They emerge across multiple structured touchpoints with different members of the team. Companies that compress screening to a single round consistently underestimate this and end up making hires whose fit issues only become visible six months later — inside the period where the cost of departure is highest.

There’s also a context point specific to the post-2022 environment. Some senior Belarusian engineers have become more cautious about new employer relationships, particularly with foreign companies whose long-term commitment to the market is unclear. Those candidates want to understand the company they’re joining, the team they’ll be working with, and the realistic time horizon of the foreign employer’s presence in Belarus. A rushed screening process doesn’t give them the information they need to commit, and the strongest of them will withdraw.

What works instead. A multi-stage screening process spanning two to four weeks: an initial conversation, a technical round, a structured team interaction (so the candidate meets people they’d actually work with), and a final commercial conversation. The total time investment is similar to what a hasty process consumes once the failed hires are factored in — it just gets spent in the right place, before the offer rather than after. Allow time for the engineer to ask their own questions about the company, the team, and the long-term plan. Stack Overflow Developer Survey data consistently shows that engineer satisfaction at hire correlates strongly with the perceived seriousness of the hiring process; this holds in Belarus as well.

Mistake 5: Underinvesting in onboarding and integration

The fifth mistake is the one that companies often don’t recognise as a mistake until well after it’s happened. They hire well, contract correctly, and then drop the new engineer into the team with a Slack invitation, a Notion link, and a vague suggestion to “ping anyone if you have questions.”

Belarusian senior engineers joining a foreign distributed team face specific integration challenges that are easy to underestimate from the foreign side. Time-zone coordination with Berlin, Tel Aviv, or US offices requires explicit norms; without them, the engineer ends up perpetually on call or perpetually misaligned. Internal documentation written for native English speakers, often in shorthand, can be opaque to a new joiner who’s highly competent in English but isn’t immersed in the company’s particular conventions. The product, the customer base, the commercial logic of the business — all of this is obvious to existing team members and invisible to a remote senior engineer joining cold.

Without structured onboarding, the new engineer takes longer to reach full productivity — commonly six months instead of three to four — and the period before they reach productivity is the period where attrition risk is highest. Worse, a poorly structured onboarding sends a signal about the foreign company’s seriousness as an employer. Combined with the career-stability concerns covered in earlier sections, that signal sometimes pushes the engineer to start looking at other opportunities within their first six months.

What works instead. A structured onboarding programme with named milestones at one week, one month, three months, and six months. An assigned onboarding partner — a more senior engineer or a manager who is explicitly responsible for the new hire’s integration during the first 90 days. Scheduled synchronous time with the broader team, the product owners, and (where possible) customer-facing colleagues during the first 30 days. Documentation written for the new joiner rather than for the existing team, particularly around product context, market context, and decision-making conventions.

For clients who want help building the onboarding infrastructure rather than the recruitment alone, our HR consulting service covers programme design and rollout.

A short diagnostic checklist

Run these questions against your current or planned setup. If the answer to any of them is no, that area’s the highest-leverage place to focus before making the next hire.

Have you built your hiring specification specifically for the Belarusian talent market, or transplanted it from another regional market?

Do you have a documented compensation benchmark for the role you are hiring, current within the past six months?

Have you chosen your employment structure — entity, EOR, PEO, outstaffing — based on a 12-to-24-month projection of headcount and intent, or based on what was fastest to set up?

Is your screening process structured across multiple stages, with time built in for the candidate to evaluate you as well?

Do you have a documented onboarding programme for new Belarusian hires that runs at least 90 days?

Have you evaluated HTP residency as a tax-leverage option, either through your own entity or through your employment partner?

If the answers cluster around “no,” the good news is that none of these gaps requires unusual sophistication to close. They mostly require the time and attention to think the next hire through before making it.

Closing thoughts

Hiring well in Belarus in 2026 is entirely achievable. The foreign companies that do it well share a recognisable pattern. They treat the market on its own terms rather than as a generic Eastern European cheap-talent destination. They make structural choices deliberately rather than reactively. And they invest in retention and integration as part of the hiring process rather than treating recruitment as a single completed transaction.

The five mistakes outlined in this article are the ones our team sees most frequently across foreign-client engagements. They are also, fortunately, the ones that are most preventable. None of them require unusual sophistication to avoid — they require thinking the hire through before making it, rather than after.Recruitment.by has worked with foreign companies entering the Belarusian market for over a decade across IT, fintech, forex, crypto, and regulated industries. Our service offering covers IT recruitment, HTP residency setup, EOR, PEO, payroll, HR consulting, and IT outsourcing and outstaffing. If any of the patterns described in this article match what you’re seeing in your own setup, or if you’re evaluating a first hire in Belarus and would prefer to avoid them from the start, contact our team for a 30-minute scoping call. We’ll start from your situation rather than from our service catalogue.

IT Recruitment for Fintech and Banking

In most industries, a bad hire costs you a quarter of productivity. In fintech and banking, a bad hire can cost you a compliance incident, a regulator’s attention, and — in the worst cases — a license. That is the uncomfortable truth every CTO, Head of HR, and founder in this space eventually runs into.

IT recruitment for financial services is a different sport. The technology is recognisable — Java, Go, .NET, Kotlin, React, Kubernetes — but the context around it changes almost everything: the vetting, the onboarding, the contract structure, and even the legal entity you hire through. This article unpacks why the niche is different, walks through the five hiring models available to you (direct, EOR, PEO, outstaffing, outsourcing), and gives you a framework for choosing the right one.

Why Fintech and Banking IT Hiring Is a Different Sport

The obvious difference is regulation. The less obvious — and more important — difference is that regulation reshapes the entire hiring process, from the first CV to the first day on the job.

Regulatory and compliance load

A backend engineer joining a payments company inherits exposure to PSD2, PCI DSS, AML/KYC rules, GDPR, and whatever the local central bank requires. The Basel Committee on Banking Supervision has been explicit that operational resilience — including the people who build and run the systems — is a board-level concern, not an IT ticket. You can read the framework directly from the Bank for International Settlements. Candidates do not need to be lawyers, but they do need to understand that “move fast and break things” is not an available strategy.

Security-first engineering culture

Threat modeling, secure-by-design reviews, least-privilege access, and incident response are expected by default. A senior candidate who cannot discuss how they have handled a production security incident is, for this sector, a junior candidate.

Domain literacy

Payments rails, core banking, ledgers, matching engines, crypto custody, settlement windows — tech skill alone is not enough. The best fintech hires read a term sheet and a Kafka topic with roughly equal comfort.

The stack paradox

Banks still run Java, .NET, and Oracle at the core, while their fintech partners push Go, Rust, event-driven architectures and, increasingly, Web3. A good recruiter has to work both sides of that line at once.

Trust and background checks

NDAs, financial background verification, and sometimes regulator sign-off for key roles are standard. This lengthens the hiring cycle, which in turn makes time-to-hire a compliance risk in itself.

The Roles That Are Hardest to Close

Not every vacancy in fintech is difficult. Front-end and generalist full-stack roles close at roughly the same pace as in any product company. The bottleneck sits elsewhere:

• Senior backend engineers with payments or core-banking experience (Java, Go, .NET)
• DevSecOps and SRE engineers with PCI DSS or ISO 27001 exposure
• Data engineers who have built regulated data pipelines
• QA engineers fluent in compliance-driven test design
• Blockchain and Web3 engineers — especially for custody, smart-contract audit, and tokenisation
• CISOs and application security leads
• Product managers and business analysts with fintech domain depth
• Core-banking specialists (T24, Flexcube, Mambu, and similar platforms)

These are the roles where a generalist recruitment approach breaks down. Market mapping, targeted outreach, and genuine domain conversations with candidates are what move the needle.

Hiring Models: Which One Fits Your Situation

Before you pick a model, narrow the decision to four variables: speed, legal presence, control, and risk appetite. Every engagement model below is a different trade-off between those four.

Model 1: Direct Hiring 
Best for established local entities and long-term headcount

You hire the employee onto your own legal entity, run your own payroll, and manage all employment obligations yourself. This gives you maximum control and the lowest per-head cost at scale — but it’s the slowest model to set up, and full employer liability sits with you. Requires deep local expertise; in Belarus, the labour code, tax regime, and High-Tech Park rules all interact.

What works: Maximum control. Strongest cultural integration. Lowest per-head cost at scale.

Watch-outs: Slowest to start. Full employer liability sits with you. Requires deep local expertise.

Realistic timeline to first hire: Weeks to months

Model 2: Employer of Record (EOR)
Best for market entry without a local entity

The EOR provider is the legal employer of the specialist. You manage the day-to-day work; they handle contracts, payroll, taxes, and local labour compliance. This is the go-to model for companies entering a new market without a legal entity, for pilot teams, and for founders testing Belarus as a tech hub before committing to full incorporation.

What works: Fast setup — often a matter of days. No local entity required. Clean exit if the project ends.

Watch-outs: Per-head cost is higher than direct hiring at scale. You are one step removed from the employment relationship, which can complicate performance management if the EOR partner is weak.

Realistic timeline to first hire: Days to 2 weeks

Model 3: Professional Employer Organization (PEO)
Best for scaling HR with an existing local entity

A co-employment model. You retain more HR control than under an EOR, and the PEO provider takes on payroll, benefits administration, and local compliance. Fits companies that already have a local presence but want to offload the operational burden of HR and payroll — or that want to scale headcount without scaling their HR function at the same rate.

What works: Strong compliance coverage. Access to better benefits packages through the provider’s scale. Faster onboarding than fully in-house HR.

Watch-outs: Requires an existing or forthcoming legal entity. Governance lines need to be drawn carefully to avoid ambiguity between employer and co-employer.

Realistic timeline to first hire: 2–4 weeks

Model 4: IT Outstaffing 
Best for extending an existing team

Specialists sit on the provider’s payroll but work exclusively on your projects, under your management, as an extension of your team. The right choice for scaling an existing in-house team quickly, filling specific seniority or stack gaps, and projects with a multi-quarter horizon where you want team continuity without hiring overhead.

What works: Fastest way to add seasoned engineers. Predictable monthly cost. Easy to ramp up and down.

Watch-outs: The provider’s quality is your quality — vet their security posture, recruiting process, and retention numbers before you sign.

Realistic timeline to first hire: 1–3 weeks

Model 5: IT Outsourcing 
Best for scoped, non-core deliverables

You hand over a scope — a product, a module, a milestone — and the provider delivers it with their own team, project management, and process. Works for clearly scoped deliverables and non-core systems, or whenever you want an outcome, not a team.

What works: Minimal management overhead on your side. Provider owns delivery risk.

Watch-outs: Weakest knowledge retention in your organisation. Works poorly for roadmap-driven product development where requirements shift weekly.

Realistic timeline to first hire: 2–4 weeks

At-a-glance comparison

A practical pattern we see often: a fintech scale-up enters Belarus through EOR for the first two or three engineers, proves the market, and then migrates to a local entity with direct hiring and PEO support once the team crosses ten people. Outstaffing fills the seniority gaps in between.

What to Look for in a Recruitment Partner

Whether you work with Recruitment.by or another agency, vet any partner against this checklist:

• Verifiable fintech and banking placements, not just “IT in general”
• In-house recruiters, not a network of freelancers passing CVs around
• Understanding of local regulatory context — in Belarus, that includes the National Bank, the High-Tech Park regime, and data localisation rules
• Multiple engagement models under one roof — so the model can change as your situation changes, without switching vendors
• Salary benchmarking data for the markets you hire in
• A documented background-check process appropriate to regulated industries

On that last point, global standards like ISO/IEC 27001 increasingly influence what “appropriate” looks like, and serious candidates expect their employer to operate in that world.

Common Mistakes Companies Make

Most failed fintech hires trace back to one of five patterns:

• Hiring pure tech without domain fit. A brilliant distributed-systems engineer with no payments exposure will take six months to become productive. You rarely have six months.
• Underestimating compliance onboarding. Background checks, security training, and access provisioning routinely take two to four weeks in regulated environments. Build that into the plan, not around it.
• Going direct in a country where you have no legal entity. This is the most common — and most expensive — mistake. It creates permanent-establishment risk and tax exposure that dwarfs any recruitment saving.
• Picking the cheapest outstaffer without a security audit. In fintech, your vendor’s weakest engineer is your weakest engineer.
• Ignoring counter-offer risk. In a hot market, roughly one in three senior candidates receives a counter from their current employer. A recruiter who has not prepared you for that will lose you the hire.

For a sense of how quickly the talent market itself is shifting, the World Economic Forum’s Future of Jobs research is worth a read — financial services is one of the sectors with the sharpest projected skill churn.

The Bottom Line

Fintech and banking reward companies that match the right hiring model to the right moment — and punish those that try to force one model across every stage of their growth. Market entry is an EOR problem. Scaling a proven team is an outstaffing and direct-hire problem. Offloading a non-core system is an outsourcing problem. The same company will, over three years, likely need all three.If you are working through that decision right now, a short conversation is usually faster than a long spreadsheet. The team at Recruitment.by has run these scenarios for forex, crypto, trading, and traditional banking clients across the CIS, EU, and MENA, and can map your situation to a model in a single call. Start with the contact page — or, if you want to benchmark salaries before you pick up the phone, the IT salary research is a good starting point.

How to Recruit a CTO or Tech Lead: What to Look for and Where to Find Them

Hiring a CTO or Tech Lead is one of the highest-stakes decisions a company makes. Get it right and you build a foundation your engineering team rallies around. Get it wrong and you spend the next year untangling technical debt, rehiring, and wondering why releases keep slipping.

CTO vs. Tech Lead: Know what you actually need

Before posting a job, get clear on the gap you’re filling. These two roles are often conflated, and hiring the wrong one for your situation creates problems from day one.

A CTO is strategic. They own the technology vision, communicate it to the board and investors, define the long-term architecture roadmap, and make decisions that affect the entire business. They spend a significant portion of their time outside the engineering team — with clients, executives, and partners.

A Tech Lead, by contrast, is execution-focused. They own the quality of delivery within a team or product area. They write code, review pull requests, unblock engineers, and make the day-to-day technical calls that keep development moving. Their audience is internal: the developers they work alongside.

In early-stage startups, one person sometimes does both jobs. That’s fine for a while, but as headcount grows past 15–20 engineers, the two roles need to split. If you’re a ten-person company that hasn’t shipped v1, you probably need a Tech Lead. If you’re raising a Series B and need someone to talk architecture with enterprise clients, you need a CTO.

RULE OF THUMB
Define the problem before the title. Write out the three most important decisions this person will make in their first six months. If those decisions are internal and technical, hire a Tech Lead. If they involve stakeholders outside engineering, you need a CTO.

What to look for: beyond the tech stack

Most hiring teams get this backwards. They start with the CV — frameworks, languages, years of experience — and treat leadership ability as a soft add-on to evaluate at the end. In reality, for these roles, the leadership capacity matters more than the technical depth.

Here’s what to evaluate across four dimensions:

On technical skills specifically

Don’t require mastery of your exact stack. At this level, someone who has built scalable systems in Go is going to be fine leading a Node.js team. What matters is that they understand distributed systems, know how to evaluate architectural trade-offs, and have direct experience with the kind of scale you’re heading toward — not where you are today.

Ask them to walk you through a system they built from scratch. Where did they cut corners and why? What would they do differently? Honest, nuanced answers here signal experience. A perfect-sounding answer usually signals inexperience or performance.

Where to find them

Strong CTOs and Tech Leads are rarely actively job-hunting. The best ones are heads-down building something. Your sourcing strategy needs to reach people who aren’t watching job boards.

LinkedIn — still the most reliable starting point

Boolean search works well here. Combine role titles with company stage indicators and relevant technologies. Target people with 8–12 years of experience, not 15+, where you’re more likely to find leaders who still write code. Personalised InMail referencing specific projects gets a 3–4× higher response rate than generic outreach.

GitHub and open-source communities

A candidate’s public contributions tell you a lot about how they actually think and communicate. Look at commit messages, issue discussions, and how they handle disagreements in pull request reviews. Someone who writes clear, patient explanations in code reviews is probably doing the same with their team.

Tech communities and events

Local tech meetups, engineering conferences, and Slack communities for specific tools or frameworks are strong sourcing channels. People who speak at these events or contribute to community discussions are usually senior enough to be relevant. Meetup.com is a practical starting point for finding active tech communities in your region.

Internal referrals

Ask your existing senior engineers who they’d want as their CTO or Tech Lead. They know the space, they know the culture, and they’re unlikely to recommend someone who’d make their lives harder. Referral hires at the senior level also tend to onboard significantly faster than external hires.

Specialist IT recruitment agencies

For roles this senior, a dedicated IT Tech Lead recruiter brings two things a generalist can’t: a pre-mapped network of passive candidates and a technical frame of reference for evaluating them. They know who left where, who’s quietly open to a move, and how to position your company compellingly against competing offers.

SOURCING PRINCIPLE
Run at least three parallel sourcing channels at the same time. Relying on a single channel — even LinkedIn — introduces single points of failure into your pipeline. Top candidates at this level often come from unexpected places.

Which hiring model fits your situation

How you engage a CTO or Tech Lead matters as much as who you hire. The same candidate can be brought on as a full-time employee, an embedded contractor, a managed vendor relationship, or through a third-party employer of record — and each of those structures carries different cost, speed, legal exposure, and control trade-offs. Most companies default to direct hiring without realising there are four other models that may fit their stage better.

Direct hiring — the default for core leadership

The candidate becomes a full employee on your payroll, with equity, benefits, and a direct reporting line to the CEO or VP of Engineering. This is the right model when the role is long-term, strategic, and sits at the centre of your product. Downsides: slower to set up, higher total cost once benefits and taxes are included, and the full legal burden of employment sits with you. If you’re hiring a CTO for a funded company that plans to scale, this is almost always the correct choice.

Outstaffing — embedded talent, managed externally

The person works as part of your team day-to-day — standups, roadmap, direct reports — but is legally employed by an external provider who handles payroll, taxes, and HR. You pay a monthly rate per person. Outstaffing works well for Tech Leads when you want embedded ownership without opening a legal entity in the candidate’s country, or when you need to ramp up faster than a direct hiring process allows. It’s less typical for CTOs, because the role usually requires equity and board-level engagement that sit awkwardly with an external employer relationship.

Outsourcing — buying an outcome, not a person

You contract with an agency to deliver a defined outcome — a product, a platform, a migration — and the agency assigns its own technical lead to run it. You don’t pick the individual; you pick the vendor. This is rarely the right model for a permanent CTO or Tech Lead role, but it has a place as a bridge: a fractional CTO or an outsourced engineering lead can carry the function for six to nine months while you run a proper search for the permanent hire. Be honest with yourself about which you’re doing.

EOR — hiring abroad without opening an entity

An Employer of Record is a third party that legally employs the candidate on your behalf in their home country. You treat them as part of your team — they attend your meetings, report to you, and work on your roadmap — but the EOR handles local payroll, compliance, benefits, and contracts. This is the standard mechanism for hiring a Tech Lead in a country where you don’t have a legal entity. Setup takes days rather than months, and the added cost (typically 10–15% on top of salary) is well below what it would cost to open an entity for a single hire.

PEO — co-employment for companies with a local entity

A Professional Employer Organisation is a co-employment arrangement. Your company already has a legal entity in the jurisdiction; the PEO takes on HR administration — payroll, benefits negotiation, compliance — as a co-employer of record. It is not a substitute for an EOR. PEO is mostly relevant when you already employ a team directly but want to outsource HR overhead, and it rarely changes the CTO or Tech Lead hiring decision itself — it changes who runs HR for them afterwards.

MODEL SELECTION
Decide the model before you open the search, not after. It changes who you source, what compensation package you offer, and which countries stay on the list. A strong candidate you can’t legally hire is a wasted month.

How to structure the hiring process

Most companies over-engineer the interview process for senior tech roles, adding rounds that test for things they could learn in a 30-minute conversation. The goal is signal quality, not quantity. A four-round process should cover everything you need.

Alignment call — 30–45 min

Hiring manager or recruiter. Covers mutual fit, expectations, comp range, timeline. Don’t waste a candidate’s time or yours if the basics don’t align.

Technical depth interview — 60 min

System design discussion, past project deep-dive, architecture trade-offs. No LeetCode. No whiteboard puzzles. Real problems from your domain.

Leadership and culture interview — 60 min

CEO or VP. Focus on vision alignment, communication style, how they handle failure, and how they think about building teams. This is where culture fit is assessed — not outsourced to gut feeling.

Team interview and optional paid assessment

For Tech Leads: a short paid project (4–6 hours) reviewing existing code and presenting findings. For CTOs: a 45-minute session with the senior engineering team. The team’s read matters — they’ll be working with this person every day.

According to SHRM, structured interviews — where every candidate is asked the same questions in the same order — are significantly more predictive of job performance than unstructured approaches. At senior levels, this discipline is even more important, because the pull toward “I just liked them” is stronger.

Set a deadline for your process and communicate it. Four weeks from first call to offer is achievable. Six weeks is acceptable. Eight or more and you will lose candidates to faster-moving competitors.

Common mistakes that derail the search

Most hiring failures at this level are predictable. They tend to come from the same few patterns.

Hiring on pedigree rather than fit is probably the most common. A candidate who built distributed systems at a major tech firm sounds impressive, but if your company runs a monolith and needs someone to mature an existing codebase rather than rebuild from scratch, you’ve hired for the wrong problem. The resume should inform, not decide.

Skipping the leadership assessment comes second. Companies run a technical interview and a culture fit chat and call it done. But leading a team requires skills that code reviews don’t reveal: how someone gives difficult feedback, how they handle a team member who’s underperforming, how they make decisions under ambiguity. These things need to be directly probed.

Moving too slowly is underestimated as a failure mode. Strong candidates at CTO and Tech Lead level are typically fielding multiple conversations at once. If your process goes quiet for two weeks between rounds, the candidate will assume the role is on hold — or that you’re not serious. Keep the cadence tight and communicate proactively.

Finally, not involving the engineering team soon enough. The incoming CTO or Tech Lead will have to build trust with your engineers. If they’ve never met before the offer is signed, you’re starting that relationship at zero. Bring your senior engineers into the process at round three or four and take their feedback seriously.

Conclusion

Hiring a CTO or Tech Lead is not a process you want to rush, but it’s also not one you want to drag out. The best candidates have short windows of availability, and the cost of getting this hire wrong — in time, money, and team morale — is high enough that it deserves a serious, structured approach.

Define the role precisely before you start. Evaluate leadership as rigorously as you evaluate technical ability. Build a multi-channel sourcing strategy that reaches passive candidates. And run a process that moves quickly enough to compete for people who have options.

If you’d rather put the search in experienced hands, the senior IT leadership hiring team at Recruitment.by works specifically with companies filling CTO, Tech Lead, and other senior technical positions — with first candidates typically delivered within five business days of kickoff.

How to Hire a Business Analyst for an IT Project: Skills, Red Flags, and Interview Tips

We’ve seen it more than once: a company hires a BA, the project kicks off, and six months later the dev team is building something nobody asked for. Developers blame unclear requirements. The BA says stakeholders kept changing their minds. Stakeholders say nobody listened. Everyone’s right, and the project is a mess.

A bad BA hire doesn’t announce itself upfront. The CV looks fine, the interview goes smoothly, and the problems only show up once the work starts — by which point you’re already behind. This guide is about avoiding that. We’ll cover what to actually look for in a BA candidate, the seniority question, red flags that rarely appear on CVs, and the interview questions that separate people who know how it’s done from people who’ve watched it happen from a distance.

1. What a Business Analyst Actually Does — and What They Don’t

Ask ten hiring managers to describe the BA role and you’ll get eight different answers. That’s the root of most bad BA hires: the company doesn’t know what it needs, so it can’t screen for it effectively.

A BA on an IT project is the person responsible for making sure the dev team builds the right thing. Not the fast thing or the cheap thing — the right thing. They do that by getting clear on what stakeholders actually need (which is often different from what they say they want), documenting those needs in a form engineers can work from, and staying close enough to the process to catch misunderstandings before they become expensive bugs.

Day to day that looks like: stakeholder interviews and workshops, writing requirements documents and user stories, process modelling, and a lot of back-and-forth between the business and the dev team to keep everyone aligned.

What a BA is not: a project manager (they don’t own timelines or budgets) or a product owner (they don’t set product vision or run the backlog). These roles overlap in practice, but they’re not the same thing. When you blur them in a job description, you end up with a candidate who’s unclear on their own responsibilities — and that ambiguity gets expensive fast.

2. The Skills Worth Screening For

Hard skills

On the technical side, here’s what actually matters for IT projects:

• Requirements documentation — BRDs, user stories with clear acceptance criteria, use cases. The benchmark isn’t polish; it’s whether a development team can build from the document without making assumptions. If the requirements leave room for interpretation, they’re not done.
• Process modelling — BPMN for business flows, basic UML for system interactions. Expert-level proficiency isn’t a prerequisite, but a BA should be able to produce diagrams that are accurate, readable, and actionable — not just illustrative.
• Tool fluency — Jira, Confluence, Miro are standard in most IT environments. A candidate with several years of BA experience who hasn’t worked with these tools warrants a direct conversation about how they’ve managed requirements and collaboration in practice.
• SQL fundamentals — reading queries, validating data, understanding table relationships. A BA who can independently verify that data behaves as specified adds meaningful value; one who relies entirely on developers for data validation creates a bottleneck.
• Agile/Scrum in practice — not familiarity with the terminology, but working knowledge of how requirements move through sprints, what a well-groomed backlog looks like, and how to handle scope changes without derailing delivery.

The IIBA BABOK Guide covers elicitation and collaboration as a core competency area — and in our experience hiring BAs, it’s the one that sets strong candidates apart from the rest.

Soft skills

This is where most interviews fall short. Hard skills get candidates through the door; it’s the soft skills that determine whether the project works.

• Communication that goes both ways — explaining technical constraints to a CFO without talking down to them, and translating a VP’s vague vision into something a backend developer can act on. Both directions matter.
• Knowing when to push back — a BA who just transcribes whatever stakeholders say isn’t doing the job. Part of the role is flagging when a request doesn’t make sense, conflicts with something else, or is going to create scope problems down the line.
• Workshop facilitation — getting a room of people with different priorities to agree on requirements is a skill. Some people are naturals; others make it worse. You want someone who’s done it enough times to know how to manage the room.
• Handling conflict between dev and business — it’s going to happen. A good BA gives both sides a shared reference point instead of becoming another source of noise.

3. Junior, Mid-Level, or Senior — Which Do You Actually Need?

Hiring the wrong seniority level is an expensive mistake, and it goes both ways.

The honest question to ask: how much ambiguity is baked into this project? The answer tells you the seniority you need.

4. Red Flags That Don’t Always Show Up in CVs

Most of these only become visible when you actually talk to the candidate. Watch for:

Vagueness. A good BA can tell you about a specific project, a specific problem they ran into, and specifically what they did. “I was responsible for requirements gathering across multiple workstreams” is not that. If they can’t provide any specifics, the experience probably isn’t as deep as the CV suggests.

They can’t separate their role from the PM’s or PO’s. When a candidate describes their past work, do they know where their job ended and someone else’s began? Confusion here usually means they were either doing a bit of everything without real ownership, or crediting themselves with work that belonged to their team.

The portfolio is underwhelming. Ask to see a requirements document or user story set before the interview. If what they bring is thin, generic, or copy-pasted from a template — and they can’t explain why they made the choices they made — that’s a problem. Templates aren’t bad; not knowing why you used one is.

“Agile” is on the CV but doesn’t survive questioning. Ask how requirements changed on a live project. Ask what they did when a sprint was halfway done and the stakeholders wanted to change direction. “We held a meeting” is not an answer.

No curiosity about the business. Some BAs treat requirements like a clerical task — gather, document, hand off. The good ones genuinely want to understand why the business needs what it needs. That curiosity is what makes the difference between requirements that pass review and requirements that deliver results.

5. Interview Questions Worth Asking

Generic interview questions produce generic answers. Behavioural questions — the kind that ask for a specific past situation rather than a hypothetical — are consistently better predictors of on-the-job performance. Here’s what we’d ask:

“Take me through how you got requirements out of stakeholders on a project that was genuinely complicated.”

You want specifics: who was in the room, what techniques they used, what went wrong. A candidate who can’t get specific here hasn’t done the hard version of this work.

“Tell me about a time the dev team and the business side were pulling in opposite directions. What did you do?”

You’re not looking for someone who made everyone happy — that’s usually a sign they avoided the conflict. You want to hear how they navigated it.

“What do you do when the requirements you’re getting are contradictory or incomplete?”

There should be a process here: flag it, trace it back to the source, get a documented decision. “I go back to the stakeholder” without any follow-up structure is a weak answer.

“Show me something you wrote — a user story set, a BRD, a process diagram — and walk me through it.”

The artifact is less important than whether they can explain the thinking behind it. If they’re defensive or vague, that tells you something.

“How do you make sure what you’ve documented is actually what was wanted?”

Sign-off processes, review loops, UAT involvement — there should be a real answer here. A BA who considers their job done when they hand off the document is a liability.

“Have you ever told a stakeholder their request wasn’t going to work? What happened?”

How a candidate handles this question tells you a lot about their confidence and communication style. Pushback is part of the job. Someone who’s never done it either hasn’t been in the right situations or has been avoiding them.

“What’s your first move when you join a new project?”

Stakeholder mapping, reviewing existing documentation, identifying what’s already been decided — a thoughtful answer here shows someone who understands that good requirements work starts before you write a single line.

6. How to Run a Hiring Process That Actually Works

The CV screen matters less than most hiring managers think. Here’s where to focus:

Write a job description that reflects the actual project. Generic BA job descriptions attract generic BA candidates. Describe the domain, the team setup, the stage of the project, what good output looks like. Candidates who’ve done that specific kind of work will recognise it and apply; the wrong profiles will self-select out.

Ask for a work sample upfront. A requirements document, a set of user stories, a process model — something they actually produced. Review it before you interview them. It’ll change the questions you ask.

Run a short case study with shortlisted candidates. Give them a realistic scenario: a vague brief from a fictional stakeholder, some buried contradictions, a tight scope. Ask them to produce a rough requirements outline. What they produce and how they reason through it will tell you more than a two-hour interview.

Get developers in the room. A BA who impresses the HR team but confuses the engineers isn’t the right hire. Run at least part of the interview with someone from the technical side.

Check references on specific outputs. “Was this person good to work with?” is not a useful reference question. Ask whether their documentation was actually usable, whether stakeholders trusted them, how they handled situations where requirements changed late in the process.

7. Should You Hire Directly or Use a Recruitment Agency?

If you have a solid internal HR function, a clear brief, and a few weeks to run a proper process, you can absolutely hire a BA yourself. HR consulting support can help structure the process if you haven’t hired for this role before and want a framework that’s actually been tested.

Where agencies earn their fee is in specific situations: you need someone fast, the domain is niche (fintech, healthcare, enterprise ERP), or you’ve already run a search and it stalled. A good IT recruitment agency has pipelines of pre-vetted candidates and can get you to a shortlist weeks faster than a cold search — which matters a lot when a project is already waiting for the hire.

8. Hiring Models: Which Engagement Format Fits Your Situation

Knowing what kind of BA to hire is one question. Knowing how to engage them is another. The same candidate can be brought on through five different models — and the right choice affects cost, speed, legal exposure, and how much control you actually have over the work. Here’s how each model works in practice.

Direct Hiring

The BA becomes your employee. You handle the contract, payroll, benefits, and all HR obligations. You get full control over how they work, who they report to, and how their role evolves over time.

Best for: Long-term roles where you need the BA embedded in the team, building institutional knowledge over time. If requirements work is a continuous function in your organisation rather than a project-specific need, a direct hire usually makes economic sense within 12–18 months.

Watch out for: The full cost of employment — salary, employer taxes, benefits, onboarding — and the time it takes to run the process. If the need is project-bound, you may end up with a BA on payroll who has nothing meaningful to do once the project wraps.

Outstaffing (Staff Augmentation)

A vendor provides the BA, who works under your direct management — joining your team, following your processes, and reporting to your people. The vendor handles employment, payroll, and HR. You get operational control without the administrative overhead of being the employer of record.

Best for: Filling a specific gap in your team for a defined period — a project ramp-up, a maternity cover, or scaling without committing to headcount. You get the control of a direct hire with significantly less administrative burden, and you can scale up or down more easily.

Watch out for: Vendor margins mean the hourly or monthly rate is higher than a direct hire on an equivalent salary. And if the BA is on the vendor’s bench, you have less visibility into who you’re getting before they start. Vet the individual, not just the vendor.

Outsourcing

You hand off a defined deliverable — a requirements specification, a discovery phase, a full business analysis workstream — to an external team or consultant. The vendor manages their own people and methods. You specify the output; they figure out how to produce it.

Best for: One-off projects with a clearly scoped BA component, or situations where you need specialist expertise — a discovery phase for a fintech product, say — that doesn’t justify a permanent hire. You pay for the outcome, not the hours.

Watch out for: Less day-to-day visibility. If the deliverable spec isn’t tight, you may not discover the gap until review. Outsourcing works best when you know exactly what you need; it works worst when you’re still figuring that out.

EOR (Employer of Record)

A third-party company legally employs the BA in their jurisdiction on your behalf. You manage the work; the EOR handles local employment contracts, payroll, tax compliance, and benefits. This is typically used when you want to hire someone in a country where you don’t have a legal entity.

Best for: Hiring international talent compliantly — particularly relevant when you’ve found the right candidate in a different country and don’t want to set up a local entity just to employ one person. EOR is increasingly common for hiring BAs in Eastern Europe or Southeast Asia while keeping day-to-day management onshore.

Watch out for: EOR adds a service fee on top of the employment cost — typically 10–20% of gross salary. You’re also dependent on the EOR provider’s local compliance expertise, so due diligence on the provider matters as much as due diligence on the candidate.

PEO (Professional Employer Organisation)

Similar to EOR, but under a co-employment structure: both you and the PEO are considered employers, with the PEO handling HR administration, payroll, and compliance while you retain control over day-to-day work direction. PEOs typically operate within a single country and work best when you already have a legal presence there.

Best for: Companies that want to offload HR complexity without losing visibility into their team. If you’re scaling headcount quickly and HR administration is becoming a bottleneck, a PEO lets you move faster without building out the function internally. It’s also a good fit when you want to offer competitive benefits without the overhead of running them yourself.

Watch out for: The co-employment model creates shared liability, which can complicate terminations and disputes. Make sure the agreement clearly delineates which decisions belong to you and which to the PEO. And unlike EOR, a PEO typically can’t operate across borders — if you need to hire internationally, EOR is usually the right call.

Which Model to Choose

The honest answer is that it depends on three questions: how long do you need this person, how much management overhead can you absorb, and where are they located? A long-term embedded BA in your home market is usually a direct hire. A specialist BA for a six-month project in another country is usually EOR or outstaffing. A defined discovery phase with a clear deliverable is usually outsourcing. Most organisations end up using different models for different situations — the mistake is defaulting to one approach regardless of context.

Conclusion

The reason BA hires go wrong so often isn’t that there aren’t good candidates out there. It’s that the hiring process is usually too generic to find them. Resumes don’t show documentation quality. Competency questions don’t reveal whether someone can actually manage a difficult stakeholder conversation. And seniority titles mean different things in different companies.

A more practical approach works better: ask for work samples upfront, run a case study, ask questions about real situations, and get developers into the interview. It takes more time than a standard two-stage screen, but it’s worth it. A bad BA hire — even on a six-month project — can cost significantly more than a recruiter’s fee.If you’re working through a Business Analyst search right now and want a team that’s placed BAs across IT projects of all sizes and domains, we’re happy to talk through what good looks like for your specific situation.

How to Write a Job Description That Attracts Top IT Talent

Most companies spend weeks — sometimes months — sourcing IT candidates. They pay for job board credits, tap their networks, and brief recruitment partners. Then they paste a job description together in twenty minutes and wonder why the quality of applicants doesn’t match the effort.

The job description is not an administrative checkbox. It is the first thing a candidate reads about your company. For senior developers, it functions as a filter: they use it to decide whether your company is worth their time. Get it wrong, and no amount of sourcing will save your pipeline.

This guide is written from the perspective of recruiters who have reviewed thousands of IT applications and spoken with hundreds of developers about why they apply — or don’t. What follows is practical advice specific to tech hiring, not adapted from generic HR templates.

Why most IT job descriptions fail

The average IT job posting is a document written for the company, not for the candidate. It opens with three paragraphs about the company’s mission, lists twenty-odd requirements, half of which are aspirational, describes the role in language so vague it could apply to four different positions, and says nothing about salary.

Senior developers have seen thousands of these postings. They know within thirty seconds whether a description was written thoughtfully or assembled from a template. The decision to keep reading — or not — often happens before they reach the responsibilities section. This dynamic is well understood by anyone working in talent acquisition inside IT companies, where the quality of a job posting is treated as a direct reflection of how the engineering organisation operates.

The most common mistakes fall into predictable categories. Vague responsibilities tell a candidate nothing about what the job involves day to day. Inflated requirements — asking for ten years of experience in a technology that has existed for six — signal that no one has thought carefully about what the role actually needs. And missing salary information reads, at this point, as either disorganization or an intention to lowball.

None of this means your job description needs to be a literary achievement. It needs to be honest, specific, and structured in a way that makes sense to someone who reads dozens of these a week.

Start with the tech stack — not the company history

If there is one thing senior developers check first, it is the technology stack. Not the company vision. Not the team culture statement. The stack.

A developer’s skills, experience, and day-to-day satisfaction are all tied to what they build with. Whether the role involves React or Angular, PostgreSQL or MongoDB, a monolith or microservices — these details determine whether this is a job worth reading further. Burying the stack in paragraph four, or omitting it entirely, guarantees that a significant portion of qualified candidates will not make it to paragraph two.

List the stack clearly and specifically near the top of the posting. Name the languages, frameworks, databases, cloud infrastructure, and any notable tools or platforms. If there is a legacy system that will be part of the role, mention it — developers respect honesty about technical debt far more than they respect pretending it does not exist. If you are actively modernizing the stack, say so.

What you should avoid is listing technologies as buzzwords without context. “We use cutting-edge technologies including AI and blockchain” communicates nothing. “We’re building a data pipeline in Python on AWS, using Airflow for orchestration and dbt for transformation” communicates a great deal.

Write responsibilities like a day in the life

The responsibilities section is where most job descriptions collapse into a list of abstract verbs. “Responsible for designing, developing, and maintaining scalable systems.” “Collaborating with product and design teams.” These sentences are technically true of almost any software engineering role, which means they are effectively meaningless.

What a candidate actually wants to know is: what will I do? Who will I work with? What problems will I be solving, and how much ownership will I have over the solutions?

Try writing one or two sentences that describe a concrete challenge the person in this role will face. The backend team is currently migrating a monolithic payment service to a microservices architecture — the person joining will own two of those services end to end, from design through deployment. That single sentence tells a candidate more than six bullet points of generic responsibilities.

Include the team structure: how many engineers, how the team is organized, whether there is a dedicated QA function or whether developers own testing, how product decisions get made. Senior candidates in particular want to understand the working environment before they apply.

Requirements: separate must-haves from nice-to-haves

Research published in the Harvard Business Review found that candidates — particularly women — are significantly less likely to apply when they do not meet every stated requirement, even when the role does not actually demand all of them. A list of fifteen requirements does not make your company look rigorous; it makes it look like no one has thought carefully about what the role needs.

The most effective approach is to split requirements into two explicit tiers. The first covers what someone genuinely cannot do this job without. The second covers skills or experience that would be advantageous but are not blockers — things a good hire can develop on the job or bring partially.

Be honest with yourself when building the first tier. If someone could succeed in this role with four years of relevant experience instead of seven, write four. If the GraphQL knowledge is something the team could transfer in the first month, it does not belong in the must-have list. Inflated requirements filter out exactly the candidates who might otherwise have been great hires, and they make your posting less competitive against companies who have calibrated more carefully.

For seniority levels, be specific. “Mid-level” means different things at different companies. Giving a concrete range — three to five years of commercial development experience, ideally with at least one production system at scale — is more useful than a label. The same principle applies when hiring for senior and leadership roles; misaligned expectations at the Tech Lead level, for instance, are among the most common reasons those searches take significantly longer than planned.

Be transparent about compensation

Salary transparency has moved from a nice-to-have to a practical necessity in IT hiring. Candidates who are actively looking scan dozens of postings a week. Those without salary information get deprioritized — not because the company is untrustworthy, but because the candidate’s time is limited and postings with visible compensation are easier to evaluate quickly.

The common objection to including a salary range is that it will anchor expectations or invite negotiation. In practice, a visible range filters the pipeline: candidates who would find the compensation unacceptable do not apply, which saves everyone time. According to the Stack Overflow Developer Survey, salary remains one of the top two factors developers weigh when considering a new role — clarity on this point is a signal of organizational maturity, not a negotiating weakness.

You do not need to publish a single number. A range — even a relatively wide one — is enough to signal that the company has thought about compensation and is willing to be open about it. If the range varies significantly based on experience, say so.

Sell the role, not just the company

Many job descriptions spend more words on the company than on what makes this particular role worth taking. Candidates can look up your company on LinkedIn, read your blog, and check Glassdoor. There is extensive data on how candidates research employers before deciding whether to apply, and most of that research happens outside the job description itself. What they cannot easily find is why this specific position is interesting — and that is exactly what the JD should tell them.

This does not mean writing marketing copy. It means being specific about what makes this role compelling. Is the team small enough that the person joining will have real influence over technical decisions? Is there a genuine path to a senior or lead position within a realistic timeframe? Is there a meaningful technical challenge that does not exist in most companies?

Remote and hybrid arrangements, learning budgets, conference attendance, and equipment stipends all belong here — but they work best when stated factually. “We cover one conference per year and provide a €1,000 annual learning budget” is more credible than “we invest in your growth.” One honest paragraph about what it is actually like to work on this team will outperform a polished list of benefits every time.

A practical IT job description template

The structure below is not prescriptive — adapt it to your context. It covers the elements that consistently appear in postings that generate strong applicant pipelines.

Role summary (3–5 sentences)

What the team does, what this person will own, and what the immediate priorities are when they join.

Tech stack

Specific technologies: languages, frameworks, databases, infrastructure, tooling. Separate what is primary from what is secondary.

What you’ll be doing

Day-to-day work, team interactions, scope of ownership. Three specific sentences beat ten vague bullet points.

What we’re looking for

Must-have requirements — keep to five or fewer if possible. Nice-to-have requirements, clearly labelled as such.

What we offer

Compensation range. Remote/hybrid/on-site arrangement. Benefits that are concrete and verifiable. Growth and development opportunities.

About the team (optional but effective)

Three to four sentences on team size, how the team works, and what a good culture fit looks like in practice — not in abstract values language.

FAQ

Should I include salary if we haven’t finalized the budget yet?

If you genuinely cannot commit to a range yet, it is better to write “competitive, dependent on experience” than to omit salary entirely. But wherever possible, do the internal work to establish a range before posting — senior candidates will often ask for compensation information before agreeing to a first call, and “we haven’t decided yet” is a weak position to be in.

Is it worth using a job description template?

Templates are useful as a starting structure, not a finished product. They ensure you don’t forget a section. The risk is that copy-pasting produces text that reads as generic — because it is. Edit every section to reflect the specific reality of this role at this company.

How do requirements lists affect who applies?

Studies on job application behaviour show that candidates — particularly those from underrepresented groups — are significantly less likely to apply when they do not meet every stated requirement. Keeping the must-have list tight, and clearly labelling the rest as preferred, has a measurable effect on both the volume and diversity of applicants.

What is the single most common mistake companies make in IT job descriptions?

Writing the requirements section before the responsibilities section. When you know what the person will actually do, you can work backwards to what they genuinely need. Most inflated or inaccurate requirements lists come from writing them in isolation, without grounding them in the real scope of the role.

Does employer branding matter in a job description?

Yes, but it works differently than most companies assume. Lengthy statements about values and culture tend to be skimmed or ignored. Specific details — the size of the engineering team, how code review works, what the on-call rotation looks like — are read carefully. Authentic specificity is more persuasive than polished generality.

Conclusion

A well-written job description does not guarantee a great hire. But a poorly written one will quietly filter out many of the best candidates before you ever get the chance to speak with them. The developers you most want to hire are typically not desperate — they are evaluating you as carefully as you are evaluating them, and the job description is where that evaluation starts.

The effort required to write a genuinely good posting is not enormous. It means being specific about the stack, honest about the scope, transparent about compensation, and clear about what the role actually offers the person taking it. None of that requires marketing skills — it requires knowing the role well enough to describe it accurately, and caring enough about the candidate experience to do so.

Companies that find the gap between candidates who apply and candidates who are actually suitable frustratingly wide often discover the problem starts here, with a posting that speaks to the wrong people or signals the wrong things. Those that prefer to hand the entire process — sourcing, screening, and matching — to people who do it every day work with a specialist in IT recruitment rather than trying to compress months of market knowledge into a single internal hire.

Write it like you mean it. That alone puts you ahead of most of the competition.

We’re Here to Help

If you contact us by the email we guarantee that you will receive a feedback from us within 2 (two) hours on any business day and within 6 (six) hours on any other day (holidays etc.).

Send

[email protected]

8 Kirova street, office 21, Minsk 220003

+375 (29) 366 44 77

How to Hire IT Specialists in Belarus: A Step-by-Step Guide for Foreign Companies

Belarus doesn’t always come up first when foreign companies think about where to hire developers. It probably should.

The country has built one of the densest concentrations of technical talent in Eastern Europe — engineers who are used to working with international teams, who speak English, and who have shipped real products for clients in the US, EU, and beyond. The market is competitive, but nowhere near as picked-over as Poland or the Czech Republic. And the quality-to-cost ratio is genuinely hard to match.

The obstacle for most foreign companies isn’t finding the talent. It’s figuring out how to hire legally, who to trust, and how to structure the engagement without spending three months on admin before anyone writes a line of code.

This guide is designed to make that process clear. 

Why Belarus for IT hiring?

The honest answer is: strong talent, reasonable cost, and a legal framework that was specifically built to make international tech hiring work.

The ICT sector generated 4.7% of Belarus’ GDP in the first ten months of 2024, and the country ranks among the world’s top IT services exporters on a per capita basis. That’s not an accident — it reflects decades of investment in technical education and a culture that takes engineering seriously.

For foreign companies evaluating their options, three things tend to be decisive.

The cost advantage is real, but it’s not a race to the bottom. Salaries are lower than in Western Europe, yes — but the developers coming out of Minsk and Grodno aren’t junior talent being paid junior wages. You’re getting mid-to-senior engineers at a price point that would buy you something considerably less experienced in Berlin or Amsterdam.

Most Belarusian developers have been working with international clients for years. That means they already understand remote collaboration, async communication, and the kind of documentation standards that distributed teams depend on. There’s less of a ramp-up than you’d get hiring in markets less exposed to global work. And the ecosystem has been validated at scale. According to the Hi-Tech Park’s official figures, the HTP’s foreign trade balance reached $1.6 billion in 2024. 

Understanding your hiring options

This is the decision most foreign companies get wrong — not because the options are complicated, but because they don’t think it through before they start sourcing. By the time the right candidate appears, they’re scrambling to figure out how employment actually works.

There are three main models. Here’s how they differ in practice.

Direct hire through a local entity

You register a legal entity in Belarus and employ people directly under Belarusian labor law. Full control, full responsibility — contracts, HR, payroll, everything. If you’re planning to build a team of 15+ people and you have the administrative infrastructure to support it, this makes sense. For most companies taking their first hire in Belarus, it doesn’t.

Employer of Record (EOR)

A local EOR employs your specialist on paper. You manage their work; the EOR manages everything else — payroll, tax filings, social contributions, legal compliance. You get the developer without needing to set up a local entity or understand every nuance of Belarusian employment law from scratch. For companies that want to move fast and stay compliant, this is usually where we start.

Outstaffing

The developer works as part of your team, under your direction, but stays employed by the agency. The agency handles HR, benefits, and the employment relationship. It’s similar to EOR in practice, but the agency is more involved in day-to-day employment matters. It works particularly well for companies with fluctuating headcount or project-based workloads, where you need flexibility without long-term employment commitments.

Step-by-step: how the hiring process works

Step 1 — Define the role clearly

The number of hiring processes that go slowly because the job spec was vague is, frankly, most of them. Before you talk to a recruiter, before you open a vacancy anywhere, write down exactly what you need.

That means the technical stack, not just “backend experience.” It means seniority level and what that actually looks like at your company, because titles vary wildly. It means English proficiency — if your team runs entirely in English, that’s a hard requirement, not a nice-to-have. And it means time zone expectations, because a developer in Minsk working core hours will overlap well with Western Europe and partially with the US East Coast, which may or may not be enough depending on your setup.

The more specific you are here, the faster everything moves downstream.

Step 2 — Choose your hiring model

This should happen before step one, really. But most people don’t think about legal structure until they’ve already picked a candidate, which is exactly the wrong time.

If you’re making your first hire in Belarus, EOR is almost always the right call. It’s faster, it keeps you compliant, and it gives you room to understand the market before you commit to a local entity. If you already know you need a team of five or more and you want the flexibility to scale, outstaffing is worth a conversation.

Step 3 — Source candidates

Job boards, LinkedIn, referrals, university networks — they all have a role. But if you’re a foreign company without an established brand in the Belarusian market, you’ll find that the best candidates aren’t actively applying to companies they’ve never heard of. They’re being headhunted.

Step 4 — Screen and interview

Have your process mapped out before the first CVs arrive. A typical process for a mid-to-senior role looks like: a short screening call to check motivation and communication, a technical assessment, a technical interview with your engineering team, then a final conversation about expectations and offer. Three or four stages, maximum.

More than that and you’ll lose people. Belarusian developers at the mid-to-senior level are rarely just talking to you. If your process drags, you will get to the end of it and find the person has already accepted something else. It happens more often than clients expect.

One thing worth factoring in: many strong candidates from this market are used to working independently and communicating asynchronously. That’s usually an asset. Build questions into your process that let you assess how someone handles ambiguity and self-organisation, not just technical output.

Step 5 — Handle legal and compliance

If you’re using EOR or outstaffing, your agency owns this. If you’re going direct, the key requirements under Belarusian labor law are: written employment contracts in Belarusian or Russian, a standard 40-hour working week, minimum paid leave of 24 calendar days per year, defined termination notice periods (typically one to two months), and social security and income tax withheld at source.

One of the most common compliance risks for foreign companies is misclassifying employees as contractors. It’s an easy mistake to make and a genuinely costly one to undo. If you’re not certain of the distinction, this is another good argument for starting with EOR.

Step 6 — Onboard properly

Signed contract, done — that’s how a lot of companies approach it. Then they wonder why their new hire seems disengaged three months in.

Onboarding for remote hires requires deliberate effort. That means a written document covering tools, workflows, and team norms before the person starts. It means a dedicated point of contact for the first few months — not just “ask the team on Slack.” Structured weekly check-ins for the first 60 to 90 days. Clear goals for week one and month one.

None of that is complicated. But it has to actually happen.

The Hi-Tech Park (HTP): what foreign companies need to know

The Hi-Tech Park gets mentioned a lot, and it’s genuinely worth understanding — not as a nice abstract fact about Belarus, but because it directly affects how much hiring costs you and how attractive your company looks to candidates.

HTP is a special legal regime for IT companies in Belarus — often called the “Belarusian Silicon Valley” — that operates with preferential tax rules until 2049. For employers working within the HTP framework, social security contributions are calculated against the average Belarusian salary rather than the employee’s actual salary. In practical terms, that means you can offer competitive developer compensation while paying significantly less in employer-side taxes than you would outside the HTP.For candidates, HTP residency signals that a company is serious, stable, and internationally oriented. When you’re an unknown foreign brand trying to convince experienced developers to join you, that signal carries weight. Our HTP recruitment page explains how we help companies navigate residency and structure hiring within the park.it’s just a different communication culture. Judge the substance.

Common mistakes foreign companies make

We’ve seen the same patterns enough times that they’re worth calling out directly.

Setting up a legal entity for a two-person team. The administrative overhead just doesn’t justify it at that scale. Start with EOR, see how the market works for you, then revisit the entity question when you’re actually growing.

Not specifying English requirements in the brief. If your team runs in English and you don’t make that explicit from the start, you’ll waste interview cycles on strong technical candidates whose English isn’t at the level you need. Make it a filter, not a surprise.

A four-to-six-week interview process. For junior roles, maybe you can get away with it. For mid-to-senior developers, you almost certainly can’t. The best people have options. Moving decisively is itself a signal that your company is worth joining.

Underinvesting in remote onboarding. This is probably the most common one, and it shows up quietly — not in a dramatic failure, but in a developer who’s technically solid and somehow never quite embedded in the team. It’s almost always an onboarding gap, not a hiring gap.

Treating termination as something to figure out later. Belarusian labor law has specific requirements here, and they’re not optional. Know what the obligations are before you hire, not when you’re already in a difficult conversation.

And one that surprises some clients: don’t mistake directness for disengagement. Belarusian developers tend to communicate precisely, give considered answers, and skip the social performance that can come with interviews in other markets. That’s not a warning sign — it’s just a different communication culture. Judge the substance.

Frequently asked questions

Do I need to set up a legal entity in Belarus to hire developers there?

No — and for most foreign companies, opening a local entity is the wrong first move. EOR and outstaffing arrangements let you hire legally without registering in Belarus at all. You manage the work; the agency handles employment, payroll, and compliance. A local entity starts making financial sense once you’re hiring at real scale and have the admin resources to support it.

How long does it take to hire an IT specialist in Belarus?

With a specialist agency, you’ll typically see first CVs within a week of signing a contract. From brief to accepted offer, most hires land somewhere between three and six weeks — faster for mid-level roles with clear requirements, longer for senior or niche positions where the pool is smaller and the process is naturally more considered.

What is the Hi-Tech Park and does it affect my hiring?

The HTP is a tax and legal regime for IT companies in Belarus, guaranteed until 2049. For employers, the main benefit is reduced payroll costs — social contributions are calculated on the average Belarusian salary rather than the employee’s actual salary. For candidates, HTP signals stability and access to international work. If you’re planning to hire more than a handful of people, it’s worth understanding how HTP residency might affect your structure.

How strong is English proficiency among Belarusian IT specialists?

At mid-to-senior level, most developers working on international projects will have solid working English — Upper-Intermediate or above is common. Junior talent is more variable. If English is genuinely required for your team to function, put it in the brief as a hard filter. Don’t rely on finding out in the first interview.

Key takeaways

Hiring IT specialists in Belarus is well within reach for foreign companies. But it requires making a few decisions clearly and early.

Pick your hiring model before you start sourcing — not after you’ve found someone you want to hire. For a first hire, EOR almost always wins on simplicity and speed. Write a precise job spec, because vague requirements cost time at every stage downstream. Move quickly through your interviews. And if you’re going to operate within the HTP ecosystem, understand the tax structure — it’s a real advantage, not just a talking point.

The talent is there. The legal framework exists to support international business. The companies that get it right are the ones that take the local context seriously rather than assuming it’ll work the same as hiring at home.

If you’d rather skip the guesswork, that’s what we’re here for.

We’re Here to Help

If you contact us by the email we guarantee that you will receive a feedback from us within 2 (two) hours on any business day and within 6 (six) hours on any other day (holidays etc.).

Send

[email protected]

8 Kirova street, office 21, Minsk 220003

+375 (29) 366 44 77

How to Build a Remote IT Team from Scratch

You have a product to build in mind. A deadline that already felt tight three months ago. And a growing suspicion that the developers you need simply don’t exist — or worse, that everyone else got to them first.

This feeling is more common than founders like to admit. Building a remote IT team from scratch is genuinely hard. It’s not just a hiring task — it’s an operational, cultural, and strategic challenge that, done poorly, can set a company back by a year or more. Done well, it becomes one of your most durable competitive advantages.

This guide is a practical, step-by-step playbook for founders who want to do it right: how to source the right people, bring them into your company without friction, and manage them well over the long haul.

Why Most Remote IT Teams Fail Before They Start

Before getting into the how, it’s worth being honest about the why. Most remote IT team efforts don’t fail because of bad luck — they fail because of predictable, avoidable mistakes:

• Hiring on speed instead of fit. Pressure to fill seats leads to shortcuts in screening. Six weeks later, you’re back to square one, plus the cost of a bad hire.
• No onboarding structure. Remote employees who don’t hear from anyone meaningful in their first week quickly disengage — or start a quiet job search.
• Timezone and communication mismatches. A team spread across 8 time zones with no async-first culture is just a collection of individuals, not a team.
• Unclear role definitions. When a developer isn’t sure whether they should be writing tests, maintaining CI/CD pipelines, or attending product meetings, they do none of them well.

The good news: all of these are preventable with a bit of upfront intentionality.

Step 1: Define the Team You Actually Need

Before you post a single job description or speak to a recruiter, build a simple team map. Ask yourself:

• What does the product need in the next 6 months — and in 18?
• Which skills are core vs. peripheral? (Core skills should be in-house; peripheral ones can be outsourced.)
• Do you need full-time employees, or would an outstaffing model serve you better right now?
• What tech stack are you committing to, and what does that mean for the talent pool?

A typical early-stage remote IT team might include a tech lead or CTO-for-hire, two to three backend developers, one frontend developer, a QA engineer, and optionally a UI/UX designer. Each of these can be hired on full-time employment terms or brought in through an IT outstaffing arrangement — the latter being especially useful when you need to move fast without a complex legal entity in a new country.

Be specific about seniority. A mid-level developer costs less than a senior, but may need more management overhead and will take longer to produce independently. For an early-stage team with limited founder bandwidth for mentoring, skewing slightly senior usually pays off.

Step 2: Sourcing — Where the Real Work Happens

This is where most founders underestimate the challenge. Posting a job on LinkedIn or Upwork is not a sourcing strategy — it’s wishful thinking. The best IT talent is rarely actively looking. They’re being recruited proactively, by people who know where to find them and what to say.

Your Sourcing Options

Direct outreach.  LinkedIn, GitHub, and Telegram communities can surface strong candidates, but meaningful outreach at scale requires dedicated time. Most founders don’t have it.

Job boards. Good for generating volume; less reliable for quality. Expect to screen many candidates to find a few worth interviewing.

Referrals. Often the highest-quality channel — but only once you have a team to ask. Not useful when you’re starting from scratch.

Specialist IT recruitment agency. The fastest path to qualified candidates, especially if you’re hiring in a market you don’t know well. A good agency has already built relationships with the talent pool, understands the tech landscape, and can assess candidates before they reach you.

When evaluating candidates, look beyond the resume. Technical skills are table stakes — what matters more is how someone communicates, whether they ask good questions, and whether they’ve demonstrated ownership in previous roles. Remote work rewards self-starters and penalizes people who wait to be told what to do.

Use structured technical assessments but keep them reasonable in scope. A take-home task that takes 8 hours signals disrespect for a candidate’s time. A 2-hour focused assessment signals that you value both quality and efficiency.

Step 3: Onboarding That Actually Works Remotely

Onboarding a remote developer well is one of the highest-leverage things you can do as a founder. Get it right, and they’re productive within weeks and loyal for years. Get it wrong, and you’ll spend months rebuilding trust — or replacing them entirely.

The First Week Playbook

1  Before Day One  Have accounts, access, and equipment sorted before the new hire logs in. A developer who spends their first day waiting for GitHub access has already lost trust in your operational competence.

2  Day One: Human First  Start with a video call — not a Confluence doc. Introduce them to the team, walk them through the product vision, and make clear that you’re invested in their success. Remote employees who feel seen in week one stay far longer.

3  Week One: Small Wins  Give a new hire a meaningful but contained task they can complete and ship in the first week. Shipping something real — even something small — is a powerful psychological anchor. It says: I belong here, I can contribute.

4  Weeks Two to Four: Structure the Feedback Loop  Weekly 1:1s in the first month aren’t micromanagement — they’re investment. Use them to surface blockers early, clarify expectations, and catch misalignments before they become problems.

Document your processes clearly — not in the form of a corporate handbook nobody reads, but in practical runbooks, decision logs, and Loom walkthroughs that a new hire can navigate independently. Good async documentation is the backbone of every high-functioning remote team.

Step 4: Managing a Remote IT Team for the Long Term

Hiring and onboarding well gets you to month three. What keeps a remote IT team performing — and together — over years is culture, clarity, and deliberate management practice.

Build an Async-First Culture

This doesn’t mean no meetings. It means that meetings are reserved for things that genuinely require synchronous discussion — decisions with nuance, team rituals, or difficult conversations. Everything else — status updates, code reviews, documentation — happens asynchronously, at the team member’s best working hours.

Tools matter here: Slack or Telegram for async messaging, Notion or Confluence for documentation, Linear or Jira for task management, and Loom for recorded walkthroughs. But the tools are only as good as the norms around them. Set explicit expectations about response times, availability windows, and how decisions get communicated.

Measure Outcomes, Not Activity

Remote management that defaults to surveillance — who’s online, how many commits per day, hours logged — breeds resentment and kills the autonomy that makes remote work valuable in the first place. Instead, define clear sprint goals and quarterly OKRs. Evaluate people on what they ship, not when they ship it.

Invest in Retention from Day One

The cost of losing a strong developer — in recruitment time, institutional knowledge, and team morale — is significant. The best retention strategy is simple but requires consistency: pay competitively, give people interesting work, make them feel that their growth matters to the company, and treat them like the professionals they are.

Consider regular team offsites, even once a year. There’s something about spending 48 hours together in person that strengthens remote team bonds in ways that no number of Zoom calls can replicate.

A Note on Legal Structure: EOR and Outstaffing

For founders hiring across borders, the legal and administrative complexity of employment can be a real barrier. Opening a legal entity in every country where you want to hire is slow and expensive. The alternative is using an Employer of Record (EOR) or outstaffing model — where a third party formally employs the developer on your behalf, handling payroll, taxes, and compliance while you direct the work.

This is particularly valuable in the early stages, when you need to move fast and can’t afford to spend three months setting up a subsidiary. With recruitment.by’s EOR service, a new hire can be fully onboarded and starting work within three days.

The Bottom Line

Building a remote IT team from scratch is one of the most consequential things a founder can do. It shapes what you can build, how fast you can move, and what kind of company you become.

The founders who do it well share a few traits: they define roles carefully before hiring, they take sourcing seriously instead of hoping good candidates will find them, they onboard with intention, and they build management systems that treat remote employees as adults who deserve autonomy and clarity in equal measure.

And the wisest ones? They don’t try to do all of it alone.

We’re Here to Help

If you contact us by the email we guarantee that you will receive a feedback from us within 2 (two) hours on any business day and within 6 (six) hours on any other day (holidays etc.).

Send

[email protected]

8 Kirova street, office 21, Minsk 220003

+375 (29) 366 44 77

How Much Does It Cost to Hire a Developer in Belarus in 2026?

Here’s the thing about Belarus nobody talks about enough: the talent is real, the rates are rational, and the country has been quietly producing world-class engineers for decades. Not a hidden gem — more like an open secret that somehow hasn’t been fully priced in yet.

That said, “competitive” is a word that gets thrown around a lot in nearshore hiring. It means nothing without specifics. So let’s get into them.

What does a senior backend engineer actually cost in Minsk in 2026? How wide is the gap between a junior QA hire and a lead ML architect? And if someone tells you Belarus is “cheaper than Poland” — how much cheaper, exactly? This guide answers all of it, drawing on recruitment.by salary data from active placements across the Belarusian IT market in 2025–2026. Whether you’re budgeting for your first remote hire or building out a full nearshore team, these are the numbers you actually need.

Why Companies Keep Coming Back to Belarus

Before the benchmarks, some context. Because salary data without market context is just noise.

The education pipeline is genuinely strong. BSU and BSUIR aren’t just names — they’re institutions that have been producing STEM graduates at scale for generations, with one of the highest per-capita concentrations of engineering talent in the post-Soviet world. That pipeline doesn’t dry up. It feeds into the job market year after year, which keeps the talent pool deep even as demand grows.

English proficiency is high — and it matters more than people realise. Some nearshore markets look great on paper until you’re three weeks into a project and every async message requires a round of clarification. That friction is largely absent here. Belarusian developers working in international-facing roles communicate fluently. Technical documentation, code reviews, Slack threads — it works.

The culture fits Western European working styles. Structured. Deadline-conscious. Collaborative without being chaotic. These are traits that align naturally with German, Dutch, Scandinavian, and British clients, many of whom have been working with Belarusian teams for a decade or more. The relationship is familiar, not experimental.

UTC+3 is a genuinely useful time zone. It’s easy to underestimate this. Full overlap with Western Europe. Enough morning hours to connect with the East Coast US. For synchronous collaboration — standups, code reviews, product sessions — this matters significantly more than a 1-hour time difference on paper might suggest.

The HTP changes the tax math entirely. Belarus operates a special economic zone for tech — the Hi-Tech Park — that applies a flat 9% personal income tax for registered employees, compared to the standard 13%. That differential compounds quickly at higher salary bands. It means developers can earn meaningfully more in take-home pay without companies having to increase gross packages to match. One of the most overlooked structural advantages in the region.

Developer Salary Benchmarks by Role & Level (2026)

The ranges below come from recruitment.by placement data, adjusted for company type (product vs. service), English proficiency, and domain specialisation. They reflect net monthly compensation in USD for HTP-registered employment.

* Net monthly compensation in USD. HTP-registered employment. Q1–Q2 2026.

What the seniority labels actually mean

• Junior (0–2 years): Needs close mentoring. Handles well-scoped tasks independently but won’t be architecting solutions. Budget accordingly — and budget for management time too.
• Middle (2–5 years): The workhorse tier. Autonomous on most tasks, can own features end-to-end, capable of mentoring juniors. The sweet spot for most teams building at pace.
• Senior (5+ years): Drives technical decisions. Architects solutions, conducts strategic code reviews, interfaces directly with stakeholders. Worth every dollar — if you actually give them problems worth solving.
• Lead / Architect (variable): Manages technical direction across teams or entire products. Deep in roadmap planning, hiring, and cross-functional communication. Rare. Price reflects it.

How Your Stack Choice Affects the Bill

Role and seniority get you most of the way there. But technology stack introduces a meaningful additional layer of pricing — and if you’re hiring for something niche, this matters a lot.

Rust and Web3 developers command the steepest premiums — not because of local dynamics, but because demand globally has lapped supply, and that pressure bleeds into even cost-competitive markets. Golang and Python/ML specialists sit in a similar but slightly more moderate bracket. React and Java sit at market rate. PHP lags, simply because the supply side is deep and the demand side has been quietly moving on for years.

How Belarus Compares to the Rest of the Region

Numbers in isolation don’t tell you much. Here’s the competitive landscape for senior developers across Eastern Europe:

Georgia is cheaper — but the talent pool is shallower, particularly for specialist roles. Ukraine is comparable in price and quality, but carries a different risk profile given ongoing geopolitical instability. Romania and Poland are both significantly more expensive, with Poland approaching Western European pricing for senior talent.

Belarus sits in a rare position: strong talent density, reasonable pricing, mature IT culture, and enough time zone overlap to make real-time collaboration genuinely work.

What the Salary Benchmarks Don’t Tell You

Salary is the anchor. It isn’t the whole budget. Companies that fail to account for the following often end up with cost surprises in month three.

Recruiter or agency fee. Retained or contingency recruitment typically costs 1–2 months’ gross salary as a one-time placement fee. In outstaffing arrangements, the margin is built into the monthly service rate rather than charged upfront — but it’s still there. Account for it.

Employer-side contributions. Direct hiring through a local entity triggers employer social contributions on top of net salary. The HTP regime reduces them relative to standard Belarusian employment — but they don’t disappear. Your legal or EOR partner will give you the exact figure; get it before you finalise the budget.

Onboarding and equipment. Hardware, peripherals, secure access setup, software licences, and the first few weeks of lower-than-full productivity. Budget $1,000–2,500 per developer for initial setup. It sounds obvious until you forget to include it.

Management overhead. This one’s invisible until it isn’t. Remote teams need deliberate investment in communication infrastructure — async documentation, regular touchpoints, clear escalation paths. If you’re building from zero, your senior in-house staff will spend real time on integration, code review, and coordination. That time has a cost. Plan for it.

Your Four Options for Hiring in Belarus

No single model fits every situation. The right structure depends on your timeline, your risk tolerance, and how central the role is to your core product.

1. Direct Hire

You employ the developer directly — either through a local legal entity you establish, or via an Employer of Record. Full control. Full administrative burden. Right for long-term, strategic hires where you want total ownership of the relationship. Not right if you need someone in six weeks.

2. IT Staffing Agency

An agency like recruitment.by sources, screens, and delivers candidates against your brief. Pre-vetted talent. Dramatically shorter time-to-hire. Ideal if you need to move fast, or if you don’t have an HR function with deep knowledge of the local market. You don’t need to know the market — we do.

3. Freelance / Contract

The developer works as an independent contractor on a B2B basis. Maximum flexibility. Minimum reliability for anything critical. Use this for time-boxed specialist projects, not for building your core engineering team.

4. Outstaffing

The developer is employed by the agency but works full-time, exclusively for your team — using your tools, your rituals, your culture. You get the integration of a direct hire without the legal complexity of a local entity. It’s the most popular model among international companies scaling in Belarus, and for good reason.

Not sure which model fits your situation? recruitment.by offers a free consultation to help you match hiring structure to business need — no commitment, no hard sell.

Frequently Asked Questions

Are Belarusian developer salaries rising in 2026?

Yes — but not uniformly. Senior and specialist roles (DevOps, ML, mobile) have seen 8–12% year-on-year increases, driven by global demand bleeding into local expectations. Junior and mid-level bands have grown more modestly, at 3–6% annually. The pace is slower than Western markets. That gap is the cost advantage. It’s real, and it’s holding.

Is it legal to hire a developer in Belarus as a foreign company?

Yes. Multiple legal routes exist: direct employment via a registered local entity, engagement through an Employer of Record, or working through a local staffing or outstaffing agency. Each route has different tax and administrative implications. Get proper legal counsel before choosing a structure. Don’t guess.

How long does the hiring process take?

Through an agency with an active candidate pool: 3–6 weeks for mid-level roles, 6–10 weeks for senior or specialist positions. Direct hiring without agency support takes considerably longer — particularly for high-demand specialisations where top candidates are already fielding multiple offers.

What’s the actual difference between outsourcing and outstaffing?

Outsourcing: you hand over a project or function. An external team manages it end-to-end. You get outcomes, not visibility. Outstaffing: you hire a developer who is employed by a third party but works as a fully integrated member of your team — in your standups, your Slack, your codebase. The control difference is significant. Most product companies building in-house capability choose outstaffing.

The Bottom Line

Belarus is not a compromise. That’s the honest version of the pitch.

You’re not trading quality for cost, or cultural fit for a lower invoice. What you’re actually getting — when you hire well, through the right channel — is technically strong talent, functional English, a compatible working culture, and salary expectations that are shaped by a tax environment most markets can’t replicate.

The planning numbers, for anyone who needs them up front:

• Middle-level backend or frontend developer: $1,600–2,800/month net.
• Senior full-stack or DevOps engineer: $3,200–4,800/month.
• Lead-level or ML/AI specialist: $4,500–$8,000+, depending on depth of experience.
• Agency/placement fee: one-time 1–2x monthly salary for placement; service margin built into monthly rate for outstaffing.

If you’re comparing options across Eastern Europe, Belarus doesn’t just compete on price. It competes on value — which is a different, better thing. If you want to hire new IT teams in Belarus with the help of EOR, you can use our services. 

We’re Here to Help

If you contact us by the email we guarantee that you will receive a feedback from us within 2 (two) hours on any business day and within 6 (six) hours on any other day (holidays etc.).

Send

[email protected]

8 Kirova street, office 21, Minsk 220003

+375 (29) 366 44 77