How to grow and scale your engineering organisation

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.

Scaling.

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.

Now.

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.

Responsive.

Yes.

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

Yes.

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.

Right?

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?

Right?

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.

Right.

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.

Right?

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.

Right?

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.

Right.

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?

Everybody.

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'.

Right?

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.

Alright?

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.

Right.

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.

Right?

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.

Right.

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

Right.

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.

Amazing.

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.

Right.

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.