I have been working in technology for about ten years. The last seven have been in financial services specifically -- private equity first, then a stint in retail technology, and for the past several years in asset management. I am based in the Boston area, I spend most of my working life inside terminals and incident calls, and I have a particular interest in the problems that sit at the boundary between engineering decisions and financial consequences.
I started Packet and Profit in January 2026 after a conversation with a junior engineer on my team who had just moved into financial services from a software startup. He asked me where he should read to understand the environment he was now working in. Not the regulatory basics -- he had those. The real stuff. What does it actually look like when a compliance requirement collides with an architecture decision? What happens in practice when a trading system has an incident during market hours? How do the relationships between engineering and the front office actually work?
I did not have a good answer. I sent him a few conference talks, some vendor blog posts, a couple of Stack Overflow threads. None of it was what he was asking for. It was all either too abstract or written for an audience that was not him.
That conversation is why this blog exists.
What I was actually looking for
There is a lot of content online for engineers. The range is enormous: deep infrastructure architecture from companies like Cloudflare and Stripe, personal blogs from staff engineers at large tech firms, vendor documentation that is occasionally genuinely useful, and enough tutorial content to keep you learning forever if tutorials are what you need.
What I kept not finding was content written from inside a regulated financial services firm. Not adjacent to one, not consulting for one -- inside one. Written by someone who has been in the room when a trade fails to settle and has to explain to the business what happened. Who has submitted a firewall rule change through a formal change management process that takes three weeks and has to justify every element of it to a risk committee. Who has built infrastructure that needs to be functional at 9:30am when the market opens regardless of what broke overnight.
That writing, as far as I could find, mostly did not exist. And the gap is not accidental.
Why financial services engineers do not write much
There are a few reasons.
The most obvious is confidentiality. Financial services firms are careful about information -- there are regulatory reasons for this, competitive reasons, and in certain parts of trading and portfolio management, genuine reasons why specific technical approaches should not be published. Many engineers in this space operate under NDAs broad enough that they are uncertain what they can discuss in public even about general practices.
I understand this caution. I am not going to write about anything that belongs in that category. What I have found, though, is that the constraint is often applied more broadly than it needs to be. The interesting engineering problems in financial services -- how do you manage infrastructure change in a regulated environment, how do you build reliable data pipelines when data quality has regulatory consequences, how do you operate trading infrastructure under genuine real-time pressure -- none of this requires disclosing anything sensitive. The shape of the problems is not a trade secret. The approaches to solving them are not proprietary.
The second reason is culture. Finance has a tradition of not talking about how things work. This is partly professional discretion and partly a status dynamic: being opaque about your edge is considered appropriate in a way that would be unusual in most engineering cultures. I find this less persuasive as a reason for silence. The general nature of how infrastructure functions inside a financial firm is not secret knowledge. It is just knowledge that practitioners have and rarely write down in a form accessible to people who want to learn.
What I am trying to do differently
I want to write about this environment with the same specificity and honesty that the best engineering writing from the tech industry manages. That means showing actual commands and actual configurations when they are relevant, not just describing a solution in vague terms. It means being honest about things that went wrong and what the failure actually looked like. It means explaining the business and regulatory context that shapes engineering decisions in this industry, because you cannot understand the decisions without understanding that context.
I also want to write about the career dimension. Financial services is a specific environment with specific rules for how trust is built and how careers advance. Most of the guidance available to engineers applies to technology companies. Very little of it maps cleanly onto what it means to build a career inside an investment firm or a bank. I have been doing this for a decade and I have learned things I would have found useful earlier.
Who I am writing for
There are a few different people I have in mind when I write here.
The engineer who is new to financial services and is trying to understand an environment that functions very differently from the software companies where a lot of engineering culture is generated. The engineer who has been in financial services for years and is looking for content that validates and extends what they have learned from experience. The engineer in a different industry who is curious about what this world actually looks like from the inside.
And, frankly, engineers like the junior member of my team who asked me a question I could not answer well. I am writing this partly so that next time someone asks me that question, I have somewhere useful to point them.
I do not have a fixed posting schedule. I will write when I have something worth writing about, which based on the last ten years should be fairly often. The problems in this industry do not slow down.
If you work in financial services and recognise the situations I am describing, I hope this is useful. If you are an engineer from outside this world who is curious about what it looks like, I hope it is illuminating. Either way, I am glad you found it.
