.webp)
Forming the panel was the former CTO of Gumtree Australia Roisin Parkes, the co-founder and CTO of Culture Amp Doug English, co-founder and CTO of Elenta Anshul Jain, and co-founder and CTO of Intalayer Dr Ian Glass.
Over the course of the discussion, the panelists reflected on their career journey to date, provided key advice for steps they took and what they would look for in a hire at the same level, as well as areas in their respective industries where they see the opportunities for growth.
The below video of the panel explores the journey to becoming a Chief Technology Officer (CTO) in the tech industry, and how you could do it as a founder of your own startups. It highlights several key steps and attributes to succeed in this role. These include:
- Build strong technical foundations: Establishing a solid technical background is key to becoming a CTO. Hands-on, practical experience is invaluable and necessary, particularly in programming languages, system architecture, and software development. Not only that, but continuous learning is crucial, given the fast-paced nature of technology.
Additionally, if you plan to be the CTO of your own startup, having this deep understanding and real-world experience, will allow you to make informed decisions and communicate effectively with your technical team.
Note: Be sure to create a portfolio that showcases your work, projects, and achievements. This can be a powerful tool for job applications and interviews, or in a startup environment, it can be useful when seeking investors.
- Develop leadership skills: A CTO is not only a technical expert but also a leader. Effective leadership involves guiding teams, making strategic decisions, and fostering a collaborative work environment.
- Network in the tech and startup space: Building a strong professional network is essential. Attend industry events, join tech communities, and seek out mentors who can provide guidance and support as you progress in your career.
Along with this, it will help you cultivate an entrepreneurial mindset that embraces innovation and encourages you to be open to new ideas and approaches - an advantage that could set your startup apart from competitors.
Networking, particularly at the early stages of business building is also a crucial way to work through issues you may face as you scale your startups. Attending events or joining groups will enable you to share your issues for feedback and also allow you to learn from others who may have similar problems.
- Soft skills matter: Besides technical and leadership skills, it’s important to develop soft skills like problem-solving, effective communication, and adaptability. These skills enhance your overall effectiveness as a CTO and help you navigate the challenges of entrepreneurship.
Overall, stepping up to CTO, especially of your own startup, demands dedication, proactive career development, and a keen focus on both technical and soft skills.
Transcript
This transcript has been edited for length and clarity and starts from the beginning of the panel discussion.
[10:15] Laura Faulconer (LF): What do you see as prerequisites for taking on the CTO role? So if you put that another way, if you were to hire a CTO to replace you, what would they need to be able to do?
Roisin Parkes (RS): Well obviously, leadership is a key component of a CTO role. So not just the technology side of things, but also good coaching skills I think as a leader. I think the CTO role can vary hugely from company to company. So it depends on the company itself.
But if I was to find a replacement for CTO at Gumtree, for example, they would need to also have significant influencing skills to be able to get the investments needed across the business for the technology. I also think, and again, this varies from company to company, but the CTO role at Gumtree, it needs to be quite commercially focused as well.
So a good balance of technical decision making, but also balancing that against business objectives.
Anshul Jain (AJ): It probably depends largely on the size of the company - if you think of small companies, you're spending a lot of your time writing code. Depending on your co-founders, you're probably spending a lot of time thinking about the product.
And as the company gets bigger and bigger, then your role becomes more focused, less about actually writing code and more about, how do I manage teams of people who can produce a lot of code effectively? And especially ones where it's more of a leadership operational type of role, as opposed to, very architect, really heavy or technical.
LF: For somebody that wants to go into a CTO role - how would a CTO role differ from what the expectations might be?
Douglas English (DE): Yeah, interesting question. I mean I think, as Anshul was talking about, I think the CTO role is quite different for different sizes of companies. One of the talks I remember from a CTO conference I went to years ago that really crystallized for me the different needs at different sizes of company, talked about four different archetypes.
The first archetype they called, "the Incredible Hulk", which is the very early stage start-up where the CTO is basically, it's pretty much exactly as you'd imagine, the Incredible Hulk. This person is up in front, basically the 10X engineer if you like, that's smashing boulders and forging a path forward for their team. And I think what that talk was talking about is that as the company grows, the effectiveness of that archetype of CTO starts to diminish.And so when you've got to the stage where you have, say 10 engineers, all trying to follow someone that's out in front smashing boulders is not particularly effective, because you need much more of that coordination type role.
So the second archetype they talked about was "the engineer", which I think is probably the one that I fitted very comfortably in when I took over the role. Which is more of overseeing and coordinating and being involved in everything but also letting go of things and focusing very much on the design, the architecture - how things fit together and connecting everything. And that style of CTO works really well up until about 50 engineers, and after that point, it becomes too difficult for that person to keep across everything and keep their hands across everything. And things start to break down.
DE: And so then the next archetype they talk about, they called "the general". I'm not sure if that's necessarily a great analogy. But I do get the point, which is that you need someone who can actually have essentially lieutenants if you like, who are able to do what the engineer does in a whole series of different areas of the business. The job of the CTO much more becomes the coordinator and connector, setting that strategic direction, setting the vision, keeping everybody aligned and moving in the same direction without getting bogged down in the details of any given team. And that style of CTO lasts pretty much up until the company becomes the dominant player in their market. So that's a style of CTO that can last for a very long time.
But once you actually reach the point where there's really nowhere left to expand, you are the dominant player, the fourth type of CTO, they call "the celebrity". Which is someone who's entirely externally focused. They have other people who are running all the internals, and they're very much the face of the company. They're working on partnership deals, they're selling to the market. They're basically trying to convince everybody that all those up-and-coming tech companies that are coming into the space are not worth going to because you got to go with the tried and proven.
So I mean, for me, I think I definitely started as "the engineer", and a lot of my challenge and a lot of my growth has been focusing on, how do I become more of a general archetype? And letting go of a lot of my natural inclinations around the engineer archetype. And I'm definitely resigned to the fact that I'm never going to be a celebrity. So if the contract ever gets that big, I'm handing the reins over to someone who can be more externally focused.
[17:46] LF: What's the difference between VP of engineering and CTO?
DE: I can certainly talk to that one given that we've had both a VP of engineering and a CTO, and we've spent years struggling with exactly that question. And I think it is challenging. I think probably it depends very much from company to company and the partnership.
I think one advantage of having a CTO and a VP of engineering is that if you get the right partnership, you've got someone that covers the other person's strengths. Well, as in strengths and weaknesses that partner well. So I think probably the first thing is, as a CTO, what are your strengths? And what are your weaknesses? I mean based on that, what VP of engineering do you need to partner well with you, to help cover some of those weaknesses?
But I mean, talking a little bit more generally, I would say, similar to what Roisin was talking about before, my view of the CTO role is, it's very much a business role first and foremost.It's working in the exec team. It's spending the time to understand, where's the company trying to go? Where are you trying to head? Where's the strategic vision? I mean, what is the tech vision that backs that? I mean, I think the VP of engineering role is to take that and be more of the coordinator of the engineers on the ground. So who do we need in what roles? How do we get them? How do we manage all of the disparate pieces of work? How do we make sure that they're running on time? My VP of engineering used to talk about his job being there to keep the trains running. I think it's a lot more than that.
[19:50] LF: What are the key things that you need at the start and what changes as you move into growth mode? And what signals someone who's actually going to be able to grow with the company in that role?
Dr Ian Glass (IG): I think as someone who naturally takes up the role of nurturing curiosity. Because they just naturally fall into a leadership position, people will formulate around them.
If you're nurturing and mentoring people as well, it's a characteristic that I regard quite highly - that kind of curiosity and willingness to take the time to explain things in a way that people understand. So understanding their learning patterns, because you'll just formulate a great team around you. And that's just how you get things done.
LF: Anshul, how did you find transitioning from being on the tools as it were, to managing teams?
AJ: So if I think about the first transition...I went from I guess, fairly smallish set up. 20-30 people, we hired a few engineers. I was the hulk archetype. I hired people and I was like, "alright, you guys go do this." But I was very close to them. And I never really learned how to manage. Then I went to freelance where I also never really knew how to manage anyone. I think it's a super important skill set, and one which Hulk or engineer archetypes tend to dismiss easily.
It takes you a while to appreciate the importance of it. First, you manage people and then you get managed by someone who's really good. And you appreciate what an impact it has on performance. To Doug's point earlier, on letting go, giving away the tools a bit more and not having to have all of your opinions on how everything is built.
And realizing your time is incredibly high leverage if you can actually empower the people below you to think in the way which you would have otherwise done it. And so your role goes more to, how can I coach this person to think about the problem in a way which I would have thought about it? Or in a better way even?
[22:49] LF: Roisin, how do you balance your time? You've got a lot of pressures, there's a lot of responsibilities. It's really easy to keep getting dragged into the operational stuff. So how much time do you dedicate to R&D? How much time do you dedicate to strategy?
Roisin Parkes (RP): I would say it's not linear, it can vary quite a bit depending on where the organization is, and what the challenges and pressures of a particular business might be at a particular time. For example, your company is gone through a period of massive scale, and you suddenly are in a position where the technology is creaking and needs some help, then you may find that you're spending quite a bit of time building a strategy and a vision for how you're actually going to improve that technology, or pay down your tech debt. So you might spend a lot of time there.
You might also be in a company, for example that's not hitting its budget or hitting its targets. In which case, you are spending an awful lot of your time focused on how you can support the rest of the business in achieving their objectives, which might look very different. So I'd say there's no clear breakdown of what that should be.
My only caveat on that may be that, you should always be focused a certain percentage of your time on making sure your tech dash is not getting too big. And you have a long-term vision for where you're taking your infrastructure. But from carving up your day-to-day, the days could look very different depending on what's happening at the company.
[22:45] LF: As you spend your time on strategy, R&D and all of these other pressures, how do you make sure that you're not drifting too far from working knowledge of the codebase and what's happening within the tech stack?
RP: This is a great question because this is something I get asked a lot and particularly if people are moving from a very hands on technical role into a leadership role.
I would say there's two things. First of all, just because you're not coding, doesn't mean you're now suddenly not technical. There's an expectation around the technical knowledge that you have, whether you're coding or not. So that does need to continue, those skills need to be continued to be grown.
My only thing though again is, as your team size grows, and back to Doug's point earlier, once you get over a certain size, you need to actually let go and trust your team. Because if you're not doing that, it's going to be very difficult for your team to actually scale and to be able to do the things that they need to do.
So you need to change your mindset a little bit and move away from the codebase, even though that might be really difficult to do, especially if you've been a CTO that's been there from the very beginning, that's really difficult to step back. But you need to trust your team. You need to trust the people that report to you that they're actually going to be able to take on the mantle. Because if you keep dipping in, then they're not going to hold themselves accountable for making sure everything's on track. So it's very hard to do, but definitely as the size of the team grows, you need to step back.
[26:45] LF: When you're looking to bring people into the CTO role, how much do you weigh formal qualifications versus experience?
RP: So the role that I've played for the last four years...there's been very little of that has been dependent on my degree. I think it looks very different from an engineering role straight out of college obviously. I think that a lot of companies push a prerequisite on you having some sort of a degree. I don't think it matters whether that's a degree in psychology, a degree in engineering or a degree in something else when you get to this level. Because it's all about the experience that you've gained along the way. And that experience can be massively different.
So I would say, a degree is not essential for this role. I think a lot of you probably find that there's quite a few CTOs out there who have grown the company from the ground up, and not necessarily finished the degree or even went to college at all. I would say it's 80% at least the experience.
[28:37] LF: If you're trying to apply for one of these roles without the formal qualification, Doug, maybe you can comment on what skill sets they would need to have on their CV? How are they going to get past the robo screen?
DE: I guess I'd start by saying, I totally agree with Roisin. For me, it's much more about an experience than it is the qualifications. The qualification can be useful if you're trying to get a visa in a different country. But beyond that, I think we're very much about the experience. So I guess what I'd be looking for, especially if I was trying to find a replacement as a CTO is, who's got experience running similar size and complexity of companies in a similar role? And ideally, people who have helped to significantly grow the company in that role.
I mean, one of the interviews that we use quite heavily in our interview process is called the Who interview. And it's basically an interview style where we literally walk through their resume and we start with the very first job after uni, or if they haven't been to uni, just their first job in the industry. And what we're interested in is the story behind it..so why did they join that company? And why did they leave? And there's a bunch of questions around, what they think their manager at the time would have seen as their strengths and their weaknesses? What they're most proud of, and those sorts of things. And what we're trying to understand is the journey.
We're looking for people who are growth mindset, who are ideally pulled to companies by other people. So being recommended to companies, and who are joining companies for the right reasons. As in they're really passionate about the mission. They're keen to work in great places for great cultures and those sorts of things.
So I think, I mean to me, that's important regardless of role.
But I think on top of that with the CTO, I think I'm definitely looking for someone that's got lots of experience in the tech space, but also has a real interest in passion for the business side. And is being that translator in a bunch of different roles. Someone who's had a lot of experience in hiring, because especially in a fast growth tech type environment, you do a hell of a lot of hiring. And I think someone who's been a really good coach. Like someone who has not just brought great people in, but then set them up for success and let go of the reins essentially. And let them do great things. So if they're interviewing and saying a lot of "I did this", it's probably a big turnoff from my perspective, I want the people who are talking about how they set other people up to achieve great things and how they help to align a bunch of different initiatives in the right direction.
[31:47] LF: Emerging technologies, what's disrupting your sector? Play futurist for a minute, what do you think is happening that's relevant to your space?
AJ: It's an interesting question, right? Unless you're building a fairly technical product, like at the size we're at, the technology doesn't matter, like you're building a product that people are going to use, and you've got fairly limited resources, which means always by necessity, unless it is some technical innovation that is the core of your product.
There's nothing crazy, I mean, like an obvious direction for us personally, and I'd like to go in eventually, once we've collected enough data, to go down the machine learning AI route. And there's lots of cool things we can do there. And that's a fairly well talked about trend.
And obviously, as you get to scale, there's things around managing scale, keeping things to performance, keeping things consistent. But I'd say for a fairly small sized company, technical challenges, less what we think about and it's probably more building the right thing at all.
DE: We're in very much the HR space, I think HR tech, what we've seen over the last couple of years is, almost all of our competitors being acquired, and acquired by HRs in particular, doing more of a stack consolidation.
And so for us, I think the way we've been looking at that space is that for us to continue to get paid, we need to spend a lot more of our time and energy connecting into the ecosystem. So building API's, building integrations, partnering with other companies, in order to create the equivalent of that integrated stack that our competitors are now naturally getting, if you like, by being acquired by these larger Goliaths.
So that's... Yeah, specific to our industry I think, but there's definitely been a lot of consolidation over the last couple of years.
RP: Yeah, I think the other thing that's happening is certainly in the classified space, we're impacted by expectations are changing exponentially because of big companies like Google, Apple, Facebook.
So what ends up happening is, you're a relatively small company, a much smaller technology team. But people still expect your search to work the same way as it does on Google for example, where they have 1000s of engineers and you've got dozens. So I think that can be particularly difficult.
I think another interesting area that's been emerging for us is that the classified space has for a long time been focused around a listing.
So you have an item you want to sell, and somebody comes looking for an auction to buy, where we see now, because of social networks that people are much more interested in the profile of the buyer and the seller, they want to know who they're buying from, rather than just details on the item itself.
So that throws up interesting challenges for us as a business, because suddenly you need an awful lot more data about your customer than you had before. A lot more information, you need the customer to freely give you that information. And then you need to be able to make sure you keep that information secure. So yeah, just interesting challenges that we're seeing.
IG: Yeah, so I mean, software is getting more and more complex by the day. And the sorts of products people demand are getting more complicated too.
As a result, it's becoming more, more difficult for software teams to align on product, customer and business decisions. So one of the trends we're seeing is a increase in the product ops role coming out of companies like Silicon Valley companies, which is good for us because that's what we're trying to productize, is to create an integration layer to help these various teams to make aligned decisions on customer's product and business strategy as well
.
[36:49] LF: Let's talk about data management and security. How should early-stage companies think about this?
IG: So the strategy we took was to add a human element to it. It's a lot easier to care about something when you can relate to it.
So about communicating, what's the impact of a data breach in a real world situation? What does it mean to your customers if that happens? It's a lot easier to care if you can understand what that means to another person. But I mean, there's simple approaches that are quite effective, like principle leaves privilege. People should only have access to things they really need.
Yeah, there's a whole list of different things you can do like that. Also putting together good technical material, things for people to read through, understanding why you do things. So if you say, "Oh, we put all these AWS policies in place, why do they?... Why do we go from there? How do they work? If you give people something interesting to read, they tend to remember it a lot better.
[38:19] LF: Infrastructure and architecting the business - when you're getting started, it's really easy to make decisions that have a long tail impact to undo. If you are going to build your company's infrastructure from scratch again, what do you wish that you knew?
RP: I wish I knew the size it was going to be.
I think everyone has a similar thing. But I think a couple of things, It's great having high 2020 vision and all of that, but I think I would like to have understood how big apps were going to be and how prevalent they were going to be. I think we would have completely changed the structure of how we approached building apps.
Also, just in terms of the infrastructure itself, I think having something that's scalable is so important. And I think Gumtree, long before I started, was relatively small in Australia but then had a massive growth trajectory. And then suddenly, one in three Australians were using us every month. And all of our hardware and infrastructure was still hosted out of Amsterdam, because no one expected us to get that big.
So yeah, I think generally, infrastructure and things like decisions around apps and the technologies you are going to use. But things move so fast and the expectations change so quickly. It's really difficult to predict these things in advance, so I would say.
DE: I wish I'd known AWS's roadmap ahead of time.
The number of times that we dedicate a month worth of work towards a feature to work around something that's missing on AWS, only for them to then release something that's better. That just means we throw away our code, I reckon we have burned a lot of engineering time doing that.
It makes sense in a way, right? Because I know AWS is this layer that you can sit on top of, so you float right up to the limits of where they are today. And of course, the things you want them to do and the things everybody else wants them to do, so that's what they're working on. And then it gets released. But yeah, that's been just quite a few times in wasting a lot of engineering time.
[41:35] LF: What are some examples of times that you really messed it up?
DE: I've seen a few questions around micro services in the chat as well. For us, I think it was moving from monolith to micro services. And I think I'm still very, very much set on, that was the right move to be doing in terms of breaking up the monolith. The monolith I think it's the right answer for an early stage company...you've got one asset to deploy, you're all working in the same codebase. There's a lot of things you get for free working in a monolith, and it's easy to get the whole team around the conforming standards and so forth.
The problem with a monolith is the bigger it grows, the harder it is to keep that consistency. And by the time you get above about 50 engineers, it's really easy. I'm sure there are teams that have managed to get it working well. But you'd have to have really strong discipline around that team to make that work. And so beyond 50, our experience at least in a fast growth tech environment, was that the monolith became increasingly complex and increasingly hard to work in. And frankly just spaghetti code. And so that was what drove our intentions to move towards micro services.
I think we've been on a very long and painful journey that has seen us building and then rebuilding multiple moves and dumping assets and trying again in lots of different ways. And I think now, looking back on the journey, the thing that I wish someone had told me up front is that we went about breaking up the monolith entirely the wrong way.
And the reason for that is I think we took very much a divide and conquer approach. So we thought that breaking up the monolith was about analyzing the domain, working out which domain the boundaries of context made sense. And then separating out those pieces so that we can have individual teams take ownership over that. And long-term that is, I think still the right answer.
The problem is that when you move to micro services, or you move to that service oriented architecture, all those things that you got for free in the monolith, you don't have anymore, right?
So there's now, not just one way to deploy this, as many micro services as you've got as you've got by use to deploy. You have to build your own logging frameworks, own permissions frameworks, you have to worry about authentication, authorization, database backup strategies. And so if you don't work on making sure that you have standardized approaches for all of those things first, you end up with N copies of those in all sorts of different ways. And you've burnt a huge amount of engineering time.
So the approach we are taking now is that we're working on conforming and standardizing all those things so that we have one library that people leverage to do their logging that goes in the right formats, and that we can build API's off the back hand and so forth.
And so my advice would be, if you're planning on moving from monolith to micro services, start by pulling authentication out and make sure that your monolith is now a service sitting behind a web gateway. And maybe think about what other backing processes you can pull out. Maybe you build your database in a... So that you can standardize the way you do backups, or pull out logging as an as a library. Do those things way before, and come up with standardized deployment pads before you start pulling domains out. That's my advice.
IG: I'll be knocking on your door when we're ready to make a switch Doug.
I guess, I don't know if you can call this stuff-up, but this is just from an early-stage start-up. But we got really fixated on the product and direction quite early on, which can be quite dangerous. Because you can go in the wrong direction for a little, before you realize and it costs a lot of time. But downed tools for probably about a week and a half and just revisited everything we thought we knew. We've been through hundreds of customer conversations, we had lots of meetings, which were lots of fun. I made lots of mirror boards. And in the end, I ended up ripping out probably half the codebase, just because it was easier than trying to rework something that already existed. So I guess my advice there, and you've probably heard a million times before is, don't fall in love with the product, fall in love with the problem, because you'll be happy to pivot every time then.
AJ: I think to build on that, and what Doug was saying before, I think at least stage 30 super common mistakes, broadly building the wrong thing. But then in two dimensions, building cool product features that nobody wants, and also over engineering. So like, micro services from the get go, for example.
And I think I made those mistakes in the past, and now the approach I take is, to the trends question a bit earlier, instead of trying to predict where we're going to end up or what we're going to need in the future, at least at this point in time, optimize the stake because it's going to get ripped up and thrown out at some point in the near future no matter what.
And just treat everything like a prototype. And then, like Ian was saying, you're going to feel a lot more comfortable throwing it out and pivoting whereas otherwise you get attached to it, and there's too much sunk costs there.
DE: I totally agree. But I would also say, also be prepared because this will happen as a founder for that code to not be thrown away, I mean five years later for everyone to complain about find the code, because it's going to happen, but it's still the right call.
RP: Yeah, leads straight into mine, because that's exactly what happened with Gumtree where you end up in a situation where the application itself was built by a very small number of engineers which is hugely successful.
So then it becomes very difficult to add more people to the team when it's suddenly not as successful as it was before. But you need the investment. And I think that was a big learning for me, was actually, you know what? We can't just continue on adding, adding, adding, adding, adding, adding, adding.
At some point, you have to actually say," No, we need to stall here or at least put a percentage of our engineering team on clearing down some of this tech debt so that we can actually continue to move forward.
And I think that was a big learning for us... At the exact time, we needed to be able to move very quickly, we couldn't move quickly at all. And so it took us a long time to actually pay down some of that tech debt so that we could actually get back to a position where we could move quickly. So it was a big learning for me.
[48:55] LF: What is your favorite software or tool right now that makes your job easier?
IG: We operate asynchronously, because we're basically a fully remote company. So pretty much any tool that facilitates asynchronous communication, it's great because I'm not getting slack messages every five minutes about something, which is very distracting.
If I was to name one tool, I'd say Vanta has been really helpful. So security is a really big, big thing for Intalayer. We've got all of pretty sensitive data. So we take it very seriously. And Vanta just made it super easy to basically sock to, type one compliance. And they also provide a whole lot of monitoring and alert on things, it might be little things, or bigger things like, if you were to offboard an employee, making sure you remove their account access.
Diving into these topics regularly are what you can expect building your startup with Antler. Antler founders get access to exclusive resources and education on the startup journey alongside our global network of advisors, mentors, and investors. We are currently taking applications from individuals looking to find a team, launch a startup, or those seeking Pre-Seed investment. If you want to work with Antler apply now!
