Email blasts to thousands of customers. Merchant partners with promotional materials printed and posted. An expanded push across every channel we had. Months of planning. Real budget. Real stakes.

By that afternoon, every single customer who tried to apply for financing hit the same wall.

We processed ZERO applications for 48 straight hours.

It didn’t start that weekend. It started months earlier — in a conference room, with a sentence that felt completely reasonable at the time.

“We just need to add their tracking APIs.”

JUST.

The performance marketing team had been making the same case for months. We were spending heavily across multiple channels and had no way to track which campaigns were actually driving applications. No attribution data. No funnel analytics. No way to verify how anything was performing.

The frustration was legitimate. The business case was real. When leadership finally greenlit the project, the team already had a solution: a comprehensive cross-channel customer engagement platform. Widely used across the industry. Well-reviewed. Proven.

“It’s easy to integrate. We just need to add their tracking APIs to capture traffic sources and funnel progression.”

This was a financing platform for customers who don’t qualify for traditional credit. People who’ve been turned away elsewhere. People for whom this is often the only path to owning a refrigerator, buying a new mattress, or washer and dryer. The platform existed because that need is real. So was the pressure to make it perform.

“Just” collapsed months of technical complexity into a single afternoon’s assumption. It made skepticism feel like an obstruction. It got the project approved, resourced, and scheduled — without a real conversation about what “adding tracking” would actually touch.

What “just” erased.

Our financing application wasn’t a form. It was a carefully orchestrated multi-step financial process that had evolved over years of regulatory compliance and technical optimization.

Each application generated dozens of individual backend operations — API calls, database updates, conditional logic branches, and compliance checks. The system processes thousands of these complex workflows every day.

The “simple” marketing attribution integration needed to coordinate with every single step of that process. Traffic source tracking at entry. Funnel progression monitoring throughout. Qualification capture at conversion. All of it, layered onto a system that had never been tested with this additional load — under holiday weekend conditions, with a marketing campaign actively driving the highest traffic volume of the year.

The business pressure was real. The deadline was real. The integration got built and shipped, in between other priority work, bundled as “just” part of a regular release.

Memorial Day weekend, furniture and appliance retailers double their normal volume. Industry data shows sales jumping 50 to 100 percent compared to the rest of May1. For a financing platform whose merchant partners include furniture stores, mattress retailers, and appliance dealers. It’s one of a handful of annual major marketing events.

Our customers wait for events like these to get the biggest discounts on the products they already need. We are usually there to help get them out the door. Instead, they were greeted by an error message.

The merchants were calling like the house was on fire.

There was no way for customers to complete an application. Just a default error wall — merchant partners lit up our support line, our sales team, and the CEO’s personal line as they desperately tried to save their sales.

The team worked through the weekend. Emergency calls with the offshore development team. Desperate attempts to isolate the failure point. Frantic efforts to restore service while the campaign we’d spent months building continued driving traffic to a broken system.

The bitter irony: the system designed to measure our campaign’s success had guaranteed its failure.

After 48 hours, the only fix was a complete rollback. Every piece of the integration had to be removed to restore basic application processing.

The “simple” addition came out the same way it went in — fast, under pressure, and at the worst possible time.

Does this sound familiar?

Maybe you were the one who said it. You needed something done, the deadline was real, and “just” made the ask feel reasonable. You weren’t wrong about the need. You were wrong about the weight of the word.

Maybe you were the one who had to own it and stop the pushback. You knew it wasn’t simple. But the pressure was real, the timeline was set, and raising the flag felt like being the problem instead of the solution.

Maybe you were the one who had to build it. In between three other things, without enough time for proper testing, trusting that “widely used and reliable” would cover the gaps that the schedule couldn’t.

Nobody in this story made an obviously bad decision. The pattern isn’t about bad actors. It’s about a single word that makes everyone feel safe enough to stop asking questions.

Removing “just” as a policy

The “Just” Whisperer doesn’t show up as a villain. It shows up as a reasonable person with a legitimate need and a word that makes the ask sound smaller than it is. The damage isn’t in the intent. It’s in what gets skipped when everyone agrees the thing is simple.

Before any “just” request moves forward, ask one question:

“Before we approve this — what does it touch?”

Not a full discovery cycle. Not a formal requirements process. One question, asked out loud, in the room where the decision is being made.

That question doesn’t kill the project. It doesn’t make you the obstacle. It makes the complexity visible before it becomes a crisis. And it gives the technical team something they rarely get: permission to say what they already know without sounding like they’re blocking progress.

Business urgency and technical caution are not opposing forces. One is the reason to move. The other is the reason to move carefully. “Just” is what happens when urgency wins the room before caution gets a word in.

Zero applications for 48 hours. The campaign ran perfectly. It just had nowhere to send anyone.

The Operating Gap diagnoses the systems that bury good work. If this landed, forward it to the person in your org who approves the “just” requests. Or send me your story at raevyndigital.com.

Share

RaeVyn will be bringing this conversation to the PMI Dallas Chapter North Texas PM Conference on September 26, 2026. Come find out what else the system is hiding.

You know that sound. It’s 4:47 p.m., and with one Teams message, your hope of logging off on time disappears.

When you open the file, you’re met with all the signs of a chop job: 32 slides, half of them broken images, “WIP” across most of the pages, someone else’s speaker notes, three identical slides, and one slide from a completely different project.

You message back. “When do you need this by?”

15 minutes later. “The presentation is tomorrow at 9am. I really appreciate your help.”

Several hours later, while eating dinner at your desk, you finally finish.

You didn’t write the deck. Your name isn’t on it. You won’t even be in the room for the presentation. It wasn’t your responsibility, and you might get a shout-out, but your name isn’t on the deck. The hours you invested aren’t evident to anyone but the person who asked. This surely gets you an “exceeds expectations” in your end-of-year review, right?

It doesn’t

The work in the scenario does not show up on any goal. It does not show up in a capacity model. It happens because someone in the organization got lost in the weeds and didn’t know how to put together their story, while you are using context clues to create a manageable narrative.

The person being tapped to untangle this mess is rarely the most senior. They are the most reliable.

Non-promotable tasks

Babcock, Recalde, Vesterlund, and Weingart published a paper in the “American Economic Review”1 in 2017 with hard numbers. Women volunteer for non-promotable tasks roughly 50% more often than men. They are asked to do them 44% more often. When asked, they say yes about 50% more often. The paper describes these as low-promotability tasks, meaning work that does not advance the career of the person doing it. That gap has not closed as of 2026.

Tanya Reilly, in a 2019 talk that became required reading on engineering teams, calls a related pattern “glue work.” The connective work that holds a team together. Documentation, follow-ups, mentoring, cross-team alignment, project tracking. Reilly’s frame is gentler than the one I am about to give you, because she is talking about engineers, and engineers eventually get promoted on craft.

Program managers do not. Operations people do not. The person on the other end of that 11th-hour Teams message does not.

Glue work is what happens when the connective work is least recognized. Invisible labor is what happens when it is neither recognized nor rewarded.

The failure is structural. The organization has a deliverable due at 9 a.m., and the work gets done because someone absorbs it. The cost of that absorption is paid by one person. The benefit of the deliverable is credited to someone else. This is not a kindness problem. It is an org design problem dressed up as a kindness opportunity.

If the work is not in the JD, it is not in the role.

If it is not in the role, it is not in the capacity model.

If it is not in the capacity model, it is not real to leadership.

If it is not real to leadership, it is not on the performance review.

It is real to you. You did it.

Does this sound familiar?

Maybe you’re the go-to person who gets the last-minute ping.

Maybe you were the one who pulled the deck together while someone else presented.

Maybe you were the program manager doing the “admin-y” work while also moving the teams forward.

Maybe you have also been the person on the other side of that Teams message.

Maybe you sent it because you were underwater, the deadline was real, and the options limited.

Either side of that Teams message, you are inside the same operating model. The model runs on absorption. The absorption is not on any slide.

How to break the cycle.

The next time your Teams pings near quitting time, send this back.

”Sure, I can help. Here are my top three projects: [list of high-priority, high-visibility projects] What am I pushing off?”

Trade-offs are real

You can’t add hours to your week. You also aren’t refusing to help. It is a capacity question. The person on the other end has to engage with it, in writing, in a tool that keeps receipts.

Three things happen when you send it.

The first is that the asker has to look at your plate. Most asks are sent by people who have no insight into your workload, because nobody has built a system that makes your week legible to them. The question forces a brief, polite conversation about priorities, and how “THIS ASK” isn’t one of them.

The second is that the answer, whatever it is, becomes data. If they say “This is the priority, drop something to make room” you have a written instruction to deprioritize. If they say “no, do all of it,” you have written confirmation that the work is being requested on top of capacity. That is a different conversation than “you didn’t deliver.” If they say nothing, the silence is also data. They went to find someone else. 🤞

The third is the slowest and the most important. The first time you send it, it costs you something. The fifth time, it costs you nothing. Eventually, the people who are asking for the support stop asking you, because they have learned that you will surface the cost of the absorption, in writing. They will send it to someone else. That other person has not learned the script yet.

The job is not to refuse the work. The job is to refuse to absorb it.

Indispensable is a trap with better PR.

The Operating Gap diagnoses the systems that bury good work. If this landed, forward it to the person who still hasn’t sent that message. Or send me your story at raevyndigital.com.

Share

A future-forward demo had been presented and greenlit. Now, a room full of product, development, and design leads had gathered to figure out what was actually being built.

What they had: a wishlist and a few fragmented wireframes.

That was my first day on the team.

The dev team tried to cobble something together from that demo, a demo that wasn’t grounded in any of the systems that would support it. No clear direction. No timeline. No roadmap. Requirements? What’s that?

The strategist didn’t know what she didn’t know and couldn’t tell the business where their app stood.

What they did was productivity theater. Hours spent in “planning” meetings. A constant loop of conversation that felt like progress but produced nothing.

Six months in, the UX’r designing the screens had no idea how far behind they were.

No transparency in, no transparency out.

The UX’r came to me, worried. The design lead told me they had been frozen out — with no visibility into what the team was doing and no way to support them.

Then I looked at what actually existed: wires and feature wishlists. Nothing was tied to a timeline. Nothing was tied to a requirement. Nothing was tied back to the systems supporting it.

Now I was supposed to help a team meet goals that had never been set.

Then Product stepped in.

They built a real timeline and implemented phased feature delivery. The work that should have existed six months ago finally started to appear.

The strategist was pulled back in. So was I. Not as partners — as support for a plan we hadn’t created. She didn’t like the structure. At least it gave me somewhere to start.

The shift.

The more visibility I brought to the project — the more meetings I joined, the more overviews I gave — the more the door slowly closed — the strategist who’d been happy to have me there started routing around me.

This is what happens when you’re too good at the job someone else was supposed to do. They no longer control the narrative. You get managed out.

Does this sound familiar?

Maybe you were the designer who found out you were behind.

Maybe you were the person who walked in on day one and saw the gaps.

Maybe you were one of the developers in the room who had been waiting for a handoff.

All three of you are living in the same broken system. The dysfunction isn’t the fault of any one person. The structure allowed six months to pass without a single visible deliverable and labeled it “strategy.”

How to break the cycle.

If you’ve been on the same screen, working on minute details for more than a few days without the full picture mapped, you are blocked. Not because something is broken — because the full picture must exist before the details do. Raise the flag before it becomes a fire.

The visibility checkpoint

Once a week. Fifteen minutes. Check in.

Send your design lead a short update in whatever channel you already use:

• Completed: What’s done and ready for review

• In flight: What you’re actively working on

• Up next: What you’re moving to after this

• Blocked: What you’re waiting on before you can move forward

That’s it. Four lines. It doesn’t need to be long — it does need to be consistent.

This isn’t a status report for leadership. It’s a lifeline between you and the person whose job it is to support you. The design lead can’t advocate for time, resources, or direction if they don’t know what you’re facing.

Subscribe now

Visibility doesn’t require a new system. It requires one message, sent before anyone has to ask.

The Operating Gap diagnoses the systems that bury good work. If this landed, forward it to the person who needs it, or send me your story.

A new and disruptive workflow shift. A new way of working that will make the organization faster, more aligned, and innovative. The plan?

The plan is nowhere.

Not because the leader didn’t care. But because in that room, vision felt like enough. The announcement was the work. The transformation was assumed to follow.

It didn’t.

The managers closest to the teams raised concerns. They knew the current workflow was actually moving things, and they could see the gap between what was being described and what it would take to get there. They asked questions. They flagged risks. They were heard, and then sidelined.

Someone who knew the language but not the work — pods, SAFe, OKRs, double diamond, design sprints, agile at scale. But couldn’t explain what they actually wanted. Couldn’t map how the work currently flowed, let alone how to transition it. The frameworks were real. The operational knowledge was not. And the one operational role in the room is left trying to pull together a vision they can’t articulate.

The program manager balanced workloads, moved sprints forward. Maintained stakeholder communication. Translating the chaos from above into something the teams could still work with. Keeping the teams’ normal rhythm alive while everyone else argued about what came next.

The program manager doesn’t survive the next round of cuts — unnecessary overhead in a leaner, faster organization.

What followed

Teams without deadlines are being told to hurry up. Structures are collapsing on one side while barely holding on to another. Designers are proposing their own delivery schedules because no one else was setting them. The old workflow gone. The new one still theoretical.

The directive had landed. The design for how to live inside it never came.

Does this sound familiar?

Maybe you were a Director — confident in the vision, certain that good people would figure out the path.
Maybe you were a manager who raised their hand and watched the room move on. Maybe you were the person quietly holding the work together.
Maybe you genuinely believed you could build it, and found out mid-air that belief wasn't the same as a blueprint.

None of these roles are at fault. These are responses to a broken system, where the dysfunction lies in the void between high-level announcements and what people actually need to succeed.

What the room never asked.

Before any structural directive becomes official, someone needs to answer three things in writing: what stops and when, what starts and when, and who owns the work that falls in between.

Not another deck or framework. A plan with owners and dates, and an honest accounting of what gets disrupted in the middle.

Vision without a plan, goals, or outcomes is like working with good vibes.

If your organization is navigating a transition that was announced but never properly designed, this is exactly the kind of work I do. I help teams build the structure that makes change survivable — not just describable.
Learn more at raevyndigital.com

That was the story being told in leadership meetings. The team wasn’t moving fast enough. Something was wrong with the team.

Except the team was fine.

Every sprint, the same thing happened. Accessibility tickets would get loaded into the queue. Then a production bug would surface. The kind that breaks things customers can actually see. Or a major release would land that couldn’t wait. The compliance work would get bumped. Not canceled. Bumped.

Next sprint, same story.

Nobody decided to deprioritize accessibility. They made a hundred small decisions to handle what was in front of them. And without any process for protecting long-horizon work from short-term urgency — no buffer, no dedicated capacity, no structure that said this work is load-bearing and cannot keep losing — accessibility kept losing. Every single time.

It accumulated. Sprint by sprint, invisibly, until the backlog had grown beyond anything anyone on the outside could see.

The dev lead had been quietly holding it together. Shielding his team from the pressure building above them, absorbing what he could, pushing back where he could. I won’t speak to what his decision to leave may have been, but it’s easy to see how burnout and a lack of support could have been a significant contributor.

When he left, the team stood exposed. And nobody, not the leads or the business, knew what they were actually sitting under.

This is where I came in.

The backlog was over 800 tickets. That number alone was enough to make the work feel impossible: an undifferentiated pile of debt with no clear start, no clear end, and no way to know what actually mattered.

Prioritization was the first move. Disciplined work of sorting what was still valid and had actionable data from what was noise. After triage, the number came down to 256 tickets. Still significant. But survivable, if the structure was right.

It wasn’t.

The team was carrying all of this with no room to absorb it. The workload was never balanced to account for two competing streams of work running simultaneously. One fully capable engineer. One still onboarding. 256 tickets. 11 sprints. Being asked to explain why this wasn’t done yet.

The business looked at that situation and saw a delivery problem.

I looked at it and saw the inevitable result of a system with no shock absorbers. No process designed to protect compliance work. No workload structure that accounted for what the team was actually being asked to carry. Just people doing their best inside a setup that made success nearly impossible.

The people weren’t the problem. The system was.

This is the pattern I’ve spent years watching play out across product teams and delivery organizations. The names change. The industry changes. But the structure is almost always the same: invisible decisions accumulate, processes that should exist don’t, workloads get distributed in ways that set people up to fail.

I started RaeVyn Digital because that pattern deserves to be named, diagnosed, and fixed. Not managed around. Not blamed away.

Every issue of this newsletter will do three things: name a dysfunction pattern you’ve probably lived inside, show you what’s actually broken underneath it, and give you one concrete move you can make this week.

If you’ve ever watched a capable team get blamed for a problem that was built into the system long before they arrived — this is for you.

You saw it clearly. Most people didn’t want to look that close.

— RaeVyn

If your team is living inside a pattern like this one, I work with organizations to diagnose what’s actually broken and build the structure to fix it. You can learn more about how I work at raevynconsulting.com.