Bubbles That Had to Burst: My First Steps as a CEO

One professor used to say that two programmers are slower than one. I didn’t believe it until we started working as a team at PrestaRock. It turns out it’s true! And it’s probably not even about programming itself but about work in general—when much additional effort is required just so someone else can do what you already know how to do. I didn’t consider this before founding my company. What other bubbles have burst for me?

As soon as I started working from an office, after the initial euphoria of being the head of a company, I quickly realized that Skype chat and conversations were not enough to assign and describe tasks adequately. Everything got lost, disappeared, became unclear, or was forgotten.

Since I was still reading many blogs then, I had heard about newly emerging tools like Trello and Asana, which were probably in their first versions when we started. After trying out just a couple, I based my choice on one criterion: writing down a task should be no more complicated than writing it down with a pen on paper. Naturally, my choice became Asana, which we still use today.

If you want someone to complete a task correctly, you must describe it clearly, structure it, agree on checkpoints and deadlines, define the expected result, and establish evaluation criteria. This is a typical delegation. But remember, I was a fourth-year student who knew nothing about this. Would a five-word task description be enough for my new colleague to complete the job? I sure did! Did it work? Not!

While finding a project management tool or, later, a time-tracking tool was relatively simple, developing soft skills took me a good three to four years after founding the company. I had assumed that everyone was just like me or, at the very least, like my former colleagues—who were always more experienced than me.

At the advertising agency, I learned from a great and well-known radio host and a project manager who understood marketing inside out. At a U.S.-based company, I learned programming from specialists with years of experience, who were nearly twice my age and had as much knowledge as I had years of life. I was in a bubble.

For example, my company’s first employee had a chronic tendency to be late. It was his first job, but probably in his entire life, he had never once arrived at work by 9:00 AM as scheduled. He always arrived at at least 9:20 AM, sometimes even 9.40 AM. And when I asked what happened, he said he couldn’t make it on time. No reason. Just did not get up early.

I had grown up with the understanding—from my parents and others—that if you wanted to have tea before work, you’d arrive at 8:45 to have time to prepare it so that at 9:00, you’d already be sitting at your desk, ready to work. Believe me—those first weeks were shocking. My naive business mindset at the time made it worse: every minute of an employee’s time should be used for work, and if they did anything else—even for a moment—that was a loss.

Arriving at 9:30, leaving at 18:00, and constantly taking longer lunch breaks—I thought he was trying to deceive me. I was young and foolish.

Interestingly, in my entire ten-year career, I’ve never had another employee who was late for work. But how do you solve such an issue? Like with project management tools—I had no idea what to do. My first reaction was anger, a strict tone, and a “talk” about how he “must” be at work on time because “that’s how everyone does it, and that’s normal.”

Fact: such conversations don’t work.

At that time, I had never heard of agreements with employees, setting boundaries, or workplace expectations. The most frustrating thing was that no matter how much I scolded or criticized him, his behavior never changed. It couldn’t have changed. All of this didn’t help build a good relationship or boost my confidence as a leader. I was the boss! He had to listen to me.

The third bubble burst when we tried to hire a third colleague about six months later. I realized that not everyone would be like me when a new junior programmer wrote code not inside methods in classes but between them.

He said, “My code isn’t working, and I’m getting weird errors.”

I couldn’t understand what I was seeing when I went to check. Even today, I struggle to find a good analogy for a non-technical person. Imagine someone needing to vacuum a carpet but standing there, staring at the ceiling, saying, “I don’t understand how to vacuum the ceiling with this vacuum cleaner.” It was a disaster.

That’s when I understood that not every hire can or will be a programmer. After talking with my second employee, I realized he had entered IT solely because of the promise of a high salary. He once told me, “I love history—I don’t need to study it; I just get it. But I want to be an IT specialist because even if I’m bad, I’ll still earn more than a good historian.”

And in that moment, my world stopped for a few seconds.

Information technology has been my life since I was 13 or 14 when I installed DOS and dreamed of owning a computer. Meanwhile, my colleague, with whom I had already worked, made many mistakes. Despite having discovered IT similarly to mine since childhood, he was careless and lazy and, like many programmers, hated testing and verifying his code.

So there I was, with my overly confident ego, no proper delegation tools, and two employees: one in the wrong field and another sloppy, unpunctual, and challenging to communicate with. What a fantastic start, right?

In summary, when you have no background in management, business administration, or leadership and business “happens,” you lack not only essential tools like communication, task management, and tracking software but also essential soft skills—how to work with people, what to say to them, how to say it, and how to communicate effectively. I understood that I needed to have some soft skills only after two or three years of having a company.

Not to mention that a hiring process shouldn’t just involve a quick chat and deciding to hire someone because they look decent and seem all right. It does not mean he will be a good specialist if it looks normal.