People sometimes ask how I ended up in asset management infrastructure. The honest answer is that I did not plan it. I planned to be a systems administrator, which I was, and then a sequence of opportunities appeared and I kept choosing the most interesting one. Looking back, there is a coherent arc. At the time it mostly felt like following my curiosity.
Here is the actual path, with the parts that are usually left out of career summaries.
2013 to 2015: data centers and physical infrastructure
My first job out of university was infrastructure engineering at a mid-sized technology company in the Boston area. I spent a meaningful chunk of the first two years in data centers. Racking servers, running cable, labeling everything, learning the physical reality of the systems that most people only ever interact with through a browser.
The work was unglamorous by any measure. But it gave me something that I have drawn on continuously since: an understanding of the physical layer. How data actually moves. What latency means when it is determined by physics rather than code. What a network looks like when something at layer one or two is broken and the symptoms appear at layer seven.
A specific thing I learned in those years: unlabeled cables are a promise that someone else will suffer later. In a large enough environment, that someone is usually you, six months from now, in a hurry. I still label everything.
I also learned what an incident looks like in an environment where the consequences of downtime are modest. The applications we were supporting were internal tools and developer infrastructure. When something broke, people were frustrated. Nobody lost money. The stakes were low enough that you could afford to learn from mistakes in real time. I made a lot of mistakes in those two years and learned from most of them, which is the correct order of operations early in a career.
2015 to 2018: retail technology, scale, and real-time systems
My move into retail technology was motivated partly by salary and partly by wanting to work on systems that more people depended on. Retail at scale is a surprisingly demanding infrastructure environment. Millions of transactions per day. Inventory that has to be consistent across hundreds of locations simultaneously. Promotional pricing that changes dynamically and has to apply correctly everywhere at once.
The first thing retail taught me was what real-time actually means in a production context. In development, real-time is a vague aspiration. In retail with a large online and physical footprint, it is a specific requirement with measurable consequences when it fails. If inventory data is wrong by even a few minutes, customers order things that do not exist and the downstream problems multiply quickly through fulfillment, customer service, and supplier relationships.
The second thing it taught me was what system failure looks like at scale. Consumer-facing outages in retail are public and immediate. You know something is broken because the volume of incoming support tickets changes visibly in the dashboard and the phones start ringing. That visibility creates a discipline. You either build reliable things or you face the consequences in a form that is impossible to ignore. There is no hiding behind "the system is mostly working."
I ran my first significant incident during peak season in retail and it was formative in a way I could not have manufactured in a lower-stakes environment. The specifics of what broke are less important than the experience of coordinating a response in real time, communicating with a business that is actively losing money, and making decisions with incomplete information on a timeline that does not allow you to wait for certainty. Every subsequent incident I have managed has drawn on that one.
2018 to 2022: private equity, data quality as a first principle
The move to private equity was the biggest context shift of my career. The transaction volumes went from millions of events per day to hundreds. The data was not streaming -- it was structured, periodic, and often manually entered. By every quantitative measure it was a smaller engineering problem.
By every consequential measure it was a larger one.
Private equity infrastructure exists to support investment decisions and investor reporting for funds that manage hundreds of millions or billions of dollars. A wrong number in a portfolio monitoring report does not cause an immediate visible incident. It causes a question in a partner meeting six weeks later, by which point reconstructing what happened requires imperfect records and careful forensics. The consequence of a data quality failure is not a spike in the support ticket volume. It is a conversation that damages trust in the data team, which is extraordinarily difficult to rebuild.
I became, in PE, obsessive about data provenance in a way I had not been before. Where did this number come from? What was the calculation method? When was the source data last updated? Is this an actual value or an estimate? Is the estimate methodology documented? These questions sound administrative. Making a system that answers them reliably, consistently, and in a form that a CFO or a limited partner can interrogate is a serious engineering problem.
I also learned something in PE that I would not have learned elsewhere: how technology looks from the investment side of a financial firm. I spent enough time with deal teams to understand how investment decisions are actually made, what data inputs matter and at what stage, and what the cost of bad data is in terms that are not abstractions. That understanding changed how I approached infrastructure decisions in a way that technical training alone would not have.
2022 to present: asset management, operational pressure and regulatory reality
Asset management is where the three previous environments converge. The data discipline of private equity. The real-time operational pressure of retail. The infrastructure depth of my early years, now applied to trading systems and investment operations.
The specific thing that distinguishes asset management from the other environments is the non-negotiability of the operating window. Markets open at a specific time. Regulatory reporting has specific deadlines. Counterparty confirmation cutoffs are not flexible. In retail, if the inventory system is degraded at 10pm, you deal with it and the day-over-day impact is limited. In asset management, if the order management system is degraded at 9:25am, you have a problem that is measured in regulatory exposure and client impact simultaneously.
This creates an engineering culture that takes reliability seriously in ways that are different from other industries. Change management is rigorous. Incident response is practiced. Runbooks are maintained because the cost of not having them is too high.
I have also found, working in this environment, that the regulatory dimension shapes technical decisions at every level. Not just security and compliance controls, but architecture choices, data retention, audit logging, vendor selection. Understanding why these requirements exist -- not just that they exist -- makes you a fundamentally different engineer in this context. Most engineers working in regulated industries comply with requirements without understanding their purpose. The ones who understand the purpose make better decisions when the requirement does not perfectly fit the situation.
What I would tell someone starting this path
The most useful thing I can say is this: learn the business of whatever industry you are working in. Not at a surface level. Deeply enough that you understand why the technology matters to the people using it.
I spent my first two years in financial services understanding the systems without understanding trading. I could trace exactly what happened technically when an order left our infrastructure. I could not tell you what happened to it after that or why it mattered. Closing that gap took deliberate effort and it changed how I work in ways that are difficult to fully quantify.
The technology is the how. The business is the why. Both matter, and the why is usually harder to learn because nobody teaches it to engineers directly. You have to go looking for it. Have conversations with people outside your team. Ask questions that make you feel underqualified. Read the firm's regulatory filings and investor materials. The engineers who do this consistently end up in different conversations than the ones who stay in the technical lane.
The other thing I would say is that the unglamorous early work is not a phase to get through. The years in the data center, the tedious incident response, the careful debugging of a system that is behaving strangely in production -- this is where judgment is built. The senior engineers I have respected most in this industry are the ones who still care about the details, not the ones who have figured out how to work at a level of abstraction that lets them ignore them.
The details are where the interesting problems live. Stay close to them.
