I want to be specific about the gap I kept noticing, because "I could not find the content I wanted" is vague and I think the precise version is more useful.
If you work as an engineer at a consumer technology company -- a startup, a SaaS platform, a large tech firm -- there is a reasonable amount of honest writing available about what that work actually involves. Engineering blogs from well-known companies describe their architecture decisions and incident post-mortems. Senior engineers publish personal accounts of what it is like to build and operate systems at scale. Conference talks get recorded and posted. The body of publicly available, practitioner-level knowledge about technology work in the consumer tech industry is substantial.
If you work as an engineer in financial services -- at an asset manager, a bank, a trading firm, a private equity firm -- that writing is much rarer. What little exists is mostly one of three things: academic research about quantitative finance that is not about infrastructure at all, vendor marketing that describes financial technology from the outside, or conference talks from fintech companies that are closer to technology companies than to traditional financial services firms.
The writing I wanted -- specific, honest, practitioner-level accounts of what it is like to build and operate infrastructure inside a regulated investment firm -- largely did not exist.
What makes financial services engineering distinct
The distinction is not just regulatory complexity, although that is part of it. It is the combination of factors that creates a genuinely different engineering environment.
The operational pressure is different. In consumer technology, a degraded service means users experience slowness or errors and some of them leave or complain. In trading and investment operations, a degraded service during market hours has costs that can be measured in dollars per minute and documented in regulatory filings. The relationship between infrastructure reliability and business consequence is more direct and more immediate than in most technology environments.
The compliance dimension is pervasive. Every significant infrastructure decision in a financial services firm has a compliance component. Data residency requirements, audit trail requirements, access control requirements, change management procedures that exist because regulators require them. Engineers who work in this environment either understand why these requirements exist or they spend their careers fighting them. The ones who understand them make better decisions.
The legacy constraint is real and specific. Financial services firms run systems that have been accumulating complexity for decades. The core banking systems and portfolio management platforms that many firms depend on were not designed for the cloud, for microservices, or for the rate of change that modern infrastructure teams are expected to support. Working around and eventually modernising these systems is a major part of the engineering work, and it almost never appears in content generated by or about technology-native companies.
The relationship between technology and business is structured differently. In technology companies, engineering often defines the product roadmap. In financial services firms, technology exists in service of investment, trading, or financial operations functions that are the core of the business. This changes what good engineering looks like in ways that most engineering writing does not address.
Why financial services engineers do not write much publicly
The first reason is genuine confidentiality constraints. Certain technical approaches in trading and investment management are legitimately proprietary. The specific models, strategies, and data sources that create competitive advantage are protected information, and the NDAs that financial services engineers typically sign are broad enough to create real uncertainty about where the line is.
I want to be honest about this constraint: it is real, and I navigate it carefully. What I have found, though, is that the interesting engineering problems in this industry -- the problems of reliability, data quality, regulatory compliance, legacy modernisation, incident response -- do not require disclosing anything sensitive. The shape of the problems is not a trade secret. The solutions are not proprietary.
The second reason is cultural. Financial services has a tradition of opacity that goes well beyond what confidentiality requirements actually demand. Being guarded about how your firm operates is considered appropriate professional behavior in a way that would seem unusual in most technology environments. There is a status dimension to this: demonstrating that you know things you cannot discuss positions you as an insider.
I find this less compelling as a justification for not writing. The general nature of how infrastructure functions inside a financial firm is not secret. It is experienced knowledge that practitioners accumulate and rarely articulate in a form that others can learn from.
The third reason is practical. Writing takes time, the compliance review process for public content at some firms is onerous, and engineers in financial services often have less slack time than their counterparts in technology companies. The conditions for sustained public writing are harder to maintain.
What I am trying to do
I am trying to write about the specific problems of financial services infrastructure with the same level of specificity and honesty that the best engineering writing from the technology industry achieves.
That means including actual configurations and commands when they are relevant to understanding a solution, not just describing an approach in abstract terms. It means being honest about the things that went wrong and what the failure actually looked like, not just the clean version of how you fixed it. It means explaining the business and regulatory context that shapes decisions, because in this industry you cannot understand the technical choices without understanding that context.
I am also trying to be honest about the things I do not know and the situations where I made the wrong call. Engineering writing that only describes successes is not very useful. The failures are where the actual learning lives.
A note on what I will not write about: I will not write about anything that falls under genuine confidentiality requirements, anything that would identify specific firms I have worked for in a way they have not consented to, or anything that would constitute sharing proprietary strategies or systems. The interesting problems are the general ones, and there are enough of those to write about indefinitely.
Who this is for
I have a few different readers in mind.
Engineers who are new to financial services and are trying to understand an environment that operates very differently from the technology companies where a lot of engineering culture originates. The adjustment period for someone coming from a startup or a tech company into an asset manager or investment bank is real, and I would like this to shorten it.
Engineers who have been in financial services for a while and are looking for content that connects to their actual experience rather than the idealised version of the work. There is something genuinely useful about reading that someone else encountered the same problems you have, approached them in similar ways, and learned similar things.
Engineers from other industries who are curious about what this environment looks like and whether they might want to work in it. Financial services engineering is a specific career path with specific trade-offs, and I would rather people enter it with accurate expectations than discover the reality after the fact.
And people like the junior engineer on my team who asked me where to read to understand this environment. I am writing partly so that when that question comes up again, I have a better answer.
