1. Business challenges
  2. Main problems on the project
  3. Results of comprehensive work
  4. Consulting format
  5. Consulting strategy
  6. Approaches and solutions
  7. Customer's achievement
  8. Review

Creation of the unified system that helps new engineers quickly delve into a complex integration project

Other cases

Business challenges

The customer needs to transfer their complex integration system development project over to a new team. However, there are no accompanying documents for the product or a clear description of the main cases and the system logic. The new team has to delve into the project without any outside help, while simultaneously maintaining their focus on commercially important deliveries, starting the development of the system architecture, and assuring the high quality of the product. All of these factors combined represent a financial and reputational risk for the business. In addition, the new team’s engineers have to spend a significant amount of time diving into the project, resulting in an increased probability of release delays and low control over product changes.

Situation on the project

  1. Complex product. The system has a large codebase, complex integration logic, and multiple cases of working with various types of data in countless combinations. The domain area of the product is also difficult to understand: the application performs the functions of transmitting telecom data using specialized protocols over the TCP/IP stack.
  2. Uncontrolled and completely independent immersion of the new engineers into the project. The team that hands over the project to the new engineers doesn’t have resources to help with their immersion in it. New specialists have to puzzle out the system operation on their own. At the same time, the customer cannot be sure how well they understood the system logic and whether they are able to develop the product without any help from the previous team.
  3. Without in-depth immersion, developers cannot comprehensively analyze emerging issues and make the right strategic decisions. As a result, there is a risk that the decisions made will lead to product degradation.
  4. Significant bus factor. When key employees leave the project, there is a high probability that the team will not be able to independently develop the product architecture.
  5. Short deadlines. The new team has less than 2 months to become immersed in the project to the fullest extent.

Main problems facing the project

  1. No documentation for the complex IT product.
  2. High dependence on individual team members.
  3. Too much time spent by new specialists getting involved in the project.
  4. Financial and reputational risks arising from inadequate control of product knowledge, so the new specialists face the possible consequences of changes they implement.


Under such conditions, it was impossible for the new team to quickly immerse itself into the project.


“This is a standard situation: when providing consulting services, I often come across big IT projects that don’t have the issue of knowledge transfer resolved. As practice shows, even engineers with a lot of experience can spend months trying to understand the specifics of the product and processes. On the one hand, developers get a lot of experience in this case, but if the customer’s goal is to quickly immerse specialists, create interchangeable teams, and take less risks, then it is impossible to do so without a thorough study of the knowledge transfer process.


Unfortunately, founders often do not allocate resources to control this area and are not morally ready to invest in it. But this should be done as early as possible: a unified system of immersion for engineers plays an important role in the security and stability of the IT business.“

Dzmitry Harachka

Comprehensive work results

Deep immersion in the project
Deep immersion in the project
All necessary accompanying documents created
6 times faster
6 times faster
New employees immerse into the project
Bus factor was eliminated
Bus factor was eliminated
The algorithm of new specialists immersing into the project mitigates the dependence on certain specialists
Reduced risks
Reduced risks
Serious financial and reputational risks are eliminated

Consulting format

This approach made it possible to build the most stable structure for introducing innovations, wherein Dzmitry did not have to spend too much time on it, but at the same time could completely control the result.

Consultation roadmap
  1. Dzmitry acted as a supervisor: he controlled the transfer of the customer's project to the new team.
  2. An additional manager was also involved in the project (this is a standard practice we use on consulting projects, for example, see case A ) to achieve the maximum possible effect in a short period of time. His duties included fixing, coordinating, and monitoring the implementation of Dzmitry's instructions by the team.
  3. An important element of consulting was holding team stand-ups jointly with Dzmitry. The stand-up duration was deliberately increased (from 30 to 45 minutes) for one month, so that all tasks and decisions made were discussed with the team. Thus, it was possible to make sure that all project participants understood the goals set so they could systematically move through the tasks and achieve the best possible result.

Consulting strategy

Personal consultations

Not all stakeholders understood the critical importance of building an onboarding process for new developers. Therefore, at the beginning of the cooperation, Dzmitry needed to convince the founders of the strategic importance of such an investment and the need to make it right now.

Analysis of the product and the situation on the project

It was necessary to understand and highlight the main types of system operation cases to create documentation, simply and easily reveal the domain area of the product, and build processes for immersion in the project.

Assistance in preparing the necessary materials

It was necessary to create a clear set of information for a new team member consisting of documents, videos, and diagrams so as to ensure a systematic project transfer to the new developers. This would allow engineers to independently understand the system operation in a short period of time.

Approaches and solutions

  1. Creating a comprehensive deployment diagram

    At this first stage, the decision was made to prepare a comprehensive deployment diagram, which would display all the interactions between system parts. The diagram consisted of 4 logical parts. Each of them denoted a certain system component and described the logic of its operation in detail. The diagram also included a scheme of data movement in the system, which specified the standards and protocols used in this process. The diagram was accompanied by a detailed text description to make it readable.

    This diagram was also expanded with elements of the activity diagram, which showed all the most important system operation scenarios.

    After that, a training video was created (lasting 1 hour), in which Dzmitry personally commented on each stage of this diagram and explained all the details of the software.

    The development team started reverse engineering and application debugging based on the created diagram. A team of test automation engineers was also involved in this task. It was extremely necessary to support all kinds of system debugging modes for the successful reverse engineering implementation: both locally in containers and in clouds. The correctness of each relationship in the diagram was confirmed through reverse engineering.

  2. Creating a Domain Dive document

    This document was created to describe typical cases of system operation in plain language. This simple method of explanation allowed new developers to quickly understand the main concepts and business tasks of the system.

    When creating the document, the consulting team carefully considered what information should be included in it to provide adequate understanding to the engineers. As a result, the decision was made to focus on visualization and simplified definitions of the main concepts, which was enough to understand the basic principles of the software within one working day.

  3. Creating supporting documents for the development process

    In parallel with the diagram creation, the team carried out additional activities to create the following supporting documents:

    1. Description of tasks in a simple format. The document was a simple description of the tasks that the team had to perform. At the same time, the formulation itself was detailed.
    2. Register of questions to the customer, list of unresolved problems. Documents were created to capture all unresolved issues that could affect the work of the team.
    3. System deployment guides: locally and in clouds. In parallel, DevOps specialists worked to automate system installation and deployment in Docker.

    New engineers immediately began creating a reference project after the immersion into the project using all the prepared materials. Dzmitry often uses this technique to implement a mechanism for transferring experience between different generations of developers on a project, as well as for fast immersion in complicated projects with a large codebase and complex combination of technologies. The essence of the reference project is to develop a small application using all the technologies and tools used in the real project. In addition to the development itself, engineers also perform other tasks during reference project execution: they work with the architecture, create diagrams, write Unit tests, participate in the implementation of Continuous Integration, and review the code.

    This means that new team members will be able to master the basic principles and technologies of the project within a few days without having to understand the large codebase, which greatly speeds up further immersion in the main project.

Customer's achievements as a result of cooperation

  1. All necessary accompanying documents for immersion in the project were created. Using previously prepared documents, diagrams, and guides, as well as knowledge transfer processes, new engineers were able to dive deep into the project and clearly understand the domain area of the software.
  2. The new development team had the opportunity to carry out the entire range of preparatory activities independently and in the shortest possible time: from understanding the tasks and the domain area to setting up, launching, and debugging the system.
  3. The time for new employees’ immersion in the project was significantly reduced. According to the results of our consultations, the time a specialist needed to become immersed in the project decreased by 6 times: from 2-3 months to one week. At the same time, we managed to keep the focus on production tasks.
  4. Serious financial and reputational risks were eliminated. At the same time, it was possible to reduce the cost of immersing engineers in the project.
  5. The bus factor was eliminated. The dependence on specific specialists was minimized thanks to the creation of a new specialist immersion algorithm.


Client's review of consulting

“This project turned out to be quite a challenge for our company. It was necessary to assemble a highly effective team of engineers in the shortest possible time, quickly immerse them in the processes and product, and motivate them to achieve their goals in the face of various constraints and difficulties. Dzmitry managed to convince us of the need to think through the process of immersing engineers in the project as soon as possible. Moreover, at the time, we had to consider the issue systematically, work out all the nuances in detail, and implement our strategy. To date, we have received excellent feedback on the results we got and do not regret that we decided to trust his opinion.

The consulting team led by Dzmitry dealt with the tasks of creating all the necessary project documentation, systemic immersion of new employees, and setting up processes very effectively. At the same time, the immersion was in parallel with the tasks that brought real value to the business, which allowed us to save both time and money.”

 Client's review of consulting
Senior Project Manager of a service company (the company name is under an NDA)
Get FREE checklist «How do you know if your project is in danger?»

Greetings! My name is Dzmitry Harachka. Specially for you, I have prepared a checklist that will help you determine if your project is in danger and provide a clear quantitative assessment of the complexity of the situation.

In the process of creating this document, I applied many years of my experience in managing, coordinating, supervising and consulting on more than 100 IT projects. Every checklist item is a reflection of the most common challenges I have seen in the development teams during my consulting practice.

Moreover, the checklist contains a large number of practical tips: this will help you move forward in solving problems on your own.