What I am here today to talk about is most of the challenges that I've had to date in my career. Some of the things I've learnt that in hindsight, I wish people educated me on. There's huge topics I'm touching on here. The other lens is what am I seeing in market?

The Need for Growth and Scaling

Scaling for me is the most important thing. If we don't scale well, it affects staff retention, developer productivity and the list goes on. Getting from phase two to three is the hottest. It's an economy as a scale challenge.

What's Your Biggest Challenge as a CTO?

One of my biggest challenges as an ex CTO was this. I needed to make a big decision on what programming language we would go with. Your programming and framework decisions will indirectly affect your ability to scale and the cost of scale for people.

Front End, Back End, Full Stack

Front end, back end, full stack, what do I do? Native mobile app development, responsive? The answer is it depends. Your engineering team should somewhat reflect your product organization. The decisions that most of you will make will affect your ability to scale your team.

Outgoing and managed services: The future of IT engineering

Don't think of outsourcing as a threat. View it as the opposite. You want to optimize where your engineering resources are being spent and make sure they're aligned to where you are. The opposite end is I try to encourage people to never say no.

Beyond Australia: Partner, onshore and nearshore

The more time zones you introduce, the more the complexity and the more hand off. There's no easy way of addressing that, but there are techniques.

What Do I Do About Security?

The other big one that is coming up a lot is what do I do about security. Increasingly in the Australian market, there's a lot more rigor and focus. It is compounded by access to talent here. It's a huge challenge.

CTO vs VP of Engineering: What's the Difference?

What you do and what you need to do is relative to your organization and the stage. What matters is what does your company need from you at the stage of your company. One of the big things that comes up, especially as companies start to scale, is tech stack consolidation.

Onboarding and tech stacks

The other lens that I apply here is developer onboarding. If you have this proliferation and your onboarding is high, you're going to lose experienced talent within two to four weeks. CICD with very top of mind. Just recognize what you're good at and what you are not great at.

Focus on your core business: Leverage IaaS, PaaS, ISVs and SaaS

IAAS and SAAS are in the context of scale. The reason why I work for a cloud company is I believe in SaaS and ISV. If search is not a differentiator, then challenge yourself on why are you running it?

What I am here today to talk about is most of the challenges that I've had to date in my career and some of the things I've learned that, in hindsight, I wish people educated me on earlier.

This is a really condensed chat.

There's huge topics I'm touching on here.

The other lens is what am I seeing in market?

I have the f the fortunate opportunity of seeing customers at different sizes, different stages, and different challenges.

And I've, been across markets that are going through hyperscale growth.

A couple of my old team members in the room, a couple of my old customers are in the room feel free to have a chat to those that I may have worked from with before.

Now first and foremost what I am I here today to talk about growth and scaling, especially in a potential market slowdown?

So a lot of people understand growth, giving me more money, and I can grow my team.

Give more money and I can do more things with tech, but not a lot of people get the other side of this, right.


And scaling for me is the most important thing.

If we don't scale our engineering org and the org get large hurts.

If we don't scale well, it affects staff retention, it affects developer productivity, and the list goes.

And the hyper scales, the big brands, the big end of town, they know about this and they get this right, but the reality is most of us are somewhere in the middle or earlier.

And the reality is when we talk about scaling as technologists, we go, ah, load balances, elastic scaling.

Yeah, we got that.

No, that's not what I'm here today to talk about.

I'm talking about people, process and tooling.


There's no one size fits all right?

This is a approximate model of me just putting some slides together, but roughly your journey looks like this, right?

You'll be at a, startup or a a phase one phase, right?

Relatively self-contained teams.

Pretty easy.

Everyone's in the same office in the same time zone, probably top echelon of staff, maybe some co-founders.

So you're going pretty well, right?

You are a cohesive and self-contained team.

Phase two is where most of us are, or most companies are, right?

That's the next step, right?

We start to introduce team leads, eng managers.

The wheels start to fall off because we haven't thought about scale.

The wheels start to fall off because one or two people manage our dev boxes and oh, they're on leave, so we can't do a deployment, right?

We all have similar stories in the room.

We're getting a couple of nods.

And then if we're really lucky and we've got a beautiful product in market, we need to accelerate the scale up.

Getting from phase two to three is the hardest.

It's the hardest, right?

You only have to talk to the hyper scales where they were at in their individual journeys, and they will tell you, sorry, I'm just bumping my slides.

They will tell you how hard it was to get from two to three.

And that is everything.

That's from how do we attract and retain staff?

How do we onboard people?

How do we make them effective?

How do we get company culture right?

It's huge and that's why I'm not gonna do the topic justice today, but I'm gonna give you insight into where I've spent most of my time as a customer.

So customer side and where I spend a lot of my time chatting to customers.

Team is huge.

Now, I'm trying to be impartial with software languages here, but I'll, share an opinion.

I'll, when you're looking at software languages, the other thing is make be clear on where the data's coming from.

Some of these are survey based.

Some of these are tooling based, and they're only as good as their sample size.

So just be careful when you're using data sets.

The reason I'm calling this out is when you are making decisions around hiring and what programming languages or frameworks you're going to pick, indirectly, it's actually starting to create bias on the access to the talent pool that you have.

And what I mean by that is if you pick a foundationary language, Java, .NET or equivalents, there's more people in the world that know that.

And there's more people in the local market that you can get.

If you pick one of the next gens, that's okay too, right?

Go, Dart equivalents.

But there's less people that know that.

And cost starts to add a factor here, right?

It's an economies of scale chaallenge.

If you're picking one of the hyperscale languages, less people, more people are tr...

more companies trying to get them.

You're gonna pay a premium if you are accessing a wider talent pool.

More diversity across early stage career, mid and established, and a bit more predictability with market rates.

So one of my biggest challenges as an ex-CTO was this, right?

I needed to make a huge decision around, it was actually at Domain, so I was building out and scaling out our B2B and FinTech businesses, and I needed to make a big decision on what programming language we would go with.

Now, at the time, the technologist in me is I really want to go with Node or Go or Dart.

And I spoke to a lot of colleagues in industry about that, but I went with, I can't remember, I think it was Java or .NET, doesn't matter.

But I went with that because I knew I had to build a team quickly.

I knew I didn't have the top end of town dollar, and I needed to be realistic about how quickly I could build a team and how quickly I could scale.

So that's my highlight.

Your programming and framework decisions will indirectly affect your ability to scale and the cost of scale for people.

The other big one I get is front end backend, full stack.

What do I do?

Native mobile app development.



The answer is, it depends, but let me start with front end and backend engineers and full stack.


In an ideal world, we want full stack developers, right?

We all want that.

We want people that can comfortably interchange between the two and be the best front ender and the best backender.

There is a lot of people that can do that, especially in the ANZ market, but it's, hard, right?

We've heard about everyone including non-traditional businesses like banks now being some of the biggest technology employers in Australia.


So my guidance with this is, Just be pragmatic, right?

Recognize that what we want-full stack engineers-and what we have access to, especially in the ANZ market, there's a bit of a disconnect.

But also look at what does your business need and how does your business operate?

And I'm not gonna talk too much about DevOps and target operating models and all that lingo.

But your engineering team should somewhat reflect your product organization.

So if your business is very heavy with consumer based interaction, right, website, mobile, then you're probably gonna have bias towards a front end engineer.

If you are more of a B2B business, you still need those skills.

But for a B2B business, more often than not, you're gonna have bias towards the backend engineering.

And the last quick insight I'll quickly say here is, and it goes back to my previous slide your, programming language selection and choices also adds weight here.

So as an example, and I'm not promoting the use of Angular and Java, I'm just using it as an example.

Please don't belt me up at the break for mentioning that.

But the reason I mention it, and alongside Node, is there's complimentary frameworks and languages here.

So using the example I just gave you, I may be able to get a really strong backend Java engineer who's pretty decent at Node and is probably good at Angular.

But if I go React on the front end on going to need React front end engineers and I, and React front engineers will go really, well with Node, especially on the the API side.

So have a think about this, especially when you're making these decisions and going through your step growth.

This, the decisions that most of you in the room will make will affect your ability to scale your team.

This one's a bit sensitive but gonna, but I'm gonna mention it.

So I'm, a significant believer of protecting internal engineering capacity for unique product value.

So product engineering for me should be spent on adding incremental value to your customer base.

What that means will vary from company to company.

And before I go into these definitions, I'll use a live example.

So going back to the front end, front end engineering example, how many of you have been asked by your marketing teams or product teams to build one-off marketing websites?


Single page app might be around for a campaign and it'll go away, and it probably has WordPress behind the scenes.

Now, if you don't bias towards what I just said, what will generally happen, and I did this many times in the early stage of my eng management career.

You're gonna put your front end engineer on that marketing website, right?

Probably it will work.

But you have just lent out one of your most premium engineering resources to a one-off marketing website, and I intentionally use that example because there's, without talking about the huge end town the, global financial, no, the global service integrators, we know the list, closer to home, there's no shortage of ad tech and digital tech companies that are probably nicely placed to help those.


So the idea that I'm trying to create here is don't think of outsourcing as a threat or partnering as a threat.

View it as the opposite, right?

You want to optimize where your engineering resources are being spent and make sure that they're aligned to where you are, right?

Your customer base, your revenue lines, et cetera.

And this is actually the expectation of your wider management team, right?

They're You're probably all going to be in these cycles anyway, but they're gonna want to know who's doing what.

And the opposite end is I try to encourage people to never say 'no'.

So one of the biggest mistakes I made early in my career is my marketing team would come to me as an example and say, 'Hey, we need to build this thing'.

And I'll say, 'Hey, we're busy for four months.

Go and chat the product and put it on the roadmap and tell me when it's a priority' . A lot of us can relate to that.

Same conversation-'hey, we're at capacity.

We can make some priority decisions.

However, I can see this is of importance to you, so let's work together on how do we solve for that', right?

If the spend and the ROI is there, then that's a good way of scaling your team that otherwise wouldn't have happened.

And it's a good way of making sure that your staff and individuals are not overloaded, right?

It's a way of protecting your engineering capacity, 'cause if you don't do that, you have a huge backlog and people constantly trying to get more done in a sprint cycle.

So you get the idea there.

Very, quickly.

When we talk about outsourcing and managed services, and I was here in my early stage career, we all think about the far right-offshore outcome.

Let's we're getting rid of some local devs and, that, that model is true.

But there's two other models that I wish I knew about earlier in my career.

Staff augmentation.

So this is where a partner can temporarily give you staff to augment your team.

I'm seeing a lot of this in the ANZ market, especially with challenging engineering skillsets.

And the other way, the other lens I apply to this is while I hire, I need to address the gap.

So it staff augmentation can be used as a technique to help you with the current market.

And the middle one is project based outcome based.

Not gonna spend too much time on this today but where you have, and I mentioned an idea, the marketing-based MarTech sites, that could be wrapped up as an outcome-based engagement and given to a local dev partner or a digital agency.


It's not just a, it's not just development here.

You can apply the lens across most things.

The other big one, and I was chatting to a couple of individuals in the room about this already., That is continuing to come up and Covid has really accelerated it and I've intentionally called it 'delivery models' 'cause you don't need to interlink this to a partner onshore, offshore and nearshore.

We all know about, anytime we think about globally distributed teams-outcome, partner, offshore.

Doesn't need to be.

Nearshore and onshore is what most are doing at the moment.

So we're seeing this a lot with the banks.

As an example, I think it's Westpac Bank.

They're opening up offices in Brisbane, NAB opening up offices in CBA.

So they're creating an office presence outside of the states that they usually dominate in.


That's a good example of an onshore delivery model.

Nearshore is same time zone.

Alright, so for our Kiwi friends in the room.

Alright . Don't just think about Australia.

Look at who else is in our time zone and what's the time zone overlap.

And New Zealand is a really good example of great engineering talent, good brands that people have come out of.

And if you slightly adjust your thinking from, say, Sydney, Melbourne, and Perth, another great way of helping to scale your eng team.

There's a lot of challenges here.

I I would typically have a one hour chat on different approaches to manage all the things in the far right.

I'm here for most of the day, so please come and grab me.

We can chat about these at length.

It's hard, right?

It, the more time zones you introduce, the more the complexity and the more the handoff and the more they interdependencies.

There's no easy way of addressing that, but there are techniques.

The other big one that is coming up a lot-always has without mentioning brands, there's been a lot in the news lately-is what do I do about security?

And without mentioning brands I've been in companies where I had no security team, I'd had no dedicated security or compliance person.

It's pretty common.

We would typically stop at using a partner to come in and do a pen test once a year and we'd tick some boxes and that was about it.

But the reality is the saying there is so true and increasingly true.

If you continue to operate like that, it's only a matter of time.


And increasingly in the Australian market, as we've all seen, there's a lot more rigor and focus.

And I can only imagine the conversations that each of you are having on, 'Hey, that thing happened in the news.

Could that happen to us?' Right?

So what do we do about it?

And it's compounded.

It is compounded by access to talent here, right?

Everyone's trying to hire security and cyber people, right?


You only have to go to the job listings on most company websites.

So it's a huge challenge.

It's a huge challenge.

We've underinvested traditionally a lot of large companies and universities and technical TAFEs and equivalents.

We're trying to address this.

We will, that's three to five years away though.

So we're all challenged with what do we do.

And I mentioned partner in the context of penetration testing.

I trust most of you know that there's all the compliance frameworks, ISO, PCI, SOC, that you can do.

So you can do something called a 'ISO gap assessment' or a 'SOC gap assessment'.

That's a really good way as CTOs and VPs and equivalents to go and get more funding, right?

Get an independent to tell you what you're not doing well.

Get a list, get it in front of your executive and say, 'Hey, I need this to fix this'.


It's a good way of removing ambiguity.

It's fact-based and it's an independent, so it's a technique I've used many times over to get more funding to do something about engineering and security incident response.

The other big one, and depending on the market you operate in managed SOC is coming up.

I didn't know about SOC early in my career, that's why I'm mentioning it.

SOC is I'm gonna simplify it with the time we have, but it's like operational run for security.

So if an incident occurs, what do we do?

So run book, false security.

Threat modeling.

Those zero day vulnerabilities when they happen, how does our company respond to that?

My open source XYZ framework has a vulnerability and I need a patch.

Where, are we at?

So if you're struggling with a lot of this and all the slides I have today I'm, sharing with you, just feel free to do some searches.

There's a lot of really good Aussie partners, right?

Doesn't to be the big ender town.

There's really good Aussie shops that can help you here and New Zealand.

Not gonna spend too much time on the CTO and VP of engineering battle and trade off and difference.

But it comes up a lot.


The slides that I had, there is an attempt at a high level to articulate the differences.

But the reason I skipped through it is I didn't want you to concentrate on the words.

I'll, give you the pack.

Titles are titles.

What you do and what you need to do is relative to your organization and the stage, right?

I've seen CTOs in a startup of three people, and I've seen CTOs in a company of thousands of people, right?

Doesn't matter.

What matters is what does your company need from you at the stage of your company?

And the slides that I'll share the demarcation or the difference that I derive is an engineering management function, whether that's eng management, a technical team lead, a VP of engineering.

What your leadership needs of you is engineering direction, right?

Managing people, process tooling.

Challenging your developers and equivalents on 'do we really need to do this?

What are the options?' Right?

'Are we making the right decisions?' Informed decisions is what I call that.

The textbook definition of a CTO is outbound.

I'm having chats at conferences.

I'm projecting the business, I'm looking at competitors, right?

That's the textbook definition between the two.

The point I'm trying to make here is we interchange between the two in our careers.

You'll probably identify with one over the other, especially if you are mid or early career, right.

Will come up through the engineering ranks traditionally.

So you'll be a really strong VP of engineering very quickly.

CTO has different skills and, Greta mentioned this not soft skills, core and foundation skills.


The, thing I'm trying to highlight here is if you come from a very strong engineering background, we need to build those skills from presentation skills to chatting to customers, to negotiations, right?

If your organization doesn't support you there, proactively identify what you can do, right?

There's low value options like you, Udemy, right?

You can self learn-LinkedIn and, the list goes on.

But what I can say from my own journey is I really focused on the non-tech.

Tech, once you've been doing it for a while, frameworks come and go.

Languages come and go.

You'll adapt and learn, right?

You've come from an eng background, you've got it.

But the rest takes time-financials, commercials, vendor management.

Then list goes on.

So if nothing else, what I'm trying to say with those two slides, recognize which one you are and recognize the gap on where you may need to grow into.

It wouldn't be a tech chat if I didn't mention tech.

A lot of these logos are here.

One of the big things that comes up, especially as companies start to scale is tech tech stack consolidation.

We need everything to be rubber stamp and be the same.

So let's go and kill all the bootstrap and this and that, and we'll just have one.

We'll just have one.

Now that's a nice ambition.

And I intentionally use that word.

My professional opinion on this is consolidate where possible, but allow flexibility where needed.

There is no one size fits all, and companies that try and do the single thing will struggle.

They'll struggle with retention.

They'll struggle with attraction, and they'll struggle with innovation, right?

Because variation brings different ideas and different innovation concepts.

So the, thing that I'm trying to articulate here is, and I know tooling consolidation's coming up a significant amount because guess what, people will associate tooling consolidation with cost reduction.


That's why it's coming up a lot more at the moment.

But if I park costs, there's also a con operational risk here.

There's different tools, different ways of authenticating with those tools.

Who knows where our secrets are with some of this stuff?

So one of the first things I do when I join a company is just do a stocktake.

What tools do we have?

Who's using it?

How are we paying for it?

Is John or Jill putting it on their credit card somewhere?

And when you do that, you'll actually organically start to address some of this tooling proliferation.

'Cause you'll find out there's five to 10 people that's picked something and the rest of the orgs using something else.

So don't approach it on a cost front, even if you're driven there.

Approach it as a desk check.

What do we have?

How are we paying for it?

What are we using?

What's the overlap?

And can we be smarter with what we're doing here?

And the other lens that I apply here is developer onboarding.


Can you imagine if you are walking into a business with a stack like this, what your rampup's gonna be?


Regardless of what team you're in, right?

Think about that.

And there is stats, and I'm probably gonna, I won't attempt the stat 'cause I'll muck it up, but with the job market where it is, if developers are not productive quickly, they'll leave.

And with some of the big end of town, I see this a lot.

I won't mention brands, but yeah, the stories are how long it takes you to get a laptop, how long it takes to get a developer profile, how long it takes to get GitHub and the list goes on, right?

Efficiency with developer ramp up has always been a top priority, but now it's almost a need 'cause if you have this proliferation, and your onboarding is high, you're going to lose experienced talent within their first two to four weeks.

That's just where the market is.

On CI/CD with very top, of mind.

The, point I'm trying to articulate with this slide without reinforcing some of my earlier messaging is not so much about tooling consolidation.

Just recognize what you're good at and what you're not great at.

Most customers I chat to who go, 'we are amazing at CI/CD.


We got all the tools', but that's probably true.

But if you have multiple tools doing different things, it gets hard.

And my lint test, of how well you do this is is do a GIT clone and prod publish for a single page app, right?

And if you all go back to your orgs after three days and try and do that, it's gonna give you a really good lint test of how well you're doing.

Because if you can't do that, especially to a new group developer, you're probably not great end to end.


And that's not a problem.

It's only a problem if we don't acknowledge it and we don't work to address it.

It's a problem if we're living in denial and we think we're amazing.

I promised I wasn't gonna mention clouds, but the, reason why I'm just quickly mentioning IAS and SAAS, it's in the, context of scale and I've been really good.

I haven't mentioned any brands.

The reason why I work for a cloud company is I believe in SAAS and I believe in ISV, right?

Very early in my career very, early I was working with physical data centers, right?

I, had to wait for a Server to be shipped into the country and plugged in the data center and the electricity costs, et cetera.

And I remember sitting in the audience at AWS reinvent, the very first one, and they announced database as a service.

I think I almost cried as a developer because I realized how quickly I could get a database now, and all of those pain points that I, that most of you have had around DB version updates and engine changes, it's made, it's so much easier for developers.

The other point I'm trying to make here is, and it goes back to what I was touching on earlier.

Really focusing on product engineering, really focusing on it, so biasing what your core business is and recognizing opportunities of where SAAS may help you.

I, and I'll quickly mention a search engine.

I, I see no shortage of people running Solr, Lucene and equivalents at scale, right?

Elastic has a really good search engine, so do all of the major cloud providers, and there's a lot of ISVs out there.

So if search is not a differentiator for you, then challenge yourself on why are you running it and I'm not.

I'll share that slide, but just so we have time for questions.

That's pretty much my chat.

I'll put up my contact details there.

I'm, here for the rest of the day, so feel free to grab me and depending on how we're going logistics wise, happy to take some quick questions, but thank you for your attendance and patience.

Appreciate it.

Thank you, Chris.

Growth vs Scaling

What's the difference and why does it matter

Growth is NOT scaling;

Growth without Scaling means trouble

  • A company adds resources (capital, people and technology)
  • Ideally leads to increase in revenue
  • When revenue increases without sub increase in resources

Growth and Scaling stages

Everyone moves at different rates and there is no on-size fits most, its unique to circumstance


  • Single self-contained team
  • 6-8 pizza box team
  • Collocated same office

Scaling (Stage 2)

  • Team size grows (15-20)
  • Multiple teams


  • Manager of Managers
  • Multi-office
  • Partners (ISVS, SIs and GSIs)

Expansion / Hyperscale

  • Global expansion
  • Teams in different geos
  • Partner mix ^
  • Introduce VPs
  • M&A

Programming Language Popularity

charts from Octoverse, TIOBE and Stack Overflow about programming Language Popularity. Details aren't visible

Developer Profile, Mix

Full stack, Backend, Front End, Native

  • Cost
  • Your language selection(s) directly collates cost of hiring and access to talent pools
  • Mobile - Native vs PWAs ??

Stack overflow developer survey. Details aren't visible

Scaling via Partners - SI and GSIs

Local Partners, System integrators (Sis) and Global System Integrators (GSIs)

Staff Augmentation

  • Temporarily acquiring skilled professionals

Outcome Based Engagement

  • Focuses on outcomes - Key milestones, deliverables
  • Short-medium term (project) based

Managed Services

  • Managing and Delivering Services
  • Likely a long term

Delivery Models


Own Country


Same/Similar Time zones


Different Country / Time zones

  • Costs
  • Time Zone differences
  • Cultural alignment
  • Expertise & Skill
  • English Communication

Security team

Dedicated inhouse, Partner, SOC?

"If you spending more on coffee than your IT Security, you will be hacked"

- Richard Clarke

  • Infrastructure Security, Data Security, Security Testing and Security Architecture
  • Compliance - IS027001, SOC 1, 2, 3 and PCI DSS
  • Specialist Assessment and Advisory Partners
  • Managed Security Operations Centre (SOC)-Threat Detection and Incident Response

Technology Stack

Examples of components of a tech stack.

chart shows dozens of logos of companies and technologies in infra, data, backend and client for web and mobile.

Continuous Delivery Tooling Landscape

Continuous delivery tool landscape • James Bowman

chart shows dozens of logos for technologies and companies in the CD Tooling landscape.

Software Delivery End-End maturity

diagram illustrates a Continuous Deployment workflow in detail with each stage detailed. it is shown only briefly

Self-managed, IaaS, PaaS and SaaS

chart shows for different hosting strategies where the responsibility lies (customer or vendor)