Engineers in your team for the duration of a project, or taking over system maintenance, ending with knowledge transfer to your people.
See the serviceSkills augmentation
One missing role in your project filled by a person from our team, chosen in conversation with your people, working under your manager, with a replacement when needed.
Scope
What clients come to us with
One decision is holding up the whole team
The developers are there, but no one in the company will decide how the system should be built. The team either builds on instinct or waits. Every month without that decision means work that will have to be redone later.
A technology no one in the company knows
The new system runs in the cloud or uses a tool your people have not worked with. You need one person who knows it, for the implementation and the first months of operation.
Someone left in the middle of the work
A developer or tester has left, is on long-term sick leave or has moved to another project. Tasks are waiting, the deadline is not moving, and the job advert gets no response. The team needs someone who will step into the existing code and process instead of rearranging them their own way.
Scope
What we do
Skills augmentation means one person from our team who joins your team in one role for the period set in the contract. An architect decides how the system is built: what parts it consists of and how they connect. A developer writes code in a specific technology. A tester checks the system before it goes live. An analyst works with users to write down what the system should do. A cloud administrator sets up and looks after servers rented from a cloud provider. Each of these people is directed by your manager. They work in your process, your tools and your repositories, meaning the places where the company keeps its code and documentation.
Selection starts with a conversation about the task with your manager: what is to be built, in what technology and who the person will work with. The team's experience includes Jira (handling tickets and tasks), Azure (cloud) and CI/CD (automated building and deployment of changes). It also includes network telemetry (measuring network traffic) and infrastructure monitoring. You receive the candidate's CV, but the conversation decides: the manager and the people who will work with the candidate check whether they understand the task and fit the team.
We treat the start of the cooperation as a trial period, with its length set in the contract. If during that time the person does not suit the team or the task, you tell us and receive a proposal for someone else. Replacement also works later: if the specialist goes on holiday, falls ill or leaves, we propose another person and organise the handover of work.
The cooperation ends on the date in the contract, or earlier if the task is done. The code, documentation and configuration are in your systems from day one, so the person leaving takes nothing with them. Training your staff to run the system is a separate scope (knowledge transfer).
We bill the person's working time: the rate and the billing period are set in the contract before the start.
Scope
When augmentation makes sense, and when to commission the task with acceptance
Augmentation makes sense when you have a manager who will direct the person, and the task changes along the way and is hard to describe in advance. You pay for time, set the priorities and see what is being built as it happens.
It is better to commission the task with acceptance when it can be described up front and checked on completion, for example connecting two systems. The same applies when no one in the company has time to direct an extra person. We are then responsible for the result, and you accept the finished work against agreed criteria.
A whole team with a lead on our side, working in cycles and reporting to the board, is a separate scope (dedicated teams).
Scope
What you get
- A role description before the start: task, responsibilities, availability, replacement and billing rules, for your approval.
- A person chosen in conversation with your team, working under your manager.
- Work in your repositories and systems from day one: code, documentation, configuration and records of decisions stay with you.
- A handover at the end: the status of every open task, the next step and where the documentation is kept.
Scope
How the work runs
- We define the role. We talk with your manager about the task, the missing skills and the period. Result: a role description with scope, period, replacement and billing rules, or the conclusion that the task is better commissioned with acceptance.
- We select the person. We put forward a candidate, and your team talks with them about the task and the way of working. Result: a person accepted by your team and an agreed start date.
- We join the team. The person receives accounts and permissions, reads the documentation and code, and carries out the first task together with one of your staff. Result: the person works independently in your process, and after the trial period you confirm the cooperation or receive a replacement.
- We finish with a handover. The person closes their tasks, describes the status of open ones and points to where the documentation is kept. Result: the work in your systems and billing closed.
Scope
Questions the board should ask the provider
- Who on our side directs this person, and what happens if they do not deliver on their tasks?
- Who from our team talks with the candidate before the start, and can we turn them down at no cost?
- If the person does not work out during the trial period or leaves before the contract ends, where will you find a successor, and will bringing them in come out of our budget?
- Where is this person's work created: in our repositories and systems, or at the provider's?
- What exactly are we paying for: time, results or availability, and what does the statement look like?
- Does this person work for other clients at the same time, and how many hours a week do they have for us?
- What provisions on confidentiality, permissions and ownership of the code does the contract contain?
Whether to fill the missing role with one person or commission the task with acceptance is decided in the analysis of processes and systems we start with.
Parent service
Team and maintenance
Book a meeting
Book a conversation about the problem
You describe the process or system that no longer keeps up and what has to change. The conversation costs nothing.
Phone: +48 455 406 404
Dedicated teams
A whole team with a lead that works only on your project, reports to the board on a fixed schedule and leaves with you everything needed to run the system.
See the scope
Taking over maintenance
A system built by someone else under ongoing care: reviewed before takeover, with a list of gaps, a plan for the first clean-up and a single queue for requests.
See the scope
Knowledge transfer
The system, its access and the knowledge of it in your people's hands, tested so that your team releases a new version and fixes a failure on its own, without calling the contractor.
See the scopeHow we start
A conversation about the problem
You describe the process or system that no longer keeps up and what has to change. The conversation costs nothing.
Analysis under an NDA
We examine the process and the systems and hand over a recommendation with a scope of work. You know the scope, deadline and price of the analysis before it starts.
Offer
You receive the scope, team, schedule and price of the implementation. You decide whether we go ahead.
The cost of the analysis is credited towards the implementation if you order it.
Phone: +48 455 406 404 E-mail: contact@aliaxit.com