The step from software engineer or senior architect to CTO can feel like a quantum leap. Knowing when to make the transition, and how, is often a barrier that prevents people from taking the leap sooner.
With that in mind, Antler recently hosted a CTO panel to share first-hand advice of those who have done it, with those who are aspiring to get there.
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.
Or alternatively, read the transcript below, including the audience Q&A. This transcript has been edited for length and clarity and starts from the beginning of the panel discussion.
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.
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 the celebrity. So if the contract ever gets that big, I'm handing the reins over to someone who can be more externally focused.
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.
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.
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?
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.
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.
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.
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.
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
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.
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.
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.
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. That might have quite privileged access that you probably should get rid of, so that'd be my one.
AJ: There's a YC startup in the recent batch called Motion, and it's essentially a Chrome productivity tool. And I got targeted or I don't know, I saw them three or four times and I'm like, “I'm going to give it a go." And it's one of those tiny things which just puts keyboard shortcuts in the right places like, checking your calendar, scheduling meetings, that type of thing. And it's a game changer.
DE: Heavy plus to Vanta because we're using it too and it is awesome. But I'd have to say for me, it would have to be Miro. And I think that's it's probably more of an indication that as a typical architect, back when we had everybody in the office, my favorite device was a whiteboard.
I love the whiteboard, it was great for a lot of the workshops. And that's probably the biggest thing I've missed since going totally remote for the last year or so. So Miro, I've just loved being able to collaborate and draw out and zoom out as much as you like, and do all sorts of things. So yeah, big heavy plus for Miro.
RP: Yeah, big plus one for Miro, for me as well. But I think the other two, it's actually funny, it's actually almost describing where we're at in terms of CTOs. But I seem to do so many presentations that death by PowerPoint is a real thing. So I moved to Canva and I absolutely love it just as a tool for making presentations so much more fun and easy to do. Especially with my own team, and just making the whole thing a lot more pleasurable when you're doing so many presentations. So yeah, big plus one on Miro as well.
LF: Thank you guys so much for your candid responses, it was fantastic. I'm going to hand it over to Sarah now to run the audience Q&A.
AJ: I think we’ve touched on this in the discussion a lot, right? But I’d say letting go of the tools, being prepared to move into more of a management role. I think essentially, it all revolves around accepting that it's a less technical role, and being willing to upskill on management and leadership, and coaching and not being super attached to your baby, which is probably the product you've spent the last few years building.
RP: I guess it would depend on what organizations they worked in. But I think I feel like if somebody has worked at multiple organizations, they get a broader view of some of the challenges that might come up, and they might have experienced different organizational structures, different strategies, different tech stacks, and a whole pile of things that could certainly help.
At the same time, I think if you've been a CTO for only a very short time at a company, then you may not have learned anything at all. So it depends on how long. But yeah, I would say, a CTO that's worked at least three years at a couple of different companies is probably worth more than one CTO, a CTO that's only worked at one company for a long time.
DE: I think there's certainly some areas in tech that have some massive gaps, right? Anything around the data engineering machine learning and frankly, like the S-array type space, where there's a lot of demand. And I think there's a lot of opportunity to help fill some of those gaps and fill some of those leadership gaps even.
Once you're talking about more, what that VP of engineering CTO, or C-level type role.I think it's probably broader than that. I don't think it's specifically about a particular area. I think it's more about the path to that is probably finding roles where you can take accountability for broader scope, if you like. Maybe it's working in a larger company, but in a role where you're taking accountability for multiple areas and keeping them aligned.
I think it's where I'd be looking for people that have got experience working across multiple teams. And where they're taking accountability for connecting across different business areas. So, not just for engineering, but how do we bring that to market working with the sales team? Working with the marketing team? Or taking the financial accountability? So owning the budgets and owning those sorts of things? I think experiencing those different areas definitely helps with the transition to a C-level or a VP level role.
RP: I think there are lots of barriers for women in technology in general, I think that unfortunately means that a lot of women leave the technology industry before getting to such senior roles.
You can actually see the data shows the drop-off gets progressively worse, but at mid-level in their career, which is right at the point where they would be thinking about moving up to this type of role. 56% of women in technology leave the industry, which is a phenomenal number. That's in comparison to 17% of men. So it's quite a drastic number. So that's a big problem.
I also think that there is a unique challenge with the CTO role in that it is such a critical role for the business, when a board or leadership team is looking to hire CTO, the risk is high. So they want to actually keep their risk profile as low as possible when hiring someone. And so that can mean that they promote someone from within the company that they know, or they go through a long 12 to 15 week process of interviews or whatever it is. They do whatever it takes to minimize risk. And if you're faced with a female candidate and a male candidate, it can often come down to a risk profile, where the board decided they're not going to take the risk in hiring a female CTO, because they haven't had a female CTO before or whatever it is. So there can be challenges like that. I think it comes down to, just the perception of women in the industry, unfortunately.
When I joined Gumtree as CTO, a couple of people approached me and said, "Oh we know X female sits CTO over here, and X female CTO over there." And I said, "Great, we'll get a group together and start discussing some of the challenges that we see as female CTOs. And I tried to find some of these CTOs, but it was incredibly difficult. I went through LinkedIn, trying to find another female CTO in Sydney, and I went through 35 pages of search results before I found another one. As a result, I created a Meetup group called Sydney female CTOs and CIOs. Now, we have nearly 500 members, which is amazing. Not all of them are female CTOs and CIOs, but we have a lot of people, supporters who want to actually encourage more women into these roles.
LF: To add to that, fascinatingly and quite impressively, I don't see this within Antler, Australia, but within every other context, I've seen equally qualified and experienced women, alongside their peers, not putting their hands up and taking that second seat position.
And so a big part of what I'm doing, when I'm engaging with women in that role is, but why not? And what would it take to make you comfortable putting your hand up for that? What's the worst that could happen? They say, "No. You just might get it." And recognizing the bias that many women have towards being fully qualified for a role, as opposed to largely qualified for a role. And really just encouraging more women to put their hands up, be willing to take that leadership role and own it and not wait to be shoulder tapped for it.
DE: I totally agree with everything that's been said. I think there's a lot of research out there that suggests that companies with more gender diverse boards, more gender diverse founding teams are more successful. I think particularly in the Engineering space, we have a big challenge as an industry that, frankly is multi-generational, it goes a long way back. I mean, I remember even in my degree, it would have been at least 95% men in my course.
So I think in terms of creating a gender diverse ecosystem, we start with but massively behind the eight ball and then as Roisin was saying, "We've seen larger drop offs." And I think a big part of that is that we don't have the role models.And It's a vicious cycle. So I think, one thing I would say is, if you're looking at two candidates that look similar, have similar experience, one of them is female, you should think very carefully about hiring that person because they've had a tougher time to get to where they are. So frankly, they're the better candidate. So I think that's definitely one thing.
To echo what Laura was saying around the research - the culture that we created has created a situation where many women won't apply for a job unless they tick every box, while men will apply if they're ticking most of the boxes.
And so I think those sorts of things, I think it's really important for people to think about in the way they write job applications. What's the language that you're using? How do you create job ads that make it clear that as a company, you care about diversity in your teams, and that you're being really clear about what really is important in the role and what's not.
I think it's on all of us to try and create more opportunities in the more junior levels and help to grow people through. So even if we can't necessarily fix the problem for our generation of companies, how do we make it better for the next generations of companies so that at least the problem is lessened as we go forward?
IG: I can't really comment specifically on the demand. But I mean, with no-code and low-code solutions, you're trying to abstract the complexity.
So how much functionality can you capture versus how much complexity can you abstract? It's a really fine balance. And then sure, you could add a configuration layer on top, but then you're getting back to complexity, so there's this ongoing balance. So I suppose, in my opinion, there's always going to be a world for both. It really depends on the application and the complexity that the user wants. I mean, to use an off-the-cuff example, A CMS platform like WordPress is supposed to be super simple that anyone can put it together, but you still get WordPress developers. There's still people who make a living out of configuring these tools. So I think there's always going to be a place for both.
LF: Massively controversial question. My N equals one view on this, is that companies fail on market and team nine times out of 10 before they fail on technology. And so you absolutely have to have the technical capability within the business to build your business at scale. But for that zero to one, it's all about proving whether people give a damn, and are willing to engage with your product and pay money for it.
There are some products that are so technical that you cannot do that. And you cannot low or no-code your way into something that proves the market. However, there's a huge chunk that absolutely can do that. One example of a portfolio company who just closed her series at round, in four days, which was amazing. Her MVP was a Slack channel, she proved the market by mocking up the value proposition in a Slack channel. And that you don't have to have code for that. And then as soon as you prove that and can get investment, you can get that amazing technical talent around you.
So it is specific to how important the tech is to the business. And how much market risk sits around that opportunity.
AJ: I'm not 100% sure what gracefully means. I mean, again it depends on the size of company you're going into.
If you're going into a tiny company, then if you're a product manager, you probably do want to be technical enough. Chances are, you're going to be running a lot of code at the beginning. If you're going into a larger company, then and I'm probably not the best place to answer this. But I think a lot of the experience running and managing product teams, especially if you grew with a company and you were leading engineers at some point, should be transferable into a CTO role at a medium to large sized company.
RP: Yeah. I can jump in, I agree with you.
I think the only caveat though is, if you don't have a strong engineering background, then you need to have a really good team. So you need to hire the right people onto your team that will actually help you fill the gaps. And I think that's probably advice for anyone who becomes a CTO, you're going to have some gaps. And you just have to make sure that whoever you hire onto your team can actually help you fill the gaps that you have.
I actually came from a product role into a CTO role. But I had previously been in an engineering leadership role, so I did both. So it's definitely possible. But if you don't have that Engineering background, you need to find a way to plug the gap.
DE: I totally agree. It's interesting, almost every product manager I know has come from being an engineer. So I think in some ways, it's a transferable role.
And it's partly because there is no degree in product management, right? So most product managers, they've fallen onto the more of the business side after being in an engineering type role. I think there's a lot about the product management role that gives you a lot of skills for being a C-level in a company, much more so than an engineering role does, a typical engineering role. So from that perspective, I think it can actually be quite an accelerator to a CTO type role.
But I totally agree with Roisin. The challenge is, as a CTO, there's an expectation that you're going to be setting the technical strategic vision for the company. And I think you need to be technical enough to be able to do that, or you need to be able to rely on some people that have that skill set. So I think that's really, really important.
I think that the opposite is probably also true. If you've only done the engineering side, how do you gain some of the business knowledge on how to earn the skills that you would gain in a product manager type role?
LF: First of all, would be to embrace the strong opinion weakly held mentality. You need to strongly believe in what you're doing. But it needs to be weakly held, in that you're always willing to learn and change your opinion and adapt and evolve how you're approaching and thinking about things.
Get embedded alongside the people that you want to be using your product and deeply understand how they experience the problem. But one often overlooked thing, particularly in the medical sector which is where the breadth of my background is in one of the workflows. If you're asking people to change their workflows, particularly in an enterprise or a medical setting, that can be really difficult, if that's an ingrained behavior.
So you have to understand all of the complexities around the commercial uptake in the opportunity...that you're going to get, not just scratching your own itch, but that you're going to get 1000s, or 10s of 1,000s, or 100s of 1,000s of people to agree, "Yes. That's also my itch, and I would also like it scratched, and I'll pay money for that."
And so that way of thinking about the commerciality of the opportunity is really critical.
IG: Jira, Notion, Google Drive, I use notepads, I've got about 15 iPads going on with various things.
But in terms of task management, we put together quite a structured workflow from the start, just so that people coming in had something to work with. Because when you are a start-up with three founders, there isn't this work culture to push things along. So having a nice structured system feature branch development, UAT staging, having all those, everyone gets to have a check and see what's going on, also keeps everyone in the loop.
We use Jira as the main task tracking tool.
DE: Yeah, Jira and Trello tend to be the two most common across most of our teams. Personally, I've been trying to use to-do lists which I use badly, I would say. But I mean, in terms of tasks it is a tricky problem... I find myself split across eight different tools all the time.
I think it's probably more about discipline rather than what specific tool you're using, which is something I'm still working on personally.
RP: There is the CTO summit, which happens in Sydney. I think it's every year, it's run by YOW! and they do record all their sessions, so I'm not sure if they're freely available online. You may need to register or sign up or something like that. But there's some great talks in there that I would definitely recommend. I have yet to read a book on how to become a CTO, maybe there's some that people could recommend. But yeah, definitely, I've found that conference very helpful.
I also follow lots of interesting people on Twitter. But if anyone wants to actually broaden their horizons and have a few more senior female technical people, have a look through my following list. One of the women that I really enjoy is Charity Majors. And so she's the CTO of honeycomb.io, which is an observability company. They build observability tools, which I really, really like. She could be a bit full on. But it's always interesting to hear what she has to say, but yeah.
DE: So I think it's really important to find the support network. So other people that you can learn from or can be your coaches, whether that be paid coaches, or whether it be ideally also people who have been CTOs, or are CEOs in larger companies that you can learn from? What groups can you join? I mean, Roisin was talking about starting a group for female CTOs, things like that.
I think it's really important to find that network that you can support just so that you've got someone to ask those questions like, even if it simple as things like, "What are your salary bands?" But much more complex things as well like, "How do you think about these problems or those sorts of things?"
So I guess probably my advice is that, don't try and do it on your own, there's a lot of other people out there going through similar things or have been through similar things. And how do you get the support from them that you need?
IG: I guess this is more generalized to just joining a startup, because I guess that's where my current experience is more relevant, but you'll never feel ready.
As a child, you look at adults and you think they've got it worked out. And then when you become an adult, you look at other people, and you think they've worked it out. Everyone thinks everyone else has worked it out. No one knows what they're doing. If you think you've got the grit to keep trying things, and you're ready to just keep pivoting and changing, you're not stuck on the same thing, you're as ready as you're ever been.
AJ: I think we've touched on this one quite a bit, but don't get too attached to the code and the product and what you're building. Just be comfortable, I mean letting the product take its own direction, but also removing yourself from whatever you've created and giving it away to other people.
RP: Yeah, I agree with everything that's just been said totally. Especially what Ian was saying, "You'll never know until you actually just do it." Somebody gave me some good advice at the beginning, which was to get yourself almost like a board of directors, a set of personal mentors, but a group. Get some people that you can really trust their feedback, that you can bounce things off of. I think that's really, really important, and that can be inside and outside of your organization. You need that independent view. I think that was really good advice for me.
This article was written by Sarah Kimmorley, Director of Communications at Antler in Australia.