He Dropped Out and Didn't Study Tech. Now He Runs a Global API Empire | James Hirst | Tyk.io

Shamil Malachiyev: All right. Good morning, everyone, and welcome to this week's episode of The Founder's Code podcast. Joining us from London is a co-founder and chief operating officer at Tyk.io, the leading open-source API management platform, used today by some of the world's biggest institutions. Please welcome James Hirst. Hi, James.

James Hirst: Thank you. Thanks a lot.

Shamil Malachiyev: So good to have you. Can we start with you telling us a bit about Tyk and the current scope at which you're operating? I think it's going to be quite interesting for the listeners to hear.

James Hirst: Sure thing. So Tyk has been trading for 10 years; this is our 10th anniversary, in 2026. Tyk is an API management platform. A large majority of the world's internet traffic today is APIs. Whether your phone is connecting to a service online, whether you're checking the news or the weather, you're watching streaming data, you're making a call, that's all API traffic. APIs effectively allow systems and devices to talk to each other. And Tyk's role in that is as a gateway: you place Tyk in front of your APIs and we secure them, control them and scale them. We're widely used by some of the world's largest consumer electronics companies, automotive manufacturers. Pretty much every digital interaction people have today is driven by APIs, and we're proud to be a big part of that.

Shamil Malachiyev: And as chief operating officer, how many people do you currently have in the company to manage?

James Hirst: Tyk is relatively small. We're around 120 people, but we are very broadly distributed. We are a default-remote business. I'm based here in London; you'll see the red buses behind me, I'm sure. My co-founder, Martin, is in Auckland, in New Zealand. So we are about as remote as it's possible to get, as two people on this globe. And our team is spread across currently 32 countries. Around 120 people across 32 countries: that's a very broadly spread remote business, and we have been since we started.

Shamil Malachiyev: Nice. And for everybody listening to this on Apple Podcasts or Spotify, make sure to visit YouTube if you want to see the beautiful London scenery James has in his background. Can you tell us a bit about growing up? You grew up in London, right?

James Hirst: Well, I grew up all over the UK, actually. I was born up in the north of the country and moved around a lot as a small child; my dad's job took us all over the country. Then I grew up just outside of London and really couldn't wait to move to London, the shiny city over the hill. I've been in London since I was 18, never left. Now I live just a couple of miles up the road from the office, in the centre of town.

Shamil Malachiyev: And what was it like, compared to the standard US or European vibes?

James Hirst: Good question. Something that's very interesting about the UK from a technology perspective, growing up, is that it definitely had its own ecosystem for computing. As a seven- or eight-year-old, we had a small 8-bit micro, we had a Commodore, and there was a huge industry of UK software publishers creating games and productivity software, which was quite apart from the US market. It was a little insular in that way; it very much had a British humour to it, a British culture to it. And I think that's something that really engaged me as a kid and followed through into being a teenager, as the world of gaming in particular grew. That's what kept me in technology. So I grew up with my family just outside of London, and computing has always been a part of that.

Shamil Malachiyev: A lot of people don't know this. The UK is not as advertised as a technology hub of the world, but some of the leading innovations were done in the UK too. I used to live in the UK for 10 years; that's where a lot of my life happened. There's Bletchley Park, where the encryption and decryption technologies were built. Some of the largest companies, like ARM, are also set up in the UK.

James Hirst: Yeah. And even the World Wide Web, right? Tim Berners-Lee created that. And I think there is a unique dynamic to running a business in the UK compared to the rest of the world, or certainly compared to the US. In many countries there are separate hubs for culture, for technology, for industry, for finance, for government. Whereas in the UK, everything is centred around London and the environments around it. So if you're launching a tech company, you're doing it alongside banks, alongside government, alongside some of the largest companies in the world. As opposed to, for instance, the US, where if your business is in media, you're in LA; if you're in finance, you're probably in New York; if you're in public sector or defense, you're probably over in Washington. So you get a very different confluence of influences, of characters, of people, of funding, all in one place. Which is quite unique, I think.

Shamil Malachiyev: What I hear a lot from my friends in the UK is that when they come to the US, everybody's so much more easygoing; people meet every day. While in London, everybody's there, and there are events happening around the city, but in order to connect, to have chances to meet all these different people, it takes a bit more effort. Have you ever felt that? Or was the ecosystem always welcoming and connecting you with everyone?

James Hirst: There's a very active ecosystem, but I think there's a different cultural expectation in the UK and the US. Certainly in the US: when we started as a business, we were a UK-founded company, founded here in London, just down the road in Brick Lane. And when we first started talking to customers in the US, because actually most of our customers initially were in the US, they said they were surprised that we were not more forthright about our capabilities. They found us too self-deprecating, too quiet. We weren't shouting proudly about the things we were doing. And I think that follows through into the local ecosystem: you do have to make an effort to go and tell that story. Whereas in the Valley, you can't sit in a cafe without hearing someone next to you telling how they're going to change the world.

I think both of those extremes can be problematic. But certainly UK founders do need to learn a little from our transatlantic cousins and be a bit more forthright, a bit more positive and ambitious, more self-promoting. Equally, I think there's a huge amount of value in having feet firmly on the ground and a very pragmatic view of reality. So hopefully there's a middle way. But yes, in the UK you do have to do a bit more running to build the network and the connections, rather than relying on bumping into someone in a coffee shop in the Valley.

Shamil Malachiyev: When you were talking about being pragmatic, I was thinking: it's probably because when you're bootstrapped, it's a different game than when you're heavily VC-backed. When you're bootstrapped, you have to optimize for your profit margin to make sure the company survives. You're not relying on outside capital, so you're not trying to market yourself to attract more capital in the future. You're focused on your bottom line and keeping it as you grow. Is there some truth to that?

James Hirst: Without a doubt. It's been a constant source of, I guess, confusion and frustration at times, as founders. We launched our business as a bootstrap, so no funding initially, for the first few years; we built it out of an open-source project, in fact. And so all of our decision-making was around cash. Not even profit: cash, because cash is the thing that keeps the business going. It doesn't matter whether you are or aren't profitable; do you have cash is the key. And that gives you a very simple decision-making framework: how do I deploy the resources I have, how quickly can I turn them into cash, how quickly can I cycle that cash around? It makes you take pragmatic decisions around marketing, around sales, around product development.

When you move to a world where you have VC funding, which we've since done, VC funding and growth equity funding and so on, the discussion is much more, as you say, about growth, and efficiency can take second place. But what's interesting is that the media, the community around tech growth, definitely up until quite recently, has always focused on who's raised money. The headline is always: Acme Corp over here has raised 50 million as a Series A. And of course that's a signal that someone has confidence this concept might progress. But what you rarely hear is: Acme Corp over here has been successfully growing profitably. That's not a headline story. It's usually the third or fourth paragraph down: and they're actually making profit, or they're actually growing sustainably. I think that sometimes drives the wrong behaviors, because it means someone thinking about founding or scaling a business starts to think: how do I get that headline? How do I attract that attention? Because that seems to be what's important. Whereas if you're building a business that you want to be resilient, have longevity and build careers for people, the fundraising should be a means to an end, and the business should be viable on its own, standing on its own two feet.

Shamil Malachiyev: As a bootstrap founder myself, I can relate. When you're entering the business sphere, you think: okay, how much money would I ideally need to live a great life? It's this amount; it's probably going to take four, five, six years to get to that point. And then you try to increase your profitability and grow to that level. Whereas when you're starting a VC-backed business, your main motivation revolves around: when is the next exit, and that's where I'll cash out. Maybe that's the big difference: the sole motivation.

James Hirst: Perhaps. I think the question is: who are you trying to orient your attention around? My co-founder is very clear with our teams: the most important thing you have to invest is your attention. That holds true personally as well as in a work context. And if your attention is spent on "how can I convince someone to give us more money for the next stage," versus "how can I spend my attention on satisfying this customer need, on building and developing the best team we have," then you can end up driving decisions that are counterproductive at best, and at worst catastrophic, because you're placing all of your attention and effort on impressing someone to get pure cash, which doesn't lead to a sustainable outcome.

Sometimes it's hard to disentangle those two things. Of course, having sufficient cash, whether through funding or organic growth, is essential to a business's survival and prosperity. You need the cash to grow, to be able to invest for the future. But if that comes at the cost of unsustainable promises, of taking short-term decisions to secure the cash versus securing the long term, you can find yourself in a difficult position. As a founder, the incentives need to align. If your incentives all align with your investors' incentives, everything should be in a good place. But that's not always the case in the world of building a business. You can find yourself out of sync with investors, and then out of sync with your customers and your team, and then you can find yourself in a difficult position.

Shamil Malachiyev: Would you agree that being a bootstrap founder builds more resilience? You have to make hard decisions earlier, I presume, because you don't have much runway to wait out bad hires and everything else. So when the time comes to raise outside money, people look at you as somebody more experienced, more capable of running things leanly and efficiently, making decisions. If you need to let go of 20% of the workforce to execute the long-term goals, that's something you will do, because you might have to.

James Hirst: Perhaps. I think the perception, certainly, is that being able to run a bootstrapped business for a number of years shows diligence and operational ability. Are you able to operate effectively? Are you able to make decisions that are sustainable? And that, of course, is valued by someone thinking about investing.

In some ways, running a bootstrapped business is less comfortable, but easier, as a founder. It's easier because there is a single source of objective truth, which is: does this deliver cash? Have I got cash? Will this deliver cash? As opposed to: will this chime with the current investment thesis of such-and-such, or is this the right story to get people to buy into my vision? So in that way it's easier. It's less comfortable because you are much more alert to every single pound that is spent, because you have a much shorter horizon on that decision-making process.

One of the great benefits of raising money, when it is right to raise, is where you have to take long-term bets. Maybe you're making a large capital investment that's required, or you need to capture a certain amount of the market to make the network effect sustainable. In that instance, being able to take a long-term decision is fantastic. As a bootstrap, it's much harder to make those calls. Every decision is revisited, if not weekly or daily then certainly frequently, because you are constantly guided by the cash imperative.

Shamil Malachiyev: So in the world we live in today, for any founder who has an idea and is starting to build: would we say it's worth exploring the bootstrapping option, trying to get initial customers by yourself and show some traction, growing it linearly before looking for VC funding? Or is it worth just looking for investors willing to make a bet?

James Hirst: I think there are very few ideas that, in their own right, with a 10-page PowerPoint deck, will secure funding. Our route into this was actually as an open-source project. The genesis of Tyk was that my co-founder was running a small bootstrapped side project, and to make it effective and efficient he needed to manage APIs, in a way that at the time was brand new. It was multi-cloud, so he was using AWS and GCP and so on. It needed to be containerized, so he was using Docker and Kubernetes. And there was no tech that would allow him to do that, so he built his own tech: the API gateway that became Tyk. It turns out other people had the same need. So when he shuttered the side project, which wasn't going anywhere, wasn't successful, he open-sourced the gateway. And because other people had the same need, they jumped in, and they helped drive that product-market fit. Through their engagement with us on an open-source community forum, through GitHub and Google Groups at the time, they were saying: well, we need this for our use case over here, could it work in that way? And we would make those changes, iterate and launch.

In that way, we got to the point where, with no external investment, with no marketing other than a single website, we were able to sell to really large organisations, like Cisco, like Capital One. And it was driven by the fact that the customer need, that feedback loop, was there already. So when we were approached by people wanting to invest, it was because they saw we were in a space that was exciting and growing, and we had something. That's a very different proposition to: I have an idea that things could be done differently, give me some money and I'll try to realize it. So whether it's a bootstrap, whether it's open-source engagement, there is no benefit to hiding away. Just get it out there and see how the market reacts. It gives you the proof points.

Shamil Malachiyev: Can we try to make the case for the open-source model as an appealing one? For most founders and people joining the sphere, what I hear is: we want to see traction, we want somebody purchasing subscriptions, anything to hear that Stripe bell ring. And when they hear open source, they think: everyone's going to be using it, but I'm not going to be getting paid. Can we make the business models more concrete?

James Hirst: Yeah, absolutely. There are huge benefits to having a community who will share your story with others and provide feedback; that product development cycle and that marketing awareness are central. Without that open-source route, would a couple of guys in London, doing things on weekends and evenings, have been able to get a product out to the level where folks like Cisco and Capital One would turn around and go: we should try this, and actually, we could pay them so we've got some support and a contractual agreement?

And I think, increasingly, the idea that the proprietary code itself has the value is diminishing. That diminishment is accelerating with the emergence of LLMs in a lot of spaces; unless you're in deep tech, you can point a product at an LLM and get your own approximation of it. The actual coding itself is not the value. The understanding of the space, the understanding of the value proposition, being able to build an organization that can then serve those needs is critical. For us, the fact that someone can take our code and get value from it without paying us is not the major concern. The major concern is: can we build a business that meets the needs of customers? Most of our customers are large enterprises, and large enterprises want to know there is someone at the other end of this relationship who will be there when things go wrong, who can advise them on how to improve and expand what they're doing.

The approach we've taken from day one is that the core value proposition we offer, the API gateway, is entirely free to everybody. Anyone listening to this can have the same value as many of the world's largest banks, telcos, automotive companies; you can have that same technology and it costs you zero. On top of that, we have a layer of software capabilities targeted at large enterprises: a management layer that handles what happens if you have 25,000 engineers who need access to update or engage with an API. We have a product that does that, and we will license it to you, support it, give you the SLA and so on. It means we benefit from putting the capability in as many hands as possible, and then benefit from revenue from the people who would rather pay us than have to build and maintain their own version; it's not their core capability.

And it means we do see small organizations getting huge value from Tyk. We know one of the world's biggest pharmaceutical companies uses Tyk at immense scale, pays nothing. That's fine. At a certain point, it's likely they'll tip over and go: actually, it'd be easier if we just paid them instead of trying to manage this ourselves. So I think it's a really powerful approach. And it chimes with that same point: having an idea, keeping it to yourself, trying to put your arms around it as though it's a precious thing no one must know about, is a pathway to nowhere. You really do need to get it out in front of people. And if people buy into it, they're buying into not just the code, but the founders behind the code, the team supporting it, the teams developing it, who are there for them. That's where the value comes. The actual lines of code itself, probably less so.

Shamil Malachiyev: So would you say the future is open source?

James Hirst: Definitely. Without a doubt. Even to the extent that we work in a lot of highly regulated industries: we do border security, we do healthcare, we do banking and finance. There are whole countries where the critical financial infrastructure involves Tyk in every transaction that's happening. And those organizations will not put a black box of code into their organization. If you say, here's a binary, just go and run it, it'll secure everything for you: they want to know what's happening inside that black box. So openness and transparency are almost a prerequisite to work with those organizations. Trying to hide code away makes little sense to me. And when you get down to what is the value I am delivering to this customer: it's not the 5,000 lines of code or whatever. It's the relationship, the trust, the resilience, the responsiveness. That's where the value comes.

Shamil Malachiyev: Everybody wants enterprise clients, and everybody finds them hard to access, because in those large organizations there are so many decision points. But when you're running an open-source project, you're basically alleviating the issue of trust in code security, because it's open, you can see it. Was that one of your superpowers that helped you grow and secure larger clients?

James Hirst: Without a doubt. Within, I think, six months of launching Tyk commercially from open source, we had a huge bank and a huge technology vendor both using Tyk. And it was on the basis that they had been playing around with the open source, the engineers liked it, and when they saw they could solve a problem with it and took it to their compliance team, their security team, they were able to say: I can see every line of the code here. That's fine.

And equally, looking at us at that time and asking: this is a small company; what happens if it stops trading? If it's proprietary code, that's a problem: the lights go out, systems go off. No good if you're in critical infrastructure or highly regulated. If it's open source, it's: well, we can just run with it and switch out as we need. We could even take our own fork of it. And the fact that we have confidence in the value we deliver as a business puts their minds at ease. Are they going to end up having to maintain this? Our answer is: we've got confidence that you'll continue to buy from us, and if you don't, you can still use the value. That's a pretty powerful statement to make to someone.

Shamil Malachiyev: I think a lot of people know the MIT license, which means you can use it, but you cannot trademark it. Can you tell us what other types of licenses are out there? Which ones have you considered, and which ones do people go for?

James Hirst: This is a minefield, and I wish I had the standard legal disclaimer: I cannot provide formal advice, don't rely on any advice here. There are many different licenses available. Some of them have very attractive structures for you as a founder, or for a consumer, and you can figure out where you sit and what's important to you. But I would say the biggest imperative is not the exact terms within the license. Of course they're important, and you need to get comfortable with them. Could, for instance, AWS take my open source, run it in the cloud and start making money off it? Is that a threat to you, or a benefit? You can get comfortable with those things. The bigger question is: when I take this to Acme Corp down the road, and their team like it, and they give it to their legal and procurement people, will procurement look at that license and say, oh yeah, we sign lots of licenses like that, we're comfortable? Or will they look at it and go: hang on a minute, what is this? What's this opening us up to?

As with all of these things, there's always going to be a compromise. The key factors are the responsibilities on the people who are going to derive value from your software. On the one hand, they're deriving value by using it: is there an onus on them to contribute back? But more importantly, is it possible for them to take that code, fork it, and run a competing version, a cloud version, and so on? That's typically where the main decision points appear. We've seen many examples. The Redis project, for instance, a hugely widely used key-value store: AWS pretty much ate their lunch by taking a version of it and just running it in the cloud, depriving Redis of all of that revenue. Which can be beneficial, because at the same time it brings more people to your product; but if the party taking the revenue is not contributing back to the project, that can be a problem.

So trying to get comfortable around that is important. And definitely don't just base it on what you've read on a blog. Go and find an expert, pay for an hour of their time, and talk it through with them. Because these are important decisions that are irrevocable. Once that's out there under that license, it's out there under that license forever. You can put new licenses out, but the old one will still be there.

Shamil Malachiyev: So do make sure to consult with your local LLM.

James Hirst: Yeah, your ChatGPT lawyers are infallible.

Shamil Malachiyev: Can you talk a bit about your co-founding relationship with Martin? How did you two meet, and how did you decide: we're going to be a good fit, we want to do this together?

James Hirst: Yeah. I'm very grateful that I have a great relationship with my co-founder, because I think doing this solo would be so much harder. Almost exponentially harder.

Martin and I joined a digital consultancy on the same day. We were recruited on the same day, by the same person, and we joined this consultancy to become project managers, effectively. We did the training together, worked in parallel a bit, and ended up working on a few projects together, and really enjoyed it. That was at Reading Room, in London, in Soho. We were doing really interesting projects, things like digital communications in disaster zones for the UN. What happens if someone gets airlifted into Haiti and they need to find information digitally, when there are really poor-latency connections and the cell towers are down? How do people exchange information in the field? Really interesting projects. And the split in how we worked was: Martin very much on the creative technologist side, the strategy of how you address this technically; and on my side, delivery and the commercial relationship. How do we make this happen? How do we make sure the client can afford it and pay for it?

We enjoyed working together for a few years, and then Martin went off and became a CTO elsewhere. I stayed until we exited the business, and I was a director at that point. But we stayed friends. We'd go out regularly for a couple of beers and a curry. And it was over a few of those nights out that Martin was telling me about APIs, which initially I thought was a weird niche he was looking at. But by that point he'd open-sourced the project, and he had people emailing him asking if they could have a call. I think it was Viacom and Home Depot, saying: we love this, we're trying the open source, have you got an enterprise version? And he's there going: it's just one guy in his pajamas eating cereal on the sofa, doing it on the weekend. So we talked about it: well, maybe we could say yes, we do have an enterprise version, we do have a way of selling this to you. He came to me and said, look, do you want to get involved? And yeah, we had a few too many beers, said yes, we should do this, let's do it, and made the decision.

We ran it as a side project initially, because we didn't have any funding or revenue, it was just an open-source project. We carved out time at the start of the day, before work, after work and at weekends, and we would do sales emails, sales follow-ups, community forum support, issue updates on social media, talk to people in the community, until we got a few people who said: yeah, here's a purchase order, here's a check, we'll buy into it. After the first couple of those, we thought: right, we can actually pay ourselves out of this business. So, a real bootstrap.

Shamil Malachiyev: What is your secret to holding tough conversations? A founding relationship is much like a real marriage: you have a partner, and you have to be able to have those hard conversations and move on from them. Have you had those, and have they helped you build?

James Hirst: Absolutely. They've ranged from constructive debate to slamming the laptop shut and going and walking down the street for a couple of hours. And I'd say, for anyone looking at a remote-first business: that amplifies it, because you have other considerations. Before this recording, I was on a call with Martin at the end of his day. He's had a long day, energy is probably low, he's tired, telling me all the stuff that's been going on. I'm just coming in heavily caffeinated after a couple of espressos, at the start of my day, full of energy about all the stuff I want to do. Having those conversations across a big time difference, over a screen rather than in person, can exacerbate things.

You're right that you spend a huge amount of time with your co-founder. So the most important thing is: it's not a relationship to be taken lightly. The decision over who your co-founder is, and why you're co-founding together, is one to spend more time on than anything else. Because if that alignment is not there, it will struggle to survive the challenges in front of you. There are many challenges, and you have to be able to go through them together and back each other. I sometimes see folks posting, "I'm seeking a technical co-founder for this project," and I think: wow, this isn't a requisition process. This is very different.

To your analogy of a marriage: there should be some dating. If you haven't spent time with this person, if you haven't gone through some tricky situations together, then maybe don't throw all-in, because it won't survive. The key thing, regardless of the individuals and personalities, is: why are you doing it? Why are you in it? If you're both aligned on that, if you've both got that same outcome, then everything else is negotiable. How do we work through this problem? How do we show up and be vulnerable, or take a strong stance over something? Those are all things you can develop and refine. But they make no difference if you're not both trying to get to the same place.

Having that clarity upfront really helps, because as things change, you can refer back to it and see whether your positions are still aligned. That's been key for us: we both wanted to build the same kind of thing. We both had a vision for a different kind of business. It wasn't just the product; it was what the company is going to be like, how it's going to operate, what kind of careers we'll create for people and for ourselves. Having that as a central touch point means difficult conversations happen in the context of this vision we've got, this mission we're on, the team around us, and it allows us to put our own personal perceptions in that context. I'm sure there are psychological principles you can apply to this stuff, but I think they're all secondary to: are you engaged in the same expedition? It will be a long haul, a difficult haul. So make sure you both know where you're going, and what to expect en route.

Shamil Malachiyev: I was just thinking about Lord of the Rings. It's like Frodo, who knew Sam for a long time: we're going to put that ring into that fire. Agreed, agreed. They have the same goal and they know exactly what to expect.

James Hirst: Yeah, absolutely. And within that, if you're both working towards the same goal, it's important to understand your role in it as a co-founder, because there will always be areas of overlap. For Martin and me, there's a comfortable and obvious separation in terms of our areas of interest and expertise, the areas where we thrive, the areas where we need support. We've described it to the company a number of times with a film analogy: you've got the director and producer partnership. You have the vision, the energy to create this thing in a certain way, and you need the producer capability of wrangling it, making it happen. Those two things together fit really nicely. And of course it's not about org charts or straight lines or boxes of responsibility; it's about how those two things interact, where they bleed over, where they coincide. It comes back to that shared vision, that shared mission: am I bought into the movie Martin's making? Is Martin bought into how we make it, the scale of it? Those two things fit really nicely.

Shamil Malachiyev: Talking about a fully remote-first company: are there aspects of the culture that have to be different from companies that are office-based?

James Hirst: Yeah. So we started remote partly because we were both in London at the time, we had those beers and made the decision, but before we signed the papers, Martin said: look, one thing you should know is, we're pregnant, and my wife and I are going to move to be with her family in New Zealand. So should we still start a business? And we said: well, yeah, we can. You could work remote.

Shamil Malachiyev: Pre-COVID?

James Hirst: This was, what, 11 years ago. Pre-COVID, when that was quite a weird thing to do. But Martin could be remote, and then maybe we'd build a team in London. But then our next hire was someone who was moving to Singapore. And the very first hire we made, we thought they might be in Germany; turns out they were in Paraguay. And so we realized: well, if Martin can be remote, and they can be remote, and they're contributing well, then let's build a remote-first business.

And that has driven a lot of the shape of the company. We spent a lot of time thinking about the kind of company we wanted to build, the things that made us thrive, and the kind of people we would want in the business. One of those things was autonomy, and one was flexibility, because we were at a point in our lives with babies and families and external commitments. Not the cliche of the VC-raising guy who lives off ramen and sleeps under the desk trying to make it big; that wasn't for us. We wanted to build a business that was sustainable for us. And there weren't many people doing it. There were a few out there who had made strides; Slack were doing a lot remote. But people regarded remote-first companies as a bit weird.

So we thought about culture, because culture is so important to a business. How do you define it? We took it from a really interesting article, I think in Harvard Business Review, where two researchers put together this idea: a description of the culture of a business is what happens, how people act, when the manager is not in the room. When the boss is not in the room, how do people respond? That tells you the culture of the business. We thought that was very insightful for us, because we're never in the room with our teams. Our teams are always remote. They can never look over their shoulder and say: what should I do, boss? So we knew that would drive the culture, and we used it to think about: how can people make the right decisions, operate effectively, efficiently, productively, when there isn't someone in the room to give them a quick answer? That meant building a culture where asynchronous communication is prized, where decision-making isn't done in a meeting room but instead engages people in different time zones, brings their thoughts together, and is done in a timely fashion. It shaped our recruitment process as well: finding people who would thrive in that scenario, because not everybody does. Lots of people find it a difficult way of working, but there are people who absolutely thrive in it.

So the remote-first thing has been an interesting journey, because we then saw people forced to adopt it during COVID. And you realise it's not something you can lightly step into, or part-step into. I think it works for us because the founders and the C-suite are all remote. There isn't a building where decisions get taken while everyone else is remote from it and feels excluded. If the CEO and the COO can be antipodes, 12 hours apart, and they can effectively lead the business, then I can contribute from wherever I am. That's really important. Where companies don't do that, where they have the head office and say, well, it's okay, we'll just hire some engineers in a different country, but we're "remote-first," or where they say it's hybrid remote, you come into the office sometimes but not others: there, you effectively just end up with a bunch of freelancers. Because the decision-making, the information flow, is still in an office somewhere, guarded by the people who are in the office. Everyone else is excluded.

So it's been an exciting experience, seeing people initially say this will never work. I presented at Accenture maybe nine years ago, pre-COVID, and someone stood up and said: look, all this stuff you're saying is great, but you could never have a company operating remote bigger than about 20 people. Lots of assent in the room. And of course, a couple of years later, everybody is remote. It's not that it can't be done. It just needs to be done mindfully.

Shamil Malachiyev: What would you say are the main differences between the James before joining Reading Room, the James right before starting Tyk, and the James we see today?

James Hirst: Hmm. I have less hair. Partly the passage of time, partly stress. I think one of the things you realize as a founder is that you are going to constantly be put into uncomfortable situations, because you are necessarily going to have to forge new paths all the time. You're going to have to deal with stuff you've never had to deal with before, whether it's huge and scary or just a small, minor part of how a business runs. Comparing myself now: the confidence I have in my ability to navigate that is huge.

But I think the big thing is much more awareness of the importance of the interpersonal within an organization. Until you've led a business, founded it and grown it, it's hard to understand the nuance that sits behind an org chart, or behind a scaling plan that looks fine on a spreadsheet, fine architecturally. You realize so much of it comes down to: are people bought into the vision? Do people believe in what we're doing? Are people energized by working with their colleagues? Are they proud and keen to talk about what they're doing? I probably naively misunderstood that and thought: get the right idea, get the right team in, put the right structure in, and magic will happen. But so much of the day-to-day is actually people: engaging, developing, promoting people and people's agendas, rather than the objective piece of "we should scale this unit 12% in the next six months." That's easy; you could ask ChatGPT and it'll tell you best practice. The thing it won't tell you is: how does this team over here, with these particular challenges, these particular profiles, make that happen? So that's the biggest thing. I've learned a hell of a lot there.

Shamil Malachiyev: You mentioned profiles. Just recently I had a talk with my HR director, and she said we should do Myers-Briggs during the interview process, to understand the psychological profile and build from there. Have you adopted any of those ideas?

James Hirst: Yeah, we've done lots of those. And the reason we've done them is not for recruitment. Absolutely do not use them for recruitment, because they are no better than reading tea leaves for recruitment. I'll be absolutely clear: they will tell you nothing that will help in recruitment.

What they do offer is an opportunity for self-reflection, and for sharing reflections with colleagues: building a common verbiage about how you work, how you thrive. I think it's really useful for a team, a management team, a leadership team in particular, to sit there and think: what actually motivates me? How do I deal with conflict? We have used that within the team. Not Myers-Briggs, but another profile, and said: I, as an individual, find the best way of dealing with conflict is this; this is what really works for me; if you see me behaving in a certain way, these are the things that trigger it, so we should think about how we organize our communication so that doesn't happen. Some people hate an email that comes in with a load of issues: oh my God, why don't you call me? Why don't you speak to me? Equally, there are people who hate joining a call where someone's giving them a litany of problems: why couldn't you just put it in an email so I could think about it?

So whether the attributes are correct, whether you buy into the motivators, I don't think that's what matters. What matters is that as a team we think about and reflect on how we interact, what motivates us, where our strengths and weaknesses in communication are, and share it with each other using the same language. Then we get a better understanding of our peers. I think that's really powerful. There's a lot of woo around, in terms of "you need this sort of profile to hire," because I don't believe those profiles map onto excellence in any role. The cliches, like "for an engineer in a responsible position you need this profile": absolute nonsense. But self-examination is important.

Shamil Malachiyev: Can you share the name of the profiling tool you've used?

James Hirst: We used something called a PRINT profile, I believe. It's very similar, but you're thinking about unconscious motivations: how do I respond or react to a challenge? How do I respond when things are going well? How am I motivating others? That was a useful one we did. We don't do it all the time, but we've done it as an exercise as a team. Really, with any of them, it's an opportunity to take the team to one side and say: let's think about how we talk, how we communicate, what's working for us, what's not. And the important part is a common lexicon: when I say this causes me stress, I'm talking about the same thing you're talking about. So we're aligned.

Shamil Malachiyev: I think as a founder, many people don't realize you have to manage your co-founding relationship, if you have a co-founder. But at the same time, there are conflicts going on within teams, between people who maybe aren't as good at communicating, whose ego is in the way. And it's up to you to be a trainer, to guide people as a mentor to communicate well. Using profiling would help you see the commonalities in the way people perceive information, and find common ground around which to teach them to communicate better.

James Hirst: Yeah. As a rule, everybody's very capable of communicating; it's just that folks gravitate towards different preferences for communication. We have a series of behaviors we ask people to consider when they're working at Tyk, and one of them is to respect folks' communication preferences. Because to get the best out of people, you can't say: this is the only way we communicate. To take a rather simple office scenario: if the way decisions are made is that you pull everyone into a glass-walled office, ask for opinions and then a vote, the decision will be carried by the loudest person, the most confident person, the one who will stand up at the front and bang the desk. It might not be the best decision, but that's the scene and setting you've put forward. So when we're remote, we're always thinking about: how do we get people to contribute, to communicate, and then come to a decision together? Whether they agree or disagree with it, they commit to that decision. Respecting that there are different ways of doing that is hugely important, I think.

Shamil Malachiyev: Looking at the current rate of technological explosion, I think APIs are playing quite a big role. Do you personally have a vision of the future that you're in a position to help shape and build? Are there particular aspects you're most excited about?

James Hirst: Yeah. Tyk is critical infrastructure, right? We keep ATMs running, we keep connected cars driving, we work with airlines, border security, all of this. It's not something we take lightly. And the driver for that has always been the scale and importance of digital services. Tyk's growth has come as people's default became doing all of their banking on their phone. No one goes to branches anymore, and if they do, the person behind the desk is basically using the same application as the mobile app. That has grown really quickly and become central, critical infrastructure for a bank, as an example.

With the rise of LLM capabilities, that is spurring the same growth that digital services brought, and then connected vehicles and connected devices brought. If you've got smart meters, a connected car, it's all driven by APIs. The next thing is: LLMs want to connect. They want to connect to that data, to those systems. And the way they do that is through APIs. When you use your app to chat to Claude or ChatGPT, you're making API calls to an LLM. Where this becomes really important in an organization: to allow a large language model to get access to systems and data within an organization, you need to make sure that access is secure and stable. APIs can facilitate that, but you need to make sure it's audited, controlled, secure. If you've got engineers with a fantastic idea for a new capability using an LLM, you want to make sure it's an LLM you trust, and that the data going to it is allowed to be passed to that LLM. Is that personal information from a bank going to an LLM? Are we sure about that? Can we see what's happened? Have we got an audit trail? That stuff is driving rapid adoption of our technology within big enterprises right now.

The more we can enable connected system-to-system and device-to-device connections, the better for everyone. It's where the demand is. Martin, my co-founder, described it as wanting to be part of the fabric of the internet; that was our challenge from a company retreat five years ago, and we're starting to make that impact by working with those large enterprises. We need to continue to double down and make sure the potential of LLMs is realized, whilst also guarding against the risks and concerns around it. It's not necessarily the sexiest part of the tech world, being the pipes between systems, but it's the part that allows the systems to run, and the part that gives people confidence that they're reliable and not leaky. That's our role.

Shamil Malachiyev: So you're maintaining the infrastructure of the future, let's say. Right now there's a lot of craze around Clawdbot, or Moltbot, which for two days has been all over the news. Giving it access to everything on your computer, plus a lot of access to everything on the internet, requires a lot of connectivity, and a lot of risk as well. Is that an area, potentially more consumer-based, that you'll be looking at?

James Hirst: I think there's an education piece needed at the consumer level. Trusting organizations to look after your data and your systems, to interact and act in your best interest, is to an extent important for modern life. You want to be able to do your banking online, therefore you have to have some trust in the bank doing that. You want your email on your phone, so maybe you trust Google to do that for you. But an awareness gap sometimes exists around: what exactly am I agreeing to? What exactly am I enabling here?

It's one of those things that won't resolve itself until the need becomes really pressing, because people are not going to self-educate out of general interest; that's the world of the really geeky ones among us who get into this early. It will be when people see scandals occur. When people suddenly realize: oh my God, all my kids' birthday photos, I've put them in a free account, and now that free account is apparently using them for AI training. Is that all right? Am I happy with that? I don't think people are fully abreast of that. So the education, and then the consumer demand, will drive the behavior later.

What's interesting about this move to LLMs is that they are not the domain of the hobbyist. Yes, building things out of them, using them, utilizing them. But the cost to train a really capable LLM at scale is not something a hobbyist can do. It's not something you're really going to be doing with seed funding. These are big projects by big organizations. Facebook, Google: we're going to commission our own nuclear reactors to power our own data centers, just for LLMs.

Shamil Malachiyev: Yeah. Bootstrap that.

James Hirst: Yeah, exactly. This is a very different proposition. So that education is going to drive and dictate what's happening there. What we can do as technologists is make sure the capabilities are there for people to secure, control and govern what's happening. A large part of these latest capabilities will sit with the big hyperscalers, today anyway. I'm sure that will change over time. People said the same about mainframes, and pretty soon we were on desktop computers, and then phones in our pockets, and our watches. So probably the same with LLMs.

Shamil Malachiyev: As a final question, for everybody just getting their feet wet in this new world of technology: as a technologist, what would you advise people to study? Which topics or skills to get on board with early, right now, before things become too hard to learn and manage? What do you think is important?

James Hirst: I'm not sure I'm the right person to answer, because I don't even have an undergraduate degree. I'm a dropout from university. I didn't study anything technical. And perhaps that's the important factor here.

I've been asked a number of times: what books do you recommend, which business books? Generally my answer is: I'm sure there are learnings in many of them, but you're probably better off reading decent literature, because you'll learn more about the human condition, more about motivators, more about creativity from that than from a series of lectures in a reference book. And from a study perspective, some of the most successful people in our organization, and in other organizations I know, come from humanities backgrounds, and equally from science backgrounds. Studying philosophy is no blocker to becoming an amazing technologist.

We talked earlier about how much of the value in proprietary code is really in the code versus the surrounding organization and the wider value proposition. LLMs are eroding that the same way: they're making it easier to create the technical capability. And it means that to be a technologist, a large part of your motivation should be problem-solving. If you're into problem-solving, and you're willing to try new approaches, not necessarily cutting-edge tech, then that's the starting point. The love of the craft of a beautifully laid-out page of code is far less important today than a love of understanding a problem and finding a way of applying some parallel technology that people haven't realized could apply here. That's where, as a founder, the value can come. I'm not saying craft in coding isn't important; senior engineers are very important. But from a founding principle: you could become an absolute black belt in Python coding, but if you're not interested and engaged in a specific area, looking at the problems that exist and thinking about how to apply something that hasn't been applied to this problem, then you're not going to make that progress. So, a long way of saying: there isn't a specific topic I would study. Instead, I would try to put myself in a position where I can learn deeply about an area of expertise, find the gaps, and be willing to try to fill those gaps.

Shamil Malachiyev: I love it. Well, I want to thank you so much for joining me today and sharing your story, the story of Tyk. I think all of us have learned something useful and increased our understanding of the technology world we live in: what to look for in your co-founders, how to approach the remote world, and how to build a good culture within a team. Thank you for joining me. I wish the best for Tyk, and for you personally. I think we'll all be eagerly waiting to see what kind of innovations you bring to the new world of AI in the future.

James Hirst: Thanks so much. It's been really enjoyable. Thanks a lot.

Shamil Malachiyev: Thank you. That's a wrap.