Lessons from 6 years of Building a Tech Company

Lesson 0: pools with plastic balls are fun.

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?

❤️ Lesson 1: People don’t care how much you know until they know how much you care

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

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

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

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

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

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

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*

I like lasagnas

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store