Saket Saurabh:
Hi everyone. Welcome and thank you for listening to another episode of Data Innovators and Builders. This is your host, Saket. Today I’m with Dori Wilson. Dori is the Head of Data at Recce. Dori, great to have you here.
Dori Wilson:
It’s incredible to be here. Thank you so much for inviting me on.
Saket Saurabh:
Awesome. So let’s start with a little bit about your background. You have a lot of rich data experiences as well.
Dori Wilson:
Yes. I’ve had an awesome opportunity to see what data looks like in governmental institutions, in big tech, and in almost every flavor of startup you can imagine, including my own. Now I’m working on building data validation tools and continuing to fill in the gaps I’ve seen in those companies and roles.
Saket Saurabh:
Tell us a little bit about your current company, Recce. Fascinating work you’re doing in making data more trusted and validated.
Dori Wilson:
Something we believe at Recce is that, especially with the advent of AI, software engineering and data analytics, data science, and data engineering are becoming closer than ever. Software engineers are having to get more into the weeds with data, and data people, because of AI, are now able to get deeper into engineering. Knowing what AI ops is, I think, is going to be standard on every data person’s resume in the future.
What we’re building is a way to evaluate data as code changes happen. Engineering has DevOps and CI/CD and various types of testing. In data we do have tests, row counts, data observability tools, but what does it mean to evaluate how code changes impact data? Not just at a row count level, but contextually. When a metric moves 5%, is that good or bad? Sometimes you create a new metric knowing it’s going to impact the business, maybe it goes up because you’re including more people in the dataset, maybe it goes down because you’re increasing a filter. Normal tests can’t catch that, and most people are doing this manually. We’re trying to make it a systematic process that everyone can do easily.
In the last six months we launched our data review agent. Any time you open a pull request, Recce runs. We understand your code, we understand the lineage, which models downstream and which metrics downstream are impacted, by how much, and whether that’s correct. We surface that to the human. We’re big believers in human-in-the-loop as well as automated checks: distribution changes, mean, median, 99th percentile, all of it.
Saket Saurabh:
So this is getting context from your code and your data. Does it actually run and process data, or is it building the knowledge to assess what’s going to happen?
Dori Wilson:
It’s doing both. It connects directly to analytics warehouses and compares your production to your development environments. When we say a metric is changing 5%, you can trust that. You can understand that what you’re doing in your dev environment will impact production by this amount. Do you need to talk to stakeholders? Is this the intended outcome?
We’re also building a meta layer around it, because context becomes so much more important without a record of why you changed that metric. You know now and can say it’s right, but your teammate two months down the line changing that metric needs to understand why you originally made that definition or tweak. That institutional context is really hard for a lot of teams to maintain, so we’re building that internal knowledge base too.
Saket Saurabh:
Who are the users? Data analysts, data engineers, or someone else?
Dori Wilson:
Anyone developing or changing code that impacts data systems. Mostly it’s analytics engineers, data engineers, and data analysts. But we also have a UI where you can surface changes to a business stakeholder in a systematic way, letting them see that a metric is being impacted and confirm whether it looks right. The conversation is tied back to a pull request. We’re really trying to make code-first workflows the norm and replace what has typically been Slack screenshots of charts going back and forth.
Saket Saurabh:
You’ve been in data science roles at multiple companies. What did you observe there that led you to conclude this kind of tooling was needed?
Dori Wilson:
How many times have I broken production? That’s really it. At all these companies I have a story to tell. Here’s how production broke. Here’s how we thought we understood that this code change was going to impact this metric, and it ended up impacting ten other dashboards that executives cared about. That type of change should just be systematic. Software engineers break production all the time too, but there are more systems around it, more types of testing and DevOps. Data doesn’t quite have that yet. We’re trying to get rid of the panic garbage fires caused by a bad code change that you or a teammate pushed.
Saket Saurabh:
I totally agree. Software engineers can run things through QA, stage releases, and get feedback. Making changes to production data and reassessing the impact is much harder. It’s a great lens for thinking about stability.
Dori Wilson:
Partly because data is living. Code changes might work one way today and another way tomorrow just because the source data or the operating environment has changed. With software you push it and, more or less, it works or it doesn’t. With data it’s constantly evolving out from underneath you.
Saket Saurabh:
What are the common patterns of breakage that people may not be thinking about, but should use a tool like yours to address?
Dori Wilson:
A lot of times it’s not understanding what you’re impacting downstream. The codebase can be so complex that it’s hard to trace: I’m impacting this table, which is 20 or 30 tables down the lineage, which feeds a dashboard that your VP looks at regularly. That’s the most common thing we see. People come to us saying they don’t know what else they’re impacting for sure. We make that systematic and tell you how much the change is, helping you surface it to that person with a heads-up, or prompting you to step back and reconsider before you ship.
Saket Saurabh:
Data people love talking about data contracts. How does Recce relate to that concept?
Dori Wilson:
I think it helps you enforce data contracts. When we talk to teams, a data contract is something most people want, but it’s still mostly a buzzword for the majority of teams. Recce is a way to actually enforce that in code. You can create custom checks that are codified. You can help put responsibility both upstream and downstream, making clear who is going to impact whom, in a way that’s difficult for most other tools. I’d call it very complementary.
Saket Saurabh:
Before Recce, you were a founder and went through Y Combinator. That’s a dream for many people. Tell us about that experience and your YC story.
Dori Wilson:
What an absolute trip. I loved it and I learned so much. It started when I got laid off. I thought, how can I turn this into the best thing that ever happened to me? So I got a couple of friends together and said let’s start something. We applied to YC more as a forcing function to get our ideas organized. Then we got the email saying we’d been invited to interview and it got a lot more real.
We got on the call, Michael Seibel and Tyler Bosmeny were there, 15 minutes late, ten-minute interview, and they just dove in. We were originally pitching a Looker killer, a BI tool. After we got in, Michael got on a call with us. We were all prepped to talk about what we could build and why, and he said, I’ve invested in dozens of companies like yours. They all cap out around 10 million. What are they missing that you’re not? Come back to me in a week.
So we did a deep dive on where the real problem actually was. Was it in the data visualization? We went back to first principles. A lot of data people struggle with this: I can do really solid analysis, and I can communicate it to you, but you’re going to take it and communicate it to other people. My original thought was that this happened in dashboards. But we dug in and realized BI tools aren’t where most of those conversations happen. If you’re at the dashboard, other than data literacy questions, you typically get the same answer. The real decision happens when you put together a presentation. That’s where we landed on the idea for Foreign Tail, data-native presentation software, trying to solve the gap I’d experienced across every company I’d worked at, from the Fed to Uber to Circle to Mux to PayOff: the analyses are good but the communication is hard.
Saket Saurabh:
That’s powerful. Ultimately it’s the storytelling that makes decisions happen. So it was a new way of building slide decks that was data-native.
Dori Wilson:
It was. And one of my learnings is that I don’t think the tool matters as much as I believed. I came into it thinking if I just build a better tool, people will get it. Doing user interviews was really disappointing in that way. You go into all these rooms, you talk to all these people, and you realize the pretty chart didn’t do it. Most people wanted the pretty chart to make them feel good. They don’t really care about the nuts and bolts that deeply. What matters is how the person crafts the story. Building a better presentation tool isn’t going to change that. It was one of the multiple reasons it didn’t work out.
But here’s what I’d say about data storytelling, after hundreds of user interviews with data teams, go-to-market teams, and everyone in between: most people are not asking the right question. Therefore, they can’t tell a decent story. One thing I tell junior analysts is that if the analysis isn’t going to change a decision or improve something, why are you doing it? Push back on your stakeholders. That’s how you start building the story. What will this change? Great. Now you can talk about the story. Here’s what I looked at, here’s the model, here’s the impact, here’s my recommendation. Keep it short, tight, and tied to what people actually want. It goes back to entrepreneurship: are you building something people want? No one pays you for fun facts, but they will pay you if you’re solving their problem. That’s a common thread.
Saket Saurabh:
One of the impact stories from your background that stood out to me was at Mux, where product feature adoption was leading to greater retention. Tell us about that. That’s real business impact.
Dori Wilson:
Mux wanted to understand how to better retain customers. They’re a usage-based video infrastructure company. If you need to do anything with video, check them out. The challenge is that there’s no direct user engagement when you’re an infrastructure product. If customers are coming to your website, something broke. You don’t want them there. If things are working great, usage numbers might go up, but that could also just mean the customer’s business is growing. Maybe no one is watching that video. So it was difficult to define retention when you can’t fully rely on usage as a signal.
That’s where features came in. What moves the needle? What do our most successful customers look like? We ran some logistic models and correlation plots. Data people often want to get complex, but you don’t need to. Stakeholders will trust a correlation plot over a complex model because they can actually look at a plot. That’s part of data storytelling itself.
Each feature adoption story came back to the same point: customers were getting more value from a platform than a competitor offered, or more than building in-house would give them. Custom watermarks, higher resolution video, closed captions, MP4 downloads, these were all features. We tried to figure out which features were driving the most retention, and we had to segment by industry. A company like Uscreen, which does user-generated content, has a very different use case from HubSpot, which embeds video in emails and on websites. Understanding how to retain both types of customers, and their customers, since Mux is B2B-to-B, required different approaches.
Saket Saurabh:
Each customer has a different pattern. How did you identify which features mattered, measure them, and connect them to retention or revenue?
Dori Wilson:
It starts with what data is available and how to get more available, especially at early-stage companies or ones that have been shipping features without needing rigorous tracking. Getting the data available is table stakes. Modeling it in a way you can trust it, putting it where other stakeholders can access it. Something I find useful is bringing people along as I’m doing the analysis so that getting buy-in on the back end is easier because they’ve seen chunks of it along the way.
For actual usage, once the metrics are available, you decide whether to look at daily, weekly, or monthly granularity. Across multiple dev tools I’ve found that if somebody uses you for 90 days, they’ll stay for at least a year. So the question became: of the people that hit that milestone, what behaviors were they doing? Since I couldn’t look at individual user engagement clicks because it’s companies and video assets, the closest proxy to engagement was product features.
So I pulled: what percent of companies that made it to 90 days were using any features? How many features were they using? What was the sweet spot? How quickly did they adopt? Were they self-serve pay-as-you-go or enterprise with hand-holding? Were there biases from new features launched recently? A customer from three years ago that retained really well might have only had three features available, so adopting one meant 33% feature adoption. And how do you avoid selection bias when you’re only looking at people who already made it to 90 days, which tells you nothing about the people who churned?
That led to the hypothesis: three features, 90 days, get at least one new feature adopted in the first week. From there you run experiments, work with growth, work with your CSM, work with marketing. And you have to run robustness checks. If people are retaining more because they’re using more features, is that because of a marketing push or a segment shift? You’re always trying to piece out extraneous noise.
Saket Saurabh:
That completely makes sense. Understanding the specific business your customer is in is critical. Consumer video is measured in views; enterprise video embedded in an email is measured very differently. And now you have a metric, feature adoption at 90 days, that sales, marketing, and everyone else can align around.
Dori Wilson:
And Mux was an older company, so there were more segments to be had and they were more meaningful. Mux’s moment was really when customers had them in production, and in different production contexts.
Saket Saurabh:
When you look at the different teams you interact with, product teams, GTM teams, sales, what differences have you seen in how they adopt data and how you storytell to them?
Dori Wilson:
All of those groups care about different things. Your first job is understanding what they care about. Sales wants to close people and see numbers go up and to the right. Customer success needs to understand engagement and how to keep customers. That’s a different question from a growth or demand gen person trying to make a compelling pitch to get someone onboard. Which is different from the PM who wants to know if the product they put political capital behind is a success.
And sometimes when you’re a new data hire and there hasn’t been a data function before, you’re also convincing people why they should use data to answer their questions at all. Early-stage companies rely on talking to ten users and hearing it’s great, which is fine because you don’t have scale yet. But when you have scale, the users who aren’t talking to you might be more important than the ones who are.
You have to figure out the motivation, the KPI, and what they’re really asking. It goes back to the right question. A PM says they want to know if something is successful. Okay, how? What was it supposed to drive? Retention? Revenue? Was this a feature enterprise customers needed and you had to ship it regardless? Those three things require very different analyses. If it was enterprise adoption, did enterprise customers adopt it? For revenue, is it moving leading indicators or revenue itself? For retention, if the people adopting the feature are already your most engaged users anyway, is that really a success?
Saket Saurabh:
How do you get people to trust the data? For example, a marketing leader who loves a campaign and you come back with data showing it’s not working. How do you get them to be more objective?
Dori Wilson:
Bring people along the way. You don’t want to annoy them because you have a job to do and so do they. But figure out who they listen to and seed the findings along the way. Another way to build trust: some people love numbers. Have your supporting data, but not necessarily in the main deck. Put it in the appendix and proactively answer their questions. If you’re presenting to a marketing leader and they look over at a colleague who asks a question, and you can immediately flip to the next slide with the answer right there, they’re going to trust you. You’re showing that you were thinking the way they’re thinking, which means you attacked the problem the way they want it attacked.
I’ve had executives who wanted to be in the weeds with me, going through standard errors and standard deviations and why I chose a particular model, at the VP level. And I’ve had executives who did not care about numbers at all. They just wanted a few curated conclusions and then access to a Google Sheet where they could explore themselves if they wanted. The problem with building trust is that we often think it’s a systems problem when it’s a people problem.
Saket Saurabh:
Coming back to Recce, the work you’re doing is helping validate data and ship it with more trust. You have agents doing detection and humans in the loop working together. What does that dynamic look like?
Dori Wilson:
It goes to both the validation and the trust issue. No one in data is ready to hand everything over to a data agent yet. But if the agent is doing a lot of work and surfacing it to you, that’s much easier for you to take and act on. And of course, another way to get people to trust you is to not break production. That’s another way Recce is directly attacking that problem.
Saket Saurabh:
Validating data is a lot harder than validating code, and the systems haven’t been there. You’re leveraging AI in a way that wasn’t possible without LLMs, getting context about code and data and understanding downstream impact. Where are agents doing a good job of detecting issues, and where are humans still better?
Dori Wilson:
Agents work best when they have context around what is happening, whether that’s historical baselines, a semantic layer, documentation, or data contracts. If you don’t have that documentation, which is most teams, that’s where they start to break down. You have to be actively building this context layer, which is one of the reasons Recce’s agents are on the more cautious side, surfacing findings to the human and starting to create a metadata trail of decisions and the reasoning behind them, which will improve the agent going forward.
Saket Saurabh:
Context is super critical. The more context we can bring in, the better the outcomes. And that context is highly distributed across an enterprise, across many documents and many people’s heads. You mentioned skills earlier, how important they are for capturing that context. Tell us how you’re seeing skills evolve in the way businesses leverage AI.
Dori Wilson:
At Recce we’ve built out our own plugin internally. We’ve been turning our skills into things the whole team can use. A specific example: we want to help our engineers write better build-in-public pieces and documentation. We’ve written skills that we keep iterating on. Every time you run a session, you iterate on what you’ve learned. The skill constantly improves and prunes itself.
There’s also a context placement question, where should memory actually live? You don’t need everything in one memory file. You can have other memory files that the skills themselves can pull from. When writing our changelog, a skill can pull a separate markdown file with editorial preferences about grammar, tone, and focus on the ‘so what’ versus just technically what we shipped. It doesn’t clog everything else. In an analytics repo, you can put inline comments like ‘if someone is asking a question about this, pull this skill or look in these memory files.’ That lets you stagger and layer context without overwhelming the model.
Saket Saurabh:
One of the ongoing challenges with AI models, even with larger context windows, is the loss-in-the-middle problem. Most chat interfaces are now doing context compaction on the fly, compressing earlier context as you move forward. Skills with references to specific context are extremely valuable. Tell us how you see skills becoming critical to how businesses leverage AI.
Dori Wilson:
Skills are really where you take a model and make it fit your use case. We used to have to work within other people’s frameworks and adjust our work to fit them. Now you don’t have to do that. You take the model, adapt it to your context. What are the semantics your company uses? What is the modeling structure you follow? What are your coding preferences? These things can be baked into skills and customized for your company and team.
With Recce, we’ve seen real improvements in our own data agent as we’ve improved the skills. Here’s how to review lineage. Here’s how to think about impact. Here’s the way we want to think about data diffs, how to pull a specific metric, what it means when a number looks a certain way. Getting more specific and closer to the actual problem you’re trying to solve improves performance meaningfully.
Saket Saurabh:
One thing I’ve been watching is the rise of AI-based data analysts, where instead of dashboards and visualization, the work is about asking questions and drilling into insights. How do you see the work of data analysts changing as visualization tools bring AI into the mix?
Dori Wilson:
If your job is data visualization and BI tools, that job doesn’t exist anymore. If you’re still doing only that, you should be retooling. You have valuable skills, but dashboards are dead. There’s a decreased need for BI tools. That’s my hot take.
People don’t go to dashboards to make decisions. They went to dashboards to learn something. But now they don’t even have to do that. They can just ask. We all have Slack channels where people are pinging the data team with questions, we’d direct them to a dashboard they’d never remember, and they’d come back a month later asking the same question. Now they can just ask directly.
So your job is no longer the visualizations. It’s curating and creating the infrastructure necessary for stakeholders to self-serve, answer their own questions, and ask the right questions. If you’re not moving toward that, your role is going to be obsolete.
Saket Saurabh:
If you can bring the data, the context, and the agent infrastructure together so stakeholders can ask their own questions, that’s powerful. What’s the best way to coach people on asking the right questions?
Dori Wilson:
You need to be in the room. It’s data literacy. Now that people are going to be asking their own questions, they also need to be able to interpret the answers. That coaching requires conversations. And to build the infrastructure to serve their questions, you need to be talking with them anyway, because you have to codify the context and make sure the models and semantics are there in the way they need.
Saket Saurabh:
Data analysts have been building pipelines in dbt, writing SQL jobs. How is that changing now with LLMs? Is it all being generated by AI?
Dori Wilson:
From what I’m seeing with our customers and users, people are still struggling with getting agents to fully own and write code. Part of it is that the customization isn’t there yet, or the nuances of how a command will impact data downstream aren’t fully captured.
I ran a project where I was going to ingest a data source, build a bunch of skills, and see how well an agent could build everything from sourcing through staging to mart. When it got to the weekly table, I needed it to aggregate using a max rather than a count distinct to get the number of users. It didn’t get there on its own. That doesn’t make any sense semantically and the agent missed it. So you still have to be deeply reviewing the code. But they’re getting better, and this is where skills come in, building the right guardrails, giving agents the tools they need.
In the same way that fewer software engineers are deep in all the code and more are reviewing code, I think that’s where we’re headed with analytics engineering. We had Wes McKinney on our podcast, the founder of pandas and Apache Arrow, and he’s not writing code anymore. Agents are writing the code. He did note that an agent could not have written Apache Arrow because it was too finely tuned. So there are limits. But if most of your day is reviewing code rather than writing it, I think that is the direction we’re going. How we make sure it works at scale and in regulated environments has not been solved yet.
Saket Saurabh:
I see it too. My co-founder runs six terminals at a time talking to Claude Code in each of them, giving instructions, asking AI to build test cases, running those, getting code reviews done. The pace of execution is much faster. It’s about the person knowing what problem they’re solving and what approach makes sense, then letting AI do the work.
On the topic of text-to-SQL, one thing we’ve noticed is that the more documentation you put around data products, what these fields are, what they mean, the better performance gets. To what extent are concepts like data products still relevant when you’re thinking about data contracts and validation today?
Dori Wilson:
The impetus behind creating those concepts is very relevant. The format and where that lives is very different. Do you need a whole separate product category? How can you fit it in ways that LLMs can better engage with? A lot of what data contracts were designed for was to improve communication between people. But with models doing the code and understanding the impacts, we need it less as a people-to-people handoff and more as a well-scoped thing in code.
It’s interesting to watch how much we can shift left, how much we can codify, how much we can put into controlled environments. Some teams surprisingly aren’t as deep into version control yet. Go-to-market teams are shifting left into code, codifying their pipelines. How much of that is relevant for their specific products is still an open question. I think most of it can be codified.
Saket Saurabh:
Much of the work around GitHub contracts or writing specs has been about humans communicating with each other. But if we’re using AI agents on both sides, that communication overhead can change. You and I are both using agents and the context is shared between them. That creates a very different and potentially much more efficient work environment.
Dori Wilson:
Hopefully more efficient. Institutional knowledge being locked to one person has always been a risk. Now the learned context can become the institutional knowledge. The thing that concerns me though is what happens when you offload too much of your memory and processing and communication. How much are you still internalizing?
I had a teammate who had written something up, and I asked them to tell me about the user experience behind the feature they wanted to build. They came back with something that was AI-generated, and when I dug in, they couldn’t go deep on it. The institutional knowledge of why this feature was valuable and what the user context was, it was technically there in the output, but we’d lost the deeper personal understanding. That’s worth watching.
Saket Saurabh:
You can’t outsource the entire thinking process and then copy-paste the output. LLMs work great as a thought partner, but the thought partner model works when you’re still doing the fundamental thinking yourself and using it to enhance, pressure-test, and explore boundary conditions. Dumping information in and going with what comes out is a different thing.
Dori Wilson:
And I’ve absolutely been guilty of that. But you still have to think through it and understand it and explain why. It’s hard not to see something that looks good and just run with it.
Saket Saurabh:
Sometimes the volume of output an LLM throws at you means you have a whole mass of things to read and digest and process, and then you’re tempted to say it looks okay to me, and then it doesn’t work.
Dori Wilson:
Exactly. We were rewriting our docs and my teammate asked me to review them. I reviewed them with Claude’s help, pushed the changes. She came back the next day and said there were a lot of redundancies. It was stuff I had added because I’d just read what Claude was doing and said it looked good. And when the outside view came in: you repeated the same thing on three different pages. Yeah. It’s so easy to do and so hard to catch.
Saket Saurabh:
You’ve had an amazing career across multiple companies and as an entrepreneur. When you got laid off and turned it into a startup, that really stuck with me. What career advice would you give to people early on?
Dori Wilson:
I’m not going to sugarcoat it. It’s a hard market right now. But I think trying to cultivate an abundance mindset is the most important thing, which is what I tried to do after I got laid off. I’m still close with the people from that company. We left on good terms. Sometimes the cost cuts just have to happen. Don’t take it personally when these things hit you. It sucks and no one wants to lay anyone off, but that’s just life. Cultivate that abundance mindset. Maybe something will work out. Ship it. Try it.
That’s one of the biggest things I learned from entrepreneurship. We just applied to YC. We didn’t expect to get in. Then we got in. Then I was able to raise money. Then I was able to build a product. I had done no sales. I’m a nerd in the back room. I had to learn how to do sales, how to do marketing. You limit yourself so much because you think about external factors stopping you. Why? Why is that external factor actually stopping you?
There are hard constraints, I want to be real about that. You can’t go full time building if you have kids, a mortgage, loans. Those are real. But at the same time, some of those hard constraints have workarounds. Maybe you can’t quit and go full time. Is there somewhere in between? Are there other ways of leveling up? Having an abundant mindset means asking what is feasible rather than defaulting to I can’t, I won’t, I shouldn’t. Stress test yourself on that.
For people early in their career: technical skills will get you in the room. But can you work with people? Can you network? I’ve offered myself as a resource to new grads and people in college. Do you know how many actually take me up on it? One in ten. If you don’t follow up, no one can help you. The biggest thing you can be right now is hungry and not limiting yourself before the world limits you, because the world will limit you. You just don’t need to start early on its behalf.
If I hadn’t been laid off, I wouldn’t have applied to YC. That changed the track of my career. I learned so much. It was a crucible. I met incredible people. It’s one of the reasons I’m here having this conversation. You don’t have to be that extreme. But you have to not limit yourself.
Saket Saurabh:
Very well said. Human potential is massive, and sometimes it’s the difficult situations that push us beyond our boundaries. What at that moment looks like a bad situation turns out to be the start of something great.
One thing I’m finding now is that AI is going to impact a lot of jobs, in ways we don’t fully understand yet. But at the same time it’s an enabler. If you have agency and a problem you’re passionate about, AI becomes your best tool to actually go solve it. You’re no longer constrained by needing money or a big team. You can get pretty far just by having agency, curiosity, and pushing on it.
Dori Wilson:
I agree. Creativity is the real differentiator now. It’s no longer technical skill that’s the limit. Can you think about a problem, can you articulate it well? The most useful class I had in undergrad was probably my linear algebra course tied to programming. But last year it has become the class I took on how to teach writing, and the year of creative writing I took under a New York Times bestselling author. Because that’s what I do now. My job is to write well, communicate clearly, and think creatively about how to explain abstract concepts and world-build the context that the modeling needs. Writing is such a fundamental skill right now.
Saket Saurabh:
I was reading about someone telling their kids that math and writing are the two most important things. Writing to communicate and understand problems. Math as a framework for logic.
Dori Wilson:
Upper-level mathematics is extremely creative. Once you get past calculus and into upper-level proofs, it’s genuinely creative problem-solving. I was a PhD dropout in applied mathematics and economics. One of the tricks in the PhD program for solving equations is adding and subtracting zero, but the zero is actually a function you’re adding and subtracting from both sides. That changes the structure and unlocks your ability to solve the equation. That’s a creative insight expressed in a very logical way.
Saket Saurabh:
Interesting and exciting times, and scary in some ways too. Your advice is really on point in terms of how people should think about their careers and how they can build on that. Thank you so much, Dori. It’s been a pleasure talking to you. If people want to follow up with you, where can they find you?
Dori Wilson:
I’m on LinkedIn, I’m on Bluesky, and you can always send me an email at dori@reccehq.com. That’s D-O-R-I. Happy to chat. If people are hungry and want to learn, whatever advice I have, it may or may not be good, but I’m willing to share. I went to public schools and know how hard it is to find mentors. I want to try to give back to others who might be struggling, especially in these uncertain times.
Saket Saurabh:
It’s all about the opportunities you take. I would highly recommend that folks reach out. Thank you so much, Dori. Really appreciate you taking the time today.
Dori Wilson:
Thank you.
Express — 
