Building an engineering team in Yerevan works best as a staged operating project, not a rush to fill seats. In the first 90 days, the goal is to appoint a credible local lead, hire a small core team, establish compliant employment, and prove that the team can ship within your product system.
The practical sequence is simple: define ownership before sourcing, hire the lead before scaling the team, and install delivery habits while the first engineers are onboarding. This keeps quality visible and gives later candidates a real team to join.
Before day one: define the Yerevan team mandate
Start with a written mandate that fits on one page. State what the Yerevan unit will own, which decisions stay with headquarters, the first product outcome, the reporting line, and the hiring ceiling. A vague instruction to “build a development centre” creates competing assumptions about whether the team is staff augmentation, a delivery pod, or an independent product unit.
Choose one first mission with a clear boundary: a service, product area, platform capability, or quality objective. Then map the skills required for that mission. The local market includes software, industrial computing, electronics, and related specialisms; the OECD's 2024 review of Armenia's digital economy also describes an ecosystem of universities, technology centres, incubators, and skills programmes. That breadth is useful, but it does not remove the need for a precise search brief.
Decide the employment model at the same time. A foreign company can establish its own Armenian entity, use an Employer of Record, or work with contractors where the relationship genuinely supports that status. The choice affects contracts, payroll, benefits, equipment, and the candidate proposition. Our Employer of Record guide for Armenia explains the operating differences, while the Engineering Studio combines team building and local employment support.
- Name one executive sponsor who can remove cross-border blockers.
- Give the local lead an explicit decision budget for hiring and delivery.
- Set a compensation philosophy and benefits package before interviews begin.
- Prepare the repository, security access, equipment, and onboarding owners in advance.
Days 1–30: hire the lead and open the talent map
The first hire should make the second and third hires better. For most new units, that means an engineering lead who can assess technical depth, explain the mission in Armenian or Russian when useful, and represent the company credibly to experienced candidates. Do not turn this person into a recruiter with a title. They need enough time to learn the architecture and shape delivery.
Build a talent map before publishing a broad vacancy. List target companies, adjacent sectors, university networks, professional communities, returning diaspora, and senior engineers who may not be actively applying. The Armenia tech talent pool overview is a useful starting point; a role-specific map is still required because backend, embedded, data, mobile, and security searches behave differently.
Run a compact assessment process. A sensible sequence is an initial motivation and logistics call, a technical discussion based on real work, a focused exercise only when evidence is missing, and a final conversation with the future manager. Agree the scorecard before meeting candidates. Otherwise, each interviewer quietly optimises for a different idea of “senior”.
- Week one: approve the mandate, scorecard, employment model, and interview panel.
- Week two: map the market and begin direct outreach to the lead shortlist.
- Week three: calibrate interviews using the same evidence standards.
- Week four: close the lead hire and let that person review the next role briefs.
Keep compliance in the plan, not at the end of it. Armenia's Labour Code, current English text with 2025 amendments, governs employment contracts, employer acts, working time, leave, and termination. If the team may include foreign nationals, the government's work-permit platform explains the employer-led online process and the exemption applicable to citizens of EAEU member states. Obtain local legal advice for the actual arrangement.
Days 31–60: form the core engineering team in Yerevan
Once the lead has accepted, hire a balanced core rather than several copies of the same profile. The right mix depends on the mission, but each hire should cover a real delivery risk: system knowledge, product judgement, quality, infrastructure, or communication across locations. A small team with complementary ownership usually learns faster than a larger group waiting for work to be divided.
Write role briefs around outcomes. Replace “five years of framework experience” with the system a person will own, the decisions they will make, and what good work looks like after the first quarter. This improves outreach and makes interviews more defensible. Our guide to hiring software developers in Armenia covers local sourcing and selection in more detail.
Close candidates with operational clarity. Explain the legal employer, salary currency and review practice, benefits, work location, equipment, probation terms, time-zone overlap, and who controls technical priorities. Senior engineers notice when these answers conflict. A consistent candidate brief is therefore part of team design, not a marketing document.
Onboarding should start before the employment date. Assign a technical buddy and a product counterpart. Prepare a first-week environment check, architecture walkthrough, customer context session, and one small production contribution. The objective is not instant velocity. It is to expose missing access, unclear ownership, and weak documentation while the cost of correction is still low.
Days 61–90: make delivery repeatable
The third month is where a collection of hires becomes a team. Install a small operating rhythm: weekly planning, a short delivery review, regular one-to-ones, an architecture decision record, and a retrospective with named actions. Copying every headquarters meeting into the Yerevan calendar is rarely useful. Keep only the ceremonies that support decisions or learning.
Measure signals that help the team improve. Useful early indicators include time to a working development environment, time to a reviewed production change, unresolved access blockers, hiring-stage conversion, offer acceptance, and the age of open decisions. Do not set velocity targets before the team understands the codebase. Early output data is diagnostic, not a league table.
Define interfaces between locations. Every important product area needs a named owner, an escalation route, a written decision record, and a reasonable overlap window. If the Yerevan team must wait overnight for routine approvals, the design is wrong. If headquarters learns about decisions only after release, the design is also wrong.
At the end of the period, hold a mandate review with the local lead and executive sponsor. Decide what the team can now own independently, which capability is still missing, whether the next hire removes a bottleneck, and which process should be stopped. Scale only after the operating model has survived real delivery.
A 90-day decision checklist
- If the product boundary is unclear, delay broad hiring and clarify ownership first.
- If senior candidates question authority, strengthen the local lead's mandate before changing the employer brand.
- If interviews produce inconsistent decisions, repair the scorecard and calibration session.
- If onboarding stalls on access, assign one owner and publish a reusable checklist.
- If cross-site approvals slow delivery, move defined decisions closer to the team.
The first-quarter test is not headcount. It is whether capable people understand the mission, have lawful and reliable employment, can make the decisions assigned to them, and can deliver with colleagues elsewhere. Headcount can grow after those foundations are visible.
FAQ
Should the first hire be an engineering manager or a senior individual contributor?
Choose the role that removes the largest uncertainty. If architecture and hands-on delivery are the main risks, a senior individual contributor with leadership range may be right. If hiring, cross-site alignment, and people management are immediate constraints, appoint an engineering manager with enough technical credibility to assess the first team.
How large should the Yerevan team be after 90 days?
Set a capability target rather than a universal headcount target. The core should be large enough to own a bounded outcome without creating management layers. Hiring fewer people with complementary responsibility is preferable to reaching an arbitrary number with unclear work.
Do we need an Armenian entity before hiring?
Not necessarily. Companies commonly compare their own entity with an EOR-supported model, taking account of expected team size, duration, control, cost, and administrative capacity. Make that decision with Armenian legal and tax advice before offers are issued.
If you want one accountable partner to recruit, employ, and help operate the team locally, explore ArgusRecruit's Engineering Studio. The useful starting point is a clear product mandate and the first roles, not a generic request for developers.