DEV Community: Malek Damiri

Teaching yourself SQL when your job is ops

Malek Damiri — Thu, 29 Oct 2026 13:00:33 +0000

I taught myself SQL. No bootcamp and no data degree. I took an online course, did a lot of practice problems, and then started answering real questions at work. If you’re in sales ops, RevOps, or finance and thinking about learning it, here is what I’d pass on.

Start with questions, not syntax

Pick three questions you get asked every month. Which reps are creating pipeline? Where do deals stall? Which accounts have gone quiet? Learn only what you need to answer those. SELECT, WHERE, GROUP BY, and one JOIN cover more ground than you’d expect.

Do the practice problems anyway

LeetCode-style problems feel artificial, and they are. They still build the habit of breaking a question into steps, and they put window functions and CTEs in front of you long before your day job would. Twenty minutes a day beats a weekend binge.

Learn window functions earlier than feels reasonable

Most operations questions are really “compared to what?” This month against last month. This rep against the team. First touch against latest touch. ROW_NUMBER, LAG, and a running SUM answer a large share of them.

Distrust your first answer

A query that runs is not a query that’s right. Joins quietly duplicate rows, and filters quietly drop them. Count rows before and after every join, and reconcile one number against a source you trust before you send anything to anyone.

Write it so the next person can read it

The next person is usually you, three months from now. Use CTEs with plain names, and leave a comment on anything that isn’t obvious.

The payoff is speed. The gap between having a question and having an answer shrinks from days to minutes, and that changes which questions you bother to ask.

Originally published at malekdamiri.com. More from Malek Damiri on revenue operations at malekdamiri.com.

What revenue operations should own, and what it should hand off

Malek Damiri — Thu, 22 Oct 2026 15:42:04 +0000

Revenue operations collects work. Anything that touches revenue data and has no obvious owner lands there: a report request, a broken field, a territory dispute, a question about a commission check. Each one is reasonable on its own. Together they turn the team into a help desk for the whole go-to-market org, and the work only RevOps can do gets done last.

The fix is to decide on purpose what the team owns, and to hand the rest to a named owner on the other side. Here is where I’d draw the line.

Own the definitions

Someone has to decide what counts as a qualified opportunity, a booking, an active customer, and churn, and where each stage starts and ends. Those definitions need one owner and one written home, and every report should read from them.

If marketing, sales, and finance each calculate pipeline their own way, the company doesn’t have a pipeline number. It has three opinions. This is the one job RevOps can’t hand off, because no other team sits across all of them.

Own the handoffs between teams

Each team owns its own stage of the funnel. Nobody owns the gap between two stages unless someone is assigned to it. That gap is where leads sit unworked, closed deals reach onboarding without context, and renewals surprise the account manager.

Routing rules, response-time targets, and the fields that carry context from one team to the next belong to RevOps. So does measuring them. A handoff nobody measures slows down quietly.

Own the system design, not every request

The CRM’s structure needs one owner: objects, stages, required fields, validation rules, and who can change them. Routine admin work can be shared. Design decisions can’t, because a field added for one team changes the reports of every other team.

Report requests are different. A team that builds every one-off pull never gets to the analysis that changes a decision. Build a small set of dashboards people trust, make self-serve the default, and spend the time saved on questions nobody else can answer.

Hand off the decisions

Quotas, territories, comp plans, and pricing belong to the leaders accountable for the results, usually with finance in the room. RevOps should build the models behind them: capacity, coverage, funnel math, and the trade-offs between options.

When RevOps makes the call itself, it inherits every argument about it, and its analysis stops looking neutral. Commissions work the same way. RevOps can supply the attainment data, but the payout and the controls around it belong with finance.

Keep the logic, share the plumbing

Where a data engineering team exists, ingestion, the warehouse, and job scheduling belong there. RevOps keeps the business logic: how a booking is defined in SQL, how accounts map across systems, and what counts as a match in a reconciliation. In a smaller company RevOps often runs both, which works as long as the logic is written down well enough to move later.

A simple test helps with each new request: would it break if every team ran its own version? If yes, it’s RevOps work. If it has a natural home somewhere else, hand it over cleanly, with the data and the documentation, and send the next request to its new owner.

Originally published at malekdamiri.com. More from Malek Damiri on revenue operations at malekdamiri.com.

Find the funnel constraint before you automate

Malek Damiri — Thu, 22 Oct 2026 12:51:56 +0000

When a team is behind its number, the first instinct is to do more of everything: more outreach, more leads, more tooling. Before any of that, I like to ask a plainer question. What would it take to hit the number, step by step?

Work backwards

Start with the target and divide. Deals needed, at your real win rate, means this many qualified opportunities. At your real conversion, that means this many first meetings, which means this many conversations started. Use measured rates, not hoped-for ones. The arithmetic takes ten minutes and it’s usually sobering.

Then look for the ceiling

Every funnel has a step that can’t go faster no matter how much you pour in above it. It might be the size of the market you can credibly reach. It might be how many deals a rep can carry, or how many new customers onboarding can process in a month. That step sets your output. Everything upstream of it is inventory.

This is where automation goes wrong. Automating the top of the funnel feels productive because the counts go up immediately. If the constraint sits downstream, you’ve built a faster way to create a backlog.

Rank fixes by payoff

Once the constraint is named, the list of projects sorts itself. The cheap fixes that widen the narrow step come first. Volume at the top comes last, and only with a way to switch it off if quality drops.

It’s also worth separating what sales can influence from what it can’t. Some lines in a plan are met by self-serve demand, some by partners, and some by the sales team. Only the last one is a sales problem. Treating all three as one target is how a team ends up working hard on the wrong line.

Originally published at malekdamiri.com. More from Malek Damiri on revenue operations at malekdamiri.com.

Your average customer doesn't exist

Malek Damiri — Tue, 20 Oct 2026 12:51:56 +0000

Most revenue plans contain a line like this: new accounts times average revenue per account. It looks harmless. It’s usually the weakest number in the model.

Revenue per customer is almost never bell-shaped. A handful of accounts produce most of it and a long tail produces very little. In a distribution like that, the average describes nobody. It sits far above the typical account and far below the big ones.

Plan on the median and size the tail separately

If you want to know what the next ordinary customer is worth, look at the median. In skewed data it can be a small fraction of the mean. A plan that assumes the mean is quietly assuming you’ll land more very large accounts, without saying so.

So split it. Model the typical account on the median, and treat large accounts as their own line, with their own count, their own sales cycle, and their own odds.

Look at concentration before anything else

Before trusting any total, sort the accounts and ask what share comes from the top ten. If it’s most of it, your “trend” is really a few customers’ behavior, and a single departure can pass for a market shift.

Report the spread

One number invites one conclusion. I’d rather show the median, the 90th percentile, and the count behind them. It takes one more line on a slide, and it prevents the worst meetings, the ones where everyone argues about an average none of them could find in the data.

The habit is cheap. Every time you’re handed an average, ask to see the distribution it came from. If nobody has looked, you’ve found the first thing to do.

Originally published at malekdamiri.com. I'm Malek Damiri, Head of Revenue Operations in Atlanta; more of my writing is at malekdamiri.com.

How to audit a revenue dashboard before executives use it

Malek Damiri — Thu, 15 Oct 2026 12:50:10 +0000

A revenue dashboard gets one first impression. If an executive finds a number in the first week that doesn’t match the board deck, every number after that is suspect, and the trust takes months to earn back. So before anything goes in front of leadership, I run the same audit. Here is the checklist, with the reasoning behind each item, because the reasoning is what tells you how hard to look.

Tie it out to the ledger

Start with the total. Whatever the dashboard calls revenue should tie to what finance recognized for the same period, or you should be able to explain every dollar of the gap. Pull the period total from the dashboard’s own query, pull the same period from the ledger, and reconcile them line by line. Timing differences, refunds, and credits are acceptable reasons to differ. “We’re not sure” is not.

Do this for more than one period. A single month can tie by accident.

Check the date boundaries and time zones

A large share of revenue disputes come down to what day something happened. The source system stamps events in UTC, the warehouse truncates to a date, the BI tool applies the viewer’s local time zone, and the month closes at a different moment in each layer. Pick one reporting time zone, write it down, and make sure every layer agrees. Then test the edges: the last hour of the month, the first hour of the next, and the weekend daylight saving changes.

While you’re there, confirm which date the dashboard keys on. Order date, invoice date, payment date, and recognition date are all defensible. Mixing them on one page is not.

Follow the currency and the fees

If revenue arrives in more than one currency, find out where the conversion happens, which rate it uses, and whether that rate matches what finance uses to close. Then find out whether the dashboard shows gross or net. Processor fees, discounts, taxes, and refunds each move the number, and each has a camp that considers its version the real one. The dashboard has to pick one, label it, and use it everywhere. A tile that says “Revenue” with no qualifier is a question waiting to be asked in a meeting.

Look for duplicates and late arrivals

Count distinct identifiers against raw row counts at every step of the pipeline. Joins duplicate rows quietly, and a retry in the source system can land the same record twice. Then look in the other direction: records that arrive after the period they belong to. A dashboard that shows last month as final on the first and then revises it for a week teaches readers to wait before believing anything. Decide how long a period stays open, show that status on the tile, and build the dedupe into the query instead of trusting the source to be clean.

Find the filters that silently exclude

Every dashboard carries filters that someone added for a good reason and then forgot. A status filter that drops a new order type. A date filter hard-coded to a fiscal year that has since ended. A segment filter meant for one tab that leaked into the shared dataset. Read every WHERE clause and every filter the BI tool applies, and for each one ask what it excludes and whether the readers know. The dangerous ones make the number smaller in a way that still looks plausible.

Freshness, and a name on the sign-off

Put a “data as of” timestamp on the page, computed from the data itself rather than from when the page loaded. Decide how stale is too stale, and make the dashboard say so when it crosses that line.

Finally, someone has to sign off, and it shouldn’t be the person who built it. The owner of the number, usually in finance or the business, reviews the reconciliation, the definitions, and the list of known gaps, and agrees in writing that this is the version executives see. Signing off doesn’t mean the dashboard is perfect. It means someone besides the builder has looked and is willing to defend it.

An audit like this always takes longer than anyone wants. It is still cheaper than relaunching a dashboard that was wrong on day one.

Originally published at malekdamiri.com. I'm Malek Damiri, Head of Revenue Operations. Drafted with AI assistance. More of my writing is at malekdamiri.com.

Snowflake SQL patterns for revenue reporting

Malek Damiri — Tue, 13 Oct 2026 17:48:44 +0000

Most revenue reporting problems are not hard SQL. They’re the same handful of problems showing up in different tables: gaps in the calendar, days cut at the wrong midnight, duplicate records, totals that need a comparison, data that quietly stopped arriving, and two systems that disagree about the same month. I’ve settled on a small set of Snowflake patterns for them. Here they are, with generic table names. Swap in your own.

Start from a date spine

If a day had no orders, a plain GROUP BY leaves it out and the chart skips the day as if it never happened. Generate the calendar first and left join the facts onto it, so a quiet day shows up as zero instead of vanishing. If you already have a dim_date table, join to that instead of the generator. SEQ4 can have gaps, so use ROW_NUMBER for the offset.

with spine as (
  select dateadd(day, row_number() over (order by seq4()) - 1, '2025-01-01'::date) as report_date
  from table(generator(rowcount => 1000))
)
select s.report_date,
       coalesce(sum(o.amount_usd), 0) as revenue_usd
from spine s
left join orders o
  on o.order_date = s.report_date
where s.report_date <= current_date()
group by 1
order by 1;

Cut days in the reporting time zone

Timestamps usually arrive in UTC, and a month that closes at midnight UTC is a different month from one that closes at midnight where the business operates. Pick one reporting time zone, convert before you truncate, and do it in one shared view rather than in every dashboard. If created_at is a TIMESTAMP_NTZ holding UTC, the three-argument form of CONVERT_TIMEZONE does the conversion.

select convert_timezone('UTC', 'America/New_York', created_at)::date as order_day,
       count(*) as orders,
       sum(amount_usd) as revenue_usd
from orders
group by 1
order by 1;

Dedupe to the latest record with QUALIFY

Systems that sync by upsert or replay often land several versions of the same invoice, and a SUM over all of them overstates revenue by exactly the amount nobody can explain. Keep the latest version per key and drop the rest. QUALIFY filters on the window function directly, with no wrapping subquery, which keeps the intent visible to the next reader.

select *
from invoices
qualify row_number() over (
  partition by invoice_id
  order by updated_at desc, loaded_at desc
) = 1;

Running totals and period-over-period

Most executive questions are “compared to what?” This month against last month. This year to date against the same point last year. Aggregate to the grain you report at first, then let window functions do the comparing. One caveat: LAG counts rows, not months. If a month can be missing, run this on top of the spine above or the comparison will shift by a row.

with monthly as (
  select date_trunc('month', trade_date)::date as report_month,
         sum(fee_usd) as fees_usd
  from trades
  group by 1
)
select report_month,
       fees_usd,
       sum(fees_usd) over (
         partition by date_trunc('year', report_month)
         order by report_month
       ) as fees_ytd,
       lag(fees_usd, 1) over (order by report_month) as prior_month_usd,
       lag(fees_usd, 12) over (order by report_month) as prior_year_usd
from monthly
order by report_month;

A freshness check the dashboard can show

A dashboard that shows yesterday’s numbers with full confidence is worse than one that admits it’s stale. Compute freshness from the data itself, not from when the page loaded, and put the result where readers see it. Watch the time zones here too. CURRENT_TIMESTAMP follows the session time zone, so if loaded_at is stored as UTC, compare against SYSDATE instead, or convert one side before the subtraction.

with latest as (
  select max(loaded_at) as last_loaded_at,
         datediff('hour', max(loaded_at), current_timestamp()) as hours_since_load
  from orders
)
select last_loaded_at,
       hours_since_load,
       iff(hours_since_load > 24, 'stale', 'ok') as status
from latest;

Reconcile two systems with a FULL OUTER JOIN

When the warehouse and the ledger disagree, you want every period from both sides, including the months that exist in only one of them. An inner join hides exactly the rows you’re looking for. Use a FULL OUTER JOIN, COALESCE the keys and the amounts, and add a tolerance so you’re not chasing rounding. Anything outside the tolerance gets a written explanation.

with warehouse as (
  select date_trunc('month', invoice_date)::date as report_month,
         sum(amount_usd) as warehouse_usd
  from invoices
  group by 1
),
ledger as (
  select date_trunc('month', posting_date)::date as report_month,
         sum(amount_usd) as ledger_usd
  from ledger_entries
  group by 1
)
select coalesce(w.report_month, l.report_month) as report_month,
       coalesce(w.warehouse_usd, 0) as warehouse_usd,
       coalesce(l.ledger_usd, 0) as ledger_usd,
       coalesce(w.warehouse_usd, 0) - coalesce(l.ledger_usd, 0) as variance_usd
from warehouse w
full outer join ledger l
  on w.report_month = l.report_month
where abs(coalesce(w.warehouse_usd, 0) - coalesce(l.ledger_usd, 0)) > 1 -- tolerance in dollars
order by 1;

None of these are clever, and that’s the point. The queries behind an executive dashboard should be boring enough that the next person can read them in one sitting. Put them in version control, name the CTEs plainly, and reuse the same few shapes until people stop asking how a number was built.

Originally published at malekdamiri.com. I'm Malek Damiri, Head of Revenue Operations. More of my writing is at malekdamiri.com.

Cohort Retention in pandas: Three Mistakes That Make Your Curve Lie

Malek Damiri — Wed, 07 Oct 2026 19:22:11 +0000

Cohort retention tables look simple: group customers by the month they started, count how many are still around each month after, divide. Then the curve on the slide says retention falls off a cliff at month three, and it's not true.

Most retention charts that lie do it in one of three ways. Here is a small pandas version that avoids all three, with the numbers each mistake would have produced instead.

The data

One row per customer per month in which they paid. Synthetic, small enough to check by hand:

import pandas as pd

payments = pd.DataFrame({
    "customer_id": ["a", "a", "a", "a", "b", "b", "c", "c", "c",
                    "d", "e", "e", "e", "f", "f", "g"],
    "paid_month": pd.to_datetime([
        "2025-01-01", "2025-02-01", "2025-03-01", "2025-04-01",
        "2025-01-01", "2025-03-01",
        "2025-01-01", "2025-02-01", "2025-04-01",
        "2025-02-01",
        "2025-02-01", "2025-03-01", "2025-04-01",
        "2025-03-01", "2025-04-01",
        "2025-04-01",
    ]),
})
last_complete_month = pd.Timestamp("2025-04-01")

last_complete_month matters more than it looks. It's the last month you have full data for, and it decides which cells in the table are real.

Build the table

def months_between(later, earlier):
    return (later.year - earlier.year) * 12 + (later.month - earlier.month)


# 1. Cohort = first paid month.
payments["cohort"] = payments.groupby("customer_id")["paid_month"].transform("min")

# 2. Period 0 is the cohort month itself.
payments["period"] = months_between(payments["paid_month"].dt, payments["cohort"].dt)

# 3. Distinct paying customers per cohort and period.
counts = (
    payments.drop_duplicates(["customer_id", "paid_month"])
    .pivot_table(index="cohort", columns="period", values="customer_id", aggfunc="nunique")
    .fillna(0)
)

# 4. Divide by cohort size.
cohort_size = counts[0]
retention = counts.div(cohort_size, axis=0)

# 5. A cohort that hasn't reached a period yet is unknown, not zero.
months_observed = months_between(last_complete_month, retention.index)
observable = pd.DataFrame(
    {p: months_observed >= p for p in retention.columns}, index=retention.index
)
retention = retention.where(observable)

# 6. Weighted curve: retained customers over the cohorts that can be observed.
curve = (retention.mul(cohort_size, axis=0).sum()
         / observable.mul(cohort_size, axis=0).sum())

The retention table:

period        0     1     2     3
cohort
2025-01-01  1.0  0.67  0.67  0.67
2025-02-01  1.0  0.50  0.50   NaN
2025-03-01  1.0  1.00   NaN   NaN
2025-04-01  1.0   NaN   NaN   NaN

And the curve:

period
0    1.00
1    0.67
2    0.60
3    0.67

Mistake 1: starting the count at 1

If the cohort month is "month 1", every column shifts by one, and the first column is always 100% by construction. Readers compare your month 1 to someone else's month 1 and draw the wrong conclusion. Pick period 0 for the starting month, and say so in the chart title.

Mistake 2: treating cells you can't see yet as zero

The April cohort started in the last month of data. It has no month 1 yet, not a month 1 of zero. If those cells are zeros, the curve collapses:

zeros for unreached cells: [1.0, 0.54, 0.29, 0.17]
correct weighted curve:    [1.0, 0.67, 0.60, 0.67]

That's the "retention falls off a cliff" chart. It's an artifact of when you ran the query. Step 5 fixes it by marking those cells NaN and leaving them out of the curve.

The same bug has a quieter cousin: including the current, partial month as if it were complete. That's why the cutoff is last_complete_month and not "today".

Mistake 3: averaging the percentages

A plain mean gives every cohort the same weight, so a one-customer cohort counts as much as a three-customer cohort:

plain mean of percentages: [1.0, 0.72, 0.58, 0.67]
correct weighted curve:    [1.0, 0.67, 0.60, 0.67]

Here the difference is small. With real data, a tiny early cohort of friendly design partners can pull the whole curve up for a year. Step 6 sums retained customers and divides by the customers who could have been retained, which is what "retention at month n" means.

Things to decide before you trust the chart

What counts as retained. Paid in the month, logged in, or still under contract? Each gives a different, defensible curve. Write the choice under the chart.
Reactivations. Customer b paid in January and March but not February. In this table they count in month 2 and not month 1, which is usually what you want for activity. For revenue retention you may want different rules.
Customer identity. If one company can have two customer IDs, merge them before step 1 or one customer becomes a churn and a new signup.

The table itself is ten lines of pandas. The part that takes judgment is deciding which cells are real.

This post was written with AI assistance.