6 Key Lessons from Building a DCM Revenue Tracker in Investment Banking

Before I was building iOS apps, I spent years delivering technology projects in investment banking front offices. The most formative was a DCM (Debt Capital Markets) revenue tracker — a system that needed to be fast, accurate, and bulletproof. Here are six lessons that still shape every project I touch.

1. Stakeholder Management Is Everything

Traders and senior MDs have zero patience for broken systems. Every minute of downtime has a visible cost. I learned to communicate in their language — not technical jargon, but business impact. "The reconciliation run will catch the discrepancy by 7am" matters more than "we are reindexing the lookup table." This skill transfers directly to every PM role: understand what your stakeholders actually care about and frame every update in those terms.

2. Change Control Saves Lives

In regulated environments, every change needs documentation, approvals, and a rollback plan. At first it felt bureaucratic. Then a colleague pushed a "minor" fix that broke the end-of-day P&L report, and I understood. This discipline directly inspired the Protected Core Framework I now use in iOS development — 3 tiers of protected files, mandatory impact declarations, and explicit approval gates before any write to critical code.

3. Data Integrity Is Non-Negotiable

When millions are flowing through your system, getting the numbers right is not a nice-to-have. I built reconciliation logic that cross-checked every figure against three independent sources. Audit trails were first-class features, not afterthoughts. This mindset carries into app development: cached data must match live data, offline queues must guarantee delivery, and every calculation should be verifiable.

4. Build for the Worst Case

Market stress reveals every weakness in your system. Unexpected data volumes, API timeouts, and edge cases that only appear when volatility spikes. I learned to design for failure: circuit breakers, graceful degradation, retry logic with exponential backoff. In the DCC app, this translated to offline-first architecture with disk caching, queued feature requests, and network monitoring with automatic retry.

5. Documentation Is a Deliverable

End-of-project reports are not optional extras. They capture institutional knowledge and prevent the next team from repeating your mistakes. I now write CLAUDE.md files for every project — living documents that encode architecture decisions, protected files, coding standards, and change control rules. They serve the same purpose as a banking project closeout report: ensuring continuity.

6. Bridge the Gap Between Business and Technology

The most valuable PMs translate fluently between business requirements and technical implementation. Traders do not care about your database schema — they care that the numbers are right and the system is fast. Engineers do not care about the P&L calendar — they care about clear requirements and stable APIs. Sitting in the middle, translating both ways, is the single most impactful skill I developed in banking. It applies to every industry.

How Banking Shaped My Approach

Every process I use today — protected frameworks, regression checklists, compile-time feature guards, structured logging — traces back to lessons learned under pressure in front office environments. Banking taught me that discipline is not the enemy of speed; it is what makes speed sustainable. The DCC Weekly Activities app has 55+ features and zero regressions on critical paths, because the change control habits I built in banking are now encoded in the codebase itself.