The Invisible Dependency

The team was thrilled. We were finally running the full end-to-end test in production, the last milestone before launching one of our platform products in Japan. Two weeks ago, a failure would have been expected. Today, it was a punch in the gut.

We'd already done the unthinkable: cracked open the terrifying legacy codebase created 15 years ago that everyone was afraid to touch, found a fix far simpler than feared, and survived the painfully slow deployment through our core monolith. I had mapped all dependencies standing in our way (eng, ops, legal, supply, billing, gtm, thirteen in total) and systematically neutralized every single one. I had this under control.

The production test finished. The flow was broken. There was a fourteenth dependency. And we were out of time.

Back then I was an Individual Contributor and I'd owned that product for three weeks before any of this started. The engineers who actually understood the codebase had long left the company, and the Product Manager before me was gone in a recent layoff. He was the last product person who'd built real judgment about it. What was left were the Ops people. They were sharp on processes and tooling, but blind on the logic underneath. The code itself had a reputation and zero maintenance over years. Nobody wanted to be the one who broke it.

Into that mix walked an enterprise account manager based in Japan, and he wanted the product expanded there, and he wanted it now. He was direct to the point of aggressive. When I couldn't find time on my calendar fast enough across the challenging timezone gap, he went to his manager, and even named specific events on my calendar, by title, as evidence I wasn't trying hard enough.

My own manager was hard to reach that quarter, for reasons that are their own story. So this landed on me. I knew little about the product, the clients, the market, but I had to figure it out. I own this.

I did what our product lifecycle framework advised: open a doc and write it down. I quickly documented the situation, opportunity, and requirements. My team had a cadence to review docs all together every week. I brought the first draft immediately, and it was embarrassing. At one point I'd written that Japan was the fourth-largest economy in the world, as if that was relevant somehow. The feedback from my peers was blunt: get specific.

So I went looking for specifics as fast as I could, into a part of the business I'd never worked before, talking to people whose names and teams I hadn't heard a month before, over Zoom calls where the hard japanese accents took real effort to follow. Every conversation surfaced another team I hadn't known existed. I started drawing diagrams just to hold it all in my head (that's always been the thing that works for me when nothing else does).

The doc grew. And grew. Past a hundred comments (more than half of them my own open questions).

I was learning constantly and deciding nothing.

Meanwhile my peers were telling me not to prioritize this. GTM's numbers had not held up before, so why trust them now. However the enterprise account manager kept telling me the revenue could be around $4 million if we just move now. There was a regulatory change happening in the local market and we could win by moving first.

For a moment I thought about following my peers' advice, and telling GTM that we had other priorities. But that wasn’t true. During the abrupt ownership transition there was no roadmap solid enough for that product for me to point to and push back to GTM and say "we're doing this instead". I just had noise on one side and silence on the other.

After a week working on the doc and getting evidence and specifics, a follow up meeting with GTM leadership was scheduled. I thought “I had to show something real”, so I stopped writing and started asking for concrete engineering effort instead.

I'd spent enough time attending daily stand-ups and building rapport with the engineering team that when I needed a favor, people picked up. So I got an Engineering Manager and one of the strongest engineers on the team to time box two days in the old codebase (this was long before LLMs, so we couldn’t just “ask Claude Code”). The task for them: “go find out what would actually need to change, and what it would cost”. The answer, when it came back, was surprising. One engineer, one week of work, one more to deploy. From what I’ve seen in this company, that was blazing fast. I couldn’t be more excited.

Around the same time I was able to find a former process owner for that product domain. He was now in a different role, but was willing to walk me through the real sequence. He helped me map the actual thirteen teams that a country launch for this product touched, from the committee that approved new billable items through pricing, supply, ops, public docs, and more. Nobody else had the whole map. As a good practice, I wrote it down, and made sure everyone had awareness in preparation of any future launch.

For the first time, effort and reward both had shape. I went into the GTM call with a real timeline. I told them: we’re almost ready. GTM started lining up clients for us.

Then we ran the end-to-end test, and it broke. I couldn’t believe it. There was an invisible limitation in another engineering team's system that our Japan configuration happened to exceed. A system we didn't know we touched, owned by a team we'd never spoken to.

“Just slack them, right?” Well, no. Engineering teams at large companies plan in quarters. Dependencies get filed, scoped, fiercely negotiated, and resourced months in advance. We had none of that. We suddenly went from "almost ready" to "not ready at all".

I freaked out for a few minutes. Then I went to their SME and got an honest estimate of what the fix would take. I sweat the details with him and asked him what the change was, where, etc. With that info I went to his manager. No history with this team, no favor to call in, nothing but the effort estimate and the GTM numbers on the table. She prioritized it. The fix itself took two weeks on their end. The real work was never the code. It was convincing a team with its own quarter already planned that this belonged in it anyway.

We finished the test. We launched in Japan, private beta, about two months after that first email from GTM. We made two million dollars with this product in Japan that year. The numbers held.

I documented the whole path afterward, and used it again few months later to expand to India where we added a few more million dollars.

I missed the mark by relying too much on a document the first days. The document was not the thing that saved the Japan launch. What saved it was a handful of people who trusted me enough to move fast on thin evidence: an EM who gave me two engineering days on a gut feeling, a manager I'd never met who reprioritized her quarter. The map I drew after the fact is useful, but platforms in large companies will continue to be full of unknowns and invisible dependencies that will get in the way.