how to live with this and not go crazy
There is nothing wrong with striving for excellence when starting a business. But this does not change the fact that you need to be smart about your budgets and human resources. Especially if deadlines are pressing. One way or another, you will have to cut corners and save.
But not everyone realizes the importance of the principle of adequacy of the solution to the task at hand. I had the opportunity to work with such people – excellent specialists and, moreover, hopeless idealists. Under the cut, I will talk about my experience, combining the features of several people into one collective image.
Meet Leonid
I first met Leonid about 10 years ago, when I was just starting my career. He was a couple of years older than me, received an excellent higher technical education and seemed like a cool guy. When the burden of “working for his uncle” began to weigh heavily on him, he decided to open his own business in a similar niche. Formally, we were partners with equal shares, but at the same time, as a founder, Leonid had the right of veto and, it must be said, he regularly used it.
We got along well even before we started working together: common hobbies, similar views on the world. We met regularly over a cup of tea to chat. But as soon as we started discussing work issues, Leonid before our eyes turned from “his guy” into a tyrant and despot.
It was easy for him to burden me with three or four large tasks at the same time – only to be ostentatiously upset a couple of days later that I had not completed one of them. He could easily lose patience and transfer me from one project to another, simply because “the deadline for project A has passed, now we are doing project B.” At the same time, the degree of readiness of project A was not taken into account at all. However, first things first.
Idealist boss and idealist performer
From the above, you could draw a reasonable conclusion: Leonid is simply a disgusting manager. And there is certainly some truth in this. He accepted the role of boss consciously, guided by his ideas about correct and ethical business. At the same time, he was a truly cool developer. Every time I watched him work, I was amazed at his ability to find elegant and simple solutions to even the most complex problems. Sometimes we would do pair coding sessions, and within 10-15 minutes my brain would refuse to understand what was happening on the screen. In fact, Leonid in solo could work for two, and I was assigned the modest role of listener and syntax corrector.
However, the entire time we worked together, Leonid was burdened with responsibility. It seemed to him that if he was a good developer, he would be able to lead a team well and make informed decisions based on professional experience.
“Civilized” approach to working with people
Leonid sincerely believed that, as a boss, it was his responsibility to provide the best possible working conditions for his employees. “European level” of confidence in the future.
He really managed to achieve something: salaries, by hook or by crook, even in difficult times, were paid accurately and on time. The layoffs took place calmly and smoothly – with full payment for the hours worked on the project, even if after that it was necessary to roll back the changes in a week or two. The most productive employees received promotions every six months to a year.
At the same time, it was always difficult for Leonid to put his subordinate in his place. Instead of directly identifying the employee’s problems, he fussed, got out of it, finished the work for him and tried in every possible way to “sweeten the pill” if it came to direct confrontation. It was easier for Leonid to speak out to me than to scold an unscrupulous employee.
Strategic decisions
Leonid had a hard time making strategic decisions. One day he directly admitted to me that he did not understand where to move next. He rejected almost all of my proposals, because they either “would bring too little money, a drop in the bucket,” or “I don’t believe in it, we won’t do that, period.” His inner idealism told him that serious companies do not waste their time on little things like outsourcing or selling assets.
According to the principle “this is a bad idea,” proposals to sell ready-made plug-and-play software solutions developed for the internal needs of a startup, but potentially needed on the market, were rejected. Despite our precarious position, Leonid did not even consider outsourcing the development of other people’s projects. His employees were supposed to develop only “his” products.
However, this did not stop Leonid, for fear of losing an hourly employee, in the absence of objectively important tasks, from loading him with all sorts of slag: for example, writing modules for an online store, which ultimately never launched. The money invested in the project was spent by leaps and bounds (pardon the pun), but we were not any closer to making a profit.
“This is how a good company should work”
These words set me on edge even in the first year of our work together. Our “good” company produced software for mobile platforms. In parallel, 2-3 projects could be in development:
The flagship project – up to 80% of the funds were poured into it, all employees were involved in it.
“Alternate airfield” is a project with a much lower priority and a simpler development pipeline.
An experimental project is an MVP for testing hypotheses without clear launch deadlines and high quality requirements.
In addition to projects in active development, we always had several MVPs that passed the initial quality check for the future. It was too expensive to develop some of them into a full-fledged product. Some required 100% of Leonid’s attention, since only he himself could bring them to fruition.
Returning to the principle of “good companies” – due to an overabundance of projects, we were constantly in search of unnecessary specialists. So, Leonid hired with his own hands and after a month or two fired as unnecessary: two project managers, a tester and a designer.
Leonid saw the reasons for hiring as follows: we don’t have enough hands, and in order to make a high-quality product, we need separate specialists who will deal with specific tasks. This is common practice in good companies.
The problem was that we were a pocket-funded startup. We could afford expenses in the range of $10-15 thousand per year, but no more. Developers took the lion’s share of the money, even though we paid far from the most competitive salaries. Design and marketing consumed everything that was left.
I tried to explain to Leonid that spending extra money on projects that may never reach release just out of a desire to be on the safe side or not to lose an employee is, at the very least, unreasonable. But it was easier to stop the tank with bare hands than to convince it.
In my opinion, a “good” company can be called one that lives within its means and maintains a balance between making a profit and the comfort of its employees.
In general, my vision was like this.
The smaller the company’s turnover, the shorter the time-to-market its products should have. There is no point in cutting a monster project if there is a considerable risk of “bursting” before its release and first profit.
Non-priority tasks (for example, a business card website for a company) should be solved with minimal investments, just sufficient to complete the task. There is no point in immediately creating a multilingual store website with support for authorization through all possible social networks and online purchases, if not a single project needs it in the next year or two.
Leonid, even realizing the validity of these theses, could not come to terms with them. Even if the day before we discussed that it was unreasonable to spend energy on task N, after a couple of days he returned with a hundred reasons “for” its implementation.
“I’ll do it when I’m free”
As I wrote above, Leonid was a first-class programmer. He could work with anything from Python to assembly language. As a performer he was invaluable. However, he was completely unable to combine the roles of boss and core developer.
Leonid knew how to write excellent, optimal code. But it was not very easy for an outsider to understand it. Leonid created some modules himself, from scratch, due to the lack of ready-made solutions, and demanded that programmers use his work. Overall, a great practice if supported by detailed documentation. But there was no one to keep the documentation, so new people had to be trained manually, through regular multi-hour conference calls. On average, onboarding took us from two weeks to a month – and this was with a relatively modest code base.
Since we could not afford to hire developers with a rank higher than “strong middle”, the development of the most critical parts of the applications was assigned to Leonid.
It is important to say here that, in addition to the startup, both Leonid and I worked in parallel in other companies and did not intend to quit without having a successful joint business in our hands.
Already feel what the problem is? Not a single release could take place without the involvement of Leonid as a developer, product owner and ideologist. At some point, the development of one or another project was completely stalled, and with the words “I don’t have time now, let’s finish project N for now, Vasya can handle it too…” we put the almost completed product on the back burner. In fact, freezing the invested money, wasting time and demotivating the team members involved in the development. There was a constant dissonance in people’s minds between “let’s release as soon as possible” and “I’ve had a very busy week so I don’t know when I’ll be able to unblock you.” Money was wasted, employees were idle for weeks – or, on Leonid’s initiative, they were engaged in projects that were not destined to be born.
We got to the first releases only after two years of the startup’s existence – and these were projects in which Leonid’s participation was minimized.
“We need fewer features, but we need more features”
Featurecutting (cutting off unnecessary functionality for the sake of a speedy product release), in my opinion, is the most important skill of a businessman – and not necessarily in the IT field. If a feature lies outside the core functionality and requires significant investment, you should think twice at the start before implementing it.
For example, if you have an online store, you do not need to immediately enable support for all payment systems: one, the most popular, is enough. This will allow you to quickly test the hypothesis and, based on the results, either refine the functionality or completely shut down the project. You don’t need to immediately aim to support 100% of the features of market leaders – but you need to efficiently implement your own unique functionality.
At weekly collective meetings, Leonid demanded a report from us on the work done – and reported himself. In general, this is a useful thing: each team member knows what stage the product is at and can outline a work stack for themselves. But too often, at the instigation of Leonid, these meetings turned into a game of “who will come up with the coolest feature that we will rush to implement, having missed deadlines.”
Let me remind you that in words Leonid’s priorities were based on the contrary. However, I more than once caught myself thinking that Leonid suffered from something like stage fright: the closer we got to the release, the more often Leonid moved the date, explaining that the new feature would take us (allegedly) a week or two, but it can dramatically increase profits.
“I’m the boss – you’re a fool”
For a long time, our business was going pretty badly: the startup wasn’t bringing in any money. On the contrary, he sucked them up like a vacuum cleaner. Because of this, we both started having problems in our family. The fairer halves did not understand why spend money on something that does not bring profit.
Partly due to natural temperament, partly due to accumulated stress, Leonid began to lash out at me more and more often. This was expressed in toxic comments regarding my competence and demands to rewrite everything the way he sees and wants. I won’t lie – sometimes Leonid was really right. But often I received a slap on the head simply for implementing this or that feature differently than Leonid wanted. Sometimes he could criticize to smithereens even the application design I approved – if it did not satisfy his (very ascetic, “coder”) taste. The end employees received distilled, soft feedback, and the poison went to me. Having cooled down, Leonid certainly apologized. The situation never escalated into direct quarrels, partly due to the fact that at some point I learned to ignore the unconstructive part of his comments.
Afterword
As I already wrote at the beginning of the article, Leonid is a collective image. It is unlikely that I would be able to work with a person who collected a royal flush from all the qualities listed above.
Each of the “prototypes” of my hero achieved success. I continue to work with some to this day, and with others I maintain friendly relations. These are really good, worthy specialists. Some of them managed to overcome the “growing pains” from performers to managers. Someone decided to return to the comfortable chair of a senior or team lead.
Most likely, you noticed in Leonid the traits of your own colleagues, partners or bosses. This is neither good nor bad. Each of us handles the burden of leading a team and making strategic decisions differently. Some people shouldn’t take this path at all. Personally, I tried (and am still trying) to get the maximum benefit from communicating and working together with such people: learning not to make their mistakes, making difficult decisions – and pushing my future idealistic colleagues to make them.
Yes, it is extremely difficult to get along with such people. But if you succeed, hang in there. A sea of unique, rewarding experiences awaits you.
