How to CTO good
Owen Evans is a man who knows a good thing when he sees it. Involved in startup life for so long now as a tech leader, I doubt he remembers what a corporate desk job looked like. We were curious to know why he went down this path, what makes him excited by startup tech, what founders should avoid with their product, and where to next for the master CTO.
Owen, tell us a bit about how your career progressed up until this point?
The short version is just following the advice my dad gave me as a 15 year old which when something along the lines of “You’re going to work for 80% of your life so make sure you do something you enjoy”
But really I’ve always been fascinated with computers, I was the geek who got away in computer classes because I knew more than the teachers back in those days, I built my school intranet when I was fascinated by the web and that led me to the traditional path of taking Comp Sci at university, during the dotcom crash. I remember the lecturer talking to me and saying that “if you’re here to make money you’re in the wrong course, all the money has gone”.. How wrong he was but also cemented my motivation to be there.
Out of university I did a stint as a QA Software Tester at a bank in the middle of the UK called Egg, and helped them automate their test suite, this was early days of test automation and I was a consultant for a small startup in the space. I loved the autonomy that I was provided to find the most pragmatic solution for our clients. Then I got poached to go and join an internal skunk works team building out a product and also experimenting with the way we should build software. I loved it, we tried eXtreme Programming and I fell in love with the idea of keeping teams as close as possible to customer needs, I didn’t really know what other ways there were to build software. From there I’ve always been drawn to the early stages and small teams of people getting shit done.
I came to NZ in 2007 and quickly heard of a company making waves called Xero, but was actually pushed to apply after interviewing for a job at Raygun (which were called mindscape) earlier in the year. I joined that ride when we were small and scrappy, but just at the IPO time. I was warned that they were burning tonnes of cash and didn’t have a hope but I could see a glimmer of a great idea and a small team that I could learn lots from.
From there I’ve always been focused on staying experimental and nimble, I was Chief Architect at Xero for a few years towards the end of my tenure there, which basically gave me a good glimpse of team leadership and management but I will admit those early days we prided ourselves on not really needing managers, which is just dumb, we ended up cementing a whole bunch of unwritten/unacknowledged power systems that probably took for ever to unravel.
Then it was a startup called Hoist (well actually my first startup was called uSnapUs but that lasted the whole of one year before we invalidated the idea)
We ran out of runway, after about 4 years, for that idea unfortunately and weren’t focused enough on the right things, so I had to do my first redundancy delivery to a team and found myself out of work too.
I joined a company called 8i which was doing amazing things in the VR/AR space, they had some really cutting edge research and I’d never been at a research driven startup before, so I wanted to learn what that would be like. I also didn’t know if I could work in a team again as you get a bit lonely at the top of a startup. So I came in as a lead engineer. That company’s main struggle was (as with most startups) to really find product market fit, and we tried a number of avenues. I also got really interested in engineering culture during my time there as I had two very distinct backgrounds to meld together from the engineering team, especially once I took on the role of VP of Engineering. This is a gross generalisation but at one extreme we had product engineers who were used to quick experiments in the market and getting things released early and often and then at the other extreme we had people who had come from computer vision and films who were used to one chance to get things right (basically once the movie was in cinemas you couldn't do much more to it) this led to a tension that I was sure could be navigated but sometimes boiled over into animosity. I loved the challenge of working there and still have some firm friends from that time, but really it was the first inkling that there was a lot that culture and values can add to software teams and it’s something we don’t really get much coaching or focus on in NZ.
My next role was at a 100% distributed company called Zapier, they wanted someone to lead a specific team they were spinning out to build their integrations and I knew the team from my time building Hoist and loved the model they had, a 100% bootstrapped and remote team working from around the world. I loved my time but there’s one thing that remote is hard for and that’s timezones. I was managing teams across time zones in Africa, the USA through to Australia and that led to a really elongated day and terrible starting hours.
I met Mikey (CEO at JRNY) during my Zapier work as he was looking for advice on how to grow their engineering team, he was a passionate individual and I could see a huge advantage in fixing the insurance landscape, so I took on the role of CTO as a way to help them get to scale. Unfortunately insurance is also one of the most risk averse and slow moving industries so it became impossible for us to prove out that hypothesis in the time we had.
In the meantime I’ve also lent my hands to coaching technical leaders across NZ startup ecosystem, helping a number of them get to grips with the problems of managing teams, growing teams, hiring, holding on to values, making good pragmatic decisions, opening up to remote work, working out where their weaknesses are as a team, and pretty much anything I can lend my hand to as a somewhat experienced leader.
Why start up life? What made you start your own startup? Tell us about that journey, the good, the bad and the ugly.
TBH I don’t think I could hack a non startup role. I’m allergic to inertia and once you get past a few hundred people you’re inevitably going to have to work out how to wade through processes that were good at one time but didn’t scale, or are simply there to save someone from getting fired. The last straw for me at Xero was wanting to spin up an experiment but because of procedures and processes it was going to take me 3 months just to get a test machine to experiment on.
For Hoist the start was very much me being approached by a friend and ex-xero Andrew Butel. From Xero I saw the advent of the cloud really take off, and left just as they were starting to get to grips with what it would mean to move off managed hardware to an infrastructure provider like AWS. I saw there was a layer above that that would be incredibly useful for the teams we saw building on the Xero API. These were small providers of add ons, the early ecosystem of Xero was bulging with nice software tools and they all ended up with cobbled together solutions on someones machine under their desk or something like heroku. We thought we could provide a huge amount of value by giving building blocks for integrations and allowing them a safe and secure environment to host on. We basically saw and I’d like to say we were part of the birth of serverless computing.
We raised a small amount of seed capital and took on a grant from the early days of the callaghan scheme, and set to work.
We fell into the biggest trap of not releasing early enough, not experimenting with our customers, we were trapped into a 12 month roadmap too by the way we’d written the grant application. Basically we did everything wrong. We got to the end of the 12 months and had no real validation from anyone who would actually pay for the thing. Developer tools is a hard market, every developer will tell you they can build what you’ve put together (they just don’t know when they’d have the time to do it) and don’t really like spending money on tools.
So we limped and pivoted, we headed to the west coast of the USA and pitched to all the VC firms on sand hill road (a famous road for basically having a VC firm on every block). We also had some strong interest but not enough to get over the fact we were not in the states full time. And raising from NZ was met with a lot of blank looks. Developer tools weren’t understood and we didn’t have growth, we wanted to raise a seed round but needed more money than you’d usually get for a seed in NZ (seed rounds in NZ were/are a fraction of what you’d raise at seed in the west coast) in the end we lost our way, found little traction and really didn’t execute on the business right. The tech was amazing though of course, and I’d love Hoist to exist today, there’s very few years go by that I don't hit a problem I would have solved easily on the platform we built.
What has been one of the best lessons you've learnt from startup’s that don’t work out? Any advice?
As a technologist, one of the hardest things to learn was that the tech really doesn’t matter that much. I don’t care how you build it, in fact it’s better not to build at all. You always have to be focused on value and proof. Everything has to take you to the point where you’re actually a company and not a startup any more. Everyone talks about laser focus but without really knowing what that means, they focus on getting the team to deliver the thing rather than focusing on “is the thing the right thing and how will we know if it is” or “is there a better way to prove this is the thing”
Beyond that there are a few other things that I hold myself accountable to:
You can’t undervalue the culture of a company, you need everyone to be focused on outcomes together. The best way I’ve found for this is being overly transparent, tell people what’s going on and treat them like adults. That’s really what keeps them on your side and not worrying about their resume.
Every founder has power even if they’re not given the position. No one can say no to a founders request, they are really the embodiment of the culture of the company and it’s hard/impossible to change the culture of a company without the founders exhibiting the same values. So if your a founder, fix your own behaviour first
Make sure failure is ok, everyone falls over, everyone fails occasionally, we learn a lot so make sure you have an open environment to failure.
What should founders, who don’t lean to the tech side, do to make sure their tech is scalable and secure, even right from the start?
Don’t think you have to build it is common mistake number one, so many non tech founders come to me to get advice on hiring the technical founder or finding the CTO. Usually my advice is to outsource anything you can. There are great companies out there that can build your first few versions. Remember you’re likely to be wrong anyway, on your business as well as the tech, so don’t start building foundations till you know a bit about the house you want to live in.
Don’t build for a scale you don’t have. Stop kidding yourself that you’ll have a million users from day one. Build for the problems you have now and in 3 months. These are usually simple things like making sure you have at least some separation of responsibilities within your codebase and being explicit that everything is an experiment.
Take privacy and security seriously, you’ll never get them back. This is my only caveat to not building, make sure you get some advice around security and privacy, have someone come in and teach you how to use a password management system, learn how to use two factor authentication. Simple things that can help you scale your business when you need to but are hard after the fact
What tech themes are ones to watch, and which ones should you avoid?
I’m still pretty bearish/sceptical on blockchain technology. I’m not a fan of currency investment vehicles so I’ve never been drawn to bitcoin and blockchain is a very specific problem that people seem to be over-applying (queue metaphor about a hammer and a nail). I think blockchain has merits I just haven’t seen the use case yet that makes me go “that’s it” which means most of the times it’s used as marketing speak for “magic”
I’m more interested in the rise of deep tech startups, like RocketLab and Halter, I think if you can get good integrated software and hardware solutions we are really looking at the future. In the past these were just so hard to get off the ground as they needed so much capital investment the risks were too high, but it’s great to see some wins in this space and hope we get more.
What makes great technical leadership?
Technical people can get hung up on technical knowledge being the ultimate goal. But good technical leadership is a completely different beast, IMHO it’s actually understanding the place of technology in the organisation and in the world as whole. There’s very little point in tech on it’s own and good leaders know that really what matters is making the right trade offs and helping the teams thrive below them.
Good technical leaders
Foster a place of intellectual safety, how do you get to say your ideas without anyone else biting your head off or having an argument, or being blamed if it’s wrong
Are transparent about goals, they know what the actual outcome is and have mechanisms to teach their teams about the actual goals of the company and wider organisation around them.
Know when to call BS. Every idea is a good idea until you provide the constraints, a good leader has to be the arbiter of those constraints and call it when ideas go beyond those bounds. Or just call a decision when no idea has more merit than others
Gives space for all to be heard, leaders are often seen as extroverts and good communicators, some of the best in our industry really aren’t that. A good leader fosters a culture that everyone can feel heard and contribute, which usually means confronting our own bias’ and privileges to give space to others
Are servant leaders and coaches. Really the best leader knows they don’t know much, they’re always willing to learn from their team and know that often their best role is to just get out of the way of their team. Give out autonomy and let the team flourish on their own, be good at delegating and allow people to fail. Then coach them to learn how to approach it differently next time
Care about outcomes more than technology. The tech won't kill you but chasing the wrong outcome really, really will.
As a CTO, what does the role bring to the startup exec table, and what should founders look out for in hiring for the role?
Let’s face it, the usual startup CTO is actually the founder who wrote code before the company started. This is the most common way and the founders are often learning business together as they go along. Some startup CTO’s really want that role, others don't and would prefer to remain on the codebase. It’s ok to admit this but at one point the technical founder is going to have to make the choice as at an Executive level the goal has to be ruthlessly in the direction of validating a business and finding product market fit, then scaling to the market.
A good executive CTO will bring the constraints to the table that technology imposes on things. They’ll be focused on how to solve the problems that the business faces but with a technology lens, they’ll be able to compromise and find pragmatic solutions and collaborate with design and product teams in a productive way, but will always be focused on the goal at hand and not over engineering anything.
Beyond that they should be advocates for their team and allow their team the trust and autonomy they need to really deliver. Too many startups are hindered by founders who don’t know how to give up and delegate trust. And they maintain their steadfast determination that everyone is lying to them about how long everything will take. A good CTO will listen to the team, challenge assumptions but in the end trust that the team has taken things into account and will fight for that being acknowledged at a top level.
We’re also a massive cost centre for a business, once code is written it’s inertia that you’re putting on change later in the business (plus the operational cost of running the code etc) so they should, somewhat perversely, be an advocate for not building the technology. So many companies get bogged down by the sunk cost mentality because the tech team built things too early.
What are you up to now?
I have a small consultancy company that’s basically my vehicle for helping as many early stage startups as possible. I’m really focused on helping founders get over the initial technical scale before they can afford to hire a full time role, or maybe when they have a technical founder who wants to upskill or just get some coaching.
Really I’m about helping you get your growth off to a good start and coaching founders and execs as I've found exec coaching, especially for technical teams, is not something that’s been done well in New Zealand.
My aim is to invest my time into helping as many startups grow as possible, because I see that as the best way to grow NZ inc.
