How to sell framework and architecture changes to the business

That was a very heartwarming talk and like lots of great stuff in there.

I'm sorry.

We're now getting into the hard realities of, of capitalism.

But, by way of introduction, I've been an engineer myself.

And, then went on to do product and had CPO, CTO type roles.

And the higher you go in, in your roles and in your career, the more commercial you have to be.

And, and I wish some of the things I would have known much earlier than I did.

It would have, it would have helped me a lot and it would, have, helped my functions.

That was part of as well.

So here's what we're going to talk about today.

How to lead the business.

Cause that's really what we have to do.

Who here has an idea for a framework change and architecture change.

There's going to be some kind of big project.

Any big tech debt that needs to be sorting anybody nobody.

Yes.

One, one person.

I don't believe you.

There must be more people.

So, when we want to do these changes, we usually have good reasons.

And, and we need to lead the business to understand how important these changes usually are, how much benefit we can derive from them.

And so I'm going to talk you through a little bit of framework on how to sell these changes and what selling actually means in that context.

And then, what if it doesn't work?

Because chances are you have made the case at some point in your life to say hey, we should be doing that and somehow nobody was listening and, it, the organization would have benefited.

Leading the business, why do we need to do that?

Anyone have an idea?

We can make this interactive if you guys, aren't too shy for me.

Why should we be part of, having a say in the business?

Anyone?

All right.

Let me ask this in a different way.

Should raise your hand if you think engineering as a function should have more influence in the business.

Great.

Okay.

Why?

Why?

I know this is a bit disruptive with people coming in.

You have to work there.

Yes.

Yes.

And it would be so nice if other people created a better environment for us all right.

I'm going to take a different spin on it because I said at the beginning, it's the hard realities of capitalism, right?

Every single role in every organization that has been created, including all of your roles if you are employed, is there to make the business more money or to help it from stop losing money in some shape or form.

So you're there to help the business more money.

It doesn't matter what, it doesn't matter what kind of business you work in, right?

If you work at Aldi maintaining the e commerce site, you're there to help Aldi more money, make more money, right?

If you're, working at the Apple Genius Bar, you're there to help Apple make more money, right?

Or at least handle reputational risks and all these things.

So that's what you're there for.

That's why the CEO decided, yeah, all right, we'll hire one more engineer.

Because they think we can make more money.

It's not personal, right?

It's just capitalism.

It's just in the world we're part of.

And so in everything that we want to like suggest to the business, we have to think about how does it help the business make more money?

It's an unfortunate reality.

But, but let's see how we can do that.

And I believe we as a function engineering, we deserve more influence in the business, right?

Because while every day, everyone is there.

To help the business make more money if we really boil it down.

But we just have unique expertise and a unique take on how we might be able to do that.

And chances are most organizations that you're part of, the technology that we're building is a key part of how they make money.

So we should have a say and we need to engage in that process, but it's an entirely different skill set, right?

It's not, it's not, coding.

It's, it's something very different.

So every decision that we make is a business decision, right?

Every line of code that you write has an impact on the business when a someone else has to maintain it, you know later or there may be bugs, etc so there may be more expensive from lines of code that you're writing or there may be infrastructure costs if something is really inefficient.

That's more the back end team, but there'll be higher expenses there.

It may be a bit jittery and so therefore we have to keep maintaining it and we have to keep trying to fix it every line of code has ultimately an impact on how the business makes money or how it spends money.

And so we need to be leaders about this.

And when I say leaders, Brene Brown, right?

So a leader is anyone who takes responsibility for finding the potential in people and processes and has the courage to develop that potential.

And I'll tweak that just slightly and say people, processes, and ideas.

Because everything we do in tech starts as an idea, right?

An idea on how we can change the architecture, how we can build something better, how we can build it nicer, right?

And so we need to lead the business and actually understand ourselves as leaders who, if we make the right suggestions and if we make successful cases, they have a positive impact on our team and the influence of our function, right?

And this says nothing about you having to have formal reports.

So every single person in the engineering team can and should think of themselves as a leader, and it's going to benefit the whole organization.

That's my challenge to you.

Think of yourselves as a leader, even if you don't have reports, right?

Every idea that you have has potential for the business.

And we just need to explain that properly.

That's what we struggle with sometimes.

So I'll give you a quick, like one, two, three framework, and we'll see how that goes.

I'm sorry.

I know it's late.

We're going to do a little bit of math here.

You can trust the math.

It wasn't created by chat GPT.

I went through it myself, but then I have two kids and I created late at night.

I'm not going to promise that there aren't any flaws in it.

Okay.

What does selling really mean?

Give me something.

What does it mean to sell?

Convince someone?

Okay, yeah.

Great.

What convinces people?

Yes, Write AI on your PowerPoint slide.

And everyone's yeah, let's do that.

Great.

Alright.

Alright.

Selling something in the business context means two things, or three things.

The first one is we need to build some kind of emotional case, right?

Why do we even want to do that, right?

We need some hook, something that tells people you should engage in this thought process with me to think about, is this not a better idea than building this other feature that the sales team just came up with, right?

That's what we're here to do.

And, you create that emotional case by finding some sort of magical sequence of words that connects someone to, wanting to take action.

And ideally you do this by something along the lines of values and their own beliefs and everything.

So if you talk to the CEO, right?

They believe that this organization is amazing and, we should be building the best tech out there.

Are we okay?

And, and maybe your company has values around customer focus.

And lastly, and famous for, don't F the customer.

So whenever an idea from engineering would surface, it was usually along the lines of, if we do this, it means we don't F the customer.

And so therefore this is a good idea.

That's a good starting point, right?

Getting people to say actually you're thinking and where you're coming from, is connected to things that excite me, right?

So we have to figure out what that is, and I'm not going to lie.

This is a whole journey on its own, right?

But think about if you're making the case for something, if your organization has any values, can you connect them to the values or can you connect things to the strategy or the things that a particular stakeholder is like constantly frustrated by, right?

So the emotional case is one thing, but capitalism, we also have to prove the hard numbers.

And that's what we'll get to now.

Here's a few things that I've heard engineers say constantly that just don't work as well.

So here's a list of things that they've been tried and tested and don't work.

You can check them out.

The first one is, the thing that's been built, the engineers just did a really terrible job, right?

It was probably outsourced, et cetera.

The guys just didn't know what they were doing in spaghetti code, like just pointing the finger at somebody else.

And working on the belief of your stakeholder that yet somehow, the engineers that we hired in the past, maybe they weren't as good, brilliant, can work.

I've seen it work, but you're fueling that distrust in engineers.

And in about three years time, that's going to come back to haunt you because then someone else is going to do it to you.

Can we please stop doing this?

I understand that, engineers like build things sometimes in a terrible way, but at the same time.

It got us this far, right?

And, it allowed the organization to, have enough money to hire us and to do it better.

Okay.

So the whole finger pointing at the engineers have done this really poorly.

And so therefore I'm the savior.

Let's just not, right?

It doesn't help us in the long run.

Great.

The second one is, this framework, this architecture is just so much more elegant.

Yeah.

Brilliant.

Shows your passion for your craft.

I promise you, no CEO could care less whether something is elegant or not, right?

And does it make money or not is the, is the question.

So it doesn't work.

You're just trying to be an artist when you say that, right?

All the things that all the developer tools and framework market to you, like it's stateless and it transpiles to JavaScript and all these other things don't mean anything to someone who's not an engineer.

So you can throw all that out as well, right?

Basically no words that you see on the marketing website for a framework or a technical tool is going to help you sell this thing, right?

Because they're marketing to you to adopt it because your passion about your craft, they're not necessarily good at marketing it to the business.

So unfortunately that doesn't work.

It has the most followers on GitHub.

Yeah, it's it's the best thing there.

It's it's growing really fast.

We should really, I've got FOMO.

That's why we should use it.

Not a good argument either, right?

Good, you're using social proof.

But again, it doesn't have a dollar figure attached to it at all.

So it doesn't work.

This version is so ancient.

I don't want to work with it anymore.

I couldn't care less, right?

It's, just because it's old doesn't mean it doesn't make money.

Last but not least, it's no longer supported.

There we're getting somewhere, right?

Because it means, if we keep using this, we're on our own and that's not a good place to be.

So let's reframe these things, in ways that make a little bit more sense to your business stakeholders or to someone who thinks in numbers, right?

The engineers did a bit job is It got us this far, but it's misaligned with our strategy.

Okay, yeah, because we're clearly CEO and everyone down right there invested in the strategy.

And it's Oh, okay, yeah, we need to execute the strategy like a thing, right?

And if you show that you're thinking about the strategy and that, the architecture just doesn't support it quite as much, and then you get open ears.

Okay.

So strategic alignment.

By the way of make you really look good, right?

There's barely an engineer I know who like actually thinks about the strategy.

But just using those words, you're gonna, derive a lot of credit.

Okay.

It's so much more elegant.

It helps us build 50 percent faster, at least certain tickets or certain things.

And now that means something to me, right?

Because it means cool.

We can throw more things in the backlog, right?

And we can we can get there faster.

Obviously we'll talk about how we can potentially quantify these things.

It's less error prone, right?

Less bugs, less disruption for customers.

All right.

Less security risks, et cetera.

It will help us onboard engineers faster.

It depends how often you're hiring engineers, right?

If you're a fast growing company and someone said, you're 50, 50 people this year, but you're going to be 200 by the end of next year.

There's a whole lot of onboarding to do.

You better don't use any sort of obscure specialist framework that takes everyone three months to learn, right?

Because then you're going to move really slowly.

If you're 10 people and you're going to be 10 people next year, and everyone is already familiar with framework, doesn't matter.

It allows us to attract better engineers.

In fact, I had this situation.

I was, I was working at a, startup accelerator.

And we were actually building products for other startups and we're using this old version of dotnet.

And, I forgot what it was, like say NET 3.0 and pretty much everyone had abandoned it.

And, and not just we were struggling to hire engineers who still wanted to work with that, but all the startups that we were building for as well, they were also struggling.

So we actually had created a, a problem for us and the startups that would like that meant like hundreds of thousands of dollars would go to waste because people just couldn't find engineers, couldn't grow, couldn't find the people that they wanted, had to outsource to some obscure locations where they didn't care what you were using.

So, that had a, like a real monetary impact.

And then, of course, security, will be a big topic has been for the last couple of years will continue to be so your vulnerabilities and not being able to, not, standing on your own, but having that support, it's going to be a big factor.

Okay.

Now.

We already started talking about making things 50 percent faster, right?

So now here's how we build a rational case.

First don't benchmark old versus new, right?

Like the investment of your team or you working on these changes doesn't get benchmarked against, is the new approach better than the old one?

Great.

You'll need a comparison page at some stage for the paper trail and everything.

But the question, a, CEO or whoever will ask themselves at some point is, is you working on that better than you working on this feature that the sales team says, if we build that, we can get this customer to pay us $20,000.

All right, that's the case you have where you have to stand the test.

Okay.

Not is the old architect lays a new architecture better than the old one.

And so for that, we need to show ROI, return on investment, right now, return on investment.

Does anyone know how to, how that's calculated?

Yeah.

Okay.

Okay.

Let's look at it.

So here's how, what I would encourage you to think about.

Often I see this in product teams and engineering teams that.

We're just passionate about building things, cool things where we can, when it's done, we can point to this, like I did that and it's amazing and that's wonderful, but unfortunately, very few people care, right?

Don't build things, change things, right?

Every line of code that we write should be changing something, should be changing things for the customer on how they can use the product or how many customers adopt our product.

Or for the business in terms of how much money it can make or how much costs it has due to infrastructure costs and everything.

So everything you build isn't just about building something is about changing something.

You either make things faster, right?

Reducing your cycle time.

Does anyone measure cycle time in the team?

Yeah.

A few people.

Does anyone measure velocity?

Okay.

A few more.

So any improvements you can show there are probably one of the most powerful things you can, you can, talk about and I'll show you in a second how, but also time to hire, right?

We'll have an impact.

Like the less time you spend interviewing people and onboarding them, et cetera.

The better for the organization because the more time you can spend actually building things, right?

You make things better by making them more robust, right?

So more uptime, better talent, and, things being less risky.

So less, disruptions.

And slowdowns due to security, issues and bugs and all these other things.

I got, I was working with one company and they had this security issue that they were aware of six months ago, and then they were like, probably don't have to do anything about it.

And then suddenly, all sorts of organizations were getting hacked.

And when the papers like, shoot, now we really have to do something about it probably took the engineering team three months to just focus on closing all the security holes that they thought existed.

And that was at a time where the organization also had to show big growth and revenue.

And so it was, there was no way around it, but yeah, they shot themselves a little bit in the foot.

So, talking about, yeah, security risks, et cetera, and PR disasters and all these things, can be a good thing.

And of course you can make things cheaper, right?

You can remove code, you can make it nicer, you can, have less code to maintain.

And, and you can have less infrastructure costs, so probably less relevant for, front end.

So these are the kind of metrics and changes that we need to be talking about to make the case for our, for our big changes.

Now let's quantify that.

And we start with cost, right?

Those of you who measure sort of story points, velocity, et cetera.

Do you know how much a point in your backlog is worth in dollars?

Does anyone?

Yes.

Good, good.

You should . Every one of you should, to be perfectly honest.

But I know this is like a little bit of a mystery, so I'm gonna walk you through, some math and I promise you each one of you afterwards will be able to quantify how much a point in your backlog is worth.

'cause nobody in the business except engineers, care about story points, right?

They care about time or money.

That's it.

And if we wanna influence other people, we need to talk their language.

We can't like Silicon Valley and the VCs and everything they've known for a long time.

It's so much easier to teach engineering people business and leadership than it is to teach business folks about engineering.

If you've tried, then yeah, you probably know.

So this is easy.

Okay.

How much is a point worth in your backlog?

Say you've got 20 points that you achieve per sprint.

Okay.

And you do two weeks sprints.

So that means 10 days.

And you have four people in your team now, but you can look online, and look at salary service, et cetera.

How much does an engineer roughly make?

Let's pick a, let's pick a nice round number, just as an example.

For example, $116,592, why?

That's a nice round number.

Super.

Yes.

You have to account for the costs of yourself to the organization, not your take home salary.

And there's super, there's equipment, snacks, ESOP, SAS tools, et cetera.

So account for the fully loaded costs.

That's probably going to be slightly higher, but let's just go with 150,000 a year.

So 116, whatever is 130,000 per super.

So for people in average, 150,000 cost to the organization.

Now we have to account for we achieve 20 points, when everyone's on deck, all those rascals in your team, this getting sick every once in a while, they're taking holidays.

Maybe I have to care for, a toddler or something.

So they're not working a hundred percent of the time.

In fact, if you take all the like public holidays and everything out, your daily rate at 150,000 fully loaded is about $682.

Don't compare yourself to freelancers.

They have to account for different things like being unemployed for a while.

Which is why freelancer rates are always high.

So every day that someone in your team actually works in average, that's roughly what it costs them by all means.

Like again, do salary service and everything, but you don't have to, that's the thing you don't have to know everyone's salaries, you can roughly guesstimate.

It might be 10 percent higher, 10 percent lower, right?

But you've got a starting point now.

And so that means every point in your backlog costs about $1,364.

All right.

So next time when you have a conversation with someone who's not an engineer, or even when they are an engineer.

And, and you tell them, Oh, it was about five points or something.

Don't say it's five points.

Tell them, it's about a $10,000 exercise, a $7,500 exercise to build this.

Okay.

That will make them think, right?

Cause that's the language they're talking.

Okay.

So let's just say this architecture change that we want to go through.

We'll take our team 12 weeks, six sprints.

So we're talking about $163,000 investment.

That's more than just adding one engineer to our team, right?

And it means that for these three months, we're not going to work on the features the crackheads in sales came up with, right?

I probably shouldn't be saying that.

Good.

We'll take that out in the edit, right?

Okay.

But we have to justify that, right?

We have to justify effectively spending 163,000.

164. If we round up.

So how do we do that?

Now we have to talk about return on investment, right?

We know that's the cost.

We've quantified it.

And, and now we have to talk about return on investment.

Now, whenever you look at the actual benefit of a change of what you're trying to do, right?

Here's what you need to think about, right?

How many hours are we saving in some shape or form?

All right.

And therefore, how much faster can we build and therefore how much more can we build?

All right.

How much, how many dollars are we saving by not having to do this job?

All right.

How much improvement are we creating somewhere and how much is that worth?

All right, it's really just these three things.

Now, we'll go through an example.

And we'll, we might have to try this more than once, right?

Because the things that we come up with at the beginning, maybe they're not good enough.

Let's just say, we can save one day per front end ticket if we go through this change, right?

It doesn't matter what it is.

If it's a process improvement, or automating QA, or, new frameworks that are nicer and stateless, and, they use tabs over spaces and so forth.

I'm glad I got a couple of laughs there.

Okay.

So let's say we do eight front end tickets per sprint.

We have a very productive team.

That means per sprint, we can save ourselves eight days.

And that means about five, five and a half thousand dollars per sprint that we're saving.

That's good.

Now 12, 12 weeks to build it, right?

So unfortunately, this is just a saving of about 141,000 a year.

So if we compare that, sad face, right?

There's not, there's a, there's negative return on investment here.

Can anyone see where maybe we could, bulk the case up a little bit.

More years.

Why?

Aha.

Every line of code that you're writing, hopefully it's going to live longer for a year, longer than a year.

And this is the thing about engineering.

It's entirely different to any other team, right?

We're here to automate things with constantly solving problems so they don't have to be solved again.

All right.

So hopefully what we do lives, I don't know, three years, five years, something like that.

So that's exactly right.

We can say, let's say an average, we stick to our architecture and like these kind of big changes for about three years or something like that.

I don't know, it might be entirely different for your company.

I was, remember one workshop where I was in, where we're talking about a button and we're talking to the engineer who wrote to that, like the code behind that button 30 years ago.

It was very impressive.

So some things live a little bit longer.

Alright.

So if we say, actually over three years, that's 425,000.

And that now we're looking quite sharp because our return on investment, which by the way is the benefit you receive minus the cost.

Divided by the cost.

Sorry, I did that wrong.

That's the, that's when you've had it as a percentage, we got about a 60 percent ROI.

That's pretty good.

That's pretty good over three years.

So we're talking about sort of 20 percent a year.

That's not bad, right?

The stock market, real estate, et cetera, that gets about a 10 percent ROI.

The problem is tech companies are often growing a little bit faster.

We might have to try this again because the CEO says, we're growing 25 percent year over year.

I don't quite, 20 percent per year.

I don't know.

Can't you, can you do something better?

And it's how can we bulk up our case even more?

Ideas.

So it's more developers.

Ah, yes.

True.

True.

And I have, I don't have that point exactly, but that's a hundred percent right.

If you're growing, and if next year you have, two front end teams and you're doing 16, so yeah, it actually grows.

Very good point.

Now in this case, I'm going to say, we are growing.

But actually what we're saving ourselves is one developer a year, and, actually 5, 6,000 a sprint, we're saving ourselves about 20%.

So if we can develop 20 percent faster, it means we can, at least in theory, develop 20 percent more features in a given year.

And of course, every feature that we develop.

Has an impact on, how many customers will adopt our product.

Like the sales team has, they have more tools in their query to convert customers and everything.

We build a better product, but we outpace the competition.

Always a good phrase to use.

And, and so we get to grow 20 percent faster.

Now, if we're adding 20 percent to 25%, we get, who's paying attention.

30%, all right, and let's just say we're working for an organization that makes 10 million a year.

All right.

So now we're looking pretty good because we're not growing 25%.

We're growing 30%, which means we make 500,000, right?

In additional growth a year after we've shipped our architecture change, right?

That's a pretty significant ROI already in, year one, right?

We've changed nothing, right?

Except we, we thought through this business case a little bit different from the organization's perspective.

All right.

We understand our costs and we understand actually the benefit of what we're developing.

And I promise you, if you can do this, your next salary negotiation is going to be a breeze.

Alright so what if it doesn't work?

Because let's face it, when we started this, one person in the audience knew the cost of a backlog.

Okay.

This is a new skill, right?

And what we're up against, especially the folks from marketing and sales and so forth, they're black belts in this stuff, right?

Half of them will have studied business.

Some have studied art history, but, like they've been solving, they've been, solving business problems and people problems and how to influence people, basically their whole career, right?

What we're doing and what we're up against is what I call the double load, right?

We have to learn leadership and solving people problems and finding those magical sequences of words.

And we're starting from scratch because for most of our career, we've been, we've been thinking about, complex and abstract problems, right?

And we've been thinking about code and how to solve problems with machines rather than people, right?

And, the commercial thinking isn't taught in most computer science courses, even web development courses.

In fact, the double load becomes a triple load, right?

We can't give up on growing as engineers and coming to these conferences and, like keeping our craft good, but at the same time, we need to learn about leadership and we need to learn about commercial thinking that's hard.

There's sort of three things we have to think about, And get better at where's the folks in marketing sales.

That doesn't show marketing changes a little bit.

Sales doesn't change all that much.

So it's hard on our brains.

And, so I say this firmly, but kindly, stop the pity party.

Yes, it's hard, but as I said at the beginning, all of Silicon Valley realized that it's a lot easier for us to learn these things.

Then the other way around to teach engineering stuff to business folks, right?

So yes, we're up against that's the cards that were dealt.

And, and that's the concept we chose as well, right?

We've decided to be engineers and to be passionate about these things.

And this is just a bonus.

If we want to have.

The influence that we deserve in an organization, we just need to get better at it, right?

And it's not going to work out the first time, right?

If you have something, like an architecture change in mind, you take what you learn here and tomorrow you're going to make the case and it's successful.

I want to hear from you and I will put that on my CV that like in half an hour I can change someone's life, but chances are it's not going to work right away and that's okay because you're building a new skill, right?

And it's just a matter of trying again, and getting better, right?

Like the first lines of code that you written, that you wrote, they probably weren't very good.

I know about six months into my coding journey, someone had to teach me about indentation.

You can imagine what my code looked like before then.

And it's a bit, it's a little bit the same, right?

With making business case and commercial argument.

All right.

So yeah, it's not going to be great at the beginning, but you're going to get better at, if you focus on it and your function and the whole world of engineering will, we'll be thankful for you.

Alright, so if you want to go alone, sorry, if you want to go fast, go alone, right?

If you want to go far and hopefully you want to go far, do it together.

Don't, don't, load all the burden off your team and everything onto yourself, right?

Take a page out of the book of learning science, right?

So connect with other people, talk to other people, right?

That's how we learn faster.

Don't reinvent the wheel, but stand on top of the shoulders of giants that have already done a lot of these things.

And, and of course you can get in touch with me.

I had some great mentors in the past.

I'm always happy to jump on a call with anyone, and, and talk through these things, whether it's leadership, whether it's commercial thinking.

That leaves us here.

We've learned, hopefully, how we can lead the business and why we deserve to lead the business, and why we deserve more influence in the business.

Because we've got a unique perspective, on, on how to grow this business and how to make money and how we can get there faster, how to accelerate the growth rate of businesses.

We learned a little bit about how to sell big changes, and we need to create an emotional case and a rational case, and quantify things.

And, if it doesn't work, Don't worry about it.

Stop the pity party.

Just dust yourself off, try again, and it's going to be a journey.

That's all.

Thanks so much.