Oleksandr Taran: From Idea to Implementation - Lessons in Startup Leadership Search

Leszek Knoll

My name is Leszek and I will be talking to Oleksandr Taran about challenges, strategies faced by ctos in startup environments. I'd like to start off with briefly going through your career and your professional journey that led you to your current role, which is CTO at Frienton. Could you walk us through that briefly?

Oleksandr Taran

I started around 15 years ago as a software engineer, started working for different companies, small companies and big ones. And I already worked when I studied in the university in Ukraine and France. And already at that time I understood that I want to combine my math computer science background with building of it products. Of course, the IT staff and products themselves has developed in the last 15 years quite a lot. But as old people, I started as junior developer, went through different career stages. Being junior middle senior software engineer, I worked with or in small and big companies around ten years, and within the ten years I became a software architect. In order to reach that point, I spent lots of time on analyzing other products you can find on Internet.

There is quite some stuff I researched how Google, slack, Shopify, all those things were built. And in parallel, of course, working in the companies, it gave me all the things I needed to understand how to build different kind of systems, how to design them, what parts do I need, what kind of interfaces, what kind of databases, what kind of people are needed for some of the teams, yes. And eventually, after those ten years, I started speaking with friends of mine, with just acquaintances with people about the ideas that I'd like to become a CTO. It was time, I felt, for me to try out new things, new challenges for me. So I spoke with people and spoke with people, just drinking beer with some friends of mine. People mentioned that there was a team looking for a CTO in a startup, and I spoke with people, drank another beer with them, and eventually that was my first startup where I joined as a co founder and a CTO. At that point we bootstrapped a lot of.

So it was around five years ago, I had experience within that startup with Kickstarter campaigns. So it was a combination of bootstrapping, constant bootstrapping, parallel projects for some clients in order to earn money, and building products for Kickstarter users who backed up our product at that moment. And I was, or we were building the product for two years, eventually sold it to one of the companies on the market. And three years ago, also by coincidence, playing sports with friends, I decided to join a group of two Germans and an Australian guy, all being based in Europe right before Corona started. And we decided to found the company where I am a CTO now, Frienton. We are a Munich based company and we help simply set, we help startups and SME's to remove the hassle around business administration and financial administration. So every company has banking problems, bookkeeping account in Texas, and all this stuff is the backbone of the company.

So we built a product around all that stuff. We take over these problems and let eventually the founders and company managers to concentrate. We let them concentrate on the product instead of on their taxes or on their bookkeeping. So at the moment I'm second time CTO, trying to mix my CTO role with doing due diligences, technical due diligences for other startups. And this is the second thing I'm doing at the moment because it's interesting at first. 2nd, it's quite useful to see how other startups are built. And third, of course it's kind of networking that I can, where I can grow.

So I constantly meet new c level people. And as a CTO, as a technical person, it's usually quite challenging to expand the network on the business level because most of your friends or acquaintances are developers from the past. You spend years in the office, coding, speaking with developers, whilst business people spend those years, yeah, building networks, communicating, going to conferences. And as a developer you go to technical conferences where you meet technical people more or less. And that's why for me at the moment, this mix of a pure CTO role in a startup and doing technical due diligences for early stage startups is a perfect match where I can develop my skills as a technical leader as well as grow my network in all the directions.

Leszek Knoll

Do these cooperations with other startups go beyond due diligence? Something like a fractional CTO or a consultant? How do these develop?

Oleksandr Taran

I was thinking about that, but at the moment, until now it was only pure due diligence. TDD I don't have time and energy at the moment to deal with to be a fractional CTO, for instance, or consult, because being a CTO or being a founder of a startup requires your hundred percent to 100% concentration. And if I try to get lots of things done at the same time, I would lose a concentration. And this is what I learned in my first startup. Try to concentrate on one thing, on one big scene constantly, because if you consult three days per week somewhere to earn money, and then you spend two, three days for the startup, eventually you burn out. There is too much of context switching.

Leszek Knoll

And just out of curiosity, but these are like or emergency related or it's just like I don't know, financing related to pass through another round.

Oleksandr Taran

It's very interesting for me.

Leszek Knoll

So that's what I'm asking.

Oleksandr Taran

At the moment, I'm dealing mostly with early stage startups, where no m and a deals happen. It's usually financing or investments. So an investor, mostly business angels, wants to invest in a startup, how bad it is, definitely worse. They want to understand whether people are selling them, what they say. So it's not a cat in the back, as people say. And most of those investors are business people, sales in the past, marketing in the past, consultants, and they have no idea of new databases, let's say, or new kind of interfaces, system designs. And this is where I come in.

I usually do short due diligences, because these are not big rounds, and I provide eventually a report, and I speak a lot then eventually with an investor and explain him what do I think about the choices that been done. So I do not consult, I do not advise the investor to invest or not to invest. It's not my, my duty in this case, my obligation is to analyze a startup, so to speak, with the team, to speak with the CTO, check the code, check the infrastructure, data storage, all aspects of a system, modern system, and provide a short report that is understandable for a business person. So in that kind of report, I do not put lots of technical stuff, because my target audience, yes, is the investor who is a salesman, let's say, and he won't understand some technical terms. So it's quite a challenge sometimes to explain technical things, to not add.

Leszek Knoll

That's actually a great skill, I have to say.

Oleksandr Taran

It's one of the things I've learned in the last five years whilst being a CTO, how to communicate with the business level and explain to them technical issues, problems, how to make them understand that this is not solvable, or this would take too much time, or here we are blocked by something because there is quite a gap between technical level and business level, and you need kind of translation between those levels.

Leszek Knoll

So one of the topics that interests me a lot, which is actually how to make this translation happen, how to make business understand technology, and the other way around. So could you tell me a little bit of strategies that you use to actually use analogies? I don't know, how do you actually translate it?

Oleksandr Taran

Yeah, you mentioned analogies, and this is quite a thing in my usage, because I need to find words that are known or understandable by business people. Some business people even don't understand the word API interface. And then you have to explain on your fingers, basically how the systems communicate. Why do we need to connect with another system? Where do we store the data? So it comes with experience. I think eventually it becomes easier and easier.

In the first two years it was quite a challenge, but I had luck that my co founders in that case and the first startup were designers, product builders, so they had some knowledge. And in the current startup I have some of the founders that are purely business people, sales consultants, and it took quite some time, I would say some months, to find the common ground with them. And I try to listen to them as much as possible to understand.

Do I don't understand? Or who is missing the point? Is it me? Because of course, sometimes I may miss some business things, concentrating on non technical stuff. Or is it? Or are business people missing something? So it definitely takes several rounds to find the common ground, to find the understanding.

The only advice I would give here is to practice, is to speak with business people and try to go to their level, because not always they want to come down, I would say, or come lower to your technical level.

Leszek Knoll

And when you're talking with the business people, what are you going after? Objectives. What's the level of the detail that you want to get to understand? For instance, the set of objectives for, I don't know, growing company, a scale up might be completely different than for a startup, which is, I don't know, chasing product market fit. And the objectives are completely different. And they also translate into maybe not completely, but significantly different approach to building the technology if you're chasing product market versus you're scaling a thing. So my understanding, or my solution would be to get to understand where the business is and what are the objectives.

Oleksandr Taran

Usually I try first to understand the business side of the things. So there are sometimes terms that I do not know. For instance, especially in the current project where or product where we are building a system around financial business administration. Usually this staff requires an MBA, right? A master in business administration. And three years ago, when we started, I had to learn all the terms in the areas that are related to business administration, because I had never experience with MBA. With business administration in Germany, people usually have BBL, there is such a term, education, and this is where economy, business stuff.

But as a technical person, I have never met it. And once I understood their language, I tried to explain them why I'm against or why I'm hesitant, for instance, to go forward with an idea. What I encountered basically daily is a challenge between doing technical things to improve the product that would not bring the business forward and the thing that where I should neglect the quality of the product and build different workarounds, let my team neglect something.

Leszek Knoll

Right, let's test that.

Oleksandr Taran

Exactly. So this challenge, this daily challenge is to decide, do I write more tests to improve to keep the quality of the product, or shall I neglect it and build a new features that would bring the business forward eventually. If you only build features without refactoring, without improving your code base or your system architecture, the product after two, three years will, in my experience, fail, start failing. So you find with time, you find some solution in the middle because you need to build features to go forward. That's the point of the whole startup, to sell products, to sell services. It's not about product. This is what I understood with time.

It's about the satisfaction of the customer who is buying that product. Because if you spend three years building a product and no one wants to buy it, yeah, it's pointless. You spent your lifetime, you lost some opportunities in your life, you may have problems with your personal life, because a startup takes lots of time and eventually you do not get anything of that except of experience, kind of, and this is maybe another good point. Whenever such thing happens or happened in my life, I tried to base my energy on this experience. So I didn't get the learning. Yes, the learning. So I didn't get to sell the product, I didn't get, let's say eventually money, I didn't get some products or customers satisfied and I tried to base all this negativity and remove it.

Thinking about what have I learned in the last years in that period. Otherwise, if you ignore this experience, this learning, and you concentrate only on negativity, after some years you will just burn out, end up. You close a startup and you are emptied, I would say.

Leszek Knoll

I think I've been there. On the other hand, I think it's if you actually to take your approach and consider learning experience. What I'm trying to say is that I think, I really think it's a valuable lesson if you do it. I think many people actually go through that failure in terms of building actually a business and instead building a technology. So I think it's a valuable lesson to be honest. Any advice on balancing the tech debt versus getting things done and delivering new features? You said it's a balancing thing.

And do you have a mental model or some kind of advice, how you think about it to make those kind of decisions?

Oleksandr Taran

Yeah, I definitely think that it doesn't make sense to cover your code, base your product with automated tests 100% in the early stages until, I don't know, see round a, maybe round b. So you need, in my opinion to cover only most important stuff. So your business logic, the things that make money maybe in the product, and I would advise to find some solution in the middle to test your product because it's needed. With that you are good to go for some years. And at the same time I try to give in most of the cases a priority to the business features, because this is what moves the product forward. It comes with a skill to make decisions that are good for your product at particular stage, and it comes also from the experience of knowing different technologies. Because if you do not master the tech stack that you are using, then you make bad decisions.

It may be JavaScript or node JS based stack, it may be a Java based stack or go whatever language you use or whatever set of languages you use, you need to completely understand it, even though maybe you do not develop 100% of time. But as a CTO you do develop, I think, and you should develop because this is where you are as close as possible to the product with time. If you are lucky to get revenue, if you are lucky to get external investment, you may eventually you will stop coding and you will become a pure manager. But even at that step you need to understand your product as a software architect. So for me, a CTO is a combination of software architecture, of mastering software architecture and engineering management. So you need to be good with technical people. And in my case, being for many years an engineer, a developer, I know how to speak with developers, with junior middle senior.

I know how to explain them things and how to explain them why business wants this or that. And I think it's another challenge that a young CTO should master. How to translate we spoke about this at the beginning, but how to translate business ideas to technical people and architectural decisions as well? Yes, and eventually you make those architectural decisions and you have to explain it backwards to the business people. Developers understand architecture much more than, of course, than business people. You just need to find right words for business people and explain to them, why do we do this integration? Why don't we need this API?

Why some things should be replaced and refactored, even though we will lose some weeks.

Leszek Knoll

Speaking of find architectural decisions, tech debt versus getting things done and delivering things, I want to ask you, have you noticed any shift and how things are getting done and how this decision is prioritized in recent quarters, maybe year or two, in the context of limited financing, have you seen a shift towards more getting things done faster and concentrating on cost efficiency of building software.

Oleksandr Taran

Yeah, definitely. I meant times or I was already a CTo in the times where the times were different from nowadays, where it was quite normal to sell an idea without a product, to sell a presentation and get your first pre seed or seed round.

2017, 2018 up to last year. And eventually the market in the last year or year and a half has shifted in the way that you need to build it. First you need to show that you can earn money, that your business model is working before you get even a proceed round. So the discussion that we had in the current startup three years ago, the evaluation of our startup has changed radically. In comparison, 2022 and 24 23, we saw that investors wanted to get more for less money. Yeah. It is related to the situation in the investment market, to the banking situation. Yes. And this may, this made us actually bootstrap more.

So this made us, in the current startup, evaluate what are the most vital parts, what people do we need to keep. So we had to let some people go. As far as I know, lots of, lots of companies did that in the last two years. But on the other side, that was quite a good experience in terms of working more efficiently. So we had to understand, yes, where can we cut the things and where is the core? What should we work on? Because if you have enough money from an investor, you kind of become lazy, I think.

And then if you.

Leszek Knoll

Or defocused.

Oleksandr Taran

Yes. If you get into extreme conditions, like lose budget or constrained budget, people wanting some stability in the bad times you start, it's challenging you. And as most of people do in challenges, you grow. So you get a challenge and you try to solve it without the challenge. You are lazy, you don't need to solve anything. And these 2023 and 24, these two years gave us a push in terms of efficiency, how to do things more with less.

Leszek Knoll

Could you give me some examples, if you've seen something of how these constrained financing translate into architectural decisions you've mentioned you have to be a master in as a solution architect. And have you seen that constraints translate into the technical decisions as well?

Oleksandr Taran

On that level, I've had chance to make simple and not very simple decisions. And a simple example would be, in our product, we are pulling exchange rates daily for some stuff from an API, and we do pay for that API. So when I had the budget and they could spend, let's say, 50 euro for such stuff, it's one of the APIs that the usual product would need. I didn't care that per month we were spending. Let's say 50 euro on exchange rates API. And eventually, and I said oh, we can do it, maybe not every hour, but every day or every week, it's enough for our case. And we can reduce the cost of this single API, one of the APIs, to ten euro per month.

Then it's quite a simple solution. So you look at the product, you look at the API and you optimize. And more complex examples would be deciding, do we build another AI solution? For instance, in our product we work a lot with machine learning models, we categorize and match documents, transactions. We do do lots of cool stuff in the bookkeeping area and we had lots of plans. And eventually, because of the restricted budget, we thought okay, this is a feature like people say good to have or nice to have. And this nice to have is not a mandatory for this year.

So because of the budget, restricted budget for developers, for some AI services, we moved this is nice to have feature to the next year or years, let's say. And of course you shape the product eventually around those APIs, around interfaces, communication with other systems. I could only say that we communicate at least with ten APIs at the moment in our product and constantly in production. And this amount will only grow because lots of things can be purchased or bought for some monthly fee. Instead of spending people's energy, more money on building it and reinventing the wheel.

Leszek Knoll

Could you tell me a little bit more about what is the specific problem that you solve and what stage are you at? You've been doing it for the last two years, I believe three years.

Three years, sorry. And it's interesting for me to see, first of all, what's the stage that you're at and what's the problem that you're solving and how is it already do you consider to be a product market fit stage?

Oleksandr Taran

Franton was founded as a solution to a problem in the area of financial and business administration. Lots of people want to build product instead of managing their finances and administration. Lots of people are tech and product founders. They have no idea of spreadsheets needed for financing. They don't have money initially for a CFO, let's say, or in most of the cases for an early say, startup. Does it make to have, does it make sense to hire a full time CFO? And this product was created from the personal pain because in the previous startup I was struggling with all that business stuff, financial administration, and my co founders were doing that too.

And eventually my current co founders also used to build products or wanted to concentrate more on the clients. And we all had this pain. And once we started speaking with fellow founders, with friends in the area, we understood that most of the people who didn't learn that stuff or are not that deep in the business administration topic, they struggle with it. They spend 5 hours per week for that stuff. And this is a lot for a founder where you have to multitask or some spend thousands per month on external services like external bookkeeper, external accountants, external CFO, all this stuff. So our platform unites multi banking, bookkeeping, accounting, controlling, reporting and planning, and eventually taxes. So we call it a money chain, because if you as a founder go to a restaurant and pay for food as a business expense, your case starts with this transaction in your multi banking, in your banking, and it goes through all the stages appearing in your banking.

You somehow get a digital invoice or receipt. In this case, you let it go through the bookkeeping, you see it in your accounting, internal accounting, it affects your budgets eventually. And if you spend more on the restaurants, as in this example, as you planned for the quarter, then your plan current comparison is just simply wrong. So you are going out of the budget and eventually, in any country, the tax office wants to get a piece of cake and you have to pay the taxes from, from your revenues and you can get back also VAT in most of the countries. So we simplify all these stages. We unite all of this in one product, one platform, where you can connect your business, bank accounts, you can manage your bookkeeping stuff. So upload your invoices, receipts to the system.

We collect it automatically. In most cases you match it with.

Leszek Knoll

The data from the banks, right?

Oleksandr Taran

And we are matching automatically. Have built several AI models for that, because we know that sometimes it's not obvious, machine can learn and can improve with time. And this is done automatically. We don't have people who are sitting and matching every single transaction with a document in background. It would be costly, it's inefficient, and we are not developing any new product with that. So we are categorizing transactions and documents, we are matching them, kind of creating pairs for usually for any transaction there should be a receipt or invoice. And this is the basis for any accounting and accounting controlling and reporting stuff.

With that we can generate reports for investors, balance sheets, cash flow statements. All of the PNL. Yes. Of the three basic or maintained statements are generated automatically from transactions and documents, right. We recognize documents with the help of OCR technology, reading and digitalizing. And we work a lot with APIs. For example, we have a comprehensive stripe integration as a payment provider.

So in that case we do not need to recognize any documents because we go through the API and we fetch data. The same applies to shopify to any e commerce. Yes, we support at least all german banks at the moment as we started in Germany, but our banking partner allows us to go to any other country in Europe and having all this stuff, the founder gets automatically main statements, cash flow statement, cash as akin as lots of people say. And we communicate with the tax office in Germany. We are official partner of the datev system, it's one of the main systems in Germany for tax submission. So we provide this digital data to tax accountants that back up our company. So we have a network of tax accountants who eventually also double check the stuff that we generate.

And all of this is submitted automatically to the tax office. And with this we close the money chain. So your transaction that started last month will eventually go to the reporting and tax office almost automatically.

Leszek Knoll

Nice.

Oleksandr Taran

But of course it's a constant growth and improvement. So we constantly improve the system. We add new APIs like Shopify, Amazon, depends on the customers. We started with the startups because we knew phone numbers. Yes, we knew the pain. We knew that lots of startups tried to have on the digital stuff. So with a production company we would have a lot of depreciation, that stuff, physical goods.

And that is a little bit more complicated than digital world. And now we are moving more into the world of stable companies, e commerce, because we validated our product with the startups group, it startups, technical startups, selling services, it stuff.

Leszek Knoll

It resonates very much with me because we have the same pain, or we had the same pain. And we build custom made simple system to deal with a similar problem on our own. We couldn't buy like it was years ago, so we didn't have the bank API. So we used Imap integration with email and set alerts for every event on the bank account. Then we sometimes fetch those emails like your story resonates and the product story resonates with me very, very much because it's a struggle for every company.

Oleksandr Taran

Yeah, the market, the banking and fintech area developed in the last year, so lot. So five years or maybe seven years ago, such a product would be almost impossible because there were no regulations on the european, european level to connect bank accounts at the moment, since several years, every bank is obliged to open this API to any company if the customer bank customer provides a consent for this. So we can access any bank, any bank account. And we see that this area develops more and more in the next year, for instance, next year European Union wants to oblige also, or to make mandatory for all banks to process instant payments without any fees and more or less automatically. So this would also make banks that are, let's say they, not all the banks want to provide the data, because it's their data kind of their money. But at the same time, banks for many, many years didn't do much with that data. And that's why we see a huge market of fintech trying to grab a piece of cake from the Linux.

Leszek Knoll

You mentioned some of the basic or standard reports, but is there any tools within their system of frontend that enable some kind of business intelligence analysis, like custom reports, this sort of things? Or maybe does it allow you to integrate it with some other business intelligence tools such as, I don't know, power Bi or tableau or other systems out there?

Oleksandr Taran

At the moment we do not have any such integrations because we provide most of the stuff that founders and startup people need within the system. So we provide three main accounting statements, b and l, profit and loss, balance sheet and cash flow statement. We also provide, depending on the group, different kind of metrics and charts, like burn rate, all of these. So what people usually use in the unit and economics of a startup, we provide all the metrics. We allow you to plan the budget and compare this with the current values. It means you plan for the next year of the budget. And we constantly get new transactions, we pull them constantly.

We see what you have spent, what you have spent, and this can be compared with your plan. And if your plan deviates from the current value, from the actual value, you are spending more or you do not get as much revenue as you wanted. Or for instance, we see the system understand that in two months you won't have any cash left to pay salaries. You get notified. So we notify our clients only when it's needed. But if the user, if our user wants to know more, he can always come in the system and drill down in the most of the chores. And usually if we are missing something, we get it at the request from the customer and we build it for the particular group that the customer belongs to.

Leszek Knoll

Nice, nice. So you probably to do that, you probably monitor several indicators like, I don't know, cash conversion cycle, all those things that, or maybe not specific cash conversion.

Oleksandr Taran

Cycle, but like you mentioned, burnt account, payables, account receivables, lots and lots of stuff. So we provide only what we as founders would need. And this resonates a lot with our users.

Leszek Knoll

Nice. I'd like to change the topic a bit, and I'd like to talk about your leadership experiences. Specifically, I'd like you to ask you for the lessons learned along the way when it comes to leading, maybe managing teams. Could you give me some advice on that flow?

Oleksandr Taran

One of the advices would be to read and research a lot in the area of building products. So this allows you to see potential solutions eventually. Speak with fellow CTO architects. It can be developers of any levels, because this opens your mind. And this is where my technical due diligence that I provide helped me. A lot. A lot.

So I get the experience. You as a CTO, you should be, most of the times, up to date.

Leszek Knoll

With the technologies you mentioned, mastering the software architecture and engineering management.

Oleksandr Taran

Yes, exactly. The second advice would be learning business things. Business stuff. As a CTO, you need, as I mentioned before, you need to understand the business people. And if you ignore business side of the things, if you only concentrate on building the product, writing the code, eventually the gap between you and the business people will be too big.

Leszek Knoll

You're not going to be the right thing.

Oleksandr Taran

Yes.

Leszek Knoll

Just to think. Right.

Oleksandr Taran

And you see it also in the big companies. You see ctos becoming CEO's eventually, right? So I think it was Twitter and many other companies where people spend years as a CTO and they listen, they get experience from business people, and eventually they migrate, let's say, more to the business as a natural development step. This would be my second advice and the third one. And I think this is the main advice I give anyone. If you want to found a startup as a CTO or as a founder, you need to consider your job as a hobby. So whenever people ask me, how can you spend 50 hours per week, how can you spend 40 or 60 hours per week on building that product, or overall consulting and building the product, I tell them that I don't have a job, I have a hobby.

That's my main mantra. I would say, I like the things. And when I have a spare minute, some people go to YouTube, some people go to other apps, social networks. Yeah, some people do different stuff. And in my free time, I try to educate myself on technical as well as business stuff, because for me, it's my way of life, it's my hobby. I don't have a job. And I hope this will never change.

And I think that's why I left as a corporate world. So I worked for a big german company called Wirecard, for example, one of the biggest in Germany at their moment. And I. I understood that, yeah, I could do more stuff. And within that company, I was restricted somehow, artificially. I couldn't implement the ideas I had, I couldn't develop as I wanted. And this is why lots of young people just leave big companies get the experience with themselves and found the companies because they love what they do.

And this is really not a job. If you have a job, my advice is, if you want a job, my advice is just stick with a big company. There are lots of them. Work your 30, 40 hours a week and you will be happy. Not everyone has to be a founder. It's not necessary. I think.

Leszek Knoll

Yeah, it's a different kind of beast. I read this interview with the CEO of Nvidia and he says, and he was asked if he would do that again, and he said he wouldn't, he wouldn't run his business again because I like, he did it not knowing what's up, what is up ahead. But I think it's value. But he still said that was really good journey and a hobby.

Anyway, Alexander, thank you very much. It was a pleasure. Great stuff. Great insights. Thank you very much.

Oleksandr Taran

Thank you. Better tech leadership powered by Brainhub Follow Lesh Schick on LinkedIn and subscribe to the Better Tech Leadership newsletter.

‍