The Hardest Problems in Engineering Are Almost Never The Technical Ones

What Tom Kershaw's Path From What Tom Kershaw's Path From Telecom and Ad Tech to Music Rights Reveals About Solving Problems Code Can't Always Fix

Every engineering leader has watched a technically sound project stall out anyway. The architecture was right, the team was capable, and the thing still went nowhere because the people around it never agreed on who decided what. Tom Kershaw has spent a career running into that pattern across four industries that share almost nothing, and he has come away with a conviction that the technology is usually the easy part.

Tom is the SVP and Chief Technology Officer at BMI, one of the largest performing rights organizations in the world, representing more than 1.5 million songwriters and composers and 25 million musical works. His path there ran through telecom and internet infrastructure at VeriSign and Ericsson, ad tech as CTO of Rubicon Project (now Magnite), and travel as Chief Product and Technology Officer at Travelport, where he led the engineering effort to replace legacy reservation systems. He joined BMI in 2024 as its first CTO, and he holds a degree from NYU and a master's from the London School of Economics.

He recently joined EverOps' CEO, Stephen Koza, on Episode 9 of TechPod Talks to talk through what that unusual range taught him about entering industries cold, building teams that scale, and leading transformations that actually finish. The examples change from telephone numbers to ad auctions to royalty payments, but the lesson underneath them lands in a similar place. 

Read on for the frameworks Tom uses to lead that way, including the open-source project he co-founded that was cited in a federal antitrust case, the two-sided data problem behind every royalty check, and why he thinks trying to stop AI in music is a losing fight.

The 20% Rule for Learning a Business You Know Nothing About

Tom moves industries roughly every four or five years, on a theory that anyone who stays much longer stops innovating and starts repeating work they have already done. The cost of that approach is arriving somewhere new surrounded by people who know how everything works, where the acronyms alone can take a year to absorb before anyone gets to what they mean.

His answer is a depth play he treats as a rule. Rather than learn a little about everything, he picks the one narrow slice of the business where he can add real value, roughly 20% of the whole, and goes as deep on it as the problem allows. The other 80% stays with the capable people who already run it. For an engineer, Tom frames this as a classic depth-versus-breadth decision, and his answer is always depth. Going far enough into one problem teaches you how the organization actually works, how the industry fits together, and which patterns you can carry to the next problem, which is why the choice of topic matters less than the commitment to depth.

"You pick that twenty percent and you go deep on it."

At BMI, that slice was AI and how it works in music. In advertising, it was identity, specifically how to target advertising without dropping tracking cookies on everyone's machine. Either way, his rule applies to any industry. 

The first 90 days call for a particular kind of restraint, which Tom frames as listening without feeling compelled to add value, a discipline he readily admits engineers find difficult. The rest of the work stays with capable people who know when to ask a question and when to simply act, and Tom is candid that no amount of process design produces that instinct. It comes from relationships and culture, which puts it firmly outside the set of problems an engineering leader can solve by engineering.

The Open Source Project That Ended Up in a Federal Antitrust Trial

The Prebid story starts in genuine desperation. Rubicon Project had built a strong business on the waterfall model of digital advertising, where a publisher called one buyer at a time until somebody bought the ad, and Rubicon sat at number two on most waterfalls. Header bidding arrived and replaced that sequence with a simultaneous auction. The preferred position vanished, and Tom walked into a company where most of the management team left within a week of his arrival, and the stock fell from around eighteen dollars to two.

The math got worse from there. Winning the same revenue in a competitive auction meant processing roughly 10 times the traffic on a platform already handling hundreds of billions of impressions a day, which made cost structure an existential question. Meanwhile Google kept growing while the independent ad platforms fought each other for scraps, a dynamic Tom describes as a group of companies stabbing each other to death. His read was that the only path to competing with the walled gardens lay in the independents uniting around shared software.

That conclusion produced Prebid, and the technical component was almost trivially simple, amounting to JavaScript running on a web page. Tom is emphatic that the hard part sat entirely elsewhere, in the work of getting twenty companies that competed directly with each other to agree on a common direction. His central objection to how most companies approach open source comes straight from that experience.

"Open sourcing software, anyone can do it, and it's often a lie. What really matters is the governance structure. How do you govern that software? Who owns it? How do you collectively make changes, and who makes the decisions?"

The deal that made it real was struck with AppNexus, under which Tom agreed to adopt their open-source platform on the condition that they open their governance. The first year was four people in a room who could not stand each other and could not get anything done. Then a few more companies joined, then a few more, and the project grew into the dominant advertising monetization framework on the internet with thousands of participants across corporate members, contributing engineers, and publishers. Prebid later surfaced in the Department of Justice antitrust case against Google, where Tom testified, and he notes with some amusement that the experience delivered every Washington stereotype, including a stay at the Watergate. What he takes the most pride in is that the thing he helped start outlived his involvement and kept growing after he left.

Leadership and Management Are Two Different Jobs That No One Person Can Do

Scaling an engineering organization requires two capabilities that most people conflate, and Tom separates them cleanly. Leadership means setting a North Star and inspiring people to walk across a desert to reach it, including on the days when the walk gets hard. Management means making sure nobody gets lost or falls by the wayside along the route, which takes patience and attention to the factory floor.

Tom is unusually direct about which of those he is good at. He likes creating and building, finds managing people genuinely unenjoyable, and has watched enough talented managers work to know the skill is real and that he does not possess it. That self-assessment drives how he builds organizations, because a leader strong on vision needs detail-oriented managers around them, and a leader strong on operations needs people who can generate inspiration.

"There are two essential ingredients to a scaled engineering team, leadership and management. And nobody can do both."

The failure mode he warns against is the belief that one person can cover both roles. Strong organizations are built from complementary people who share a vision and a culture, bring genuinely different skills, and recognize their own weaknesses; recognizing your own weaknesses is the prerequisite for assembling that group.

The Data Problem Behind Every Royalty Check

BMI exists to make sure that writing music remains something a person can survive on, which means counting every performance of every song in its repertoire and paying the people who own it. That was a manageable job when music reached listeners through radio, live performance, and vinyl. It became a different job once music started living inside streaming services, movies, video games, user-generated content, and ten-second clips scattered across TikTok.

Tom describes the challenge as two data problems that look nothing alike. The first is structural, involving relatively few records that carry enormous complexity. A song written by three people with unequal splits, represented by different publishers and managers, becomes considerably more complicated when one writer dies and leaves their share to three children, one of whom divorces and gives half of that share to a former spouse. Copyright stretches across generations, so BMI collects and pays on works written nearly a century ago, and the growing practice of investment firms buying up catalogs adds rights holders whose motivations differ from those of the songwriters themselves. For Tom, this is exactly the kind of problem relational databases were built to handle, and he defends them with some feeling.

"A lot of younger engineers don't recognize or appreciate the greatness of SQL the way I do."

The second problem inverts the shape entirely. Counting streams is straightforward per event and enormous in volume, which makes it a blob storage problem well suited to Kafka for filtering signal from noise and to Databricks, Parquet, and Spark for organizing the results. His data science team does the work of matching the two sides, mapping large-scale against high complexity. Tom notes with some perspective that billions of performances a day is a small number by internet standards, well under what he handled in advertising, and that the structural complexity is the genuinely hard part.

The ambition he is working toward is one his colleagues tease him about, which is fingerprinting the entire internet to find music performances, identify them accurately, and pay them promptly. He believes the technology to do it has arrived and continues to mature, which puts something that looked impossible five years ago within reach five years from now.

A Flood of AI Songs That Almost Nobody Is Listening To

Tom's position on AI in music starts from a practical observation. You cannot stop it, and any strategy premised on stopping it is a strategy that fails. He is careful to pair that with a firm line on rights, stating plainly that he does not believe in fair use and that anyone using a copyrighted work should pay for it, a fight BMI intends to keep having.

The complication is that the clean separation people imagine between human and machine creation does not hold up under scrutiny of how songwriters actually work. Songwriters already use AI tools and computers, and BMI has no mechanism to determine what percentage of a song each of two human collaborators wrote, which makes determining the equivalent for AI even harder. Tom points out the inconsistency directly, noting that searching for a song title on Google raises no objection, whereas doing the same with a chatbot somehow does. BMI's response is to build methodologies for opting works into AI platforms and flowing profits from that use back to the original songwriter alongside the platform.

The volume question turns out to be less alarming than the headlines suggest. Tom pointed to Deezer data showing that a majority of tracks uploaded to the service were AI-generated while AI tracks accounted for a tiny sliver of actual plays, which reframes the flood as a discovery problem more than a consumption problem.

"If you generated eight billion songs and nobody ever heard any of them, do they even really exist?"

The real risk sits in the noise. A catalog absorbing enormous volumes of registrations has to ensure that the works people will actually perform stay findable, so that a Taylor Swift song never ends up buried behind a hundred thousand AI tracks nobody will ever hear. Tom frames that as a solvable prediction problem, exactly the kind of work models are built for, identifying the patterns that indicate which songs are likely to be performed and focusing effort there. It is the same choice he faced at Rubicon when request volume jumped roughly 25 times in a month, where the options came down to either filtering intelligently or driving marginal cost toward zero.

Why Saying “No” Is the Whole Job

Transformation work carries a high failure rate, and Tom's read on what separates the successful ones has nothing to do with picking the right answer at the start. Anyone who believes they can consistently make correct calls in a changing environment is wrong. The discipline that matters is charting a course, honestly recognizing when it stops working, and correcting.

"You should never feel embarrassed that you picked the wrong course. You should feel embarrassed if you didn't turn around when you had the chance."

The trap he sees most often is products that become too big to kill and too small to ever turn a profit. Accumulate enough of those, and the organization loses the capacity to focus on the work that matters, which is why Tom keeps BMI pointed squarely at songwriters and treats the question of what to decline as inseparable from what to pursue. When Stephen observed how much harder it is to decide what to say no to than to build the list of priorities, Tom collapsed the whole idea into a single line, pointing out that focus and no mean the same thing.

"Focus is no. That's what focus means. It literally means the word no."

How to Apply These Frameworks This Quarter

The conversation maps onto decisions engineering and technology leaders are making right now. A few concrete places to start:

• Pick your 20% when you enter something new: Choose one narrow problem where you can add genuine value and go as deep as it allows, letting that depth teach you how the organization and the industry actually work. Trying to learn everything at a shallow level teaches you neither.
• Write the governance before you write the code: For any shared platform, standard, or cross-team system, define who owns it, who decides changes, and how decisions get made before the technical work starts. Software shared without a governance structure creates the appearance of collaboration and very little of the substance.
• Audit your leadership bench for the missing half: Assess honestly whether you are stronger at setting direction or at running the machine, then check whether the people around you cover the other half. A team built entirely of one type will predictably fail at the other.
• Separate your structured problems from your scaled ones: Map your data challenges by complexity and volume, and stop forcing one architecture onto both. Low-scale, high-complexity problems and high-scale, low-complexity problems call for genuinely different tools, and the leverage comes from mapping them to each other.
• Name the products you will not build: Identify anything in your portfolio that has grown too big to kill while staying too small to matter, and make the call. Every one of those you carry costs you the focus you need for the work that counts.

When the Hard Part Is Governance, EverOps Builds the System Around It

Tom's conversation kept returning to the same underlying point that the technical work is rarely what determines whether an initiative succeeds. The structure around it determines who owns the decisions, how the organization corrects course when something stops working, and whether the data architecture actually fits the problem it was designed to address. AI raises the stakes on all of it because accelerating an organization without that structure produces speed in several directions at once.

Our recently launched AI Opportunity Assessment identifies and prioritizes the AI use cases that are genuinely worth a team's time, evaluating data readiness and technical infrastructure before a single line of code is written. For organizations ready to move past assessment, our strategy consulting and embedded operations engagements bring the hands-on delivery support that turns a roadmap into production-ready results.

If your team is wrestling with any of the questions Tom raises here, reach out to our team today to start the conversation.

Keep Up With TechPod Talks

Tom Kershaw joined EverOps CEO Stephen Koza for Episode 9 of TechPod Talks. 

Subscribe to listen to the full conversation now on: 

Apple Podcasts | Spotify | YouTube | EverOps Podcast Page

Frequently Asked Questions

Who is Tom Kershaw?

Tom Kershaw is the SVP and Chief Technology Officer at BMI, one of the largest performing rights organizations in the world. He joined in 2024 as the organization's first CTO, leading technology modernization, AI strategy, and the engineering behind royalty tracking and payment. His career spans telecom and internet infrastructure at VeriSign and Ericsson, ad tech as CTO of Rubicon Project and Magnite, and travel technology as Chief Product and Technology Officer at Travelport. He co-founded the open source organization Prebid.org and served as its board chairman.

What is Prebid and why does it matter?

Prebid is an open-source header bidding framework co-founded in 2017, when Tom was CTO at Rubicon Project. It allowed independent advertising platforms that competed directly with each other to run on shared software and compete with the dominant walled gardens. Tom argues its durability stemmed from open governance, with the code itself constituting the simpler half of the problem, and that the project later featured in the Department of Justice antitrust case against Google.

What is TechPod Talks? 

TechPod Talks is a podcast hosted by EverOps CEO Stephen Koza featuring candid conversations with technology leaders, engineers, and operators. Each episode explores how real teams build, scale, and operate modern systems, with a focus on practical takeaways.

What topics does Episode 9 cover?

Episode 9 features a candid conversation with Tom Kershaw on how to learn a new industry by going deep on one problem, the open source governance story behind Prebid and the Google antitrust case, why leadership and management are separate jobs, the two-sided data challenge behind music royalties, how BMI is approaching AI in songwriting, and what makes transformation initiatives finish.

Where can I listen to TechPod Talks?

TechPod Talks is available on Apple Podcasts, Spotify, YouTube, and the EverOps website, with episodes released in both audio and video formats.

How does this episode connect to EverOps' work?

EverOps helps technology leaders navigate the same questions Tom covers in this episode, including AI adoption strategy, data architecture decisions, and the organizational structure that lets transformation work actually finish. Services like AI Opportunity Assessment, strategy consulting, and embedded operations map directly to the challenges Tom describes in this episode.