What "Senior" Actually Means in Ops

A product manager once asked me for one custom field. A picklist, four values, on the lead object. She needed it by Thursday and she was slightly apologetic about asking, because she assumed it was a big deal.

It took about forty minutes.

Forty minutes is the only number that ever got written down, so I want to walk through what the field actually cost. Not to make her look bad. She asked a completely reasonable question, and I said yes, and I'd say yes again.

The field needed values for the two million lead records created before it existed, so we backfilled. The backfill needed a rule for records where the answer was genuinely unknowable, which meant adding a fifth picklist value that the original spec didn't have and that nobody wanted to be responsible for naming. It got mapped to the marketing automation platform, because a field you can't segment on is a field nobody uses. That mapping became a sync rule. Sync rules are things that can stop working without telling anyone.

Within a month it appeared in three reports. One of those reports went to the board, which meant the field now had an audience that would notice if it broke, but no owner who would notice first.

Fourteen months later, someone built a routing rule on it. That person has since left. Nobody currently at the company can tell you why leads with the third picklist value skip the standard assignment queue, and everyone is slightly afraid to find out.

Forty minutes was an honest build estimate. It was never the cost.

"Can we" is the wrong question, and it's the one we reward

Ask a marketing ops team whether something is possible and you'll almost always hear yes, because it almost always is. These platforms are enormously permissive. You can do nearly anything to a Salesforce org, which is a sentence that should frighten people more than it does.

So feasibility is a bad filter. It doesn't separate the good requests from the bad ones, because it passes both.

But feasibility is what we reward, because it's fast and legible. The person who answers "can we?" in under a minute looks responsive. The person who says "give me a day and I'll tell you what it costs you over three years" looks like an obstacle, right up until the third year.

I've been both people. The first one gets better performance reviews for about eighteen months.

The second question is harder to ask because it has no clean answer. Pricing a request means holding a lot of half-known things at once and being willing to say a number anyway, knowing you'll be wrong about parts of it. That's uncomfortable in a way that "yes, that's technically possible" never is.

What pricing a request actually involves

When someone brings me a change now, I'm running a handful of questions that have nothing to do with whether it can be built.

Who maintains this when it drifts? Not who builds it. Every automated thing degrades, and the degradation is somebody's Tuesday afternoon, repeatedly, for years. If the answer is "we'll figure that out later," the honest translation is that it will be figured out by whoever inherits the instance, in an emergency, at speed.

What does it make harder later? Every field, every rule, every integration point narrows the range of things you can do next without breaking something. This is the cost nobody prices, because it's invisible at the moment of building and only shows up as the vague sense, two years on, that everything takes longer than it should.

How does this fail? Loudly or quietly. A thing that fails loudly is fine. A thing that fails quietly — a sync that returns partial records without erroring, a rule that stops matching and reports success — costs whatever the wrong data cost during the months nobody noticed. Those two failure modes are separated by orders of magnitude in cost and are usually estimated identically.

Can it be reversed? Some things can be undone in an afternoon. Some things you get once. Deleting a field is one afternoon. Deleting a field that four dashboards, a routing rule and a board report depend on is a project with a change-management plan.

And the one that actually separates people: what happens when I'm not here? Not a hypothetical. Ops people move every two to three years. The question is whether the thing survives its author, and the answer is usually determined at build time by whether anyone wrote down what it was for.

None of that is technical knowledge. All of it is knowledge about time.

You can't learn this from being right

Here's the part that resists training courses.

I know these questions because I built the thing that had to be ripped out. Multiple things. Specifically I once designed a lead lifecycle model that was extremely elegant, genuinely well-documented, and completely dependent on a definition of "qualified" that two teams agreed on for about a year. When they stopped agreeing, the model didn't break. It just quietly began describing something that didn't exist, and reported healthy numbers the entire time.

I was the one who ripped it out, four years later, which is the only reason I understand what I'd actually built. If I'd changed jobs at the usual interval I'd have left with a good story about an elegant lifecycle model and no idea it had rotted.

That's the uncomfortable mechanism. This kind of judgment is compressed regret. You learn what a request costs by having personally underpriced one and then being present, years later, for the invoice. Which means the useful thing about a decade in this work isn't a decade of accumulated technique. It's a decade of consequences you were still around to see.

There's no shortcut, and I'm suspicious of anyone who claims one. Certifications test whether you know the platform. Nothing tests whether you've been wrong in a way you can now recognise early, and that's the entire skill.

Why it doesn't fit in a job title

Companies hire for this badly because it has no name. "Senior" in a job posting usually translates to more years of the same activity, or people management, which is a different job entirely.

What they actually want, when they want it, is someone who will look at a reasonable request from a reasonable person and say: yes, we can do that, and here's what it costs you every quarter until 2029, and here's who has to care about it after I'm gone. Then let the business decide with the real number in front of it.

Sometimes the answer is still yes. Often it should be. Pricing a request isn't a way of saying no in a longer sentence — the point is to make the trade visible, not to win the argument.

But the number has to be real, and it has to be said out loud, before the thing is built. Afterwards it isn't a price. It's an autopsy.