Why 20 Years of Experience Didn’t Prepare Me for This

In this session, Eric Peterson, CTO at Secret Escapes, discusses the paradigm shift that artificial intelligence represents for technology leaders. He reflects on his two decades of experience, expressing that traditional management practices are becoming obsolete in a world where the cost of experimentation is diminishing. Peterson emphasizes the need for CTOs to adopt a mindset of exploration rather than merely following the old playbook. He identifies three pillars of effective leadership: optimizing for business value, reconfiguring talent and teams, and nurturing organizational culture. He warns against cultural debt and stresses the importance of psychological safety for high-performing teams. By embracing agentic engineering and leveraging AI tools, Peterson believes organizations can streamline processes and redefine their approach to software development.

Next up for our next session, I'd love to introduce Eric Peterson, CTO at Secret Escapes. He's been a technology leader for over two decades. Now, you said you thought you knew the playbook, right? You said you thought you knew the playbook, but then came AI. Looking forward to hearing your insights and your expertise. There you go. >> Thank you very much. >> Hello everyone. Um, it really

is my pleasure to be here today speaking to this room full of seasoned technologists. My talk is entitled Why 20 years of experience didn't prepare me for this. And my hope is by the end of my slot you'll be inspired to challenge everything you think you know and have the courage to go back and transform your teams. So to brief just briefly about me, my name is

Eric Peterson. I'm currently a CTO at Secret Escapes, um, which is an online travel agent specializing in discount luxury travel. Uh I started out as a CTO at my own startup back in 1999 and it was called Moonfruit. Uh it was a uh software software as a service website builder before SAS was even a term. I had no real experience but had all the confidence that ignorance

can bless you with. I learned everything the hard way. How to deal with unmustable deadlines, defending against DOS attacks, the constant battle to attract and retain talent. I read all the articles. I debated with my peers and I thought I'd gained all the hard one wisdom that would uh allow allow me to anticipate almost any challenge. After more than two decades in this seat, I thought that

this was my greatest asset. Then AI arrived and I realized much of that wisdom was actually a set of rules optimized for a world that no longer exists. And it's easy to feel lost uh especially when all the principles you've learned such as how to manage technical debt, structure your teams, or even how to make buy versus build decisions seem to be all up in the air

again. So what I want to share with you is that despite that, the core of what it means to be a CTO remains. It's just the way we do it needs to be rediscovered. We need to move away from being the librarians of the past and librarians of best practice and return to being pioneers. Uh the biggest challenge isn't learning all the new tools necessarily. It's it's

learning unlearning all the old ones. We've been trained to mitigate uh risk because code was expensive. Today the cost of trying is dropping to near zero. Our librarian instincts, the desire to protect and slow down are now the very things that are holding our teams back. So we must embrace an an explorer's mindset. So, what is at the core of being a CTO? Well, I've chosen to

break it down into three pillars. Optimizing for value, harnessing your talent, and nurturing nurturing your culture. When I talk about optimizing for value, what I mean is remembering that the purpose of the tech team is to deliver outcomes for the business. It is not about the code we write. That's just the means, the byproduct if you will. Yet we have built many up many rules up around

the software delivery life cycle that are optimized around the economics of yesterday. What used to be important before was making the most of that precious engineering time spent on deploying production quality code. So we'd run cheap discoveries built such as building prototypes or run technical spikes uh in order to derisk the slower expensive deliberate delivery of product increments. But now we are able to create working prototypes

within minutes versus days. We can spike out three different implementations and test the actual solutions instead of debating over a technical design document. The line between discovery and delivery gets blurred as these builds tend more and more towards production quality. And what about the rebuild fallacy? So the dogma is that we should avoid building a version two of anything. Um, the thinking being that your code is

full of requirements that were never documented and so you always woefully underestimate the task. Even if you did estimate it correctly, you would never reach an acceptable ROI. But in a world where implementing the requirements is minutes over days, does this still hold true? Now a rebuild becomes uh viable economically, we capture the requirements as we know them. We use we can use AI to discover as

many as we can from the documentation and codebase. Hell, we can even delegate user interviews to AI these days. And when we're finally satisfied we've captured enough requirements, we set our agents off implementing them. We discover a new requirement along the way, no problem. We'll add it and we'll implement in almost real time. And that's just one example. In this new world, we are challenged to reexplore

the end-to-end software delivery life cycle and find the new rate limiting steps. Now, as you've probably all experienced, many people, including some of my developers, think that is the codew writing. In our case, at least, it's planning and designing work. At Secret Escapes, this is becoming the focus of our technology strategy. It's less about how we tackle our technical debt and architectural debt per se and more

about how we unbridle agentic engineering. Later, I will share the moment that I realized I was really stuck in legacy thinking when we marched ahead with the technical strategy that was rooted in the old ways. Moving on to talent, I break this down into two themes. How do we configure ourselves and how do we hire and develop our staff? I have been configuring configuring product squads for

the last couple of decades comprising a cross functional team with members from product design and engineering. Teams would be be would be between six and eight people strong and everybody had very well- definfined roles. In terms of engineering, you'd have your tech lead focused on delivery, a senior as a guardian of quality and then two to three uh juniors or mid-level engineers to turn out your they

um lost myself just as we made the step up from um where sorry I have lost myself completely uh again that is a design that's optimized for the pre-agentic era now your tech leads and seniors can use AI to write up the tickets come up with a UI design generate a bunch of tests and finally turn out the code they can even get it to do the

code review so what does that mean for our team structure and topology what I is the role of leads and seniors is no longer as the caretakers of the code but as the car caretakers of the context. I'd like to call it higher order engineering. Just as we make the setup step up from machine code to higher order languages, we now must continue up the funnel to

engineer the environment, the standards, the patterns, design documents and tests. What does it mean for the rest of the team in the short to midterm? What I see is that team sizes shrink will be shrinking and the role boundaries will start blurring. While we will still have product managers and product designers, their job too will be about architecting the context, setting standards, and upholding quality. But the

product squads will be smaller, perhaps only one to two strong, and staff with product engineers capable of orchestrating cohorts of agents taking ideas from conception to production. What that means for hiring is that we will be looking for engineers with much more businessminded mind orientations. Engineers with a product mindset and the potential to deliver results through review and feedback cycles over individual contribution who value shipping features

over crafting code. But how do we how do we fill that talent gap? What happens to our juniors and our mid-levels? Long term, potentially controversially, I see a future where the profession of software engineering will shrink considerably and will be concentrated in the firms that are developing the agentic coding platforms um the the platforms themselves as their harnesses and models iterate towards better and more complete autonomy.

The career path for the for a software engineer will be that of an apprenticeship at these kind of firms working years under the supervision of a master to gain the exposure and the wisdom before being qualified to contribute independently. I wonder if we'll really even see software engineers outside of these companies in the future. And finally, we come to culture. In many ways, I think this is

the theme that is least directly affected by a by the advent of AI. But as many have said, AI is the great amplifier. And nowhere is this more true than in your culture. As your organization's leader, you set the tone. And if you have cultural debt, this is where you need to put your focus. or as you progress into the agentic future, you'll fail to reap the

rewards and in fact may fall behind further behind your competitors. There are many studies that we all know have seen that highlight the importance of culture. Perhaps the most recent and famous being the Google rework study back in 2014 and the bombshell that delivered of course was that psychological safety not things like tenure or seniority were the fact that was the factor that was most correlated to

team performance. So what is cultural debt? It's the accumulation of dysfunctions in your organization such as unclear accountabilities, legacy roles, inefficient reporting structures, outofdate institutional learnings. You'll recognize it when you see it, and when you do, it's more important than ever to address it. And you need to lead from the front, be an example, and be brave. So, let me tell you a story. About a month

ago, uh my CEO added an agenda point to our weekly management meeting. He had installed clawed code over the weekend. I don't know if any of you have that experience. Um any uh so basically he built a trust clone. Uh in case you don't know, trust is a reviews aggregation service. It collects reviews from goo colleates reviews from Google uh trip adviser and other sources and provides

us with badges for our site like in the top 5% of city hotels or rated highly for families. So we use trust you. Why are we paying all this money for trust you? I can build this thing in a weekend. Um it had taken him just a few hours to go from claude install to a working demo. So he's experienced firsthand how powerful these teams are, the

tools are and asked what kinds of impacts are we seeing in our in our team. Why in particular he wanted to know why longunning projects like Flamingo were not getting any faster. So let me tell you about Flamingo as Secret Escapes. Uh through the years our front-end stack has evolved to be quite the mess. Uh much of it is intentional. We took some shortcuts. We were driven

by business needs and priorities and we are where we are. The situation as it stands is uh we operate two brands across eight territories with six different front-end architectures running on two different backend stacks with six repos devoted to the front end, eight deployment pipelines and four front-end squads. So what do we do with that? Well, of course the answer is consolidation. simply migrate to a single

codebase. We scoped it to the booking journey because that was the most uh well the area of the code with the highest rate of change and the most commercially important for the business. So it seemed the right place to be focusing our consolidation efforts. So we estimated it would take six months to get the core changes out and then a long tale that we could pick up

in our 20% time. Well uh that's six months planned. 18 months later, uh we estimate we still have six months to go. Again, probably uh familiar. Um to be fair, for about six months of that elapse time, the project was put on hold to divert capacity towards urgent business priorities. Uh but it's still taking way longer than planned, and the CEO is right to ask why. So,

the aha moment for me was That's a librarian's goal. What we actually needed was something else. We needed transformation. We had to stop porting code and start engineering the context and let the machine start doing the heavy lifting. So what does that mean? If I were to rewrite our technology strategy today, given what we know now and where we are with the tooling, I would focus on

how we shift to endtoend agentic workflows. And I break it down to three phases. Firstly, it's about closing the loop. Go beyond the basic use case of prompting to get code snippets to investing in the tooling and the infrastructure such that you can task an agent with a ticket and it comes back with a pull request. All tests screen. Later, of course, you can move up the

chain uh to get your agents to fix errors at the CI/CD level. And ultimately, you want to get uh be deploying the code through canary releases and checking checking uh getting it to fix the production areas. But I think level one for most people is is good enough for now. Um secondly, it's about reducing the noise in your code. Find out why your agentic task completion success

rates are low and addressing systematically addressing those issues. Mine for inconsistent design patterns. Um seek out poorly named functions and variables. Get rid of those vestigial implementations like that AB test uh that's still been in the code after two years. um it's throwing all your agents off. And the final step is uh as you have improved the signal to noise ratio within your code is to turn

your attention to the context outside of your code. Make sure your standards documentation is up to date. Get AI to critique and refine your architectural diagrams until they are fully self-documenting. Review review your test suite. As it happens, the end result of these endeavors should actually be much the same. you're going to get cleaner code and cleaner architecture. But now it's a side effect of your aentic

enablement as opposed to the being an end goal in itself. While we have may have struggled in the past to explain to our commercial colleagues the value of paying off technical debt and getting our documentation in in in uh in in a good state, the AI revolution makes that crystal clear. If we don't do it, we're going to be left behind. So my suspicion is that the

will share a close resemblance to the distribution that we see in the broader world outside. There'll be a handful of you that are cooking on gas and leading the charge, but I suspect there will be plenty of you who like me have yet to get meaningful traction on this transformation, this transformation of our industry. So, I hope this talk goes a little way towards cementing your confidence

and boosting your bravery. But I will finish um by saying that it truly inspires me to look out into this room of select CTO's because it tells me there are good people willing and eager to take on that challenge to seek out where they are defaulting to habitual old ways and having the courage to do something different. And for that I salute you all. Go find your

flamingo and good luck to us all. Great. On to questions. Uh, smaller product engineering teams are an interesting future state. How would you invest engineers in optimizing the software design STLC for agentic AI now to make this a reality? Would I invest engineers reinvest in? Yeah. So, I think this is the the the core of it. Like I think um you know like when we went through

the DevOps revolution where we realized that we were operating with our engineering in a silo and our ops in a silo and that you know as we looked at this in a systems thinking approach addressing the problem upstream and making sure we have our our flow of of um of value through the system. I think that's exactly where we are now in that we we as a

company at least haven't been investing in trying to get our enentic engineering to a state where we can get that flow happening through the system. So I would yeah definitely like for me the the shift in the technology strategy for us will be focusing on how do we make that really work and I think there's some been some great material we've seen earlier in the conference about

how we might go about that you know how do we address you know the stuff from son cube this morning was really interesting about the how do we engineer into the cycle the the verification steps um so that we can get these agents to to to run more freely. So yeah, I think it's definitely it's one of those things when you invested in the DevOps suddenly you

got this massive improvement in our commercial outcomes. It's the same way here. I think if you invest in your agentic engineering, you will get your same um commercial outcomes that you look for. Um all right, next top question. How do you train your engineers to become product engineers? Um it's a very good question. So I mean obviously um there's a lot to be you know I mentioned

in the in the talk that partly it's about kind of finding that talent out there people who have that that inclination like you'll come across that you know the engineers who do really like to craft the code versus the one that really are looking at what the result of the AB tests were. Um so partly that will be will be about a selection process. Um but you

know it's feedback right with any form of training. um you know we have to uh describe what good looks like and and um and and provide the training for people to go there. Um yes, everyone's very keen on understanding project filming. Uh yeah, we have about six months left. Oops. Um today uh that might change. Um good. Right. Next question. What assumption did you hold longest before

letting it go? well so I mean let's to be really fair about Flamingo it's it was is a you can see it's like a multi-reo architectural problem and like I think today you know the LLMs aren't good enough for those big sort of system level re factors like it require a huge amount of context um and so you know I think So, so we're still kind of

like we're still plowing on I guess with the the flamingo strategy um because we can't sort of apply that AI at that system level thinking but you know in terms of once we get I think I mentioned it earlier in the talk like I think we see that the the the rate limiting step is in that planning and designing um phase where we want to look at

the the system in in its entirety. Um and so it's probably you know it's an ambitious goal to really move towards agentic engineering when you still have quite architectural debt to to go for. So I think it's probably that is the the thing that I'm having to um trade off each other and like how far you go into the agentic engineering before we kind of clean up

all our architectural debt. All right, I think I think I'm running out of time for questions here. Um yes, >> thank you very much. >> Thank you for sharing.