In December 2015, I asked a new member of the Reonomy product team to read a long technical email before we met. I told him he could forget most of the details later. I mainly wanted him to understand the history.
I had joined Reonomy that spring after several years at Shutterstock. Reonomy was a two-year-old commercial real estate data startup that had raised almost $20 million. I was responsible for technology and product design. When I left, Shutterstock had a market value of about $2.54 billion.
I wanted to work at a smaller company again. In an interview at the time, I said that early-stage startup work did not feel like a job to me. I also talked about the failures I had collected as “scar tissue.” I expected some of that experience to help.
Nine months into the job, the biggest technical problem was clear.
The email I forwarded was written by an engineer as a guide to the Reonomy system. It was funny in places, but it covered a serious amount of product and engineering history. There was the original application, several partial rewrites, pieces that had once been planned as replacements, and newer services meant to create cleaner boundaries.
Those layers had been built by smart people under startup deadlines. Customer needs changed. Company plans changed. Engineers joined and left. Work that looked temporary kept running because the product and revenue depended on it.
My summary in the email was blunt. I said we had been “saddled / burdened by a mountain of tech debt that I have never seen.” Some of the scaling work would be digging out of the hole before we could run.
That did not mean every old decision was bad. Technical debt can become a lazy way to describe any code the current team did not write. The real issue was how the history affected product work.
A small feature might touch several generations of the application. A critical path might be understood by only one or two people. A service that looked replaceable could still support an important customer workflow. Adding engineers did not immediately make that easier, because each new person needed enough context to change the system safely.
We could not stop the current product while we built a cleaner one. Customers were using it, and it paid the bills. We had to maintain the old application, improve the product, and create better technical boundaries at the same time.
That made onboarding important. A new engineer could not learn only the architecture we wanted to have. He needed to know why the older parts existed, which ones were still necessary, and where newer services were taking over. He also needed to know which apparent shortcut was connected to a live customer or data pipeline.
The long email gave him a few systems to clone and inspect first. It included warnings about places where the obvious path was not the right one. It named the parts of the application that had to remain stable while other work moved ahead. That was more useful than giving him a clean diagram that described only the future.
For me, the management work was mostly about deciding where to make the next change. We documented interfaces. We looked for boundaries that would let teams work without touching every part of the application. We kept people close enough to the existing system to operate it, but tried not to leave the whole engineering team stuck there.
The codebase was not going to be replaced in one large project. We had to move it piece by piece while Reonomy kept serving customers and expanding its commercial real estate data platform.
So the new engineer’s first meeting started with the unclean version of the story. Here was the current product. Here were the older attempts and the newer services. Here were the parts we still had to support. Now we could talk about what to work on next.