#7 - Bhairav Patel of Atom CTO

I'm doing very well. I should get you to write my bio because you're kind of better than I can.

Yeah, so I started off. I actually did a law degree back in the day. I didn't want to become a lawyer; I decided that wasn't the thing for me. Ended up looking at lots of different areas, sectors, marketing, things like GlaxoSmithKline back in those days, to advertising. Eventually found a job at PWC IT consulting. I'd always been interested in tech from a young age anyway, and this was a way for me to get involved in technology but also travel. So that was one of the key things. Actually, from day one, I was sent out to Lithuania in '99. We were building a technology platform for the local telecoms provider, I think the BT equivalent in Lithuania. So we built that. Then for the first half of my career, about five or six years, I was working at PWC and then IBM bought up PWC consulting. I was living in Norway, came back to the UK to IBM, then realized I didn't really want to be in the UK, ended up going back to Norway as a consultant, and lived there for another five or six years. I think in total I lived in Norway for about 11 years. Then I became the CTO for an e-commerce business back in 2008. We grew that quite nicely, quite massively. We had three different brands within that e-commerce business, three different kinds of shops, and we took that out from Norway to Sweden, Denmark, and Germany. Actually, it was operationally in Germany but selling in Denmark. Then just as I left, it went to Sweden. Then became CTO for a fintech back in 2013, when fintech was just a new thing. We raised $12 million back in those days, and over the next five or six years we grew that again globally. We scaled that to have operations in Ireland, Singapore, South Africa at one point, and three different parts of the US. Scaled that team up, became a Forbes Fintech 50 business, which is very nice alongside the likes of Stripe and Acorns. Then I left that, ended up with a stint in Thailand, in Bangkok, working for an e-commerce business out there, and then started Atom Ventures, which is now really Atom CTO. The whole story behind Atom Ventures, Atom CTO, was that during these past 20 years, myself and the rest of the guys who formed Atom Ventures had been working with startups and advising them, really advising early-stage startups. We saw the same problems over and over again. The problems that happen in tech for large companies are the same as in small companies; they're just smaller because there's not much infrastructure. So we really started it as a way of giving top-quality advice to early-stage startups, to help founders navigate the waters when it comes to tech and understand how to build a strategy, how to execute that strategy, how to make sure that what you're getting is right. Because we always asked the same questions from founders, but also saw the same problems: projects overran, they cost too much money, people didn't get what they wanted. Founders always found that they had to change everything within the first six months and were saddled with lots of technical debt. You saw these problems and realized that a lot of it can be dealt with very early on. Once you talk to the founders, understand their business, understand where they're trying to go, create a right strategy and roadmap, and actually articulate the features of the product that they want to build in a way that developers can understand, because that's what we were very good at as a team. We obviously understand the technical language, but we also understand the language of business, which I think is something that's weirdly not improved over the years. I would have thought it had, but for some reason those worlds seem to remain apart.

Yeah, so I think most founders are generally good at one or two things. The reason they start that company is because they've been doing those one or two things for a long time and feel that they see a need in the market. So they may be great at sales, or maybe great operationally with running a business, or they may actually be a techie with the idea for a great product. But a startup is, as I keep saying to the founders, an app is not a business. You need to think beyond just the technology that you're building and how you're supporting from a customer perspective, sales, marketing, advertising, all of these different things that you need to have involved. I think that's what we bring to the table. We tell them, given our experience building businesses, technology is just one of the pieces of your toolkit. It's a tool for the business, it's not the business itself. No matter what you are, even if you're one of the big fintech banks, they're all tech-heavy, they still employ a huge number of people, and they all must be doing something which is KYC, AML, all those kinds of different things. So the way that we always have a very set methodology that we've used over the years, and we stick to that. What we find very hard is to articulate to the founders and the startup owners that they need this process because it's important. What tends to happen is they ask for your advice and then dismiss your advice because it might be too costly or too time-consuming, and then they come back again after they spend a huge amount of money and say, 'Well, it's all broken now, how do we fix it?' Well, if you'd gone down our path very early on, it may not have been perfect, but it would have been much better than where you are now. I think that's the key. Most people, when they start a business, because you have a limited set of money, you feel that you want to spend it in the right way, but they don't see planning as the right way, which is odd.

Yeah, it's that whole lean startup thing which just created the myth that you need to get out there and fail fast and reinvent, which is there to a point. But actually, the most successful startups I know go very slowly. They're very considerate with each of their moves. The ones that we work with, one of the reasons we work with them is because they understand that the business will take its own time. No matter what you do, you can't force customers to buy from you. It will take time for you to evolve that business and understand your market and really change your product to address that market. You can't force it down the throats of your customers.

But I guarantee you, and I'm sure he limited that, that took a long time. It wouldn't have been something that he would have done magically overnight, that suddenly had an amazing process. I think that's where people need to spend a lot of time. What we tend to say to startup founders is, if you can run this on a piece of paper, run it on a piece of paper. Because one of the issues that you have with tech is that people try to build too much tech too soon, and then you're stuck with it. A lot of people talk about technical debt, but actually it's not necessarily technical debt; it's just building the wrong thing. Because you've anticipated something in the market, and what you haven't done is thought that maybe the market doesn't want all of that. Maybe they want 20% of it. I think what people need to do is be more agile in the way of thinking when it comes to the actual product. There are so many times I've spoken to founders, and we just don't work with them, who say we need to have everything because there's no point. We know it's going to cost you a couple hundred grand, and actually you could have spent 30 grand and saved 170, and used 170 to actually get the customers. And as you say, you have an app with hundreds of different features, but customers want to use a small part of that. It's working out what the customers are going to use most and invest all your efforts into that, and then grow from there.

And ideally get someone else to do it for you. Because the problem is, as a founder, you'll only listen to the things that you think are good. You'll end up having a filter in your head. So whether you hire someone specifically to do that, or you think like a third party, customer review type... There are companies that do that. There'll be designers that can do it for you. They'll go out and they'll kick you out the room and they'll talk direct to the users. So if you've got a designer with you, then they should be able to do this as well, or you can just get someone else to run a workshop. It's very simple: come up with some questions and then listen to the feedback.

So actually, with the fintech, what happened there was that there was another third-party company that had built it, and the whole point was that they were going to build it and then they were going to stay on. I just got rid of them and brought in my own team. There was no working relationship. It did mean that I had to work very hard, but it got us to where we needed to get to much quicker, much cheaper than we would have done. But I had another situation where I ended up having to go in and we fired half of the IT department as soon as I got there, within the first month. We just got rid of the IT department, which dramatically improved the quality of output and actually reduced the number of production issues and speed to market. So sometimes you inherit a team and you just have to get rid of the people that were actually causing the problems. You could see quite clearly who that was and why they were doing it. They weren't all working towards the best interest of the company; they were working to the best interests of themselves. So when you go into a new business and there's an existing development team, you can always assess the development team you have there and potentially have to make some dramatic changes to move forward. It's case by case. There have been a number of times when I've gone in and they've had a great team. But usually, I don't come into a situation unless there's a problem. So there's usually a reason that I'm being brought in, unless it's with a lot of the companies with Atom CTO where there is just nothing and they want to start from the ground up. But there have been a number of occasions in my career where I just get brought in to solve the issues. It may not necessarily be the people; it's just the process and the way that people work and how they've been treated. A lot of times, the people in front of you are great; they've just been either not given a chance or they're unmotivated, treated poorly.

I think the green field, everybody's joyous. But the thing with going a green field is that you've got more that can go wrong. So if you've got a product that already exists and is working okay, you may not be doing everything in the right way, but it's serving your customer base and you're making some money, and a few tweaks here and there will make it better. That's actually a much easier situation to get to, even though it may sound more disastrous than going to a green field. Because with a green field, you are making decisions that will impact the company for a couple of years, where there is a huge unknown. It's actually very hard to develop something that will be flexible to the massive unknowns. There are unknowns and unknown unknowns. With a startup, they're pretty much mostly all unknown unknowns. You have an idea of your market, you have an idea what your customers want, but until you're out there with the MVP, you don't really know. That's why I always try to emphasize that you build as little as possible to begin with, to get people up and running. Because as soon as you are up and running, things will change. I do not know to this day a startup that I've worked with or talked to who has been doing in the second six months of their existence the same as they've been doing in the first six months. It changes very quickly. You have to be adaptable and make dramatic changes sometimes.

So there are two different aspects to that. There's culture from an actual culture perspective, where people are in different countries and think and behave differently than others, and then there's the company culture. I think generally, when you go into a business, everyone wants that business to succeed, unless there's some real weird politics going on, especially at a smaller level. So as long as you can convince everyone that what's happening in front of them is for the best of their business, inevitably increase their pay or value of what shares they have, then that's always a good thing. Typically, early stage, if the founders don't know each other well and haven't really secured their shareholders' agreement and haven't really figured out the way that they're going to work together, then you get a little bit of politics. That's where things can get very messy very quickly. I always say to anyone who's starting a business, the first thing I would say is just prepare for the bad times. Make sure that you've got your shareholders' agreements in place, you know what roles and responsibilities everyone has, and ensure that if something does go wrong, there's a very clear plan of what to do about it. But then you've got the other cultural aspect where people coming from different parts of the world and working together. I guess because I've worked in so many different countries and with so many different types of people, it's kind of natural. I can understand when people say one thing and mean something different to the way I would normally interpret it as a Brit. But you can see it happening, especially when I'm sitting there as an independent person watching two people, there's just cross-communication that sometimes happens. The way to get around that is just to be very clear in what you want and use very simple language. I think a lot of times, I see this a lot in pitch decks, there's a lot of jargon used and a lot of abbreviations and acronyms. Unless you create a common terminology, any developer or architect listening to this will understand. Unless you've got a common data dictionary, unless you've got a common terminology within the business, things get confusing very quickly. You need to have that; that's one of the key things you need to start off with, and that helps iron out some of the other issues around the culture.

Yeah, so it's an interesting one. I think now COVID has obviously shown that people can work remotely from anywhere. There are always going to be those people that don't really want to work remotely; they want to have someone in front of them, and that's never really going to go away. Actually, there are certain industries that are probably right, like betting and gaming, you kind of want to have people in front of you to share ideas and actually lock down some of the IP. But I definitely think that there is a much more move. You can see in the market now that hiring developers is harder, the costs have gone up globally. It's not just in one country where things have increased in price. People are now understanding that they can hire, but whether the managers are good enough to be able to manage multicultural teams and understand really what it means is a totally different matter. For example, I've got my team currently residing in Latvia, Germany, India, South Africa, and me in London, and we're about to hire in Portugal. Each of those countries have their own differences. For example, hiring in South Africa, there's a huge issue with power, there's something called load shedding, which means that people could be without power for 12 hours. If you're a manager who doesn't know this and doesn't understand technology, this can happen, especially if you're running tight deadlines. It's okay for us because we knew this was an issue, so we work around it. In India, when there's a lightning storm, people power off their laptops because they don't want to get electrocuted. It's actually happened to one of my team members. So there are all these little nuances that can happen, and you've got to really be aware. You can't assume that everybody's like you. You can't assume that everyone has the same infrastructure set up. I'm sitting here with three screens; most of my team are not, not because I'm not paying for them, but because they don't have space.

Yeah, I mean, I was a very big believer in either bring them to you or go to them. So a good example was when we were ramping up the team at the fintech that we raised money for. We had the choice of the world back in 2013-14. You go anywhere. I narrowed down the shortlist, started talking to people through my network, I knew a few people here and there, but I just kind of randomly Googled places and got some of my team. Back then, there were other brokers that could help you out as well, which is very interesting, but that's a different topic. So what I decided to do there is you talk to them, and then you go out and meet people. We ended up in Portugal back then. Even then, I got my team to work out of the offices of the companies that we were looking to work in, near shorts for them to spend a week there and get a feel of those businesses and understand a little bit more, because they would be managing people directly. Once we got the teams onboarded, I went down for a month, and my senior team were always someone out there. I ended up moving there to Portugal, but other people spent a long time there. We sent people backwards and forwards. Similarly, India's a little bit different, a bit harder sometimes to get visas, but we try and make sure that people are moving or I go out there as and when I can, just to make sure that people understand that I am real, not just an image on the screen. So you do that. I think the key thing is to always talk to people who've done it before and understand the issues that you might face. There's no substitute for experience. You've got to seek out those people who've done it before and never take the face value of anyone that's selling to you, which is plain obvious.

There's a huge amount of due diligence you need to do, depending on how you see yourself as a business. For example, let's take India. I worked for IBM, I went out to India to train some of the guys in the early days back in 2000, 2001, so it's 20 odd years ago. If you look at some of the Indian companies selling their software developers, a lot of those companies are really treating their employees really bad. They've got bad conditions that they're working in, they're working very long hours, their contracts are quite onerous, and they're locked in for a year or two years. You can't know that by talking to the guy who's in a nice room on a Zoom meeting. You just don't know that. So you've got to do a little bit of digging. You've got to meet the teams themselves. You've got to try and make sure that you put in front of the people that will be working for you. You've got to try and gauge how they are, how that team is put together in itself, and how well they can work. Other people that are working for you have never worked together. Do they have a manager? How are they being managed? There's a whole bunch of nuances. Again, working with teams in Vietnam is very different to anywhere else. But again, with guys on my team who had spent a lot of time in Vietnam, they understood the nuances. But you really need to dig a little bit deeper into the background of the businesses, how they work, how they operate, how they treat their staff. Because the problem never comes from you yourself. As a company, you'll be coming from the company in the middle that's employing it. I've had instances where huge numbers of staff would just rotate really quickly. You're like, why are these guys only spending two months with you? It takes a while to figure out, but you kind of want to know that beforehand.

IBM, we were working for a big client in the UK, and I was out there because IBM India were providing some of the staff back in those days. IBM treated them very well, actually. So when it comes to if you are a startup and you're going to use a third-party technology solution, you also want to get to know the business and how the developers are being treated and what the culture's like there, to ensure you're not having turnover even in the third-party situation.

So the whole point really is that you need to understand. You're going to get a great spiel from the people that are selling to you. What you need to do is try and spend some time with the developers on their own without their managers, simply because they're the team who's going to be working for you. You need to understand how they are. They're obviously not going to tell you that they're getting treated badly, but you can always get a sense of it. Once you start having private conversations, you get a feeling from the sense of communication. You'll see how they are, if they're quite timid. You've got to have people there that match your culture as well. I think a lot of people just throw out the work and expect it to get done. That could work fine for you, but if you're looking to create a long-term relationship, you need to ensure that the company that you're employing is treating them well enough so that they do stay long-term, because your knowledge resides in people, not in the business. It's in the other company that you're hiring.

So it depends on the situation you're in. If you're a startup that is just starting out, or maybe just a normal tech team that wants to branch out and use more international developers, there are a few things. If you're looking to augment your team, if you've got a team of three or four and you need to bring in another four or five quite quickly, there are a number of different ways you can do it. The very basic is you're nearshoring or you're offshoring or you're hiring directly. Hiring directly is getting a little bit easier, but it's still quite costly if you're not going to set up companies out there. There are platforms like Deel and another one I know that just became a unicorn based in Portugal, I forgot the name. When you're looking at hiring individually, you've really got to figure out which country you want to go to. That can depend on time zones. Are you looking at offshoring it completely to someone like India, Vietnam, China, or Malaysia, so you're going for cost benefit there? Or are you looking for something slightly closer to home, so if you need to fly out, you can fly out there? What are your real motivations? Do you need to have everything in the EU? Can you hire people in Ukraine simply because a lot of your data needs to reside in the EU, so your infrastructure costs become a little bit more because you have to deal with data not moving in and out? There's a lot of cultural and structural things you need to think about. What kind of wage can you afford? What skills are you looking for? Certain countries have more of certain skills than others. It's no different from hiring a person in your own country in the sense that you set your budget, you set the working methodologies, and then it's the logistics side of it. That's just extra costs and hassle. So when it comes to the country itself, it's really then up to you to figure out if you're going to need a large number of developers. If you're going for a large number of developers, then places like Croatia, Slovenia, and Slovakia may not be so great for you because they just don't have that pool of talent. You can't go to Lithuania, Latvia, Estonia. Estonia is a bit different because that'd be very expensive; you've got a lot of unicorns paid very well out there, so the talent pool isn't so much. But if you're looking to get a team of 100, then Portugal might be interesting, or Spain, or even France. But if you're looking to set up a team of two, then it doesn't really matter where they are, as long as you're getting the right quality people. If you're looking to get cheaper, then you can go further east, the less expensive it becomes. But again, it depends on whether you're doing it yourself or through a third party.

Yes, slightly. It's easier to hire seniors and manage them remotely than the juniors. The juniors will, a lot of times, if you've got a number of different developers in one place, then you can have a nice mix, but the juniors do tend to need more support. If you're not geared up to be able to give them that support when they need it, then you're going to find that a big overhead. So it's easier to manage a senior team remotely than it is to manage a junior team. There are certain types of people that work remotely better. Most developers like to be left alone just to get on with their thing. But testers may need more interaction with the business because they need to understand the business more, so you might want to have them closer to home than the developers. That's what I tend to do. I tend to have business analysis and testing in-house or close to in-house, and then development can be done at the house, and then bring in specialists for things like AI/ML whatever is needed.

It depends a little bit on how organized you are. Most people working at larger companies like the stability of that steady paycheck and the fact that they're going to go into work and they know what they're going to do and how they're going to do it. In the startup world, you might be happily developing one product feature and then someone comes in and says, 'Well, no, don't need this anymore, scrap what you've done, we're going to do something completely different.' If that's something that you don't like, you don't like that kind of change, then it's not for you. And if you aren't quick to learn new things, because it may well be that you suddenly have to do a completely different technology or work in a whole new sector, and if you can't do that quickly, then you're probably not going to enjoy the startup life so much. But again, it does depend. As the startups grow and you start bigger teams, then it becomes more like a traditional business. You'll have people who have set jobs, and because the team scales up to a certain level, it just becomes business as usual, and you're not running around trying to fight fires or doing 15 different things. As a developer in a startup, you might be doing a bit of DevOps as well as UI/UX as well as back-end coding. You kind of do a bit of everything sometimes to really provide as much value as you can across the whole. One of the key things is a lot of people are perfectionists, a lot of developers are perfectionists. They may have the talent in something, but they won't do it. I meet plenty of developers that don't want to do front-end work because they think they're not good at it, but once you actually get them to do it, they're pretty good. But because they don't feel that they're the best, they don't want to do it. That is not helpful in a startup world, because you just sometimes need people to get on and do it even if they don't feel that they're great at it.

It's an interesting one. I think if you're going to do something very complicated, for want of a better word, if you're going into natural language processing or image recognition, those kinds of things, then you want to be more in that niche and understand more about that world, because the speed of improvement and development in those industries mean that you kind of have to be on top of it. You can't then suddenly go off and do something else. But from a full stack, let's say .NET developer, it's useful to understand different parts of the stack in order to know how they all fit together, but you don't have to be a JavaScript developer if all you want to do is deal with identity.

Yeah, definitely. We've got some youngsters on our team now, and they're less mercenary than some of the ones that are a little bit older. But having said that, obviously everyone wants to be paid. It's a little bit cultural as well. In some of the countries I used to work in, the younger developers just like the cachet of being a developer. A friend of mine in Bulgaria said the guys 20 years ago were driving the tinted BMWs as gangsters, and now they're the developers. So there's a bit of that. But I think a lot is made of the ping pong tables and stupid tables. That is nice, but people just ultimately want to be treated fairly. They want the flexibility. You're seeing that in the younger generation. The older generation wants that too, but they're less used to having it, or it's kind of a novelty for them. Whereas I think it's harder to motivate the younger generation if you're just going to sit and chat with them and dictate work. There's got to be a little bit more knowledge sharing, putting things more into context. But again, that's a good thing. Everyone should be trying to do that. There are a lot of non-financial benefits you can give to that generation, especially in learning and opportunity. My guys who are younger, they don't mind working long hours, not that I'm making them do that, but they don't mind working on hours if it's a new technology or something new that they feel like they're learning and progressing. But I think that's probably an intergenerational thing anyway. I think every generation wants that. I just think that overall, yes, they are concerned about money, but they're also concerned about doing things that they are interested in and have some sort of impact.

I tend to just hire. Whether they like what we do or not is a bonus if they do. They don't always necessarily understand what we do, because from the outside it's not always easy to understand how the mechanism works inside. What I do tend to do is I always try to gauge the curiosity of the person beyond their CV. So what have they done? What projects have they worked on outside of their core day-to-day work? I had a team in Norway where pretty much every single person had a side project going on, a side hustle. One guy had a side business that he started up while he was working for us, and he's doing really well now. He quit his job to do that, which is fantastic, because he started learning about a whole bunch of new systems which in effect helped him in his day job. Obviously for the company it didn't help because he left, but that's good. That curiosity is there, and you're developing and learning and adding new skills. I think that for me is the most important thing. I've discussed this with other people before, and we talk about being a developer like being a bus driver now. It's just a job for a lot of people. But when we started out, it was really very new and very interesting, and we wanted to do something. I think if you can still find those people, they still exist. People building stuff with their own empires. That's the key. If they're motivated doing other things and learning something completely tangential to what they do on a daily basis, that's great.

For sure.

I think it's a big difference if you're joining a very early stage to one that has received its funding and is moving on to the next stage. If it's a real early stage, maybe got some seed funding, there's a lot more risk to that than someone who's got maybe two, three, four, five million in the bank and knows that they're reaching out in terms of the funding stages. For someone coming from a larger company, a lot of it depends on your life situation as well. You're going from something, I'm not going to say IBM was a job for life because I think they fired everyone over 40 last year. But the thing is, if you have family, kids, a steady paycheck is what you need. A startup is not necessarily for you, because even though a company might have funding, it could still go bust in a couple of years. One company I invested in raised two million and a year later they went bankrupt. There's an inherent risk in any startup, and most startups fail. Within five years, I think 97% fail after three years, and after five years only another 10% of those succeed. So it's risky. But if you want to learn a lot and get involved with many different aspects of the business, a startup is fantastic. As CTO of a fintech in 2012-13, I learned huge amounts of non-technical stuff, which is great because it helps me when I'm running businesses, starting my own business. But if you're looking for security, pension, all of that kind of stuff, then startup isn't necessarily for you. And don't be fooled by the shares, unless it is a company that has actually got a value, because the shares are meaningless until there's an exit. You might say it's not valuable; you've actually done your research on them and seen exactly. So these are all nice things, but if you're going in at a junior level, it could be good because you get to learn a lot of different things. But if there's not enough senior support, you may not have the people there with the experience to know how to deal with challenges and risks and mitigate those risks.

I think, I mean, I talked to a lot of people, and I actually talked to one of my friends, she's set up businesses in Australia, Canada, and the US, and we talked about this. I think the training that we got at PWC was fantastic, and that has really helped us. If you find someone that has worked with that kind of background and can come into your business, it's fantastic because there's a methodology there. You don't necessarily understand that methodology until you're out of that system, but it is a great one for setting up your business. Now, I'd caveat that by saying if you're there for too long, you're useless to me. If you've been there for 15, 20 years, I don't really want to deal with you because you only know one thing. What was very interesting was that I've been on both sides of the table. I've been a consultant for five or six years, and then I've been a CTO for 12, 13 years. When I look at consultants now, I realize how little they know about business. They know nothing. They've never run a P&L, they don't know how a balance sheet looks, they don't have to deal with wages or anything like that. So they might know about a specific area and topic, and if they stick to that, fantastic. But if they start advising about your business, then no. So if you want to be a bit more rounded, then I would suggest you go into a company. It's like being a lawyer. You can be a corporate lawyer, but until you become general counsel, you don't see all the different things that are going on.

Yeah, don't go for glory. I think the thing is, a lot of people try to go for the latest and greatest. What you've got to remember is, if your business takes off and you're using a technology that's just come out that doesn't have great support, that doesn't really have many developers, it's going to be really hard for you to grow that team. If you're going for the newest JavaScript technology that's come out, one of the 15 million that have just turned up, and you're fully behind that, remember that if you scale your team, there may not be anyone in the market to hire. That's really interesting. So choosing the shiny bright new technology that no one has had exposure to really limits your chances. From someone who works in the recruitment industry, you mentioned this at the start of the podcast, there are more companies hiring software developers than there are developers at the moment. You want to have a bigger pool of candidates for sure if you're trying to grow your team. Give up some of the snobbery that's around. There's a huge amount of snobbery when it comes to open source and this and that. What you've got to decide as a CTO of the business is what's best for the business. You've got to ensure that if the company grows and scales and you need to start going into new territories and doing new things, you're able to do that, and there's enough knowledge and skills within the team to be able to do that. If you're looking to align your business and tech strategy, you as a CTO have to understand the business. You can't just be sitting there going, 'I don't know about business.' You've got to get more involved in that and think more strategically rather than keeping your head down. The first year, year and a half, two years of the startup, you're thinking operationally. But as you get into the third year and the business hits three years, because a lot of businesses don't survive three years, then you're moving more strategically. Because no matter what anyone says, and I know I'm going to get killed for this, your strategy is rubbish really in the first six months. Until you're out there, you don't know that strategy is really going to stick. So what you've got to really concentrate on is your operations and know your risks in your business. So many CTOs don't really think about what are the actual risks, things that can go wrong. We come across tech stacks or platforms that we take over where there's been no security audits done, no encryption of data, they haven't thought about what happens if you decide to go into a new market, make it multilingual. These are really basic things you can do very early on. Create those structures to allow you to be flexible. You don't have to make it multilingual focused, but reverse engineering that is hard. Also, your operational piece, don't forget how to monitor your platforms, all the logging, error mechanisms, failover. If that's done early and well, it will save you a lot of bother further down the line. I've got plenty of war stories that we could spend another couple of hours on of things that have gone wrong in businesses. The key is just to de-risk that business as much as possible, and that is in many different areas.

Yeah, you've got to remember, CTOs are the worst jobs ever. No one knows who the CTO of Microsoft is, who the CTO of Oracle is. You're the guys who keep the lights on, and no one really cares about you until something goes wrong. You'll get no glory. All that happens is if something goes wrong, you're the first one to be fired. So you've got to become a risk manager.

It's inevitable. It's going to happen. So as long as you keep track of it and understand that it exists and that you need to go and fix those problems, just don't hide it away. Just say, 'Okay, it needs to be done, let's go and do it.' One of my pet hates is that a lot of times we'll be in a beauty parade and we'll see some reports that have come from other companies who have done due diligence on a business, and they'll just say, 'Oh, we have to throw it all away now.' You don't always have to throw everything all the way. The whole job of the CTO is to go and look in there and say, 'Okay, what can we really salvage? What can we pick? What can we build on? What needs to go? And what do we need to improve going forward?' Technical debt is something that's always going to happen. Not all your developers are going to be at the same speed or the same skill level. You're going to have to make decisions to get things out quicker than you want to. Just keep a track of it all and know that when you do, the worst thing that happens, and I see this in a huge way, we've been breaking down some monoliths into microservices and things like that. What ends up happening is everyone just hides their little things that they've done. That's what kills you in the long run. So just keeping a track of it and making sure you're dealing with it as you go, but it is inevitable. You have certain deadlines to hit, and you might need to be careful and decide when to accumulate technical debt and then deal with it as and when, so it's not too much of a hassle later down the line.

Yeah, it does differ, but generally most businesses aren't profitable for the first two or three years. For example, Atom was profitable from day one, but we were quite lucky in the sense that we had a pre-existing network and set of people that wanted to buy from us, and we had a very low operational footprint. So it depends on your business for sure. But generally, you should ensure that you've got enough money in the bank for the first 18 to 24 months, and then expect to raise after the next 12 months if you've managed to hit your sales targets. It's hard in this environment. Generally, it's hard to create profitable businesses, but be patient. It's one of those things. Like I said, the business will go its own pace. You can't force it.

100%. I think the more senior head you can get in early on, you don't need to have them the whole way through, but you need those, especially if you've never run a business before, you need those advisors early on just to help you set a framework. Then you can do whatever you want to do within the framework, but at least you then get an understanding of how you should operate finances, how you should operate tech, how you should operate sales, and set yourself some targets and goals. I think that's the key. A lot of people don't do that. When I ask them, 'Okay, so why are you doing this? What are you going to get out of it?' ROI is a huge pet peeve for me. The amount I talk to people about, especially when it comes to tech, and I say it's going to cost you X amount to put this new feature in, what do you think that feature is going to do for you as a business? How many new customers will you get from it? No one has an answer. So why are we doing it? I'm not saying don't do it, I'm just saying why are we doing it? That's the thing.

So I've been doing a number of founder stories recently. I've been interviewing a number of non-technical founders who've built on low code, no code, so they've gone without any kind of technical help, no technical CTOs, and they've built their own things. It's been really interesting to see how they've done. If you listen to their stories, you think, 'If you had asked me for a bit of advice, I would have maybe done that slightly differently,' or they've done it well. The two key takeaways are that low code, no code is not as easy as everyone thinks it is, and do you really want to spend your time messing around building an app when you should be going out and getting customers? That's really the key. But it's up to them. I know guys who have done very well, but they've put a lot of sweat and tears into their journey. But then they've also learned about the value of tech, which is great because they've learned what it means to do it now, so they know that they're going to prize someone who can come and do it. They're going to actually value that person. So there's that. We've also been doing a few demystifying pieces. A lot of it is generally business entrepreneurship, so it's not always tech-focused. It's actually not much tech-focused; it's really more business-focused and helping entrepreneurs get through the crazy times of the startup.

Atom CTO dot com is where all the podcasts are, or on SoundCloud under Atom Ventures, and LinkedIn Atom CTO, and Twitter Atom CTO.

Thanks a lot.