Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses Technical Sparring Partners to Make Better Decisions
Transcript
- Lucas: You've got a major technical decision on your plate — database sharding, a new service mesh, maybe a cloud migration. You've done the analysis, the team's aligned, but there's that nagging feeling. What if you're missing something? Luna: Right, and you can't exactly run it by your CTO because you are the CTO. Lucas: Exactly. So a growing number of engineering leaders are turning to what's called a technical sparring partner. Not a mentor, not a consultant — a peer from a non-competing company who agrees to stress-test each other's big decisions. Luna: I've heard that term thrown around, but I've never seen it formalized. How does it actually work? Lucas: Let me give you a concrete example. About a year ago, the CTO of a mid-stage SaaS company — about 80 engineers — was planning to shard their Postgres database. They'd done all the modeling, the cost projections, the rollback plan. But something felt off. So they booked two hours with a sparring partner from a fintech company they'd met at a conference. Luna: And the partner actually told them to pump the brakes? Lucas: More than that. Within thirty minutes, the partner identified that the data access patterns didn't actually justify sharding — a well-designed read replica with a caching layer would solve the performance problem at a fraction of the complexity. The CTO later said that single session saved them about six months of engineering time and a massive operational headache. Luna: So the sparring partner isn't just a rubber stamp — they're there to play devil's advocate, but from a place of deep technical empathy. Lucas: That's the whole idea. And the key is that it's reciprocal. You spend an hour on their problem, they spend an hour on yours. No money changes hands. It's built on trust and mutual respect. Luna: What makes a good sparring partner? I imagine you can't just pick someone from your own company — too much shared context, and politics. Lucas: Exactly. The best partnerships are cross-company, ideally from adjacent industries. You want someone who understands your technical stack and scale, but who isn't burdened by your internal politics or groupthink. One CTO I spoke with found her partner through a private Slack community for engineering leaders. They'd never met in person, but they did a video call every two weeks, alternating who presented a decision. Luna: And the ground rules? I'd imagine you need structure to keep it productive. Lucas: Absolutely. The most successful pairs I've seen use a simple three-question framework. Before the session, the presenting partner sends a one-pager that answers: one, what decision am I making? Two, what are my top two alternatives? Three, what's my gut leaning and why? Luna: That forces clarity before you even show up. I love that. Lucas: Then during the session, the sparring partner's job is to poke holes. They ask things like 'What would have to be true for the alternative to be better?' or 'If you were wrong, how would you find out?' It's not about being adversarial — it's about surfacing blind spots. Luna: I can see how that's different from a mentor. A mentor might say 'here's what I did in your situation.' A sparring partner says 'let me challenge your assumptions.' Lucas: Exactly. And the relationship is symmetrical. Next week, you're the one challenging their decision. That peer dynamic keeps egos in check. Luna: It also builds a kind of decision confidence. You walk away knowing you've been stress-tested by someone who has no skin in the game. Lucas: That's the real value. And it's worth saying — this isn't just for big architectural calls. I know a CTO who uses their sparring partner to debate hiring decisions for director-level roles. Another uses it to decide which technical debt to tackle next. Luna: The frequency question: how often do these sessions need to happen to be effective? Lucas: Most pairs I've seen settle on every two to four weeks. You need enough time between sessions to have something substantive to bring, but not so long that you lose the thread. A recurring calendar invite is key — it forces you to prepare. Luna: And if you don't have a technical sparring partner yet, how do you find one? It's not like there's a directory. Lucas: There actually are a few communities now. The Rands Leadership Slack, the CTO Connection, and some industry-specific groups. But the old-fashioned way works too: reach out to a peer you respect from a conference or a past job, propose the idea, and start with a single trial session. If the chemistry is there, it'll snowball. Luna: I want to come back to the database sharding story. What was the specific blind spot the sparring partner caught? Lucas: The CTO had assumed the bottleneck was write throughput — that's the classic reason to shard. But the sparring partner asked to see the actual query profile. Turned out 95 percent of the slow queries were reads, and most of those were on the same three tables. A read replica with a Redis cache in front handled it easily. Sharding would have introduced cross-shard joins and a lot of pain for no benefit. Luna: So the partner's value was in questioning the assumption that everyone else had already accepted. That's hard to do internally. Lucas: Nearly impossible, because by the time you're presenting to your team, you've already socialized the idea. People are on board, or they're afraid to push back. An external partner has zero social debt. Luna: That reminds me of something. A couple dollars a month is genuinely what keeps these shows going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Lucas: Yeah, listener support is what keeps us ad-free and focused on content like this. It really does make a difference, no matter the amount. Luna: Alright, back to sparring partners. One thing I'm curious about: are there any downsides? I could see someone getting overly reliant on a sparring partner for every minor decision. Lucas: Great point. The CTO I mentioned actually has a filter: if they can make the decision in a day and undo it in a week, they don't bring it to the partner. Sparring is for decisions that are hard to reverse or have multi-month consequences. You don't need a partner to choose between two cloud providers for a prototype. Luna: That's a good heuristic. Also, I imagine you need to be careful about confidentiality. You're sharing pending strategic moves with someone from another company. Lucas: It's a real concern. Most pairs sign a simple mutual NDA, but the trust factor is huge. That's why the best partnerships often start with a low-stakes conversation — maybe a general architecture discussion — before you bring your most sensitive decisions. Over time, trust builds. Luna: So let me summarize what I'm hearing: a technical sparring partner is a peer from outside your company, meeting regularly, using a structured format to challenge your assumptions on high-stakes technical decisions. It's reciprocal, it's not mentoring, and it builds decision confidence. Lucas: That's it exactly. And I'd add one more thing: it's also a loneliness cure. Being a CTO can be isolating. Having a peer who genuinely understands your problems — without any organizational baggage — is valuable in ways that go beyond any single decision. Luna: Well said. So for anyone listening who's a senior engineering leader, maybe it's time to find your sparring partner. Start with a single session. The upside is huge, and the cost is just a couple of hours. Lucas: And if you do it right, you might avoid your own database sharding disaster. Thanks for listening, and we'll see you next time.