Technical Analyst/Strategy & Operations Lead

We're looking for someone unusually good at figuring things out and getting things done. This is a hands-on, execution-oriented role sitting at the intersection of technology, data, product, GTM, research, and operations. You won't own a traditional department. Instead, you'll work across them—finding gaps, solving problems, creating structure where it's missing, and helping make strong specialists more effective. A typical week might look something like this: Monday: Our outbound numbers don't make sense. Pull apart the data and determine why. Tuesday: Research how five companies solve a product problem we're considering. Actually use the products, inspect their APIs/docs where relevant, and tell us what matters. Wednesday: Take several ugly datasets from different systems, reconcile them, build the spreadsheet or analysis, and turn them into something humans can understand and act on. Thursday: An important GTM automation initiative is slipping. Figure out what's blocking it, identify the gaps and dependencies, and then help drive the work required to get it moving again. Friday: You notice something in the data nobody asked you to investigate. It looks important. Investigate it, determine what it means, and surface it before someone has to ask. That's the job. This is not a role where you identify problems and hand them to someone else. We want someone who gets their hands dirty. Sometimes the output is an analysis or recommendation. Sometimes it's a spreadsheet, a script, research, a process, a project plan, or a fixed workflow. Often it's some combination of them. What We Care About You're genuinely technical. You should be able to write code, even if software engineering has never been your job. Maybe you started as an engineer and moved toward product, analytics, operations, growth, strategy, or entrepreneurship. Or maybe you've never worked as an engineer at all , but while doing those other things you taught yourself how to code because it made you dramatically better at solving problems. Either is great. What's not enough is having "worked closely with engineering." You should be comfortable getting hands-on with SQL, APIs, scripts, databases, JSON, webhooks, automation systems, spreadsheets, and AI tools. You don't need to be writing production application code every day, but technology should be something you can use , not just something you can discuss. You're a problem solver. We don't expect every problem to arrive neatly defined. Often, figuring out what the actual problem is will be part of the job. You can start with an ambiguous question, break it apart, determine what information is missing, investigate it, and work your way toward an answer. You're comfortable moving between technical and business problems and using whatever tools are appropriate to solve them. And you don't stop at identifying the problem. You're biased toward execution and will personally do the work when that's the fastest path forward. You're good at gap analysis. You notice what's missing. Missing data. Missing ownership. Missing processes. Missing instrumentation. Missing requirements. Missing follow-up. Missing connections between two teams that each think the other is handling something. You can look at a system, project, dataset, or process and quickly start asking: What do we have? What do we need? What's missing? What's blocking us? What should happen next? Then you help close those gaps. You're extremely analytical. You can take hundreds of thousands of rows of messy data and turn them into an answer. You're excellent with spreadsheets. You know when an aggregate is hiding something important. You look for patterns, inconsistencies, outliers, and explanations rather than simply reporting numbers. And your work doesn't end when the analysis is complete. The point of the analysis is to change what we do next . You're a great researcher. You know how to quickly become dangerous in a subject you knew almost nothing about yesterday. That could mean reading documentation, testing products, analyzing competitors, digging through data, reading source code, interviewing people, or using AI. The methodology doesn't matter. Getting to a reliable answer does. And we're looking for product research, not just market research . If we're evaluating how something works, we want someone willing to actually use it, understand the workflow, investigate the underlying technology where useful, and figure out why it was built that way. You're operational. You don't just identify what should happen. You notice when it isn't happening. You anticipate dependencies and bottlenecks, chase down loose ends, and surface problems before they become emergencies. You don't need authority over people to make things move. Most importantly, you execute . We're not looking for someone whose primary contribution is assigning work, running meetings, or maintaining project-management software. If a problem can be solved by opening a spreadsheet, querying the database, writing a script, researching something, testing a workflow, or getting into the system yourself, we expect you to do it. You communicate exceptionally well. Complexity goes in. Simplicity comes out. Leadership should be able to give you a messy question and receive a concise explanation of: What happened? Why? Why does it matter? What's missing? What should we do? You also understand that timing matters. If you discover something important on Tuesday, you don't bury it in a report scheduled for Friday. This Is Not... This is not a project coordinator role. It's not a traditional Product Manager role. It's not a Business Analyst role where your primary responsibility is gathering requirements. It's not a Data Analyst role where your responsibility ends after producing the analysis. It's not a strategy role where your responsibility ends with a recommendation. And it's not a software engineering role, although your ability to code and work directly with technical systems will be essential. It's a role for someone who likes operating in the gaps between those disciplines—and personally doing the work required to close them. The Person We're Hoping to Find Your career may look slightly strange on paper. That's probably a good thing. Maybe you were a great engineer who didn't want to spend the next 20 years exclusively writing software. Maybe you've never held an engineering title, but taught yourself how to code while working in product, analytics, growth, operations, or another discipline because you kept running into problems you wanted to solve yourself. Maybe you've bounced between startups, product, analytics, growth, technology, and operations because none of those boxes completely described what you're good at. Maybe you're the person everyone gives the weird problems to because they know you'll eventually come back not only with an answer, but with something built, fixed, analyzed, organized, or moving. That's who we're looking for. You'll work closely with company leadership and with strong leaders across engineering, sales, marketing, and GTM systems. We have excellent specialists. We're looking for the technical generalist and hands-on problem solver who finds the gaps, closes them, and makes the specialists more effective.