PPT Driven Development (PDD): Why Drawing Architecture Diagrams Is More Important Than Writing Code in Banks?

For many developers transitioning from big tech to fintech, "PPT Driven Development" (PDD) is often viewed as an ironic workplace joke, or even equated to a typical symptom of banking IT formalism. However, this "PPT before code" phenomenon is not mere bureaucracy, but an inevitable survival mechanism and project logic evolved within the bank's massive, strictly hierarchical, and extremely risk-averse organizational ecosystem. With banks strictly defining IT departments as cost centers, tech teams cannot prove value to non-technical executives via code; thus, polished presentations become the sole "universal currency" for securing annual budgets, project approvals, and cross-departmental communication. Unlike internet culture's focus on "rapid iteration and breaking conventions," banks' extreme pursuit of fund security and regulatory compliance necessitates reliance on detailed architecture diagrams and reports to build a defensive "exemption contract." In this system, PPT functions as a virtual MVP (Minimum Viable Product), forcing teams to complete risk simulation and interest alignment logically before touching complex legacy code. Therefore, deeply understanding the PDD model is not about compromising on window dressing, but about gaining insight into the deep waters of digital transformation: how to translate obscure technical implementations into quantifiable business certainty, thereby finding the true fulcrum to advance projects amidst strict compliance constraints and resource competition.

What is "PPT Driven Development" (PDD)?

In the IT context of banks and large traditional enterprises, PPT Driven Development (PDD) is not merely a joke, but an established project operation methodology. It refers to a development mode centered on presentation slides (PowerPoint) as the core deliverable and progress metric. In this mode, system architecture design, requirements analysis, and even final acceptance are often first reflected in exquisite slides rather than in deployable code or actually running software.

To avoid confusion with industry terminology, we first need to perform Disambiguation regarding the meanings of "PDD" and "PPT" in the banking context:

• Not the Financial Unit of Measurement (Percentage Point): When reading bank financial reports or financial research reports, you will often see the term "ppt" (e.g., "NPL ratio decreased by 0.5 ppt"), which stands for "percentage point." The PPT discussed in this article refers to Microsoft's presentation software and the reporting culture it represents, not financial indicators.
• Not the E-commerce Giant (Pinduoduo): Here, PDD does not refer to Pinduoduo. In bank technology departments, PDD represents a workflow where "diagrams determine the outcome"—PPTs precede code.

Typical Symptoms of the PDD Mode

By observing the lifecycle of bank IT projects, we can identify several significant characteristics of PPT Driven Development. These symptoms indicate that the project focus has shifted from "technical implementation" to "upward management":

• Architecture Diagrams Prioritized Over Feasibility Verification
  Before any requirements are detailed or any technical prototypes (PoC) are verified, complex logical architecture diagrams, deployment topology maps, and data flow diagrams are already drawn in PPTs and approved by leadership. This "God's eye view" planning often ignores the actual limitations of underlying Legacy Systems.
• "Reporting" Equals Output
  Key project nodes (Milestones) are often not code go-lives or feature deliveries, but reporting meetings to the technology or business department leadership. Developer output is quantified by the number of pages and the exquisiteness of the PPT. As pointed out by industry observations, the sector has begun to reflect on and be wary of the phenomenon where digital transformation remains on PPTs, but in actual execution, a logically self-consistent PPT often gains more resource support than a piece of well-running code.
• Visual Beautification Masks Technical Debt
  In the PDD mode, if the system architecture looks symmetrical, decoupled, and modernized on PPT (e.g., forcibly applying concepts like Middle Platform or Microservices), the hard-coding or complex dependencies in the actual code are often ignored. PPT acts as a "beauty filter" for technical implementation.

In short, the core of PPT Driven Development lies in this: PPT is not merely a communication tool; it becomes the actual "contract" and "product." In the highly risk-averse and strictly hierarchical system of banks, the sense of certainty provided by PPT (even if illusory) is far more welcomed by management than the iterative trial and error in agile development.

Core Logic: Why Must Bank IT "Write PPTs"?

Many developers transitioning from big tech companies to banks often experience "culture shock": why is the time spent drawing architecture diagrams and writing reporting materials far greater than the time spent writing code? If one attributes this solely to "formalism" or bureaucracy, one often ignores the underlying business logic of bank IT operations. Unlike the "agile iteration" advocated by the internet industry, banks have an extremely low tolerance for error, and the positioning of the IT department is completely different.

Within the banking system, being "PPT-driven" is actually a survival mechanism to cope with structural constraints, primarily supported by the following three core logics:

1. The "Universal Currency" for Budget Acquisition and Cross-Departmental Communication
In the vast majority of bank organizational structures, the IT department belongs to the Cost Center rather than the Profit Center. Technical teams cannot directly prove value to non-technical executives (such as the Bank President or CFO) through code. To secure annual budgets or project approvals, obscure technical implementations must be "translated" into visualized business value, strategic planning, and ROI (Return on Investment) analysis. In this context, exquisite PPTs are the only "currency" for acquiring resources—without a PPT that passes the report, there is no budget; without a budget, no development work can be initiated.

2. Risk Aversion and the "Liability Exemption Contract"
Internet culture may encourage "Move Fast and Break Things," but in banks, stability overrides everything. As pointed out by industry observations regarding challenges in bank project management, although agile concepts are applied in the financial sector, given the security of customer funds and the strictness of regulatory scrutiny, necessary documentation, rigor, and discipline are key to project delivery. Detailed proposal reporting materials (PPTs) actually act as a "liability exemption contract" or "defensive documentation": when issues arise after a system launch, the architecture design diagrams that have passed through layers of approval serve as legal evidence that the team has fulfilled its duties, acting as a necessary shield against internal audits and external regulations.

3. Governance of Legacy System Complexity
Bank IT systems are often the product of decades of accumulation, where core transaction systems (Mainframes) are intricately interwoven with peripheral microservices and cloud-native applications. In this environment, any minor change can trigger a butterfly effect, so "trial-and-error" development is absolutely prohibited. Before touching core code, high-level architecture diagrams (PPTs) must be used to align the understanding of multiple departments such as risk, compliance, security, and business. Only after logical deduction is completed and consensus is reached on the PPT can coding begin in the physical world; this is a governance method that uses extremely low costs (modifying slides) to avoid extremely high costs (production incidents).

Project Initiation and Reporting: PPT Precedes Code

In internet companies, the starting point of a project is often a git init or a quickly built MVP (Minimum Viable Product), verifying market demand through rapid, small steps. But in the bank IT system, the logic is completely opposite: PPT is the stepping stone to resources and the sole proof of progress.

1. Project Initiation: Using PPT to Exchange for a "Birth Permit"

Inside a bank, no line of code can be legally submitted without a "project number". To get this number, the IT department must pass a complex "Project Initiation" (Lixiang) process.

This isn't just filling out a form, but requires producing a set of "Feasibility Study Reports" and "High-level Architecture Design Schemes". At this stage, PPT acts as a "Virtual MVP":

• Funding Application: Since bank IT is a cost center, every budget item needs approval from non-technical business leaders or the financial approval committee (IC meeting). PPTs must use exquisite charts to translate technical terms into "Business Value" and "ROI (Return on Investment)".
• Defining Rights and Responsibilities: As pointed out by Securities Times' observation, many banking practitioners reflect that "digital transformation cannot stay on PPTs", but in practice, PPTs are often the "contract" for cross-departmental collaboration. Before code is written, the architecture diagrams in the PPT must be signed off by the Risk Management Department, Compliance Department, and Operations Department to ensure the project's "political correctness" in terms of compliance and security.

2. Reporting Culture: The Game of Visibility

Once the project starts, the PPT-driven development characteristic shifts from "acquiring budget" to "proving existence". In the bank's massive organizational structure, senior management cannot judge project progress by checking GitHub commit records or Jira burndown charts.

Therefore, the quality of reporting materials directly equates to the quality of the project. This "reporting culture" leads to the following phenomena:

• Deviation in Progress Visualization: Weekly and Monthly Business Reviews (WBR/MBR) are the highlights of project management. Even if backend logic refactoring is complete, technical teams' workload is often ignored if they cannot draw beautiful "green light" progress bars or add new "business empowerment" modules on the PPT.
• Internal Friction of Formalism: To meet the reporting needs of leaders at different levels, technical teams often need to maintain multiple PPT versions—technical details for the Division Head, digital transformation visions for the Bank President.

Scenario Case: 3 Days Coding, 2 Days Making PPTs

Suppose a senior developer, Xiao Zhang, is responsible for developing a "credit approval automation" middleware function.
* Monday to Wednesday (3 days): Xiao Zhang completed core code writing and unit testing, conquering technical difficulties regarding data consistency.
* Thursday to Friday (2 days): For the Monday department meeting, Xiao Zhang must create a 15-page PPT. He needs to transform dry code logic into a "Smart Risk Control Panorama", replace simple sequence diagrams with high-end 3D architecture diagrams, and prepare to answer leadership questions about "how this function empowers retail business growth".

Ultimately, in performance appraisals, that PPT praised by leaders at the meeting often reflects Xiao Zhang's "work output" more than those 3 days of high-quality code.

Although this mode is criticized by frontline technical personnel as "digital formalism", under the bank's strict risk control system, it indeed serves to reduce communication ambiguity and establish accountability mechanisms. As mentioned in China Agricultural University's research on bank digital transformation, eliminating digital formalism is the goal, but in actual execution, how to balance the contradiction between "compliance records" and "agile delivery" remains a core pain point in bank project management.

"Visualizing Results" in Digital Transformation

In the massive bureaucratic system of banks, digital transformation often faces a fundamental contradiction: the disconnect between the complexity of engineering implementation and the abstract nature of management perception. For senior management responsible for strategic decisions, the refactoring of tens of millions of lines of code, millisecond-level optimization under high concurrency, or containerization are essentially "invisible." In this context, PPT-Driven Development (PDD) is not merely formalism, but a "translation mechanism" evolved by technical teams to survive and acquire resources.

"Visibility" is the Only Hard Currency

In big tech companies, a product's Daily Active Users (DAU) or conversion rates are direct "battle reports"; however, in bank software development centers, many core tasks (such as core system migration and middle platform construction) are of a backend support nature and lack direct market feedback.

Core Paradox: A perfectly running backend API interface is physically "invisible," but a screenshot of an architecture diagram depicting how this API empowers the business is "visible" in a PPT.

This visibility bias has made "result visualization" a core skill for technical leads. As pointed out by Securities Times, many banks frequently use terms like "Digitalization," "AI Agent," and "Large Model" in financial reports and strategic presentations. This pursuit of technical concepts requires technical teams to provide "milestones" that can be concretely displayed. In a PPT, a beautifully designed "bank-wide logical architecture diagram" is often more convincing to leadership that "digital transformation is happening" than a segment of robust code.

PPT as a Carrier of Abstract Achievements

In the project management ecosystem of banks, PPTs actually serve as a bridge connecting abstract technical achievements with specific KPI assessments. Senior leaders often lack the ability to review code, but they are proficient in reviewing flowcharts, risk matrices, and progress traffic lights.

• Transformation of Technical Debt: You cannot directly report "fixed 50 NullPointerExceptions," but you can show "System stability risk index reduced by 20%" in a PPT, accompanied by a downward trend line chart.
• Securing Resources: To obtain computing budgets or headcount, developers must first draw a grand "future state" blueprint. This mode of "drawing the pie before baking it" makes PPT conceptualization often precede actual development.

Caution: It is "PPT-Driven," Not "Data-Driven"

It is necessary to specifically clarify that PPT-Driven Development (PDD) is fundamentally different from true "Data-Driven Decision Making."

• Data-Driven: Decisions are based on real-time, automatically collected objective data; data guides action.
• PPT-Driven: Data often serves to corroborate the established PPT narrative logic.

In the PDD mode, data charts in slides are often the result of "manual curation." To meet reporting needs, data may not come from automatic scraping of real-time dashboards, but are static snapshots manually aggregated, cleaned, or even embellished via Excel and pasted into the PPT. While this approach satisfies management's psychological need for "digital control," it also plants the hidden danger of "reporting only good news" — as long as the red light on the PPT turns green, the project is considered a success, even if the underlying system still has logical loopholes.

Career Comparison: Internet Giants vs. Bank Software Development Centers

For many technical professionals considering moving from the internet industry to bank software development centers ("landing" a stable job), the biggest challenge is often not the technology itself, but the huge culture shock caused by different definitions of "deliverables." At internet giants, code is an asset; within the banking system, code is often viewed as a risk, while processes and documentation (especially PPTs) are the auditable assets.

To help job seekers adjust their expectations, we need to deeply analyze the essential differences between these two types of workplaces from three dimensions: core outputs, toolchains, and assessment logic.

Core Difference Dimensions Table

1. Misalignment of Output Definitions: Code vs. Visual Results

In internet thinking, a backend API is a result as long as it works and meets performance standards. But in the context of bank digital transformation, an "invisible" API is hard to define as a milestone.

As noted by Securities Times, although terms like "AI" and "Large Models" appear frequently in major bank financial reports, in actual implementation, to avoid the technical trap of "AI for AI's sake," management needs to see concrete results. This leads to the inevitability of "PPT-driven development": PPT is the only bridge connecting abstract technical implementation with management's strategic intent.

In bank software development, your output is not just code, but also reporting materials explaining "whether this budget was worth spending." An excellent architecture diagram that clearly shows fund flows, risk control nodes, and data security boundaries is often worth more than thousands of lines of unexplained Python code.

2. Toolchain Downgrade: Skill Restructuring for Tech Leads

Many senior developers (Tech Leads) moving from big tech to banks often feel a frustration of "skills having no place to be used." At internet companies, a Tech Lead's time allocation might be 40% writing core code, 30% architecture design, and 30% team management. In a bank, this ratio might become:

• 50% Creating Reporting Materials (PPT/Word): Explaining requirements to business departments, security to risk departments, and progress to leadership.
• 30% Coordinating Processes: Handling cross-department approvals, resource applications, and outsourcing management in the OA system.
• 20% Technical Control: Mainly reviewing the code quality of outsourcing vendors or the compliance of architectural designs, rather than coding personally.

This change requires job seekers to possess "bilingual ability": understanding technical principles while being able to translate them into "risk management" or "cost reduction and efficiency increase" language that management understands. If you are only proficient in Java or Go but are not good at using Visio or PowerPoint to draw high-fidelity business process maps, your career advancement path within the banking system may be obstructed.

3. Assessment Logic: From "Data-Driven" to "Reporting-Driven"

At internet giants, if a service crash leads to user loss, the data will be directly reflected in OKRs. But in banks, since many core systems are implemented by outsourcing teams, the core duty of bank personnel shifts to management and supervision.

The focus of assessment often lies in whether you can clearly define requirement boundaries and complete project node reports on time and with quality. This means that an employee who can package complex Technical Debt as a "System Robustness Upgrade Plan" and display it via traffic light charts in a PPT often receives higher performance ratings than an employee who silently fixes bugs but is not articulate.

Advice for Job Seekers: If you enjoy the pure pleasure of coding and pursue extreme tech stack updates, bank software development might make you feel a sense of constraint due to "insufficient natural endowment" (as described by Securities Times regarding the status of system construction in small and medium-sized banks); but if you excel at macro architecture design, process sorting, and cross-department communication, this will be the best place to exercise your "technical politics."

Survival Guide: How Technical Professionals Can Break Through in a PPT Culture?

For many technical professionals accustomed to "letting the code speak," entering a bank's software development center or technology department often involves a culture shock: here, a line of elegant code may go unnoticed, but an exquisite architecture evolution diagram can determine the life or death of a project. Instead of consuming your passion in complaints, it is better to view this as a special "workplace survival protocol." In this environment, PPT is not just a presentation tool, but a core deliverable for technical personnel to acquire resources, avoid risks, and manage upwards.

Here are three specific breakthrough strategies to help you maintain your technical identity while meeting the requirements of "PPT-Driven Development."

1. Build a Reusable "Visual Asset Library" (Template Mastery)

In the banking system, reporting is often highly repetitive (project initiation, milestones, production review). Efficient survivors do not draw from scratch every time but establish a set of standardized visual assets.

• Layered Architecture Template: Prepare a "logical architecture diagram" template that meets internal standards, including the access layer, business middle platform, data layer, and infrastructure layer. No matter how the project changes, the underlying Visio or Archimate models can remain consistent; you only need to fine-tune the highlighting of business modules in the PPT.
• Data Flow Components: Banking systems place extreme importance on data consistency and regulatory compliance. Pre-designing a set of clear "fund flow" and "information flow" diagram components (e.g., arrows with locks representing encrypted transmission, dotted lines representing asynchronous reconciliation) can significantly improve the professionalism of documents.
• Toolchain Integration: Do not attempt to align every pixel using PowerPoint's built-in drawing tools. Proficiently use Visio or Draw.io to draw source files and import them into PPT in high-vector formats. Remember, in the eyes of leaders, a rigorously laid-out topology diagram is often equivalent to "rigorous system design."

2. Master "Tech-to-Business" Translation Skills (Translation Skills)

The biggest mistake in reporting is trying to explain technical details like "microservice splitting" or "code refactoring" to non-technical managers. In the banking context, you need to translate technical terms into the language of risk and cost.

• Technical Debt $\rightarrow$ Operational Risk: Don't say "the code is too messy and needs refactoring"; show the "SLA breach risk under high concurrency scenarios like Double 11" on the PPT, and cite compliance and risk review requirements in bank project management as an endorsement.
• Version Upgrade $\rightarrow$ Asset Preservation: Describe middleware upgrades as necessary measures to "eliminate security vulnerabilities and meet regulatory audit requirements," rather than simply chasing new technology.
• Quantify Benefits: Learn to speak with numbers. If ROI (Return on Investment) cannot be directly calculated, at least list the reduction in TCO (Total Cost of Ownership) or the percentage reduction in failure response time.

3. Execute a "Dual Core" Career Development Strategy (The 'Dual Core' Approach)

This is the most critical survival advice. Banks often use closed development platforms, outdated technology stacks, or highly customized frameworks; long-term immersion can easily lead to the degeneration of general technical abilities (Skill Atrophy).

• Public Cloud vs. Private Cloud: At work, you may have to master the complex private cloud deployment processes and PPT reporting logic within the bank (this is your "inner core," used to keep your job and get promoted); but in your spare time, you must maintain attention to mainstream public cloud technologies (AWS/Azure), containerization (K8s), and the open-source community (this is your "outer core," used to maintain market competitiveness).
• Code Desensitization Review: Even if you spend most of your time writing documents at work, develop the habit of regularly reviewing core code logic. Try to mentally deduct and refactor the business complexity problems encountered at work using mainstream technology stacks (such as Go or Rust).
• Avoid Tool Dependency: Do not rely solely on the internal OA or approval flow systems. Maintain sensitivity to general efficiency tools (such as Jira, GitLab CI/CD); even if not used internally, understand the engineering philosophy behind them.

Takeaway: Doing technical work in a bank, making PPTs is not a compromise, but an encapsulation. You are using PPT to encapsulate underlying technical complexity, providing a simple, visual interface (Interface) for the decision-making layer. Once you master the right to define this interface, you also master the initiative in technical implementation.