Derek Wise, CPTO at Civica, discusses leadership, legacy tech, and the art of failing fast

‍Host: Lucas Hendrich, CTO at Forte Group
Guest: Derek Wise, Chief Product and Technology Officer at Civica

Introduction

Lucas Hendrich: Welcome to the CTO to CTO podcast, where chief technology officers dig into the challenges and opportunities leaders face every day at the intersection of business and innovation. I'm your host, Lucas Hendrich, CTO at Forte Group. In this episode, I'm talking with Derek Wise, Chief Product and Technology Officer at Civica, a global leader in public sector software and technology. We'll discuss the multidisciplinary aspects of the role and how it pairs with his diverse industry and personal experience. Here's the conversation.

Derek, it's great to be talking to you today.

Derek Wise: Thank you.

The Platform Guy

Lucas Hendrich: Looking at your background, you've worked in different geographical regions and cultures. Could you introduce yourself and take us through what you've learned working in different parts of the world? What's unique, and what's the same everywhere you go?

Derek Wise: I enjoy this part of my career. If you look at my CV, I've done a little bit of everything: video games, running my own infrastructure, hosting, and IT company for a while, pharmaceutical research, and advertising. Now I work in government technology across healthcare, education, and local government. So it's a pretty wide range.

What's always been consistent for me is solving some of the common problems in software. Can I make this simpler? Does it have to be this complex to solve the problem? Where's the reusable technology?

In every company I've ever walked into, I ask: Do you have single sign-on? Can you start to normalize your user interface so customers have an expected experience with you and your brand? Those questions apply regardless of geography, language, or culture. There are still core components to a product.

Underneath all the titles and roles I've had, I consider myself the platform guy. I'm almost always trying to take what's been built, or what needs to be built, and turn it into something more reusable, componentized, or service-oriented for whatever offering I'm building.

Skill set, mindset and organizational structure

Lucas Hendrich: It's interesting, because it's also different industries. You might have the platform or SaaS mindset, but then you go into a tech-enabled services company and have to build out that platform. Talk a bit about those challenges.

Derek Wise: There isn't a formula that works for every company, so you have to treat each one as an individual. It's like meeting someone for the first time: you establish what you have in common and what you don't.

Whenever I work with a company on where it is in its product development lifecycle and where it wants to be, we start with an audit: What tools do you have? Where are you at? My CEO has a brilliant phrase for it: skill set, mindset, and organizational structure. You have all three components, and mindset is probably the first to start with. Is the team really ready for whatever journey we're signing up for?

If you're in a legacy software company with a truly monolithic, single-piece-of-software structure — and that applies everywhere; I've been in video game companies like that, so even some of the coolest tech is fairly monolithic and hard to break apart — you have to ask: Is it worth it? Do you really want to go on this journey? Is service-oriented architecture right for you? If so, in what quantity and at what speed? You start those conversations early. That's where everything is the same, but it's very different per company in terms of where you start and where you aspire to finish.

Regulation and the Velocity of Change

Lucas Hendrich: Where has that been hardest to reconcile with a domain? Going from gaming to pharmaceuticals, what are the hard parts — the tails — where it's most challenging?

Derek Wise: It's easiest where you don't have many legislative frameworks, governance, or compliance restrictions to deal with. In healthcare, HIPAA in the United States really affects how fast you can move and what you can do with data. Similarly, in advertising, GDPR made a big difference to what we could and couldn't do, at what speed, and with what tools.

On the other side, advertising and video games were much more about what the customer could consume and what was appropriate for us to do with them. There was a smaller distance between us and the customer. And I think that's how you determine the velocity of change you can achieve: the distance between your product and your customer.

Lucas Hendrich: Interesting.

Derek Wise: It determines that. What is it — Kevin Bacon?

Lucas Hendrich: Six degrees of separation.

Derek Wise: How many degrees of separation are there between your product and your customers? Are there legislative, compliance, or regulatory constraints that restrict your ability to make changes?

Lucas Hendrich: So gaming would be ideal in that sense?

Derek Wise: Absolutely. We made lots of bad changes, but we could fix them in two weeks. In healthcare or pharmaceutical research, any change could have a 10-year knock-on impact on the discovery of a drug. You had to think really hard about making changes, so much more thought went into pre-planning.

Whereas, frankly, when we looked at the funnel for acquiring new customers in a free-to-play video game, we could just move the fields around and see if it made a difference to the funnel. If it didn't, we'd switch back.

What It's Really Like Being a Gaming CTO

Lucas Hendrich: In a sense, you're answering a question I'd thought about before this conversation: What aspects of being a CTO at a gaming company might surprise our audience? People might think that you're a gamer, it's your passion, you get a bunch of gamers together to build games for gamers, and it's easy-peasy. But I'm sure it's not that simple.

Derek Wise: If you look at where some of the biggest innovations in technology have happened since the '80s, video games have led the way in quite a few areas. Think about A/B testing on workflows in web development. We were looking at free-to-play games, funnels, and drop-off, trying to figure out: Do I need them to validate their email? That might cost another 12% drop-off in acquisition.

So it's a great place to experiment if you want that high fidelity. It's not "fun and games," so to speak. It's a lot of standard process you'd use in any web application for customer acquisition, and it applies everywhere.

You just have a bit more latitude with your attire — jeans and a T-shirt are totally fine — and you can be a bit more daring with the kinds of changes you make with your customer base. Being a CTO in video games is the exact same job as being a CTO at a large enterprise software company, just with different things you can change at different speeds. It's fundamentally the same job.

What I find interesting is that when people see I've been in video games, they assume it's a different quality of software development practice and a different kind of practitioner.

Lucas Hendrich: Well, it's a different toolkit to a certain degree.

Derek Wise: There are some different tools, but the fundamentals are the same. Exactly what I've done in large software companies happens in small video game companies. Is there single sign-on? Can we reuse some of this tech? Wait — why did we build this monolith that's no longer maintainable? The exact same problems exist.

It's still people writing code, so those fundamental skills are still required, and they transfer. You just have to be more careful about how rapidly you make changes in some environments — enterprise software with governance, risk, and compliance, versus a video game company focused on the inbound marketing funnel. It's a very different metric to track.

Lucas Hendrich: You know, when you think of Slack, that was born of video game development as well.

Derek Wise: Exactly. And Slack is essentially a derivative of IRC. They changed it and packaged it to make it easy and free for people to install. Try it before you buy it, then add the hooks and triggers. They basically took a game design document about how to hook people into something and built it into Slack's SaaS model.

Lucas Hendrich: That's brilliant.

Monoliths vs. a Portfolio of Modern Products

Lucas Hendrich: Talking about legacy monolith applications, I have one of those questions with no right answer — I'm just interested in your thought process. At Civica, I understand you have a portfolio of products. Which is more challenging, and why: taking one big monolith and breaking it apart, decoupling it, and modernizing it? Or taking several modern platforms, born of different tech stacks and talent, and integrating them?

Derek Wise: Both are difficult, for different reasons. Much of what makes something hard to change is the architecture, but part of it is the product's success.

A really successful, highly valuable, highly profitable monolith is hard to change. As soon as you start tinkering with it, you affect all the customers and the whole revenue base, because it isn't fragmented or segmentable. You might want to make a change, but it can be very expensive and risky.

Monoliths with a small customer base, or declining in value, are easier to change, because the business's desire for change is higher and the risk may be lower. If we're already losing customers on our legacy tool, there's a strong imperative to change. If we have 100% year-over-year growth on our legacy tool, it's very hard to convince the business that now is the time to rewrite it. So honestly, success creates the biggest risk to change.

If I had to choose, though, I'd take highly segmented modern products. I can put a REST API around them and connect them. It's an easier way to work modularly back into a platform than trying to crack the monolith.

In my experience, when you crack the monolith, you find things everyone knows by different names: stored procedures or triggers. Someone wrote a really smart script into the database with no documentation and no linkage, and you have no idea what it does. Unpicking that spaghetti code is the danger in legacy systems — you don't know what happens if you remove something.

I've had that happen in large enterprises, and in video games too. I worked for CCP Games in Iceland — I can say that one out loud. They wrote everything in Stackless Python: a single-threaded application, everything in one space, one live universe that everyone played simultaneously from one hub. It's brilliant, and I absolutely love it — until you try to change something. You don't know what moving one core line of Python does to the whole system, and it's very hard to unpick.

Legacy Decisions and Respect for Predecessors

Lucas Hendrich: I want to reflect on what you just said. I think the world at large — maybe the non-tech business community — would be surprised at how boring and old a lot of the technology we deal with is, even when it's wildly successful. That's exactly why you don't go and modernize it. What do you think about that?

Derek Wise: It's rare — at least, I haven't been hired yet — to walk in and find software already running on microservices or nano-services, using service-oriented architecture, with Swagger auto-documented endpoints and a CI/CD pipeline that publishes every hour. When you do find those, they're usually built out of a legacy system the company decided to move away from because it hit a scale problem. That's where you get hired to come in and do the work.

Even the most innovative companies I've met started somewhere. They're trying to unpick the MongoDB choice they made years ago, or move the Redis pipeline they built onto Kafka. They're making these choices now because they learned.

As a tech leadership industry, we need to be careful not to self-flagellate and be overly critical of ourselves. We made choices that got the software through the first part of its journey, and now we can make choices that let it grow to the next stage. I haven't found anywhere yet that isn't carrying some legacy tech or legacy choice that may have been right at the time but is wrong for the business at scale, today, or in light of a new security issue.

Lucas Hendrich: And it's a huge risk that those choices are rarely documented. It's so easy to look back and say, "What a horrible decision." I know I've done that, only to find it was a decision I made, or code I wrote. You look at it six months later and think, who would have done that?

Derek Wise: Yes. And no matter how hard you try as a software leader, you end up wondering: When I leave this company, will they think about me the way I talked about the person before me? It's very hard to avoid.

But "write it down" is a very good policy. Why did you make this decision? It's OK to make a mistake, but record that the decision was made for these reasons. Then: here's the scope that's changed, here's why it changed, now change the outcome. That's totally fine.

We're often pretty critical of ourselves and our predecessors. I try to be gentler with the people who came before me, because they usually got the product to a place I couldn't have. So I try to be respectful of them. Maybe we should create a Slack group where we all hang out and praise each other for doing a better job than we give ourselves credit for. The companies I've been at got where they are on the backs of people making really hard choices on really tight budgets to get things done.

Lucas Hendrich: Absolutely.

Derek Wise: And then they bring me in and say, "Hey, can you make it scale now?"

Lucas Hendrich: Yeah.

Derek Wise: That's usually a different set of choices from the ones they faced at the beginning.

Lucas Hendrich: Absolutely. It's very Bayesian in that regard — constant updating.

Derek Wise: And it's hard to know all the outcomes. It's lovely to build an architecture for success, but if you have to wait 24 months to deliver it and the revenue opportunity is two months away, did you miss it by making "better" choices? Or was the better choice to deliver for customers earlier? I'm a big fan of iterative software development, and that means you have to be comfortable with failure.

Learning From Failure

Lucas Hendrich: That's pragmatic, but also very empathetic. Did that come from being a gaming CTO?

Derek Wise: I wouldn't say my pragmatism came from games specifically.

Lucas Hendrich: But this ability to fail fast and iterate…

Derek Wise: That's probably where I've seen it happen most. Here's my favorite story. I tell it to my teams, because I'm trying to make them comfortable with the idea that I'll create an environment where they're allowed to fail, and I do that by talking about my own failures.

At one video game company, I took all the servers down for 32 hours within my first 30 days on the job. It was a very critical moment. When I came back in, the CEO had my face on a screen in front of a burning building, in front of 600 employees, and said, "Derek, what did you learn from that?" I said, "Never trust the DBA when he says he did the backup." It was a big joke and it was funny, but they loved it. That team enjoyed failure — presenting it loudly, and saying what the failure was.

From there, I was on a mission. We got rid of all tape backups at the company and moved to disk-to-disk recovery. We moved to Fibre Channel SAN storage instead of some of the legacy systems we'd been using. We changed the business and how we operated because of a failure. Without that failure, we never would have done it.

We'd have stayed on DLT tape drives and incremental storage, with the tapes kept in the garage of a guy named Ollie here in London. That's why it took us 32 hours to recover. Afterward, we had a separate SAN where we just swapped the drives, with real-time red/blue, on/off backups. We became leaders in how that worked there.

Lucas Hendrich: But it took a failure. It reminds me of what I think Anthony Hopkins' character in Westworld says: that the best invention of the universe is the mistake.

Derek Wise: Absolutely.

Leadership Lessons From the Marine Corps

Lucas Hendrich: Talking about your background, I understand you were in the military at one point. Being a CTO or chief product and technology officer, I find it really hard to narrow the role down to one skill set. It's so multidisciplinary. To succeed, you have to think about the business, be something of an economist when it comes to budgets and macro factors, and obviously have a technical background. But that technical background usually goes deep in one area; there isn't time to span every domain. Thank goodness we now have generative AI to help extend that. So I'm curious: what heuristics do you bring to the role from your time in the military — if any?

Derek Wise: I definitely got something out of my time in the military. But stepping back to your question, my first comment is that there's no such thing as a CTO. A very bold statement on the CTO to CTO podcast!

There are many CTOs, each fit for a particular type of role. Often when someone sends me a job ad, I ask: Are you looking for a lead developer cum CTO? An engineering manager cum CTO? An Agile coach cum CTO? There are many flavors, and some people mix several. A small London startup trying to do something quickly is often looking for a CTO who can also write code and is the number one committer in GitHub.

What I do today is predominantly building culture. I spend a lot of time making sure my team feels safe to fail, and I focus heavily on hiring people who are better than me. There's no one on my senior leadership team whose job I could do better than they do — that's one of my prerequisites. They're all better CTOs, better engineering managers, better VPs of product than me, and so on.

That's part of what I learned in the Marine Corps: there's a difference between leadership and management, and management is a job title. My job title is Chief Product and Technology Officer. It's wild and wide and covers a lot. But my task is to be a leader and ask, how do I enable these people to succeed? That's where I spend most of my time.

The heuristics I learned came partly from the Marine Corps and from Navy SEAL and war college thinking on good leadership traits. If you try to be everything — the manager and the leader, doing all the work and all the actions — you're setting yourself up for failure. There are stories in Good to Great about becoming the indispensable person. But indispensable also means single point of failure. It also means a limiter on the business. So getting out of your own way by enabling your team is the number one thing I learned in the Marine Corps.

Integrating Teams and Closing the Distance to the Customer

APIs are contracts

Lucas Hendrich: Let me go back to the earlier question. Say you have five product teams on modern platforms. They're all elite, deploying to production eight times a day or more.

Derek Wise: Wow. OK, great.

Lucas Hendrich: What are the challenges in integrating those teams after you've acquired them and are creating an ecosystem? It should be as easy as exposing APIs, right? But nothing's ever that easy.

Derek Wise: I'd start with two areas. An API integration is sometimes called a contract, and it really does take negotiation on both sides. Who's going to run the interface? Who's going to aggregate this data? Who's going to build the microservice that connects these two things? There's work that needs to be agreed on.

It sounds simple — there's an API, so why not just call it? But typically another microservice is needed to aggregate the data and report on it, and someone has to decide who presents it and why. So there's work to be done, and agreeing who does what work, for what purpose, is really important.

One reason I love being a CPTO — with the product piece added — is that it connects you to the customer and to why you're doing things. Instead of engineering teams independently deciding, "I think I should run this piece of software," we talk about where it will be presented to the customer, how it generates value, and therefore who needs to operate and maintain it: whoever is closest to the customer.

I use that distance-from-the-customer idea almost every day. I'm constantly trying to reduce the number of nodes between my product and my customer, including where engineering sits and how far it is from the customer.

Purpose over purism

Lucas Hendrich: That's a great mental model. I wonder whether it's something we've learned over time in technology from burning-platform failures, where people thought, "We'll just do it this way," without being in touch with what customers want.

Derek Wise: I think we sometimes get too purist in engineering: the hamburger model, service-oriented architectures, microservices, nano-services. Yes, they're a means to an end. But if you don't know why you're doing it, you can pontificate all day about the right engineering model. In the end, the outcome for the customer is all that matters.

I'm a big fan of Phil Knight: do the right thing for your customer and the money will come. That's how I like to model things with my teams. I like to think in Neo4j-style graphs: looking at all the nodes connected to my customer, how far away are my engineering and product teams? How close could I get them? If I can get my engineering and product teams to understand and empathize with what's happening with our customers, better things come out of those teams.

Lucas Hendrich: Do you have meetings with sales to do that? Does that help?

Derek Wise: We treat the sales teams as a great stakeholder group, and I like to put sales and commercial in the right place. They're a good aggregator of what customers are willing to commit to commercially. But they may not always understand the business imperative that customer is facing.

So we try to connect the dots where they might be disconnected. Yes, we want to sell this to them, and yes, they're willing to buy it. But does that tell us why they're doing it and what their strategy is? That's where I think product managers have a key role. I connect the product manager there, and the distance between product manager and engineering team tends to be almost exactly zero. They're embedded in the engineering team, which I consider the most modern way — or, at worst, one node away, sitting just outside the product engineering team.

One node between the customer and engineering

Lucas Hendrich: I think we'll see an inverse proportionality over time. As technology becomes more commoditized and easier to generate, success is indexing more on product thinking than on the technology side.

Derek Wise: I think that's how we've grown up over the years. Scrum and Agile came out, and we talked about doing things a certain way. That's fine — great, even. But for a while it got too rigorous; it started to feel like PRINCE2 project management. Once we really honed in on using Agile the right way for customers, we returned to some of the original principles. Can you iterate quickly? Can you get something out the door? When can you show the customer value? How quickly can you get feedback on the value created?

What I've seen some companies create — even some I've worked at — are giant groups sitting between the customer and the engineering team. That was just too much. My principle is to minimize how many people sit between the voice of the customer and the engineering team. At most, I'd like that to be one.

Lucas Hendrich: That's a great model, and I like the analogy of looking at it as nodes. It's a great way to think about it.

Derek Wise: Computer geeks — that's what we do.

AI and Technical Debt

Using AI to unpick tech debt

Lucas Hendrich: Here's the question you probably saw coming, though I didn't prepare you for it. I hate saying "AI" generically, because there are many use cases, but specifically generative AI: How is it being sprinkled through the products you're working on now? I'm asking in terms of material gains, either on the product side or in internal development. You mentioned legacy platforms with lots of undocumented stored procedures. Are you throwing those into an LLM and having it try to sort them out? What are you experimenting with and learning from?

Derek Wise: Let me start with what's most concrete. If I could solve one thing for all engineers worldwide, it would be tech debt. I see AI as a tool we can use to understand how big the tech debt is and how to solve it.

At its core, AI is a really good translator. You give it one language and it can convert it to another. So we're looking at some of our legacy languages and generating recommendations on how to rebuild them.

I've also been working with a couple of companies here in London that I can't name. They can log into our GitHub, go into Dependabot, move across all the repos affected by a change we're making, and make recommendations. Not just the line of code to optimize, but how to orchestrate all the other pieces it has dependency mappings to, to optimize or rewrite the code. That's where I think we're heading.

If you've written code for a while and carry a lot of tech debt, it really slows you down and makes change hard. If I could unburden software developers from tech debt, what we could create would be amazing. That's where I want AI to take away the drudgery of technical debt and defect fixing.

I've seen great companies do this. One I can talk about is GitHub, which has autofix features. If there's a legacy security issue that's already been fixed elsewhere, you find it, right-click, and fix. It applies what it's learned from other places, which gives you a really big lift.

What the numbers show

Derek Wise: Across the daily active users on my team using GitHub Copilot, about 30% of Copilot's recommendations are being accepted by our engineers. That shows we're really starting to interact with recommendations from Copilot-type tools and integrate them into our workflow.

As an engineer who got his start in the '90s, I used to go to SourceForge and copy someone else's code. We've always done this. But we used to pop out into other browser windows or search engines to find snippets. Now it's integrated into our workflow, which removes a lot of friction.

Lucas Hendrich: It's interesting. When people think about the productivity gains, they often think it's just writing code for you. But really, it's about reducing context switching — not having to keep track of browser tabs anymore. I love Cursor for that reason, for example.

Derek Wise: Yes. You used to have to track everything: here's where I always go for these tools, here's the person I follow for this snippet. That's how I used to write code. Now all of that has been read and aggregated in one place. When I type, "I'm looking for a quick way to build a 24-hour clock," it gives me examples that just work.

Then I can tune and improve them for my application. That's another reason engineers need to be really close to the customer: so they understand which recommendations to take and build on.

Lucas Hendrich: I think about it like learning chess online. The chess database tells you every move: that's a 97% move, so it's pretty safe; or it's a 3% move, so you're either an incredible genius like Magnus Carlsen or you're mucking it up. I feel the same about suggested code. It's not necessarily the best or even the right code, but it's in the right area. It gives you a landing zone, and that's a big productivity gain.

Derek Wise: I'd just say we're in the early days. I still see really good recommendations sometimes and really bad ones at other times. You still need a human in the middle saying, "That doesn't work," or "That does work for my needs."

But look at the acceptance rates — and this isn't just our numbers; you can see GitHub's published Copilot stats. We're seeing about 30% of recommendations accepted by engineers and implemented in the code. If you trust your engineers, that's a pretty good indicator of how much time it's saving them.

Lucas Hendrich: Do you see that ticking up over time?

Derek Wise: I think we've reached where the current generation of tools is today. When a new version comes out — a new set of skills, a new language supported, and so on — those numbers will go up. But if I have code in Fortran, there's no code-recommendation support for Fortran, so I can't use it there. In C#, though? All day long.

Communicating Technology to Investors

The same language, whoever the investor

Lucas Hendrich: A topic that's becoming more prevalent among technology leaders is working in investor-backed companies, whether seed, VC, or private equity — particularly private equity, in my experience. One challenge of the role is communicating your technology vision, and what it means, concisely to investors. I think that's a unique skill. What do you think, and how do you handle that pressure, especially now that you're not at a gaming company? Not that gaming companies don't have investors, but it's a different kind of…

Derek Wise: I worked at a gaming company owned by a private equity firm. Now I work at a government technology company that works with a private equity firm. The principles are pretty much the same: What are we doing with our funding that makes an impact on the customer — and sometimes, in B2B, on their customers — and how does that help the company generate value? We care about that regardless of whether it's VC or private equity. They just have different time horizons.

Lucas Hendrich: I'd have to agree. But I think in private equity there's a greater chance the investors are less technologically savvy. It's a dangerous statement, but depending on the VC fund, there may be plenty of tech-savvy people there already. Maybe I'm wrong, but I've seen that as a real challenge. How do you break it down so a totally non-technical person can see the value?

Derek Wise: You definitely have to translate in board meetings and other meetings. But I'll go back to my original point. I was in a VC-backed company in Silicon Valley for quite a while, and the language I used there is pretty much the same as what I use in private equity now. We simplify everything down to the impact on the business, the outcomes, and often the commercial side.

When I walk into a room, regardless of how savvy any individual is about REST APIs, technical detail isn't for the whole room. It's for me and the one other person who understands me, because there's always a CFO in the room, and always a CRO. Whatever company they're at, they won't be speaking at the level we do as CTOs.

If they don't understand, it's on you

Derek Wise: One principle I use: when you're speaking to someone, their not understanding is your fault, not theirs. I take it on myself to figure out how to communicate what my audience needs to know. If my audience speaks JSON, fine — we'll talk JSON.

That's actually happened. I have a funny story, which maybe I'll tell you another time, about a very prominent multi-billionaire CEO who liked to speak to me in JSON. That was the language we spoke. It was very efficient — and actually really annoying. I'd be giving a PowerPoint presentation on a budget, and he'd say, "Hey, can you open the editor? I want to change that currency value." That's a weird place to be with a CEO.

For the most part, though, I'm translating into the language that matters to the people in the room. Not dumbing it down, and not trying to get anything over on anyone. You don't want to sound like you're hiding or obscuring information. But trying to ramp everyone up to your vocabulary, when you don't know theirs, probably isn't the right approach. My focus is that I'm the communicator, and they want to be communicated to. I need to understand their language, not just mine.

Learn English before Rust

Lucas Hendrich: That's not typically an engineering skill you learn in an undergraduate computer science degree. I think it's a testament to your success that you can communicate with an investment audience that isn't technologically savvy. What advice do you have for others?

Derek Wise: It's going to sound a little rough if you're a CTO, but: before you go out and learn Rust, learn English. It's critical that you speak the language of the people you need to align with. Knowing another programming language or toolset may not be what scales you up and lets you make a bigger impact on the business.

I spend a lot of time and effort learning how the private equity cycle works and how investors think: why years four and five are such a big deal, what happens at year six, what happens at year three. I educate myself so I can speak to them in language that matters to them.

My other advice: say you don't know. I think it's my biggest skill. I'm very happy to tell a private equity investor, "I don't really know the answer to that. Could you explain what you're looking for?" Then let them speak. Ask a question, let them answer, really hear them, understand their real concerns, and see if you can solve them.

Lucas Hendrich: People are more forgiving than you might think.

Derek Wise: Yes, people are more forgiving than you think. These are highly successful individuals, but they're still human. If you ask for help — especially when you're the one who'll help them make more money and make the company better — they want you to succeed. Asking for help is a really hard thing for us introverted CTOs, who sometimes don't love interacting with people. But go ask for help from people outside your typical circle of techies.

Lucas Hendrich: And financial engineering is another kind of engineering, with a different lexicon.

Derek Wise: I spend much more time than you might expect with Martin, our CFO, because I need to understand his language, and he's catching me up.

A Book That Changed His Thinking

Lucas Hendrich: This is one of my favorite questions. Surprise me: the last book, movie, or anything that changed the way you think. I love hearing things that have nothing to do with the typical Lean, Agile, or O'Reilly books. Not that those are bad, but I'm looking for…

Derek Wise: I think that's the right approach. I've read other things, but I'm staying off the sci-fi track for a minute. The last book I read, and one I strongly recommend, is Why We Sleep. I'm finding out that four and a half hours…

Lucas Hendrich: Is that a Huberman book?

Derek Wise: I think so, yes. It's a fantastic look at the research on how sleep scientifically affects our daily lives.

I've been one of those people on 40 units of caffeine a day and four and a half hours of sleep: stay up all night, get up early, crush, crush, crush. Recently, I've been focusing on how to get better at being me. When are my neurons firing best, and when am I most creative? It's also about being empathetic with others. That's really hard when you're tired and broken, angry and caffeine-deprived, or wishing you had more caffeine.

This book was really helpful for me, and I've passed it around my leadership team. First, so they know I care about their health and whether they're taking care of themselves. Second, it helps me be present and better in the room, and less angry or reactive. I can slow down and think a bit more before I react or overreact.

Lucas Hendrich: So the book you're talking about is Why We Sleep by Matthew Walker.

Derek Wise: Absolutely, yes. Correct.

Lucas Hendrich: Then I'll have to read it. I've heard a podcast about it, so now I'll go back and check it out.

Derek Wise: Podcasts are great, but I'd recommend the book too.

Lucas Hendrich: A good shortcut.

Derek Wise: A good shortcut, yes. But the book is great. I read it on a sun lounger on holiday with my wife, practically in one sitting, and realized I needed to change my evil ways. It's been transformative in preparing me for my daily duties. And I've used it as a catalyst for reminding my team that I care about them too, so I've really pushed it out to my teams.

Lucas Hendrich: That's a great insight. It's how I think about who we are as human beings: these biological processes get in the way of everything. They make communication messy and make it hard to get through the day consistently.

One book that changed the way I think is Thinking, Fast and Slow. There's an anecdote in it about a study showing that judges convict more people right before lunch, because you can't resist the biological impulse — the hanger — that modifies your behavior.

Derek Wise: Yeah.

Lucas Hendrich: And the last way you want to make decisions is when you're angry or out of sorts — or sleep-deprived. Is part of that because you've worked across many time zones, do you think?

Derek Wise: I think I'm just a product of the '90s. I thought the best way to be a hacker was to stay up all night working my butt off. Every moment I took a break felt like I was undermining my productivity, my product, my goal. What I've realized is that much of the time and energy I threw at problems was pretty fruitless, and actually error-prone.

My best productivity is from about 10:30 to 12:30. That's when I'm the most efficient human I can be, especially when I'm well rested and know how to handle the stress coming at me. I'm a better manager for it, too. My teams can work with me better than with the stressed-out version of me.

Managing Younger Talent

Lucas Hendrich: That's interesting. Speaking of growing up in tech in the '90s — I think we're the same cohort, give or take — what are your thoughts on managing younger talent?

Derek Wise: I once got a piece of feedback from John Chambers, chairman of Cisco Systems at the time. He said, "Derek, no one else is you." That's something I take into the room. I work the way I work, the hours I work, and in the structure I work in because that's what works for me.

The younger people I've met aren't lazy. They work differently. So you have to find different incentives, because it's not all about salary. Some of it is about autonomy. I spend a lot of time figuring out how autonomous I can help my teams be. How many decisions can you make on your own? How much experimentation can you do? How wide can I make your budget window so you can go off and run with it?

We create mechanisms for them to demonstrate success, failure, and improvement, instead of the rigor I've applied with groups in the past — where, frankly, I was micromanaging. I've found that younger generations reject micromanagement even more, so I'm changing my style to adapt.

In my opinion, good managers don't have one management style. Good managers adapt their style to their team. With my younger team members — whose birth years start with a 2 instead of a 1 — it's really critical that I give them the support they need, but also the room to experiment and contribute. And I think some people from older generations are seeing that and want more of it too.

Lucas Hendrich: That's interesting, and I totally agree. One thing I've noticed with that cohort, and now with my own adolescent kids, is that they're less likely to voice their dissatisfaction. They're more likely to just tune you out.

Derek Wise: You just get ghosted, right? Either they're ghosting you on the job, or they've already left and you don't know. You don't always get the feedback loop of someone escalating to their manager in a one-to-one and saying, "This isn't working for me." They've just checked out. So I think you have to be more proactive in checking in to make sure they haven't checked out.

Closing

Lucas Hendrich: Derek, it's been wonderful talking to you. I really appreciate you being a guest — really great insights. Thank you.

Derek Wise: Thanks.

Lucas Hendrich: That's it for this episode. Join us next time for more real-world conversations between technology leaders. And if you liked what you heard, subscribe to CTO to CTO. See you soon.

‍