Task Bridging

You’re the bottleneck?

How many times has it felt like that?

Let me introduce you to a concept I call task bridging.

It’s an age-old idea — we’re just bringing it back.

At its core, task bridging is about increasing the surface area of people who can actually do a task. It’s not delegation, it’s not management, and it’s definitely not OKRs.

We toyed with calling it deskilling, which is probably the most accurate descriptor — but that word brings along some political baggage. We weren’t trying to start a labor movement — just trying to unblock our team.

So — let’s dig in.

A Real-Life Example: Sutro

I started a company called Sutro back in 2014. We built smart water monitoring devices that measured the quality of your pool water — pH, free chlorine, alkalinity, all the usual suspects.

One of our customers, Tom in Austin, used to check his pool chemistry manually. Now, with a Sutro, he gets proactive alerts to keep his water clean for his friends and family.

But early on, if something went wrong with a device, there was a problem:

We had to toggle things in the backend manually — using MQTT (a protocol for IoT communication). And only 2–3 people on the team knew how to do it.

So we wrote up SOPs and handed them to our customer service team, thinking, Great, they can now run the same commands as our devs.

Disaster.

It took an average of 45 minutes for CS to resolve an issue. They were essentially writing code in customer support tickets. Satisfaction scores dropped. Morale dipped. The whole thing was messy.

So we asked: How do we “deskill” the developers?

How do we turn what they’re doing into something repeatable by a less-technical teammate?

The answer: we built a tool.

We called it DMT — the Data Monitoring Tool. It let the CS team see what was happening with a device, send commands, and take action — without writing any code. Just buttons and toggles. Click. Done.

That’s task bridging.

Principles of Task Bridging

Here’s how I think about it:

Task bridging is turning a single point of access — like a developer’s terminal or someone’s 2FA-protected phone number — into a shared interface that multiple people can use safely and consistently.

It’s replacing the developer Slack ping with a dashboard.

It’s making sure you’re not the only person who can update the pricing table.

It’s turning tacit knowledge into accessible action.

And it’s not just technical. It could be:

• Setting up a Google Voice number for 2FA that multiple ops folks can access
• Giving an SDR access to the pitch deck builder
• Letting a customer success rep restart a device without engineering support

Basically: if you’ve been the bottleneck three times or more, the problem’s no longer technical — it’s structural.

Bridging From CS to Product

Here’s another angle.

Our CS team had dozens of macros for common issues. Customers kept writing in about the same things. Instead of scaling the support team, we sat down and asked:

Can the product itself fix this?

Can we code the macro into the experience so the customer never hits the issue in the first place?

This was another kind of task bridging — not from dev to CS, but from CS to the product team. A tight feedback loop. Something annoying got solved at the root.

What’s an example of a macro you’ve recently eliminated or should have? Or one that should be passed upstream to product? ← Think for a sec // Jump in here

Tools That Help

Now with tools like Cursor, Lovable, or other “vibe-coding” platforms, you can build small internal apps or utilities in a day or less.

They won’t scale like enterprise software — but they don’t need to. They exist to remove you as the blocker. To make your role modular. Replicable. Push-button.

Where in your org could you build a tiny tool that saves 3 hours a week?

Sci-Fi Interlude: Mind-Reading Ops

Of course, the ideal version of all this is full-on sci-fi.

Imagine you could just read your teammate’s mind. You’d grab the right password, send the Slack, flip the backend flag — all without ever asking. Frictionless operations.

We’re not there (yet). But maybe a GPT agent tied into internal tooling gets us 80% there.

In the meantime, task bridging is your closest bet.

Final Reflection

Every time something stops because one person holds the key — literally or metaphorically — it’s a delay. A rift in momentum.

Task bridging is about looking at that rift and asking:

How do I make this task available to more people — without losing quality?

What is only I can do right now — and how do I design myself out of it?

You don’t scale by working harder.

You scale by letting others do the work you used to do, just a little bit better each time.

We wanted to include this concept in Story Driven Smart Products, but it didn’t make the cut. Maybe we’ll turn this into a short PDF or zine — let us know if you want it.