Praveen Yadav

Over more than a decade at Wells Fargo, my role has evolved from hands-on application engineering into a broader technology leadership position spanning solution architecture, application ownership, delivery leadership, production governance, modernization, people management and Generative AI.

Today, I operate across multiple enterprise applications as an Application Owner and Alternate Technical Manager, working with distributed India–US teams and leading through a combination of technical depth, delivery accountability and people leadership.

My responsibility goes well beyond getting software built. I work across the full lifecycle of enterprise platforms — shaping architecture, developing technology roadmaps, planning delivery, managing technical and operational risk, coordinating stakeholders, developing engineers and remaining accountable for systems after they reach production.

Engineering Leadership & People Management

A significant part of my role is leading engineering teams rather than simply leading implementations.

I work across direct and matrix structures involving approximately 20+ engineers, with responsibilities spanning delivery planning, capacity and resource coordination, mentoring, technical guidance, hiring, technical interviews, capability development and helping engineers progress toward greater ownership.

I spend considerable time working with engineers on the thinking behind the code — architecture choices, implementation trade-offs, production considerations, engineering standards and how to approach difficult problems independently.

My leadership approach is centered on building teams that can operate with less dependency on individual experts: engineers who understand the business context, challenge technical decisions constructively, own their systems and remain accountable for production outcomes.

Application Ownership & Delivery

As an Application Owner, my responsibility extends beyond an individual project or release.

I help shape and govern:

• Technology roadmaps
• Engineering priorities
• Delivery planning
• Capacity and resource management
• Solution architecture
• Modernization strategy
• Technical-debt reduction
• Release and change governance
• Production stability
• Vulnerability and risk remediation
• Business continuity
• Incident management
• Stakeholder communication
• Cross-team dependencies
• Engineering capability development

The role requires balancing engineering ambition with the realities of large financial-services environments — security, regulatory expectations, operational risk, resilience, release controls, business priorities and long-lived technology estates.

It has given me experience operating across the complete chain: Business → Architecture → Engineering → Delivery → Production — rather than treating those as separate disciplines.

Corporate & Investment Banking Experience

For roughly three years at Wells Fargo, I worked within technology supporting the Corporate & Investment Banking organization, adding another dimension to my banking-domain experience.

Working in a CIB technology environment exposed me to the operational rigor required around business-critical institutional banking systems, where reliability, security, data integrity, resilience, auditability and controlled production change are fundamental engineering expectations.

That experience strengthened my understanding of how technology decisions operate within highly regulated financial environments. Architecture is not evaluated purely on whether a solution functions technically; it must also account for operational risk, controls, security boundaries, recoverability, production governance and long-term maintainability.

It also reinforced the importance of understanding the business process behind a system before designing the technology around it — an approach that has continued to influence my work across enterprise architecture, application ownership and AI.

MDT — From India Collocation to End-to-End Engineering Ownership

One of the defining transitions in my Wells Fargo career was leading the 2021 collocation of MDT engineering and production support to India.

MDT is an enterprise reverse-logistics platform supporting monitored technology-asset disposal processes.

The transition established MDT as the first EFT line-of-business application to be engineered and supported end-to-end from India.

My responsibility went far beyond transferring work between locations. It evolved into long-term ownership across:

• Solution architecture
• Engineering roadmap
• Modernization
• Technical debt reduction
• Enterprise integrations
• Delivery
• Production governance
• Risk management
• Team capability

The platform evolved from a more traditional ASP.NET architecture toward modern .NET Core and API-driven engineering, supported by SQL Server, Azure, APIGEE and enterprise integration services.

I also led improvements to enterprise data integrations, including simplifying data flows and reducing unnecessary intermediate processing.

For me, MDT became a strong example of what long-term engineering ownership means: not simply shipping releases, but continuously improving the architecture, operating model, delivery capability and engineering organization surrounding the platform.

Enterprise Architecture & Integration

A substantial part of my work has involved systems that operate across multiple enterprise platforms rather than inside a single application boundary.

I have architected and led integrations involving:

.NET Core · REST APIs · Kafka · OpenShift · Azure · SQL Server · SSIS · APIGEE · ServiceNow · Splunk · CI/CD platforms

These solutions require decisions around more than data movement.

They involve:

• API boundaries
• Authentication and authorization
• Event-driven versus synchronous communication
• Data contracts
• Reliability
• Retry and failure strategies
• Observability
• Security controls
• Scalability
• Deployment architecture
• Operational ownership

One example is the ICMP–KEES enterprise integration, providing controlled document upload and retrieval workflows between ServiceNow and internal enterprise systems through APIs, event-driven processing and secure document-handling services.

I have also worked across the SACM Common Services ecosystem, spanning .NET and Java services, Kafka, OpenShift, SQL Server and enterprise API infrastructure.

Work of this nature progressively shifted my perspective from individual application development toward solution architecture across interconnected enterprise ecosystems.

Modernization & Cloud Transformation

Modernization has been a recurring part of my responsibility.

Across different applications and shared services, I have led or contributed to initiatives involving:

• Legacy-to-.NET Core modernization
• API-first architecture
• Azure public-cloud adoption
• SQL Managed Instance migration
• PCF-to-OpenShift migration
• CI/CD modernization
• Enterprise API integration
• Event-driven architecture
• Reduction of manual operational processes
• Production and support-model improvements

Across modernization, automation and process-improvement initiatives, solutions I have led or contributed to have generated $250K+ in annual savings.

Several opportunities were self-identified rather than arriving as formally funded projects — including operational problems affecting business teams with limited or no dedicated development support.

That ability to identify a business or operational constraint, quantify the problem and turn it into an engineering solution has become an important part of how I approach technology leadership.

Generative AI & Agentic AI

The latest phase of my work has expanded strongly into production Generative AI and Agentic AI.

My interest is not in adding conversational interfaces to applications simply because LLMs are available.

I focus on situations where AI can become part of a real enterprise workflow — reasoning over information, retrieving enterprise knowledge, invoking tools, recommending actions, orchestrating activities and operating within explicit deterministic controls and human oversight.

GENIE AI

I spearheaded GENIE AI, an AI-driven coordination and administrative automation platform supporting MDT reverse-logistics operations.

The architecture brings together concepts including:

• LLM orchestration
• Retrieval-Augmented Generation
• Enterprise knowledge retrieval
• Tool and API integration
• Agentic workflows
• Workflow automation
• Microsoft Teams and Graph integration
• Human-in-the-loop controls
• Deterministic guardrails around AI decisions and actions

The objective is to automate a substantial portion of coordination and administrative activity that previously depended heavily on manual effort.

The initiative is projected to reduce operational effort by approximately 70% across the affected reverse-logistics team.

What matters to me about GENIE is not simply the presence of an LLM.

It represents the transition from AI as something that generates text to AI as a controlled participant in an enterprise workflow — while ensuring that deterministic systems and humans retain authority over decisions where correctness, security or accountability cannot be delegated to a probabilistic model.

Generative AI Engineering Recommendation Platform

I also led work on an internal Generative AI recommendation platform supporting infrastructure migration analysis and engineering decision-making.

The platform analyzes enterprise infrastructure and workload information and uses AI to assist engineers in identifying opportunities, evaluating candidates and making better-informed technical decisions.

The initiative contributed to approximately 11,000 engineering hours of effort savings, representing an estimated value of roughly $660K.

The solution combined enterprise data, retrieval, AI reasoning, recommendation logic and a modern application architecture.

The experience reinforced one of the principles that now shapes how I design AI systems:

Use LLMs where reasoning creates value. Keep deterministic systems in control where correctness, authorization, governance and accountability matter.

AI-Assisted Engineering at Scale

Alongside architecting AI solutions, I am also focused on the broader transformation AI is creating inside engineering organizations.

That includes embedding AI-assisted development across activities such as:

• Requirements analysis
• Solution exploration
• Coding
• Refactoring
• Unit-test generation
• Troubleshooting
• Documentation
• Architecture analysis
• Engineering decision support

But enterprise AI adoption is as much a people and operating-model transformation as it is a technology transformation.

Teams need to understand how to provide context effectively, review AI-generated output critically, detect weak reasoning or hallucination, maintain secure development practices, define appropriate human approval points and remain accountable for software regardless of how much of it was AI-assisted.

That is where my architecture and people-leadership responsibilities converge.

My focus is increasingly on enabling enterprises to adopt and scale AI across technology and operations — architecting production Generative AI and Agentic AI solutions, building AI-powered enterprise platforms, embedding AI-assisted development across engineering organizations and developing the teams and practices required to make that transformation sustainable.

I started my professional career at DSRC as a Trainee Programmer in 2010 and progressed over the next five years through increasingly senior engineering responsibilities, ultimately becoming a Senior Developer.

Those five years provided the engineering foundation for everything that followed.

I worked across web and desktop applications using C#, ASP.NET, SQL Server, JavaScript, WCF, WPF and DevExpress, across projects spanning multiple business domains.

But DSRC gave me considerably more than technology exposure.

Learning End-to-End Engineering

My earliest responsibilities were straightforward: understand a requirement and implement it correctly.

That scope expanded quickly.

I became involved across the complete development lifecycle: Requirements → Design → Development → Database → Testing → UAT → Release → Production Support

I worked directly with customers during requirements discussions, clarification, demonstrations, UAT and production issue resolution.

That experience taught me early that software engineering is ultimately about solving a business problem — not merely implementing whatever happens to be written in a specification.

As my experience grew, I began owning complete application modules rather than individual tasks.

With that ownership came responsibility for design decisions, database performance, troubleshooting, customer communication, releases and ensuring that problems were genuinely resolved rather than simply handed to somebody else.

Growing from Programmer to Go-To Engineer

Over time, I became one of the engineers colleagues and project teams regularly approached when they needed help solving a difficult technical problem or stabilizing a delivery.

I was consistently recognized as a strong performer and progressively trusted with larger modules, more complex technical work and greater client-facing responsibility.

The progression from Trainee Programmer to Senior Developer therefore represented more than a sequence of titles. It was a change from:

“Tell me what to implement.”
to
“Give me the problem — I’ll work out how we should solve it.”

Mentoring Junior Engineers

As I became more experienced, helping junior developers became a natural part of my role.

I spent significant time:

• Reviewing code
• Debugging problems alongside developers
• Explaining technical concepts
• Reviewing application and database approaches
• Helping engineers understand C#/.NET fundamentals
• Discussing alternative implementations
• Supporting developers during challenging deliveries

I learned that providing somebody with an answer fixes one problem. Teaching them how to arrive at the answer makes the whole engineering team stronger.

That principle continues to influence how I lead teams today.

Technical Interviewing & Hiring

I also became heavily involved in technical interviewing and developer hiring.

Over time, I conducted a large number of interviews covering:

• C#
• .NET
• SQL
• Object-oriented programming
• Application development
• Problem-solving
• Engineering fundamentals

Repeated interviewing taught me that technical capability is not simply the number of questions somebody can answer from memory.

I learned to evaluate how candidates think — how they approach unfamiliar problems, whether they understand fundamentals, whether they can explain their decisions and how they respond when they do not immediately know an answer.

In practice, DSRC gave me significant exposure to technical talent assessment, mentoring and capability development years before people management became part of my formal responsibilities.

What DSRC Gave Me

By the time I left DSRC in 2015, I had moved from someone learning professional software development to an engineer capable of: owning application modules · working directly with customers · solving production problems · mentoring developers · interviewing engineers · and taking responsibility for complete delivery outcomes

That foundation made the transition into large-scale banking technology possible — and many of the engineering and leadership principles I use today were formed during those first five years.