Lessons from 6 years of Building a Tech Company
I feel insanely nostalgic as I write this a couple of weeks after my final decision to exit FlowUp. I’ve been building FlowUp with my two co-founders: Albert & Vojtech. I find it hard to find words for gratefulness I feel for the chances I’ve had over more than six years with these guys. Thank you.
This article is not a tutorial nor a guide. I write this to reflect on my actions and sum up the essential learnings on my adventure, from being an engineer to learning every day how to be a better leader. Take it if you like it; blame it if you don’t.
Why the exit?
There are two modes in my life: when I mostly take (learn), and the other when I mostly give (teach). These two modes oscillate. I love sharing experience and leading people through what I learned & discovered. I also expect the same from others. The trouble begins when I am stuck inside the giving mode with nothing to give. Six years in, I took & gave everything I could, and it’s time for me to depart on a new adventure.
❤️ Lesson 1: People don’t care how much you know until they know how much you care
That is a quote from Theodore Roosevelt, and I apply it to all kinds of relationships, from personal to business. In my early years, I was a result-only-driven person. My personality worked fine with people I already had established friendships with outside of work. However, once we started hiring people I’ve never met, it took me quite some time to realise that caring foregoes results. People won’t be motivated to make results if they think you don’t care about them as a person.
From the business perspective, I was the “just give me the problem, and I’ll solve it” guy. Nowadays, I know people will give me their headaches to solve only if they genuinely trust me (or are so desperate that it’s a lift straight to hell). Before even starting to think about a solution, I want to make sure all people in the room listened carefully, understood the problem, asked their questions, and are on board with the vision. It shows that we care and builds trust. It’s counterproductive to fake caring (as in my job is to sell, not care) because any solution will inevitably fail on people in the long run if they don’t care.
🏁 Lesson 2: Take people on a journey, don’t send them
We’ve hired many people across those years (peaked at ~50). My previous misunderstanding was that because I love going on a journey to a potential discovery (both: alone and in the team), everyone will be the same. So I made journeys for everybody, giving them challenges to tackle and come back to me if they discover something — thinking I gave them the best I could. People love journeys and challenges, but they need to be their journeys and their challenges. Otherwise, it’s just a task from a boss that probably leads nowhere.
Journeys can all work just fine. However, for them to work, I need to be with the team, leading the journey. Being there transforms the journey from “being on a random journey somebody gave me” to “being on a journey with people I care about to discover what we care about”. People suddenly become productive, happy, and innovative when taken on a journey instead of being sent.
⌛ Lesson 3: Make selfless actions
For me, this world is not about helping others to the extent we expect them to help us. It’s about making a positive change. And whenever something changes, mistakes are made — and everything that can go wrong will go wrong — Murphy’s law.
There’s no preparation for the unknown. It’s critical to take actions that benefit my teammates and even more crucial not to expect them to return the favours (more often than not, they will come naturally). And if the storm comes, I know there will be hands-on-deck because we care about each other and the vision we are pursuing.
If you’re reading this and thinking: “I cared, but nobody cared back when sailing through the storm”, ask yourself: did you take the risk with the team or on their behalf? Deciding without the explicit consent of the group (e.g. enforcing deadline, promising undiscussed, or taking random actions) can destroy any trust built across the time.
✨ Lesson 4: Sacrifice the good to go for the best
I could probably write a book with 400 pages that have my ideas and their positive impact on whatever I was tackling at that moment. That book would also have a companion of 100 pages with times this behaviour paralysed me.
It took me time to realise that I am never going to catch up to this idea backlog. Starting everything and finishing nothing is nice training but brings very little value. Opportunities lie everywhere, and if we give it time to think, we’ll always end up thinking that our current idea is the best one yet. So I built myself a system with a couple of rules to follow:
- Call/email a potential customer. Can’t do it? Maybe there are far more catches when we look into it from the customer perspective. Or, the idea is just a SISP (Solution in Search of a Problem) — a.k.a. waste of time.
- Ask the customer what’s stopping them from resolving the problem. This question clarifies their specific issues (e.g. not worth it, no time, missing talent/specialisation, etc.), and the same questions need to be answered by myself.
- Build a Wardley Map for the product migration. Mapping helps understand dependencies and their maturity, and thus the cost that could be in/directly incurred by the product. The more the product is a drop-in replacement, the better. However, I often ended up with a good product but wrong timing (e.g. targeting companies working in a proper DevOps environment — not the one everybody uses in their hiring materials)—context matters.
If these steps are successful, I want to start looking for sponsorship with executives. Otherwise, the idea might be excellent, but it’s hardly worth pursuing.
💡 Lesson 5: Faster is slower
I love technology—the more futuristic, the better. When we started as a team, we’ve had our bare-metal running in a dorm room. Then it was six months to start using containers, six months on IBM Cloud, a couple of months on Azure and AWS clouds, and two years in, we’ve settled on Google Cloud. Three years in, we migrated to Kubernetes, which was starting to be popular. I could go on.
There’s probably no need to continue to get the idea of my obsession with new technology. Even though I am more than happy where we’ve settled, I know this never-ending adoption of new technology slowed us down.
As we grew, I learned the hard way (read: I made people mad) that significant technology switching has a tremendous cost on people’s morale, requires full sponsorship on the executive level, and takes years to return the investment. It needs to be handled with care, a vision that everybody understands, and a concrete execution plan. I called it agile, but it turns out there’s no agility without a plan, measurement, and direct feedback. There’s no way to wing it.
⚔️ Lesson 6: Never leave the arena
Lastly, I’ve learned that experience decays in months. An engineer has little idea about a code they wrote six months ago if they don’t maintain it. The same applies to tech leads, product managers, or executives.
After hiring 10 people, I found myself reviewing work more than writing the code. After 20, I was only reviewing occasionally and started focusing on what I called strategy. For the first months, I was helping with inventions (automating processes, helping teams deploy reliably, setting up new projects automatically, and standardising our work). However, my work later became more and more theoretical (teams implemented those changes by themselves). Things went south when I started innovating on top of innovations that I didn’t implement nor lead their implementation.
It took me a couple of weeks to get back to a spot where I could lead the changes myself and start inventing tools that help practically, not only theoretically. It’s critical always to own ideas that we want to execute, and as said in Lesson 2, take people on a journey.
The same idea needs to apply at the level of people management. Either fight beside them or don’t make decisions on their behalf.
Final Words
I have one too many influential people in my life that helped me, and I am infinitely grateful for them. I also strongly believe they know about their influence in my life. To all of you: Thank you for your support. This is not a goodbye, of course.
In case you’re wondering where I am continuing my adventures — I don’t know yet. In the meantime, I am actively looking and doing things I didn't have time to do in the last months (spending time with myself, reading, and learning new things).
Feel free to contact me on my LinkedIn with questions or interesting adventures :)
*mic drop*
