Introduction
Around 66% of tech projects fail due to budget, timeline, or expectation issues. Some never get completed at all. Why is that? Syberry believes the main reason is poorly structured processes. They are developing the DaVinci technology, which will finally streamline the work of production and other teams within companies.
DaVinci is being developed by a team of engineers at Syberry. The platform's creators believe their technology can improve the quality and speed of software development by at least tenfold.
We spoke with Paul Vasiliev, CTO and Co-CEO at Syberry, and asked what approach to organizing work processes could save the software engineering industry, what the DaVinci engineers are currently working on, and who they are looking for to join their team of superheroes.
Why is the project failure rate so high?
Our industry has been around for decades, but not as long as others like construction, medical engineering, aerospace, etc. We are at a stage where we have learned to find talented people, assemble them into teams, and set goals for them. Then we tell them, "Go ahead, work your magic, develop what you know how to develop." Success is heavily reliant on the talent of individuals, and the correlation between a team's competence and success is high. However, there is almost no specific guide or methodology to consistently achieve stable results with people of varying competence levels in different contexts.
I usually ask candidates during interviews: "Imagine that airplanes were built in the way we develop software. Would you fly in such a plane?" No one has ever answered yes to this question.
Planes would crash, and people would die. This is a significant enough cost of error to understand what went wrong, improve these processes, and minimize these errors. The same process happens with software, but we believe it's happening too slowly. Our company's goal now is to help the industry mature as quickly as possible.
Is it all due to poorly structured processes?
If you ask people working in the industry about the typical problems they face, they can list a whole lot — and you can create huge checklists of potential risks. The question is, what do you do with these lists? Do you create a document with a thousand lines, give it to the team, and tell them to solve the issues? Most likely, people will ignore most of the problems and continue doing things the way they are used to.
The only solution, then, is to take each element from this list and incorporate it into tools, practices, and processes that people will then follow. In simple terms, to create a set of technologies that make it impossible to do things wrong. That's what we are doing with DaVinci.
How does this work in practice?
Take an example: how to organize meetings and calls. You often hear that a lot of time that could be spent on individual work (coding, requirements, design) is wasted in meetings. Many of these calls are indeed pointless.
Let's assume a company consciously addresses this issue and creates rules for conducting meetings. But what ensures that a company of 200-300 people will follow these rules?
The simplest way is to write a document, post it for the entire company, and say, "Folks, here are our new rules, follow them." Some will misunderstand the rules, some will ignore them, some will forget, and within a few months, the rules will be forgotten because people will have other more pressing tasks.
Now imagine you have a technological solution that allows you to tell the system: I need to solve this issue, and I need this person for it.
The system itself finds available slots and plans calls according to the rules (e.g., ensuring they are not back-to-back and allowing time for breaks). During the call, the system records your discussions using AI technology, highlights the main points, and assigns tasks to people based on what was discussed in the meeting.
Imagine how many routine tasks this removes from one person, and then multiply that by a hundred, a thousand people in the company. It frees up a huge amount of time for people to use creative ideas and their implementation.
How has this already changed the company's processes?
We have already made many changes to the company's operations. Recently, we transitioned the entire company to weekly cycles. Most companies operate on two-week sprints. We concluded that a one-week cycle is optimal. We recognize that some people might be so opposed to this that they are not willing to work at the company at all. Others will agree with it because they see the logic and positive effects of this approach.
Currently, we are working on many other aspects: proper CI/CD, eliminating manual testing, systematic architectural design, etc.
We focus less on people's emotions and more on whether the new rule will lead to faster achievement of goals, and we experiment accordingly.
Why was DaVinci created for internal use?
When a company is small — 10-20 people — establishing processes is not difficult. But as the company grows, the quality inevitably starts to decline. Then management starts thinking, okay, we need to do something to maintain quality while continuing to grow, we need to focus on processes. This is when process consultants and process groups come into play. But a very serious problem arises — neither consultants nor groups have real influence to make changes in a large company. There are already departments, management hierarchies, and managers with their KPIs. Imagine you're a recruitment manager. You already have metrics on which your salary or bonuses depend. Then a Process Engineer comes to you and says: you need to change how you do recruitment. This change will worsen your metrics, but it will improve the company's overall performance. The question is: how many managers will agree to this? Therefore, a large company due to its inertia will remain in local optima, making major changes very difficult.
What did you do differently in DaVinci?
We made process engineering the core of the company. Essentially, DaVinci as a product, as a system and technology, is the owner and guarantor of the process. The effectiveness of the processes is not the responsibility of department managers but of the DaVinci team: because they design, implement, monitor, and continuously improve them.
Why create your own product when there are many others available?
When I say "product", I don't mean we created process automation technology. It's a product that helps systematically apply these technologies to building an engineering service.
We don't write our own business process engines; we use existing tools.
What processes can be currently managed with DaVinci?
There are deterministic and less deterministic processes. For example, onboarding a person into the company is a deterministic process with clear and predictable tasks: preparing a workspace, signing documents, showing the office, and so on.
Most administrative processes fall into this category, and therefore teams have been working with DaVinci for a long time.
For some processes, it doesn't make sense to define the order of tasks. For instance, in the sales process, it's very difficult to establish a sequence; however, there are a set of conditions for a sale to happen, and the order or actions needed to be taken are not as important.
Production processes are also non-deterministic. Naturally, there is no answer to the question of the order in which things need to be done to produce software. But there are still working methods and practices, which, when applied systematically, can yield more predictable results.
One of the tasks we are currently working on is the ability to guarantee the delivery of an MVP within 6 months from the first contact with a client. This is quite a serious commitment. We realized that to achieve this goal, we need to optimize the entire chain, starting from the first contact with the client. We cannot look at marketing, pre-sales, and production separately. It's a single chain and needs to be optimized. We need to understand where time is lost in discussions and waiting stages.
Which teams are already successfully working with DaVinci?
HR, recruitment, finance, marketing, sales, and production teams.
How has DaVinci helped automate production processes?
Initially, we asked ourselves: where does the production process begin? For example, is assembling a team a production process or not? It's debatable.
Therefore, we don't strictly define this boundary for ourselves. We have already automated many processes: team assembly, onboarding, project initiation, lifecycle management, and configuration.
We ensured that on the first day of the project, people weren't setting it up, configuring tasks in the system, or creating code repositories, but were instead bringing concrete value. And a week after the start, they show increments unique to that product.
Typically, this is how it happens: the team starts working, a month passes — they've developed a bunch of features, but these are features like login, password reset, home page, etc. None of this brings unique value to the product. All of this should already be ready when the project starts.
Now, when we start working with a client and realize at some point that the likelihood of starting is high, we do a pre-start. Repositories are set up, CI/CD is configured, infrastructure is prepared, necessary tasks are assigned, and requirements are organized so that people can read them, familiarize themselves, and ask questions.
Thus, when people begin working on the project, they are already doing something unique.
You decided to deliver an MVP in six months. Are there any cases where this has been achieved?
Yes. We recently completed a mobile application for a client within this timeframe. The case itself is not particularly inspiring, but what is more inspiring is that we were able to significantly restructure the production system. The next stage of development is to make this statistically reliable.
How much time did it usually take to create an MVP?
It usually took between 9-12 months.
Was there any feedback from the team that worked on the project?
Formally, there was no feedback, but informally, people shared that they enjoyed it. This was a bit surprising. The work was intense, and we thought that such a pace might be less enjoyable, but it wasn't. People like working in effective, productive teams. It's important to maintain a pace that can be sustained long-term, without burning out in a month. Productivity is a matter of focus, not the amount of time spent.
Tell us about the team working on DaVinci.
Currently, there are eight people on the team. All are engineers. They have diverse backgrounds: there are DevOps, Process Engineers, and developers.
The task of the DaVinci team is not to deliver software and code but to ensure the company operates in a process-oriented manner.
Who are you looking for to join the team?
We are looking for System Analysts who are ready to be responsible for goals such as delivering an MVP in 6 months; and who are ready to design processes, software, and organization. We are also looking for an Engineering Manager to help implement the right practices across all company projects, and Java Developers: from strong Juniors to Solution Architects — there's a lot of work.
The most important thing for us is an interest in the task. Without this, it will be difficult to come up with solutions. The things we do are more complex than purely technical solutions because they involve people.
Whatever processes we come up with, ultimately, they will be carried out by people. We must think about the client experience. And our clients are the people working at Syberry. Therefore, our task is socio-technical. Some talented engineers are not interested in thinking about other people. They might create great technology and then watch as it doesn't work in people's hands. We don't need that. In our view, this is not great technology.
Are you looking for engineers specifically for the product, not for projects?
Yes, we are looking for people specifically for the DaVinci team, but there is one dilemma. It's impossible to design good processes as a theoretician. A person needs to experience some things in practice and bear the good and bad consequences of their ideas. Many things require practical experience in production teams.
Imagine we are creating a process for system architecture design. How do we understand how to form this process? My answer is that without going and engaging in architectural design and then abstracting the process from that knowledge, nothing will work. It’s impossible to be isolated from production teams and create tools for them.
This doesn’t mean that you need to go and work in production teams, but you need to interact with them. Let’s say we start designing a new process. For a person to understand the details of the process, they need to work on a project.
Tell us about the team culture and conditions.
There is one criterion that is relevant for the entire company — to be useful for our clients.
Logistically, we work remotely. However, there is an option to work in a hybrid format or from the office in Minsk.
What is DaVinci working on right now?
Delivering an MVP in 6 months is our main goal this year, but it is also part of a broader objective. We want to learn to work in a way that makes our production teams measurably and visibly more effective than the internal teams that clients create for themselves. To achieve this, we will need to work on many complex things: a platform for production projects, the implementation of engineering practices, tools for structured task management for the entire company, automation of routine operations, and so on.
Do you really believe that DaVinci can make the world better?
We are working towards a specific goal that we find interesting and important. We believe in this goal enough to invest our time and money into it. More precisely, 10% of the company's resources. Will it make the world better? I don't know, but I’d like to believe so. We approach this more practically — it is a sufficiently complex and interesting task that we want to work on.
