I want to be upfront about what this post is and is not. It is not a listicle of generic career advice that applies to every industry. It is my honest account of how career progression actually works at the intersection of technology and financial services, based on fifteen years of navigating both, and what I have learned about presenting yourself effectively in each context.
The fundamental difference
In pure technology companies, career progression is primarily about output visibility. The engineer who builds the system that scales to ten times the load, who refactors the codebase that was slowing everyone down, who ships the feature that unlocks a new market segment. That person gets promoted because their work is visible, measurable, and attributable.
In financial services, career progression is primarily about trust and access. The technology still matters. But you get ahead by being the person that the business trusts with its most critical systems, the person who gets invited into rooms where decisions are made, the person who understands both the technical and the financial reality well enough to speak credibly in either direction.
This is not a value judgment. Both approaches reflect the nature of the work. Technology companies compete on product velocity; visibility matters because shipping fast matters. Financial services firms compete on reliability and risk management; trust matters because the cost of losing it is existential.
If you are building a career in tech and wondering why you are not getting promoted despite doing excellent work, it is often because your work is not visible to the right people. If you are building a career in finance and doing the same, it is often because you have not yet been granted the access that comes with trust.
How finance is different from what you expect
When I moved from a technology company into private equity, I expected the pace to be slower and the stakes to be higher. Both were true. What I did not expect was how much the relationships between technology and business would define what was possible.
In a technology company, engineering is the core business. The engineers run the product roadmap. In private equity, investment management, or most financial firms, technology is in service of the business. This sounds obvious. It took me longer than I would like to admit to understand what it actually meant for how I should behave.
It meant that the most important thing I could learn was not a new technology. It was understanding what the business was actually doing. How does a deal get done? What does a portfolio company review look like? What does the compliance team actually care about and why? The engineers who learned the answers to these questions became trusted. The engineers who stayed in their lane, however technically excellent, stayed in their lane.
Promoting yourself in a tech environment
The advice here is to make your work legible. Technical excellence is necessary but not sufficient. The person who builds something brilliant that no one understands or notices is not going to be promoted ahead of the person who builds something good that everyone in the company can point to.
Concrete practices that work:
Write about what you are building. Not exhaustive technical documentation. Brief, readable summaries of what problem you are solving and why. An internal post that says "we were spending four hours a week on this manual process, here is what we automated and here is the result" is more career-relevant than a six hundred line PR with no description.
Present at internal forums. Most technology companies have some version of an engineering all-hands, a tech talk series, or a team retrospective. Getting comfortable presenting your work, even briefly, creates visibility that code commits do not. This is uncomfortable for a lot of engineers. It is worth doing anyway.
Sponsor other people's work. One of the least discussed factors in promotion is how much other people are willing to advocate for you. Engineers who publicly credit their collaborators, who highlight other people's contributions, who make others look good. They build the kind of reciprocal goodwill that shows up in promotion conversations.
Promoting yourself in a finance environment
The approach is different. Visibility matters less than trust, and trust is built through consistency and competence over time. A few specific things that matter in financial services that do not matter in the same way elsewhere:
Be known as someone who does not create surprises. Financial firms have a visceral aversion to surprises, especially bad ones that come without warning. Engineers who develop a reputation for surfacing problems early, for communicating honestly about risk, for not understating complexity. Those engineers become trusted. It sounds simple and it is genuinely hard to do consistently.
Understand the regulatory context. I am not suggesting you become a compliance expert. But understanding why certain controls exist, why data residency matters, why audit trails are not optional. This understanding makes you a fundamentally different kind of engineer to work with. Most engineers working in financial services have no idea why half of the compliance requirements they work around exist. The ones who do get access to a different set of conversations.
Build relationships across the business. In technology companies, relationships across the business are nice to have. In financial services, they are career-defining. The investment team, the risk team, the compliance team, the front office. These are not just stakeholders to manage. They are the source of context that makes you better at your job and the source of advocacy that gets you promoted. Have coffee with people who do not know what a Kubernetes pod is. Be curious about their work.
The question of visibility in finance
A common complaint from engineers in financial services is that their work is invisible. The trading desk knows when the system goes down. They do not know when someone spent three months improving the reliability that meant it did not go down last quarter.
The answer is to make the absence of problems visible. This is genuinely difficult. One approach that works: regular, brief, readable summaries of infrastructure work sent to a wider audience. Not technical details. Business impact. "Last quarter we migrated three critical services to the new platform. Year to date, the incidents we have attributed to infrastructure failures are down sixty percent from the same period last year. Here is what we have in flight." This kind of communication is unusual in infrastructure teams. That is exactly why it creates disproportionate impact.
The intersection: why it is worth being in both
I have spent most of my career at the boundary between technology and financial services because I find the intersection genuinely more interesting than either side alone.
The problems are harder. Building reliable infrastructure is interesting. Building reliable infrastructure that processes billions in transactions per day, that has regulatory requirements around every piece of data it touches, that needs to work at exactly nine-thirty in the morning when markets open regardless of what happened the night before. That is a different category of challenge.
The learning is richer. A decade in financial services has changed how I think about reliability, risk, and the relationship between technology and the business it serves in ways that would not have happened in a pure technology environment.
And practically: the engineers who can operate at this boundary, who are trusted by the business and respected by the technology team, who can explain a network security decision to a CFO and a regulatory requirement to a junior developer. Those engineers are not commodities. The intersection is a good place to build a career.
On self-promotion, specifically
A lot of engineers are uncomfortable with self-promotion. The discomfort is understandable and the instinct to let the work speak for itself is reasonable. But the work does not speak for itself. Someone speaks for it, either you or whoever happens to notice it, if anyone does.
The version of self-promotion that works in both technology and finance is not boasting. It is narration. You are telling the story of what you are working on and why it matters. You are doing it consistently, not just when you have something impressive to show. You are doing it in language your audience can understand.
The most effective form of self-promotion I have observed is consistently being useful to people and making sure they know that your help is available. The engineer who helps the business understand a technical decision, who responds to questions clearly, who makes complex things legible. That engineer builds a reputation without ever having to say "look how good I am."
That reputation is what gets you promoted. In both worlds.
