How do data engineers buy dev tools?
What I’ve seen play out in 4 years selling dbt, Datafold, SQLMesh
When selling, there’s a prevailing incentive to persist information asymmetry. I don’t like playing games when the other person doesn’t know what they’re getting into. That’s called a scam. I don’t think you like buying things that way either. I am no guru, but I am earnest. I wrote this channeling the energy of a friend at the last night of a summer camp dropping some heartfelt lore at the bonfire…meets tiny home tours. This is my long-winded, journeyman’s guide armchair tour to buying (and selling) dev tools for data engineers.
Trying to Sell; Ignoring How You Buy
I used to believe my Solutions Architect (aka Sales Engineer, I don’t care what you call it) career was about conveying algebraic “enterprise value” that made cathartic cost-benefit analysis. Like I had to bring forth the aura of a “Thought Leader” and at the same time show tasteful restraint, “I’m like one of you my fellow data engineer, but I’m more experienced (read: better) than you”. But that usually came off stilted, or even worse “try-hard”. There was a malaise that infected people’s body language when I threw up overbearing proof of value (POV) spreadsheets during trials. They contained the most beautiful pivot tables to “definitively” prove ROI for your company. Or worse yet, I thought slogans that read cool in the vacuum of a sales book would copy and paste gracefully into a living conversation (read: it did not).
I selfishly looked for conversational sound bytes that fed my confirmation bias, and you returned that energy by politely answering how I wanted to hear it in word but not action. I believed in the software I was selling, but I missed the point. I was tragically successful at the wrong thing:
I stringently applied a seller’s caricature to a buyer’s caricature.
I imagined the ancestry of bmw-owning, rolex wrist-twitching (so you can hear the metals clink and dart your eyes), slick-back hair, titans of the car salesmen zeitgeist “tsk tsk” and whisper “get good bro” my way on r/sales. I pounded the ground, sweat dripping, envisioning myself like many anime protagonists before me after losing to a villain. It hurt to admit that I was training to be this cartoon character of a Solutions Architect instead of helping people buy useful stuff. My ego craved to be a “Pro Solutions Architect” rather than be good at helping you solve problems worth paying for. Title as identity is a powerful aphrodisiac.
I had to change, so I made a bet (read: stumbled my way through experimentation) and short-circuited my crusty scripts,
Does it feel too hard to learn?
Do you like how it makes you think?
Hey…do you actually want to work this way with: dbt, Datafold, SQLMesh?
All this with the candor of a close friend tenderly nudging them with that look, “How are you really doing?” It was then, I felt, I was selling for the first time in my career. I tried it again a second, third, fourth, 128th time and learned something.
You, as a data engineer, with a sales-allergic disposition, do NOT want to talk to a seller. You want to work with a reasonable person who cares about you and your problems. Now the contrast against the image above may lead you to think this person is a saint (AKA: I’m trying to make myself out as a saint). Nah dude. A reasonable person is someone who knows how to read the damn room and listen vs. fish for an overloaded sound byte. I’m lucky to be in a position where I get to be a person who cares about you, and that aligns with my raging extroverted personality. Because then…something pleasant fills the air, and I hope you’re willing to say aloud,
I like working with you.
That’s something we can both work with when money moves between hands in exchange for software. Alright, now I’ll explain the mysterious DAG above.
Due Diligence is an Experience, Not a Deliverable
A reasonable person who cares about you and your problems.
What does that really mean? Well, to care about your problems requires an informedness of said problems. I’ve had hundreds and hundreds of conversations selling data dev tools across 3, count ‘em THREE data dev tool startups in a row! I stake my name on these abstractions. No hedging baby.
People buy on the surface for enterprise value, but people buy in their hearts with how they feel. There’s a temptation to think this is a bad way to buy stuff…but that’s how we buy lots of important things (think: fancy office space, cars, high-end email clients, the best mac spotlight replacement in the game, and yes — even enterprise software). You will contort yourself through each node in the DAG above if you’re serious about buying dev tools.
Feel Pain
I want to save time and money on my data pipelines.
That’s what everyone says off the cuff, but we all know it’s hollow. You hate it when a sales guy connects with you on LinkedIn, waits a day, and messages that same line (cough cough, I’ve sent and received those messages to much dread). Even this doesn’t feel specific enough, “My Snowflake bill feels high.” The pain that motivates you to talk to a stranger like me must be both acute AND chronic. It’s a specific story on loop in your head each time you touch your DAG. You will note something that’s inconvenient until it happens often enough where you believe it’s detrimental. What you thought was joint pain is feeling more like arthritis (Bengay isn’t enough to your dismay). The slow drudgery of your job melts willpower to change anything except keep your head above water. But you know deep down, atrophy only makes it worse. You can’t work like this anymore (this is a judgement free zone):
20 incremental SQL models (think: hundreds of millions of rows) take hours to build when you want them done in minutes for simple updates and schema evolution. No smart, concurrent, batch mechanisms for backfilling intervals.
It takes 30 minutes to debug anything with 5 tabs minimum to glue context together…multiplied by 10 production failures per month.
You have 300+ SQL models and contort your backlog to bundle up change requests because you’re afraid of rerunning your whole DAG for tiny changes.
True story: I saw someone turn off dbt tests in a live screen share in their slim CI job because they took too long.
You have 1000+ line stored procedures (true story) and literally everyone on your team is afraid to touch it. You build on top of it and say a prayer everyday to deaf ears.
You don’t test any of your pipelines
→ Feelings
They are not a snapshot in time. If you’re serious about buying a dev tool, you will answer these questions hundreds of times within your subconscious. This is a big decision that requires brooding as much as building. On the surface, it feels like due diligence via pure pros/cons lists and logic. But really, you’re constructing a map that’s saturated in subjective, qualitative, musings. You’re not going to write your heart down on slides 1-5, but you will act on it. You’re going to surprise yourself with how little you pitch this to yourself and team with slides — and much more with candor.
Is this worth the learning curve pain?
Does it feel good to use it?
Am I using the “latest and greatest” aka modern data tools?
Are other people I respect using this?
Will this help me get into FAANG? Do I care?
How’s r/dataengineering looking?
Has Zach Wilson co-signed it in a LinkedIn post?
Does this force me to learn difficult things adjacent to the tool (ex: better data modeling)?
Do I like how it solves the problem?
Is it easy to imagine a happier life with or without this?
What will this do to my career once I put it on my LinkedIn profile?
Will my leaders think this is a cute toy to make my life easier or a worthy investment?
Do I like the people I’m working with?
Do I trust these people?
You’ll notice throughout the above there’s a substrate: how does due diligence flare your feelings? You can brush it off as “vibes”, but we diminish how much status, emotions, and pain drive much of how we buy software. The veil of being incorporated in Delaware isn’t thick enough to smother the human experience.
So why do I stake my name on this stupid DAG above? Well, because it’s fun! It’s freeing! It’s refreshing to cut through a fog of stilted scripts, copy/paste sales tactics, and slogans to compensate for lack of depth. It reframes this from:
How do I sell this thing? → How do I optimize the buyer’s journey? → How do I help this person win at their job?
Imagine in 2025, the only messaging software available was MSN messenger. For 10 years, you have complained how much this sucks and you’ve twisted your whole job to build workarounds for this. Heck, you got promoted for those workarounds. But you hate your job every single day, undeniably. Then Slack comes out of the ether as you’re drowning in dread. Yeah, we’re all slamming our credit card numbers until the keyboard screams back. This story isn’t that fictitious. Some of your companies just bought Slack after using IBM Lotus Notes.
We buy software for many reasons that don’t fit into neat metrics. You have to feel you’re getting value for the price. It’s hard to encode that in a spreadsheet, and I don’t think we can. But these feelings that we share, now that’s something we can work with.
Buying and selling are fun when both people know the game they’re worth playing.
ROI is More Geographic than Spreadsheet Formula
Deep down, I—as a seller—and you—as a buyer—wish that we were logical, calculating people. That somehow we could channel the non-existent quant in us both to invent the Black-Scholes Model for dev tools. But you and I both know from doing the job that how you work with a daily tool goes beyond feature lists. It’s about taste. A laundry list of features melts into the background as a nice to have or a given (think: I’ve seen POV criteria like, “Does it provide a login?”). What matters after weeks of working together is deliberating the map of questions dozens of times over in live conversations, behind closed doors, in the shower as you scrub those crusty elbows, and in the quiet of an afternoon lull:
🔷 Do I want to work this way?
❓ Does it solve the problem?
🟡 Does it solve it in a way better than how I do it today?
😰 How hard is it to learn?
🧃 Does it feel great to use?
🟣 How hard will it be to migrate away from the old?
🤔 Do I trust the Account Executive, Solutions Architect (me), company?
Discovery
You: are in pain and searching for answers
Feel a problem in your work 🔷
It becomes painful to search for solutions on failing solutions: ChatGPT, r/dataengineering, and DMin’g your homies fails you ❓ 🟡 😰 🟣 🤔
Google a couple products or follows up on LinkedIn content you’ve been passively consuming
Talk with a vendor or multiple vendors for intros by clicking the “Talk With Us” button 🤔 🟡
Get a first impression of the tool and me. What’s it going to be like working together and wonder if I catfished you into an information gathering meeting with no demo payoff 🔷 🤔 🟣 😰 ❓ 🟡
You talk with other teammates and boss about it to verify it’s worth pursuing further 🤔
Schedule a demo for the full tour 🔷 ❓ 🟡
Demo
You: 50-60% of the time you’ll drop off if you’re a no above
Get a second impression of working with us and with the tool 🧃 🟣 🔷 🤔 ❓
Decide how to prove value. You will talk internally if you’re iffy on the solution and/or time commitment. Or, you will schedule next steps right away if eager 🤔 😰
Proof of Value (POV)
You: 80% of the time, this shows you what it really means to work with me
Go through the trial (proof of value) and see how it feels to work with me and the tool. You get a taste for the learning curve. This is the critical juncture here as lots of ROI math happens internally for you (see geographic gif above) 🤔 🧃 🟣 🔷
At the end, decide if it’s a technical win or not 🔷 🟡 🧃🟣 ❓
Then comes the next hard part: Does price match value? 🤔 🟣 😰
Negotiation (long story for next time)
You: muster up the courage to use the juice within you
Wrestle back on forth on spending the political capital and paperwork tedium to sign the deal? I baton pass to my account executive 🤔 🟣 🔷
Sometimes you’ll be asked to create spreadsheets, slides, and an essay for the CFO (true story, but I’ll help you write it) AFTER you go through POV to crystallize things. This can feel theatrical but these numbers have more power because you have lived experience
Pitch to the executive who will sign off without the sales team involved. From there, the executive and account executive have choppy email threads, red lines (think pull requests for legal contracts, and yes it’s as tedious as it sounds). Usually there’s a mix of direct text messages to nudge the executive if things aren’t moving fast enough 🤔 🟣
Send the fully signed order form (think: docusign) email confirmation and BAM, you’re a customer! 🤔
I trim this story intentionally because the point isn’t living in the minutiae. The point is: did your answers expand and contract your feelings, logic, doubts, trust in yourself…trust in me? Does your final decision map contain a collection of shapes, borders, and connective tissue that concludes?
This is worth it.
Dirty Hands Clasped Together
Let’s zoom in here. Everything above feels like formality until we get to the POV. There’s a temptation here that I follow a perfectly manicured template OR freeform jazz on intuition and wit. Prescriptions nor vibes will take us to where we need to go. Let’s play out the over-prescribed way. I have a spreadsheet I meticulously crafted, color-coded, double-clicked all the cells so no lines wrap, and diplomatically bully you into inflexible criteria. Where I see a beautiful spreadsheet that echoes the golden years of my accounting career past is where you see a chore. No one likes chores.
Let’s play out the freeform jazz way. I blitzkrieg you with charisma and we awkwardly pick up random tasks, catchup here and there, and then you’ll go, “Ah but we didn’t test this one feature.” Then it becomes a tour of the feature list, and then you still say, “Ah, but give us another week to try it out,” with no clear reason. You eventually ghost me because you don’t want to turn me down straight up — classic scope creep into oblivion. Then you have the middle ground below.
Tech Win Criteria:
Developer experience feels better than current state
developing locally and scheduling
reasonable learning curve
Easy to test changes
Existing sample pipeline is cheaper and faster to run with the new tool
Extrapolate to rest of your data pipelines
Easy to promote and govern changes to production
I kid you not, what you see before you is criteria that consistently worked across my time at dbt Labs, Datafold, and Tobiko all in a shared slack channel or email. The only formatting is that bold header and proper bullet indentation. Yes, we’ll have back and forth with pregnant pauses and vocal fry to negotiate wording. However, we’ll generally land in the same place. I can see many seasoned and unseasoned sales people shudder at something so simple as to name it heretical. But…it works! This isn’t to be absolutist about a candid approach. It’s to be honest that dev tool decisions are internalized. You get your hands dirty and wonder if the level of filth on those hands (think: learning curve, bugs, UX) are worth the fruits of your labor. How you, as a data engineer, feel about the tools you’re using 8 hours a day is causal to how well you’ll deliver quality data pipelines. This isn’t like selling to an executive who will never use the actual software, and it’s an emotional inconvenience to the individual contributors (think: generic HR software). Emotional dread to a data engineer who has to live in that negative energy 8 hours a day is devastating to an executive. Quiet parts out loud:
I’ll answer your ad hoc request in 1 month.
Every interaction with my data pipeline is 5 minutes minimum whenever I click something or a run a command in my terminal.
It’s normal to rerun my whole DAG without much value and with giant warehouse bills.
We’re afraid to make changes.
The goal of the tech win criteria is to believe these are things you won’t believe anymore.
Now that you’ve allowed me to have this dance, this is where delicateness is required. It’s important you feel friction in the learning curve. Just enough to be motivated to rise to the challenge (think: understanding the workflow opinion, basic configs), but not so overwhelming like a Rube Goldberg machine (think: no sane defaults, and every operation is opt-in). This is where I see how you debug, whether in logs or UI. If I see timidness, I’m happy to hold your hand a bit tighter. As you get deeper into work, you’ll cross the line of immersion into, dare I say, “flow state”. This is where I want you to marinate. This is where I bathe in your micro-expressions working through a problem together and catching up on your experience. I can tell you’ve played through a dozen scenarios of how this changes your job, for better or worse. It’s a safe bet your inner world is fluctuating in flurry asking if it’s a tech win:
Yes, I can see this Solutions Architect being the reason I’m more effective at my job, so this tool + access to this person is worth the tech win.
No, this tool is so hard to learn that it’s just not worth the time and labor.
Yea, I love working this way and how it forces me to think a better way. This levels up my craft.
No, I know it’s technically better but I don’t like the UX compared to how I’m used to doing things.
Yeah, there were bumps in the road, but this guy really showed up and we fixed it together. Great role model experience when we face a hard problem together. This person will stick with me to overcome.
No, I don’t want to be this enmeshed with a vendor.
Yeah, I see how fast these guys are shipping and how they fixed my bugs so fast and how responsive they are on slack. I know I’m in good hands with this team.
No, such a buggy experience, and I want more polish and maturity in the product.
All of these are valid responses to the same situation. The hard part is figuring out which proof or combination of proofs are enough for you. It’s messy. It’s a bet on what I think you need and what you need from me. This isn’t a novel exercise. What does this sound like? It sounds like how you got interviewed to become a data engineer in the first place. This is an interview with me. This is an interview with yourself.
Then I muster up the courage to ask:
Is this a tech win?
You have to Taste and See for Yourself
This is not doctrine. This may be terrible advice for those buying and selling cybersecurity or project management software (read: I see you asana/jira/wiz veterans out there) or maybe this only works for me. You won’t know until you spar with this guide in the wild. And no, role playing and fairytale simulations aren’t enough. You (Data Engineer) and I (Solutions Architect) need real stakes, real mess, real social pressures, nervous vocal fry, and real people involved. These are lessons that reading an essay will never internalize for you.
Reading the room
Psychoanalyzing each other
Noticing the other person doing this to you
Learning how to be a great conversationalist
Tone and candor
Coming off as earnest but not overeager and desperate
Being technically skilled enough to have an engaging conversation and not feel like you’re just slinging buzzwords
Knowing when a deal is not worth your time
Green, yellow, red flag discernment
Knowing when a deal is worth your time even when it’s excruciating
Knowing when to shut up to let each other talk
Knowing when to firmly and tastefully tell a salesperson to shut up
Discerning skill vs. tool issues in each other
If you ask me for help, do you trust the answer I give you?
Knowing when to interrupt each other
How to deal with anxiety and uncertainty in real time
Knowing what’s in your control vs not
Knowing who has authority or not
Who can sign off on what piece of paper?
Honor the uncertainty of luck: both good and bad
Layoffs, vacations, budget cuts
Contract with previous vendor is expiring soon, new budget approved for the year
If you memorize this, it’s quite worthless. You need to live and do this to know what works for you. Until then, all you did is read. This is my invitation to you. Not to me, but to this game buying (and selling) dev tools. It’s entertaining, weird, messy, adrenaline-fueled, and easy to learn but tough to master. Aren’t those the best kinds of games?
Buying Dev Tools can be Beautiful Less Dreadful
Dev tools are powerful as it’s a marriage between build vs. buy incentives. This is not an either/or game. By definition, it can’t be. You’re not buying something to replace yourself. You’re buying something to enhance yourself. It’s one big beautiful bet on a data platform, your hands that make it, and believing I’m a reasonable person who cares about you. Lots of data engineers hate working with sellers. I get that. I feel the same way lol. But I think a lot of you never experienced it as a fun game vs. manipulative game theory.
I know you’ve been waiting with bated breath for a Calendly link to “Talk With Us”. That’s too on the nose even for me. I’m not here to flaunt my guru flag neither. I just enjoy this game. I’d love playing it with you.
If you want to talk, my LinkedIn DMs are always open.
Post-Credits Scene: Gameplay Trailer
Keep those beautiful eyes wide open and moist. I’m showing you my poker hand before the flop.
There’s something lower-level here: philosophy in what a job means to you. We buy things to cope with the world we operate in. I listen for these signals, and they reveal themselves subtly. It’s tempting to view this exercise through a moral lens. Nah dude, it’s simply about what you value in a career. These are the questions that swim in my mind.
Do you love the craft or is this just a job to you?
How dogmatic are you about linting rules?
Are you afraid of debugging in the command line with
breakpoint()? (Not a shaming question, just an honest one. I used to be afraid too.)Do you reason through the problem methodically or are you cribbing from chatgpt?
Do you read the docs and ask thoughtful follow up questions?
Do you watch the tutorial videos I send you?
Do you google things on your own beyond the first non-sponsored result that pops up? (hard to verify, but easy to sniff out)
Do you care about learning python beyond
pandastutorials?Do you reason through a data model vs. build yet another node in your DAG for ad hoc logic?
Do you choose to stay as an individual contributor to chill or to focus on those juicy technical muscles?
If you love the craft, the story is easy for selling you dev tools. A better version of you is the solution, and this tool will help you get there. In plainer terms, your future self is the prize. If this is just a job to you, then how do I make the learning curve feel like butter? I have to paint the picture that migration pain is worth the gain. I get it. Not everyone has a job they love. You’re likely one of the many data engineers in the 2010s that fell into the game by chance but didn’t fall in love with it. I can’t make you love your job, but I can make it less miserable.
The geometry of our time together changes once we see the flop…and well…it only gets more interesting from there. 🧃 🔷 🤔