Miles Ward

Miles Ward: Okay, ladies and gentlemen. There is no voice of God; it is just me. My name is Miles Ward. I am CTO at a company called SADA, and this is going to be a somewhat unusual talk. I hope you go to a bunch of sessions this week. There is going to be a lot of pragmatic, applied, hands-on, technical, IDE-open, how-to-do-it sessions. This is not one of those. If that is what you are trying to do, I strongly recommend bailing to someplace else.

This is a strategy and tactics conversation about how to make it so we do not all get hosed in this transformation in technology, which is very different than a bunch of previous ones, but it sort of rhymes.

I come from a company called SADA. If you want to put the slides up for me, that would be amazing. I want to mirror the one that I am looking at, dog. So I go choose content, I say this content, and I say that one right there, and then you show my son slides. Look at that.

SADA works together with Google Cloud to help companies be successful with that platform and the technologies that it embraces. Cool note for artificial intelligence fans: all of the LLM models are available in Google's Vertex platform. That means kind of all the different LLM tools are available. But that is not actually really why I am here.

The stuff I am going to talk about, the strategies for helping your engineers be successful in this change, have helped the engineers that built this business be very successful. So, not a big company: a hundred full-time people when I started. We grew revenue 27-fold and have been their partner of the year back to back, to back, to back, to back, to back, to back, to back. I have at least some examples that suggest this is the right way to work.

I worked before that for five years at Google and before that for four years at AWS. If you are tracking the timelines, that is in the first hundred people for each of those organizations. So if you want to know where to work next, you should hang out and talk to me. I have a good picker, and that picker is oriented around a very critical, specific issue, which is growth.

Assuming the thing allows you to click. How many folks are in a cost center? Do you work in a cost center? Your boss talks about toil and effort reduction, and what can you do to make my cost go down, and there are quarterly targets about efficiency improvements and productivity and all the rest of that kind of stuff. Great. How many folks are in the growth center of the business, where the profit gets made, where the money actually happens? Okay, a smaller minority.

Here is the hint: everybody needs to be able to raise their hand in the second category. I promise, if you take nothing else away from this talk, the most important part is that businesses are the first artificial intelligence. Have any of you ever successfully interacted with a faceless robot designed to extract maximum capabilities from us, which we do not quite understand, and which operates in non-deterministic ways?

I really encourage you to start to think about your position, or how you position your position in the organization, in these terms, because they are kind of the only terms that really matter. Either you are part of the toil, part of the systems of operation that every business everywhere will be using the tools we are all talking about to reduce in size over time, or you are part of the business that grows because you are making the whole company more effective and more successful.

Let us do this in the most specific terms possible. I remember a guy with a much nicer watch than mine sitting me down as a young engineer and saying, kid, if you are not in the P side of the profit and loss statement, you are going to get canned.

So how does that work? What is the sort of transformation? I hope everybody had a good time during the keynote this morning. Booking.com's presentation I thought was really, really strong, except they put it right at the top of the line. It said, look, here are all the improvements we are making to reduce the cost of our developer effort. That is so close. They almost had it right.

They also had on the same slide, further over to the right, how many dollars Booking.com earns. Every one of those engineers, if they all went home tomorrow, there is a ticking time clock. Maybe 15 seconds, maybe two days. Who knows what the actual timeline is, but all of a sudden that money-printing machine stops working. I do not know whether that is going to happen quick or slow, but by and large it happens quick in most of these sophisticated businesses.

The more that technology teams are able to articulate not only their current value but their future plans in the context of revenue to the business, profitability to the business, commercial outcomes for the business, and new markets you can enter for the business, the more you are going to be able to get the investment that is required to be able to show a return. Everybody talked about the ROI measures that we are supposed to get for a project that we are taking on. I promise you, you get far less if you cannot articulate the R in terms that actually mean something to the business you are working with.

Tim O'Reilly, who is here, I directed him to breakfast this morning. His framing for this is that technology destroys professions and, in doing so, creates more value, which creates more jobs. There is a slide here that looks like that.

How many folks have heard of Jevons Paradox? You know what I am talking about with this thing? Cool old economist figured this out 200 years ago, way before the rest of us. It is cool; we get to go just take notes. When he was doing it on coal prices, if you reduce the cost of coal per ton, you increase the demand for coal, so that the total amount of dollars being spent on coal actually goes up.

So this paradox: you make something cheaper, you actually need more of it. You will spend more on that thing over time. What is happening in every one of our businesses? We are reducing the cost of intellectual property. That is the actual trajectory that we are on. We make developing software cost less, operating software cost less, designing new software and coming up with the ideas for software cost less. All of those tactics we are applying make it so that every part of the business we are trying to pursue is getting cheaper, which I promise you means the demand for those services will go up. The dollars per unit will go down; the total dollars will go up.

I want you to be on the side of the equation where those dollars accrue into your wallet, as opposed to your competitors or certainly your shareholders or bosses. There is a contest to be had there about the correct division of effort.

My suggestion, as a general hint, is that this shift is not only a shift of lowering cost for more total outputs. It is also a shift where, as we were talking a lot earlier today about shifting left, moving technology engineers into being product managers, product managers into being business consultants, and business consultants into being new startup owners.

A lot of the technology I am watching happen is unfortunately actually moving problems to the right. I build a new app and it is amazing and my boss loves it, and I have no plan for its compliance or compatibility or operating or backups or reliability or test compliance or any of the rest of that stuff. All that is a mess. Somebody else will deal with that later. I am off building the new shiny thing. The boss just asked how many folks have had that happen at their office. Yes, me. I have been the one who has done that to myself. Simon has done it to me on a plurality of occasions.

Some folks, when you are doing this with business planning, are calling that work slop. I can get generative AI to squirt out a bunch of work that now someone else has to parse and deal with. I just sort of shove the problem to the right in my process. If you are doing that in AI development, I think the framing is that code is legacy code on day one, because you do not know what the hell is in there. You are going to do forensics on day two to try to figure out what it is the heck that they just built, especially if the framing from the business is: great, now we have automated this tool; I do not need the people who do that process anymore.

A great case study for this is the folks at Airbus. We all want to be like Airbus. We do not want to be like a whole bunch of other companies. Airbus had 250 full-time people working to analyze, not satellite images, but it is kind of like satellite images because they put cameras on the bottom of the planes. Every Airbus plane is kind of a crappy satellite imager, and they assemble a picture of the earth from all these photographs in higher resolution because they are closer to the planet.

But when you fly over mountains, there are white sections. Are those white sections snow, or are they clouds? If you are trying to get a correct image of the earth, you have to be able to tell the difference between snow and clouds. I am telling you, literally 250 full-time people were working on this. They clock in in the morning and clock out in the afternoon, and what they are doing is sifting images to say, nope, that one is clouds; yep, that one is snow.

This sounds exactly like the kind of thing you would automate out with AIs, agreed. Unimaginable toil. We are talking years of this job for people, a profession, not just a job. We worked together with them at Google. We used machine learning technologies before LLMs and were able to completely automate this process at higher quality.

You might imagine the correct thing, if I am a business guy and I do not know any better, is to say, sick, I can lay off 250 people who have chosen the strangest job profession of all time, and it is the least reusable skill in the history of mankind. We should definitely get rid of those folks and capture those profits.

But no. Airbus is thoughtful about this problem. They realize that the folks they have trained to use all of their internal imaging processing and management tools, who understand all of the nuance of satellite imagery or near-satellite imagery and all the complexities there, and who have worked through their process of building training data sets, are effectively the information that you need for a machine learning model to take advantage of those images. That is exactly the team you need to train it to learn about anything else.

They set up that same group to figure out the difference between air-conditioner types, road-pavement types, different categories of forest land, whether it is growing or not growing, and different levels of agricultural information, whether crops are succeeding or failing. They have this immensely richer data set growing all the time because of a symbiosis between engineers and technicians and evaluators and learners who recognize their job is to change jobs every three weeks.

Instead of three years of practice just figuring out snow to clouds, they only get about three or four weeks of sample evaluation before they move on to the next problem. That means, for Airbus, the data set is this unbelievably rich, growingly valuable service that they have monetized. They have taken all of those profitability measures from the product as it gets worth more, as companies buy that data set for more and more money, and those bonuses accrue to the training team that is assembling that output. It is a pretty powerful example.

I will give another example. How many folks have been in the meeting where they say, hey, you have to figure out how to increase developer productivity, whatever the heck that means? Developer productivity is a strange misnomer. How many folks have been asked to unitize that in lines of code?

I had one of my bosses ask this. I will give you this trick; you should do this. Say please, please, please give me a commercial bonus on lines of code. He said, that is what I want: I want to know how many lines of code the AI writes. I go, perfect. You give me a dollar for every million lines of AI code that gets written. He goes, that sounds great. I would love that change. I am amazing; I am just going to do this loop here for a little bit: write as many lines of code that do not execute as possible and insert them in source control.

All of the kinds of measures that fit this category, I think vanity metrics was a label that got used today. There are a couple of other measures that fit into this category where any of us who are sharp engineers will immediately start playing the video game: how can I screw with this measurement? If you have that impulse, it is generally a good early indicator that you have stumbled upon a thing you should not optimize for.

Some measurements are kind of good in passing as a way to inform that you are starting to take the steps that you want. My business was really frustrated that we did not have as many AI experiments going on as we wanted, so we encouraged everybody to take that on. We had a little measure on our side of how many distinct repos had projects where we were building AI, and that exploded. Now there is a whole bunch of experiments, which is great, but it creates a new problem: there are a whole bunch of experiments to clean up, and somebody has to figure out whether this stuff works or not, and whether we want to keep any of these experiments going.

Invariably, all of those processes lead back to measures that probably sound like what your salespeople are measured on. That is the next major guidepost. Ignore your friends in IT; they are great, I promise they will do fine. Do not pay really close attention even to the finance guy. His view of the world is baked into the bizarreness of the way that the finance equations work; they have their own very particular worldview, and I think it is important to understand. But the folks to pay attention to are your salespeople, and the charts and graphs they put in front of customers, the CEO, and the chief revenue officer.

Those measures are: how many customers do we have? How fast are those customers growing? What is our retention rate on customers? How do we acquire new customers? Problems solved in those areas will prove immensely valuable over time. They will increase in value over time, and it sets you up in a situation where, as the problem solver in that area, the benefit you have created is instantly understandable by anybody outside your technology organization.

You could do unbelievable things to reduce the mean time to recover on a given change failure rate adjustment. I promise you, the CEO has already tuned out. He has no idea what you are talking about. The DORA measures are magical and they actually work, and they are important if you are in an open source project or working for a nonprofit and your actual goals are building more stuff. Great, you should use those measures. But I know almost no businesses have a goal of building more stuff. They are trying to make more money.

I think a lot about how many folks have ever seen any of the code extracts from the earliest versions of Facebook. It is an absolutely batshit, abhorrent PHP nightmare written by maniacs, which barely works in a hundred contexts, and that business is now worth billions and billions, coming up on trillions of dollars.

In most cases, we have to work together with the idea people, the creatives, the folks that are out in front of customers, the people at the edge of our business, to set them up to make things that are pretty crappy. You were using Brian Eno as an example earlier. One of the Brian Eno cards from his Oblique Strategies book is: make a crappy one.

I strongly encourage you: I saw a bunch of presentation bits earlier today that were like, set up a whole sweeping framework of controls and protections and installations. Forget all that. Put somebody way out in the pasture where they do not have access to any of the scary proprietary stuff that you are using, and have them experiment in a space where they do not have any of the constraints of your environment either. Focus them on getting down to the value that customers want and that your users need to see. Get at the examples of delight and utility.

We built some tools on our side. I will show you some examples where customer adoption has been vertical. All of that was built by not paying attention to all the limitations of our current data systems, the constraints of the way that we bring applications to market, or all the compatibility issues. That stuff will get paid for if you have screaming clear demand from customers, screaming clear profitability in delivery, and screaming clear positive impact in sales measures.

I had salespeople. How many people have salespeople? You have salespeople. They are wonderful and awful at the same time. I love you too, Jane. I am a chief technology officer, but I certainly put the sales hat on every once in a while, and my responsibility is to kind of know everything all the time about everybody. That is the position that our sellers get put in. They get shoved in front of customers. They get asked to be able to describe the art of the possible in basically any business context.

Well, they do not know. They have not actually read every case study. They have not digested every one of our solutions materials. They do not have any idea what our engineers do day to day. That stuff is super complicated. So we used Gemini to build an application that lets us sort out what questions you should ask a customer, what benefits of the tools we would propose as a result of those questions, what possible competing technologies they could use, what case studies where we solved that problem before, and what solutions make sense. It is just a search interface.

Does anybody find this complicated? Search for the stuff you built and show it to the people who need the stuff you built. I do not think anybody is going to get an award at any company for pathbreaking, innovative genius ideas about finding people's stuff and giving it to them. That is not a giant insight. But the performance of our sellers, I can see it on the chart: all of a sudden they get shorter time to deal close, better outcomes with customers, and more renewals in the customers where they are using this information.

So we get paid to work this problem and to push this kind of system forward. Without asking, I get asked, how much do you need to go further, faster? Not, what do you mean you have a budget request for this tool, this is crazy. Our orientation around helping our sellers be successful and helping our business understand their customers, orienting ourselves around that category of problems, is pretty powerful.

I also wanted to show: how many folks have seen The Wizard of Oz yet? Wizard of Oz is pretty cool. At the Sphere, they have just redone it where they used Google's AI to outpaint and infill and re-composite the whole set of images. It is a bunch of employees of mine that did a bunch of that compositing work. I am super pumped about that outcome.

That is the kind of project where no dollars were saved at Google Cloud by diving in with the folks at the Sphere and building up a whole new visualization system. The duration of the investment required is really material: multiple years of work on this video asset to reproduce it for the Sphere, and hundreds of thousands, millions of dollars worth of GPU time to grind away at it.

I was sitting in the audience last night getting ready to watch my buddy's work, and I am looking around and counting: I know my ticket was 200 bucks, and there are a thousand people in that row, there are a thousand people in that row, and they do this every night, or twice a night. Oh, so the millions of bucks in GPUs is no big deal. I saw the first presentation that was done to propose this internally at Google, and it went right to the eventual output: if we can sell this many tickets, we make this kind of money.

I want to help you think through, in each of the proposals you take on and the projects you get from customers, separating into two layers. Almost all the stuff we are going to be talking about this week is largely irrelevant to business stakeholders and executive buyers, unless you are the CEO. This stuff is out of their wheelhouse. It is the tools of our trade, our tactics, our approaches to make it so that the end outcomes we are able to deliver, the promises we can exceed, the surprises you can put in front of the business unit.

I was super happy about the travel team that was describing bringing features completed before the business was able to react. I think that is powerful. But I want you to hear the difference between a feature nobody asked for, an internal improvement in productivity, or reducing the amount of toil that is part of a process, and saying: we were able to move forward with a higher revenue target, or we can reduce the cost of this product to a customer as a result of these changes. The end outcomes, the stuff that is in your press releases, the stuff that is in your profit and loss statement as part of quarterly results: doing the translation work is one of the superpowers that AI is helping a lot of us do.

I certainly see developers using AI to augment their code, but I want to encourage all of you to have it and work with it as a consultant to help you think about how the work you are doing is being interpreted by your bosses. The more you can try to set up a fake interview with a fake boss. I have done this with Gemini and GPT: hey, evaluate the work I have done. Look through all my repos, all my emails, all the documents that I have sent across. Is this the kind of output that you want over the course of the quarter? Every time I ask it a question like that, it comes back to: what are the business measures that you would use to describe the success of this work? That has to be the guidance and advice I give you.

I will tell you, AI is kind of bad at this. Another product that we built, outside of this one, a brand new thing that we are working on now, came from a lot of customers who struggled with what to do next in AI. They were not sure what the right next project was or how to proceed. They wanted that in a nuanced way: per department, per division, per job role, what needs to change for us to pursue the business goals I am talking about?

We built an application. This did not seem like a hard thing to do: use AI to synthesize AI use-case ideas per department, per function, characterize them in terms of likely level of effort, and stack-rank them so you can take a look at what we think we would propose that you change. Here is the bummer: unassisted, and without real prompt modification, every single recommendation from the AI was a way to reduce the cost of a given function. All of them. We have talked too much about this category of problems; the AI has learned from us, and all it knows how to do is cut costs too.

I promise, it is a lot harder to get the AI to score ideas on how to grow revenue, how to increase market share, and how to displace competitors. We all have to work together with the tools we are building not to set up inadvertent landmines for ourselves and for our peers in the technologies that we take on. It is real easy for these systems to come back and make recommendations about how to make things easier because they are looking at the space of problems we have provided to them as examples.

The more we spend time empowering individual developers and empowering innovators, I like that dichotomy. Innovations are almost always unitized in terms of positive customer outcomes and positive effects. Folks that are polishers or process improvers get categorized back in cost management.

You probably have a whole bunch of existing measures. As generative AI squared this out, it tells us, you can see exactly how biased it is. It knows exactly what measure you use to manage an IT system: server uptime and ticket resolution. It gets a little bit squirrelly if you look at what the new dashboards are supposed to look like, and that is on purpose. The reality is every one of your businesses is different.

All of you have your own view to what is not just the persistently important issues at hand: are we profitable in our given executions? Have we figured out how to grow into new customer categories? Do we have the ability to serve customers more reliably so that they renew? But you need to work together with your business stakeholders to get any of the initiatives or efforts you take on unitized on these terms, or you will simply set yourself up for a later conversation where they will say, hey, that is great, you got 50% productivity improvement. Can you just cut 50% of the cost out of this business?

I have done layoffs. I do not wish it upon anybody. It is really not the right way to spend your afternoon. The more that we are oriented around the positive opportunity for most of our companies and the way that they can go tackle new customers, I think the better off we will all end up being.

One part of that: I have heard this mentioned a bunch of times, that savings are concrete, savings are real. I can actually see savings. I know for sure I am going to get them when I lay somebody off. I can guarantee that those dollars will make it back to the business. I think that is an indictment for all of us about how carefully, how specifically we have worked together with the modeling and measurement teams to make just as concrete, just as specific the gains that we earn in terms of new profitability in our product delivery or new capabilities that are bringing on new categories of customers.

We have to work together. I have seen the framing: a CFO bulletproof ROI case. The hard part of that is always the R. So the more that you work out at the edge with customers, with your salespeople, with the folks that are in delivery, with the end shippers of product, the edges of your business that interact, you will get to a place where you can see the measures they are goaled on. That is the easiest way to pull into your systems.

SADA as a team can do this with you. I run an organization that thinks this way. That is the way that we built SADA. I do not do projects where companies say, I do not want to do this anymore, you do it for me. It is not how we are built. We are designed to interact with customers and help them learn how to do this. This is always a coaching, partnering, mentorship, collaboration exercise.

We have high-end engineers. We have a bunch of ex-Google people. We have a bunch of, frankly, ex-Amazon, ex-Microsoft, ex-Apple, ex-NASA, and a bunch of the hotshot places, specifically because they have been forced to solve problems of this category. People want to learn from people who have had to solve real-world problems.

That operations experience, that excellence in modernizing other businesses, sets us up to help companies think that way, which is a way bigger outcome than helping them refactor some application or move from VMware into GCE or some other kind of migration step. We certainly help with the mechanicals there.

I think lots of the AI projects you are going to take on are going to be limited by data access. They are going to have problems in terms of security and authorization. I am looking forward to you making all sorts of amazing new messes on behalf of your high-end clients, and then I can run around and fix all of them. That is generally the business plan as far as we are concerned.

But I know when I go and fix those problems, I will be telling you that it was successful because of your end-client measures. That is how I am going to report to you that our project went well, not that I was under budget and on time, because your business does not care, I promise. They do not care. They only care about that end outcome.

So happy to help you with it. Looking forward to any questions. Simon and I are here. Simon is going to do a whole end-to-end demonstration tomorrow of how this stuff works in Google's Agent Assist and Code Assist platforms. Really, really.