In a world where only your own business can make you truly wealthy, people still choose to work for others. First of all, not everyone is happy being a businessman, and living must go on. Secondly, work is clear and safe — you perform your function, while most risks are taken on by others. This is where old, dusty conflicts arise: owners want employees to be motivated as if the job were their own business; employees want to do what they are paid for, and nothing more.
These classic relationships have variations — options, bonuses, which subtly remind us that owners and employees are in the same boat. But there are also more atypical situations.
Flant consists of several DevOps teams that provide turnkey services for external productions. They grew out of a group of enthusiastic students and Linux fans, and now have built a structure of 'businesses within a business', simply because it's more comfortable and honest this way. Dima Stolyarov and Sasha Batalov shared with us how it works.
Flant made it to the best IT employers of 2018 with 4.68. Judging by the company's ratings on 'My Circle', employees believe that the company is making the world a better place, and they appreciate Flant for interesting tasks, good relationships within the team, modern technologies, and communication with top management.
A gang of Linux students
Dmitry Stolyarov (Technical Director) during his presentation
— (Dima Stolyarov) We have always worked with Linux and open source, but we started with a rather amusing concept that we are a bit embarrassed about now. For some reason, we thought it necessary to implement Linux in offices instead of Windows. The company's first name was TrueOffice — 'true office'. Then we realized that nobody needed that. It was in 2006, I was 19. Only in 2012-13 did I come to understand how to run a business and what technologies the world needs.
Alexander Batalov (CEO) at the company's booth at the conference
— (Sasha Batalov) Besides technology, there is a huge aspect of marketing, sales, and economics, which no one ever taught us, except for university courses, but I don't know how applicable or useful they are.
At first, we thought all of this was unnecessary, but then we had to learn through practice, read books, sometimes after getting our bumps. In general, we took a long and thorny path, trying a bunch of wrong things.
— (DS) But gradually, as our qualifications grew, we specialized more in Linux, and now we only deal with high-load, high-traffic web projects. And when Kubernetes appeared, we quickly realized that it was the very foundation we lacked.
— What sparked your interest in Linux? Ideological or technological?
— (DS) The company has two founders — Dima Shurupov and me. Dima Shurupov was more interested in open source. I was drawn to Linux, technologically, by how everything was organized. It turned out to be a combination: Dima liked the ideology, while I was more focused on technology. I love open source as an idea, but the technological aspect has always been more important to me.
Einstein said: 'Make everything as simple as possible, but not simpler.' Linux is built so simply, reliably, and transparently that I enjoy it. We all liked it, and we transformed from a group of students into a large company. Now there are 70 of us. For IT and specialized services, that’s quite a lot.
— What were things like in the days of the student gang?
— (DS) Well, it was like it usually is for students — fun and lively.
— (SB) An enormous amount of altruism, a desire to conquer the internet, to achieve technological peaks. We engaged in very complex tasks — sometimes taking on serious (but very interesting!) projects in system integration, doing them for pennies. We tried to create our own frameworks, absorbed every technology we learned about, and immediately sought to apply them.
— Did it all work out commercially?
— (DS) Yes, but in the early stages, we didn’t need anything. At that time, a monthly income of 40,000 rubles was perfectly fine for me, I was living large on that.
— (SB) I thought that for a thousand dollars, you could create any website you could imagine.
— (DS) In 2013, we didn’t have the funds to hire freely in Moscow. We had already taken everyone we could from our circle. We decided to open an office in Nizhny Novgorod. We went there, set up, and started hiring. Later, we realized that managing two offices was tough, and we decided to operate without any offices altogether.
Of course, we made a lot of mistakes. Only in 2016, to my shame, did I read Remote. I cried and laughed because we went through the exact same journey. Every paragraph resonated with my personal experience.
— (SB) Every paragraph contained our scars.
What Flant does
We provide full-service management for high-load productions. This differs from regular outsourcing because we live with clients for a long time and interact very closely; people trust us with one of their most important assets. How we work significantly affects their business.To establish quality production operations, you need 15-20 DevOps, database specialists, Kubernetes experts, support staff, and so on. If the company is small, with only two or three dozen developers, this is impossible. That's where we come in to save the day. For about 150,000.
Previously, our mission was to create a company where we ourselves would feel comfortable working, no matter how silly that sounds. Now that we've achieved that, our mission is to make Google and Facebook-level technology accessible to small businesses and early-stage startups.
People can focus on their product instead of overcoming challenges that don't need to be faced.
Many of the people who come to us are surprised by how diverse everything is and the load everywhere. We have over 50 projects in production and more than 70 Kubernetes clusters. It’s always possible to complicate things. Open a drawing tool, sketch a microservices architecture, compile a list of 200 technologies — and off you go. But it always leads to problems and consequences.
The trick is to maximize stability, reliability, and simplicity on one hand, while on the other hand achieving a high level of innovation. We take pride in being able to do this. We do it everywhere and on a large scale, like a hypothetical Ikea.
Who needs DevOps outsourced
I think large companies prefer to keep DevOps in-house.
— (SB) It's clear that major players like Avito or Badoo can build their own DevOps teams. Small companies with huge investments can also do it — but while they can hire, it doesn't mean they have the strength to manage effectively.
We believe that even large companies are better off turning to experts who have extensive experience. Smaller companies, whose business relies on web solutions, simply must seek the expertise of seasoned professionals. Because any simple fault in a key system is a loss of money.
— (DS) We know that people in Russia are wary of outsourcing due to negative experiences and other reasons. However, our clients don’t leave us. Over ten years, they've only left for two reasons. Either they outgrew us (for example, they were acquired and everything was restructured) or they closed down because the idea didn’t work out.
— So who comes to you more often — small companies or large ones?
— (DS) Currently, it’s about the same. But small companies are simply afraid of us, thinking that we…
— (SB)… are large, complicated, inaccessible, and out of touch with reality.
— (DS) Well, yes, you walk past a dealership with a Maybach and don’t go inside or ask the price because it can’t possibly cost just 500,000 rubles.
— Of course, it can't.
— (SB) But as soon as it appears in car-sharing, people can afford to drive it.
— (DS) Yes, we’re certainly not a Maybach — we’re more like Ikea. We have made things simple, reliable, and affordable. Overall, the number of companies reaching out to us from the TOP-50 and small companies is about the same. However, we primarily target small businesses and mainly work with them, while we try not to collaborate with large ones.
— Why?
— (DS) There’s a lot of bureaucracy.
— (SB) In a large company, there are many levels at which responsibility is distributed, the feedback process is very lengthy, and often people start playing with technology: 'Let’s weigh this, let’s write a strategy, a plan for the year ahead, let’s do it this way, as it looks better for enterprise culture. This is how our practice has developed.' And thus, they start complicating things that can be solved through a simple, short path, where 80% of the result could be achieved by tomorrow. They take the longer route, without knowing if it will even work.
As a result, instead of established practices, we are reinventing the wheel, and the cost of technological solutions becomes disproportionately higher. Moreover, the quality is not necessarily better.
Outsourcing fees
We have a bunch of projects on GitHub, and we actively contribute to open source history. Not just our own — but others' as well. We strive to share the tools we use every day. We believe it's our duty, and we take great pleasure in doing it.Everyone in the company contributes in one way or another — be it through feedback, documentation, or code. We consider this our payment for all the great open-source utilities we use. And I believe we make this payment honorably.
We call this the condensation of experience. Initially, one person learned something, shared it with colleagues, and that knowledge became folklore. Then we documented it, and eventually turned it into utilities and forgot about its existence because it's all accounted for automatically now.
The popularity of technologies and the toxicity of developers
— Why specifically Ubuntu? What else was considered before it was chosen?
— (DS) We were just a bunch of students who liked Linux. We used Gentoo for a long time — it's a source-based distribution, and you have to compile it from scratch every time. When we had a couple of hundred servers, updates took months. Of course, we first automated and optimized everything, but eventually, we realized something had to change. Knowing the pros and cons of various solutions, we simply chose the most popular one. Back then, it was intuitive — since it was the most popular, it would develop best, and all shortcomings would be fixed sooner or later.
There was a database called Resync DB. They competed with MongoDB and started around the same time. For a long time, Resync was technologically superior.
When users came, they tried to solve internal systemic problems, and MongoDB did that much less, but could conditionally set up IF statements to perform better in synthetic tests. Therefore, MongoDB's popularity grew. In the simplest cases, they performed better, but internally they were lacking. Resync DB was good internally, but it didn't gain popularity.
In the end, everything internally improved for MongoDB, while no one remembers Resync DB. The company went bankrupt. It's a similar story with Ubuntu. This distribution has a lot of focus, which is why we decided to use it.
— What are your thoughts on the recent political changes, CoC, and all that?
— (DS) Well... there's no negativity, everything is fine, everything is clear. I myself struggle with sometimes hurting people. For example, I find something obvious, and it really frustrates me that others don't understand it. I get angry, and it results in negativity (but I'm working on it).
Linus is very smart; after all, he has been doing this for 30 years. It's clear that he's a blunt guy, not one to mince words. His politeness suffers, and the community is working on that. He understands it all and admits it.
— But, as I understood from the reactions in the discussions, many people support the idea of speaking directly and harshly, and if someone doesn't like it — they're not made of sugar, they won't melt.
— (DS) No, that's not true. As someone who struggles with a lack of politeness, I understand that it's very bad. It spoils the community. There are people who don't care, but for most people, emotional comfort is still important.
Here's a silly error in the code. You could say: "Guys, it's bad that we miss these simple things; we need to fix it." Or you could say: "What idiot did this?!" Just one phrase. The person who made that mistake might actually be smarter and more experienced than you, but was simply not in the right mood when they messed up — you never know what happened to them. And for them, it will be a direct offense. Why is that necessary?
You need to be direct, but you shouldn't say, "What idiot wrote this?" There's no point in hiding or wrapping things up, but you shouldn't hurt people's feelings either.
Why do DevOps folks need to call in every day?
— (DS) Right now, we have one small office where the documents are stored, and there's an office manager who takes care of those documents.
The company has 70 people. 20 people make up the OPS team. 30 people are three DevOps teams of about 10 people each. The remaining 20 are developers and sales. There are 8 developers, and the R&D department has 4 people. There are 5-6 non-technical staff for the entire company.
The key money is earned by the three DevOps teams. The processes are the same everywhere — a long meeting every day that lasts for an hour to an hour and a half. But they discuss all technical questions there, and the guys decide what to do next. And since everyone is remote, it's a chance to communicate properly.
— Is it really necessary every day?
— (DS) Yes.
— Is everyone in agreement on this?
— (DS) Yes, everyone agrees, everyone is comfortable. But on some days, the meeting can last 30 minutes. Despite the very intense communication on Slack, we still want to synchronize well and understand what happened yesterday. We want to understand each other, not just click through tasks. This is a culturally significant point.
— (SB) At any moment, something can happen, the situation can change. Continuous adjustment is necessary.
— (DS) Do you have a good joke on this topic?
— (SB) Yes. A heart surgeon goes to an auto center, and the mechanic tells him: 'Listen, we're doing the same thing, only you operate on a human heart, while I work on a car's heart. You get $10,000 for the surgery, and I get 100 rubles for maintenance.'
The surgeon asks: 'Do you want to earn 10,000 for repairs too?' The mechanic says, 'Of course.' The surgeon gets in the car, starts it, and says, 'Go ahead and work on it.'
It's the same with us. In development, you can take a task and deliver the result in two weeks. Everything can be adjusted later because a few days here or there don't have much impact.
In our case, every missed alert or incorrect decision regarding an alert can lead to a very big problem. To avoid this, we need close, quick, and constant communication.
Is it difficult to switch to remote work?
It's hard to manage people remotely. But it's difficult only as long as you're in one office and they are in another, and there's a sort of mental fog. You sit in Moscow and feel like the guys from Nizhny are not working well or efficiently. In Moscow, you see people's efforts around you, but you don’t see the efforts of remote workers. You only accept the result.
In the office, a lot of communication happens in an informal way — someone says something to someone else on the way to the kitchen. People in another office don't see that, don’t feel it, and the context gets lost.
By the time we were ready to give up the office, all communication (even among employees in the same room) was happening over Google Meet. And once we structured all remote communication, it worked 100%, all barriers of misunderstanding were removed.
Building everything is challenging, but if done right, it works and doesn’t cause any discomfort.
How teams manage their own finances.
Remote work is a controversial topic. Sometimes companies hesitate to let people work from home because they fear losing control over them. However, those that do allow it also say that work needs to be done quite differently.
— (DS) We have solved this problem by being ready to share finances with teams. Our economy and motivation system are built almost like a franchise. Salaries are quite high, plus we leave the team with discretionary funds.
The team services a pool of projects. They know how much each of these projects generates in revenue. They are fully aware of their share of that money. All funds that remain beyond their salaries stay with the team and are distributed among them according to a specific system. The motivation is completely straightforward — they take on a project worth an additional 200,000, and they get an extra ten in their salary. Made a mistake? They have to compensate the client.
— (SB) If you start letting the team down, it becomes immediately noticeable. You deny yourself the opportunity to earn additional income. Our system completely solves the control issue. Each person makes a plan for their day, and daily meetings are enough to understand who is doing what.
— (DS) In a combat situation, comrades in the trenches don’t lie to each other.
So, do you have open salaries? Does everyone know how much everyone earns?
— (DS) We closed salary information some time ago. There is a regional difference. Even though we aim to pay salaries equivalent to Moscow wages in the regions, there is still some dissonance.
— (SB) Now everyone knows how much money the team has in total. They can see their share of the bonuses.
— (DS) The team lead decides how much their guys will get and how bonuses will be allocated. We only provide advice on this matter; the final decision always rests with the team lead.
Why do people fear job vacancies?
Celebration of the company's 10th anniversary in 2018.
Is 70 people enough for you?
— (DS) No. Our plan is to hire at least 20 DevOps engineers this year. But it’s very challenging. We have a sufficiently large pool of candidates, and everyone knows about us one way or another. However, it's like with clients. Many say, 'We are afraid to work with you; what if we can't handle it?' But we don't think we have anything out of this world.
Correspondence with a candidate.
What does one need to be like to keep up?
— (DS) Theoretically, a person should be well-rounded in both development and operations. In practice, there are only a handful of such people in the world, not to mention in Russia. Especially those who are senior in both fields. I wouldn't even include myself among them.
In our job postings, we always clearly outline what is needed. We put a lot of effort into them and strive to be straightforward.
— Could it be that the job descriptions actually scare people away by detailing everything that is required?
— (DS) No, no, no, we don’t think it's necessary to know everything.
— (SB) What we’re interested in is not just knowledge, but thinking ability and a person's capacity to find solutions.
— (DS) We look for experience in Linux, and we check this with relatively simple tasks – just a large number of them. Our test is quite lengthy; it takes an average candidate about 8 hours. By the end, we assess how the person dealt with problems, how they search online, and what their overall perspective is.
Knowledge can be quickly acquired here since we have numerous different projects and experienced colleagues who are always willing to help. Therefore, we primarily look for individuals who can think quickly and have relevant experience.
— Apart from the test, do you identify this in any other way?
— (DS) We have three phases. First, an HR representative speaks with the candidate and asks about their experience. Then, those who impress the HR go through a practical task. Finally, the team leads discuss their opinions with HR, and if they unanimously agree on a candidate's suitability, that triggers an offer.
500,000 rubles to hire the future superman
— (DS) We have a very unconventional approach to finances; we share profits with the teams and are not stingy. Additionally, we allocate 500,000 rubles to the team for expanding their staff. This is essentially a grant so they can find someone and train them while that person gets onboarded.
— 500,000 per person?!
For the team to earn a significant amount of money, they need to take on more projects. To do that, they need more people. And to bring on more people, they need more money. It’s a vicious circle. To break this cycle, we provide funds for a new hire. While they get integrated, the team can take on more projects and pay the newcomer from the earnings. Essentially, it's compensation until the new person starts generating revenue.
— Isn’t that quite a lot for DevOps? They are overloaded daily, constantly in a high-pressure environment, and now they also have to handle financial management.
— (DS) This is handled by the team lead, who is no longer quite a DevOps. Team leads tend to move towards partnerships to have options. Therefore, we consider this normal for them. However, this does not apply to the regular members of the team.
Roughly speaking, they know that if a colleague drops out, they receive their salary the following month. Of course, they'll have to work more. And when they find a replacement, they give that money back.
When we give team leads 500,000, they don’t want to hire someone who won’t deliver results. Sometimes it’s easier for them to filter out 20 candidates and select one. There were instances where 100 people talked to HR, 30 went on to the technical assignment, 20 passed, and the team lead filtered out everyone except one. It’s tough. Team leads are very afraid to take risks. We discussed this topic, and everyone seemed to understand it's a mistake. Many people show themselves differently in an interview than how they will work later. So we need to give chances and take risks.
— But don’t team leads start to take advantage? You receive 500,000, don’t hire for a long time, and get another 500,000.
— (DS) They receive the money only once. We say, 'You currently have ten people, but you need 11. There’s a sales plan, more projects will come in, and you need to be ready. Here are 500,000 for the eleventh position.' You won’t get this a second time. If someone leaves, it becomes the team's problem, and they resolve it within their budget.
It’s like playing Monopoly.
— (SB) We believe that the team lead should be involved in finances. Our people receive their salary from the money they earn. The extent of project expenses is very important. A client comes with one infrastructure, and a year later, their infrastructure is ten times bigger. If the team lead is not involved in finances, he won’t be able to adequately assess the service costs.
— (DS) Sometimes the team battles client issues for months, realizing that they are being paid a conditional hundred thousand, which does not reflect what’s happening now. No matter how painful it is, they need to either raise the price or part ways. And the guys make these decisions themselves, even while working remotely. We consider this our significant achievement. We truly have autonomous, motivated teams.
— Yes. It sounds like you have to be a superman to work here. You need technical skills, self-discipline, and financial literacy.
— (SB) We can turn you into a superman. But even those team leads who can do this started out as ordinary engineers. It usually takes a person a year or two to transform into such a superman.
— Partner team leads have grown from regular engineers. Can someone be hired directly for such a position?
— (DS) We haven't had that yet; everyone has grown from engineers. However, we are considering merging with a small company that would become just another one of our teams. We would like to try that.
— Can you take a person if they are a good engineer but not organized enough for such teams?
— (DS) We are not afraid of disorganized people; we have a flow of tasks. It quickly becomes clear if we can help someone get organized. If they share what they did every day without actually accomplishing anything, they will feel embarrassed.
When you see that everyone is in the same boat and rowing, it feels uncomfortable to drop the oar. In such conditions, even disorganized people become organized. If they don’t, then they don’t.
We cannot stand superficiality — in people, in work, and in ourselves. Once people get here, they develop very quickly, three times faster than anywhere else. We genuinely experience a year’s worth of growth in skills and experience in just three years.
We really do not like superficial mid-levels. From our perspective, a mid-level is someone who can do a lot already. To be honest, the DevOps market is terribly blurred. There are mid-levels who think they're juniors and juniors who think they are seniors. When someone joins us, they quickly understand their actual level.
This doesn't mean we don't hire juniors — we happily do, and we will take even more. We are already creating a special team called "DevOps Accelerator" and allocating projects where we can take risks, where the client is ready for us to take risks. There will probably even be a special service for this, something like "Flant Light."
— Would you like to become a big corporation?
— (DS) We would like to, but with one caveat. We really don’t want to lose our culture. We will definitely grow, but preserving our technical and work culture is even more important than growth itself.
We only have one life, and we can't earn all the money in the world, but we want to live it alongside good people. We categorically reject bureaucracy and the simulation of productive work. Our connections are completely horizontal. One can convey their thoughts to management even in the most direct manner: essence is more important than formalities.
— (SB) But for that, you need to have very strong arguments.
— (DS) Certainly! And remote work is also necessary because that's how we live, that's how we see the world. Dima Shurupov lives in Thailand, I live in Germany. Sasha Batalov is in Moscow, and the HR director is in Tyumen.
We believe that living on this planet means wanting to experience life fully. It’s unnecessary to work in an environment that you dislike. That's why we want our workplace to be enjoyable. Conflicts at work are certainly unpleasant, so we create an environment without them. We have debates and discussions, but not conflicts.
— Don't you think that becoming big means not only providing services but also producing? That it's necessary not only to live life and see the planet but also to leave something behind?
— (DS) This is a very sensitive topic for us because we are a service company. But we produce a lot of software, and essentially our product is services with completely different effectiveness. We have never sold hours or people to anyone. Clients always come and ask, "Can we buy a hundred hours?" No, we can't, we do not sell hours.
We sell results. The result is that we alleviated pain and solved a problem. And we solve it not the way we were told, but the way we know how. Our product is our experience. And we will certainly create ready-made solutions, SaaS products; there are many ideas. But there is no rush. Many decades lie ahead.
Source: habr.com
