How Depending Leads to Independence

True independence isn’t the absence of dependencies. It’s an intentional integration. An assembly that’s clear, chosen and changeable.

It depends.

If you ever ask a design question, most likely this is the answer. It depends.

It’s true. Everything depends on something else. There’s no black or white, right or wrong answer, because it always depends. This is the context you’d need to understand. How it’s related.

This applies to your backlog as well. In previous articles, we covered priority and timing. When does something deserve attention, and in what order do you pick up work. And even when you know what to pick up, when matters.

So let’s say you know what work to pick up and when to pick it up, the question still worth asking is: what does it depend on, and is anything else depending on it?

We call this “dependency management.” I think that means more than a dependency graph. It’s about relationships and context.

The Regulatory Reflex

We often manage dependencies well as part of backlog management to mitigate or address risk. And there’s a reflex, a regulatory reflex, that makes us lean toward risk avoidance.

A dependency gets seen or projected as a negative thing. That risk, the thinking goes, can then be mitigated by reducing dependencies.

I’ve seen this a lot in product development. “Dependency management” became a synonym for reducing dependencies. Avoid the vendor. Build it yourself. Own the code, own the outcome. Right?

It sounds strategic. But it rests on the wrong definition of independence.

Does True Independence Actually Exist?

Here’s the question to ask yourself: Does true independence actually exist?

The word independence literally means “not to hang from.”

In (not) + pendere (to hang).

The whole concept is built on negation.

But you always depend on something. A framework, team, budget or a market. Even the time you have in a day.

The question isn’t whether you depend. It’s what you depend on and whether that dependency works.

Fortunately, there’s another way to read that same prefix.

The in- in independence has another root. The one in include, inject, integrate, insight. In as into, within, part of. Not negation. Integration.

Read that way, independence doesn’t mean “not hanging from.” It means “hanging in.” Being part of something. Integrated into a larger system. Intentional.

That’s a very different idea than avoidance.

You’re not running from dependencies. You’re choosing which ones to integrate into. Seeing them clearly. Selecting them deliberately. Keeping the freedom to shift them when the system needs to evolve.

Not the absence of dependencies. The presence of deliberate ones.

A purposeful assembly of parts. That’s what we should mean when we say “independent.”

A New Definition: Clarity, Choice, Change

True independence is about intentional integration, based on three requirements:

• Clarity: You can see what you depend on.
• Choice: You can select your dependencies deliberately.
• Change: You can shift them when you need to adapt to reality.

Dependencies you see clearly, chose on purpose and can shift aren’t risks. They’re the assembly.

The risky ones are those you can’t see, didn’t choose and can’t change. And those are often the ones created by chasing the wrong definition of independence in the first place.

The Pain of the Wrong Definition

I worked on an edge connectivity ecosystem for remotely operating oil rigs. The goal was to standardize how software ran at the edge. Authentication, data access, data streaming, etc. All the foundational components every new project needed.

We built those components once, so other software teams wouldn’t have to rebuild them every time.

It was a strategic bet. I did a lot of the narrative work, high-stakes pitches, executive alignment, the whole thing. The argument was simple: consolidating common parts saves money, reduces waste and lets the company move faster.

The numbers worked. But the adoption didn’t.

A lot of product teams resisted. Some flat-out refused. The cost-saving argument was easily offset by something they felt more acutely: the fear that being tied to a centralized platform would hold them back later. That when they needed to solve a new problem or make a different strategic choice, this dependency would be in the way.

They heard the pitch as: Give up your freedom to build, and we’ll give you efficiency.

And under the old definition of independence (the negation one), they were right to resist. We were asking them to depend on something they didn’t fully control.

But that’s not what was actually happening.

We weren’t asking them to give up independence. We were asking them to redefine it. To stop measuring freedom by what they built themselves, and start measuring it by what they could deliberately depend on. Clearly, on purpose, with the ability to change.

The pain wasn’t the dependency. The pain was the wrong definition.

What the Ecosystem Actually Offered

Before the platform, every team built authentication, data access and streaming from scratch. They depended on their own budget, their own developers, their own expertise. Their speed, their skill and their security were limited by what each individual team could pull off.

The result was scattered software. Reinventing the wheel. From a company perspective, it was waste: the same work, done badly, in parallel.

What the ecosystem offered wasn’t fewer dependencies. It was better ones.

A centralized team with deep expertise. A dependency the company could see, manage and improve. The freedom to shift the underlying technology when something better came along, because the contract was clear and the boundaries were defined.

The product teams’ dependencies didn’t shrink. They grew. But they became something the company could actually manage.

A purposeful assembly, with each part chosen.

The Same Pattern, Smaller Scale

The same pattern showed up in our design system work.

Teams had been forking and falling out of sync, maintaining custom code originally built by an external agency. When the agency engagement ended, we kept the code, but not the expertise. Internal teams were on the hook for something they hadn’t built.

The fix was the same shape as the platform shift: move from custom in-house code to a well-documented third-party framework. We migrated to Progress Kendo UI. The license fee was new but visible. The hidden internal cost, buried in cross-charges and undocumented maintenance, went away.

We even ran a hybrid model. Kendo UI for most components. Different libraries for charting and mapping if Kendo UI wasn’t the best fit. More dependencies, technically. But each one chosen on purpose. Each one we could see and could change if needed.

Different definition.

What Independence Actually Looks Like

The question was never how do I become independent? It’s what am I depending on, and does it work?

Independence isn’t escape from dependence. It’s intentional integration. Clear. Chosen. Changeable.

A purposeful assembly. That’s what independent should mean. On purpose. By design.