Stories from the field - how I've helped organizations scale teams, build systems, and make better decisions.
A digital bank in rapid growth hired new developers every week. The team grew from 30 to 150 engineers. On paper, recruiting was a success. In practice, new employees arrived and disappeared into the organization. No structured onboarding, no learning plans, no pre-start communication. New hires wrote short-term code because they didn't understand business needs. And eventually, they left.
Improving communication with new hires before day one - making them feel expected and prepared with a buddy, a clear agenda, and zero first-day anxiety.
Working with IT to create role-specific profiles. Laptops arrive pre-configured. A checklist replaces chasing people around.
Guiding team leads on building two-week plans. Buddy sessions, recorded onboarding, and real quick wins - like fixing a log entry and deploying to production in week one.
Bi-monthly rooftop events where new hires helped organize - building cross-team connections that hold during tough times.
Result: Retention improved significantly. New hires became productive faster. Code quality improved because developers arrived with business understanding. Team leads received a clear framework instead of reinventing the wheel.
The principle: Onboarding is not a one-day event. It's a journey from contract signing to full integration. Companies that scale headcount without scaling absorption capacity are filling a leaky bucket.
Building an entire banking infrastructure from scratch. Customer onboarding, loan approvals, credit scoring - all under strict regulation. The real challenge wasn't technological. It was organizational: data was the central asset and everyone wanted it - support, analysts, product, credit officers, operations, BI.
Selecting tools that integrate well and have strong documentation. Good docs mean self-sufficient teams, lower vendor costs, and no single-person dependencies.
No time for refactoring. The system had to be secure, fast, compliant, and valuable from version one. Strong architecture that allows adding and removing integrations easily.
Heavy investment in automation. Result: deploying a new version to production within 15 minutes - not by skipping tests, but because testing was so robust it gave full confidence.
A mechanism allowing analysts to define approval criteria without code - turning what required a dev sprint into a business operation that took hours.
Result: 500K+ loan requests processed for 100K+ customers. Architecture that enabled easy integration. 15-minute deployments. Business autonomy that reduced dev dependency. Regulatory processes that withstood audit.
The principle: When building regulated infrastructure, there are no compromises on architecture. "We'll fix it later" doesn't work under regulation. The investment in building right from day one is what enables speed later.
A fintech company of 4 people providing services to nearly half the investment firms and banks in the market. Not a story about hard work and long hours - a story about architecture and engineering discipline.
This is what allowed 4 people to do the work of 40. Not harder work - smarter work. Every hour invested in proper architecture saved dozens of hours down the road.
Result: A 4-person company serving half an industry. Adding new integrations in days instead of months. Near-zero downtime. Architecture as a competitive advantage.
The principle: Real speed over time comes from building correctly. Investment in infrastructure, standards, and engineering discipline isn't a luxury - it's what allows a small team to compete with giants.
Developers receive tasks, implement them, move on. They know what to build but not why. They understand the API but not the business model behind it. This isn't a personal failure - it's a systemic one.
They build generic interfaces for future data sources from day one. They design separation between business logic and code. They build synchronization mechanisms rather than point solutions. Business understanding doesn't replace technical skill - it multiplies it.
Structural accessibility of business knowledge: onboarding that includes business context, direct access to customers and data, product discussions that include developers - not just update them on outcomes.
The principle: A developer who understands the business doesn't just write better code - they make better architectural decisions. The "business vs. tech" gap isn't a communication problem - it's an organizational architecture problem.
"We'll build fast now, fix it later." But "later" never comes. And if it does, it arrives as a massive, expensive refactoring that freezes development for months.
Every line that enters the system is a line that will stay. Writing code with the intention of replacing it is writing technical debt deliberately.
A small improvement today is an hour of work. The same improvement six months later with 15 integrations and 50 developers - that's an entire sprint.
When there are few integrations and dependencies, the change is simpler, the risk lower, the cost orders of magnitude less.
Not something you add later. Every component independent, with clear interfaces and minimal dependencies from day one.
Result: A 4-person company serving half an industry. A bank deploying in 15 minutes. Teams adding integrations in days. In every case, the investment was upfront - not after the fact.
The principle: Big refactoring isn't a solution - it's a symptom. Plan far ahead, execute in small steps, improve continuously. That prevents the need for a "revolution" in the first place.
A fintech company at a turning point. Business growth had been consistent - expanding customer base, rising revenues, a growing team - but what once worked almost by itself was becoming increasingly dependent on individual effort. The company knew it needed to grow, but didn't know where the cracks were.
The company was in the "Creativity" stage - fast decisions, direct communication, founders who hold everything in their heads. Highly efficient at the beginning, problematic as you grow.
Analysis indicated the company was approaching the "Crisis of Leadership" - where growth slows not because the product is bad, but because the organizational structure wasn't designed for its new size.
Using BJ Fogg's Behavior Model (B=MAP): behavior requires motivation, ability, and a prompt. Clear gaps were found in Ability - processes too cumbersome, information not accessible, responsibility too spread out. The feeling of "everyone wants to improve, but nothing moves" is not a motivation problem - it's an Ability and Prompt problem.
Result: Comprehensive report delivered with gap map, priorities by urgency, three-phase action plan, and detailed work procedures for Phase 1 - all ready for execution, not for filing. "Blitz Days" methodology adopted for cross-functional decisions that normally take weeks.
The principle: Diagnosis alone isn't enough. The real gap is between understanding and execution. Greiner's model enables precise diagnosis. B=MAP enables designing recommendations that real people can actually execute - not just approve in a meeting and forget.
An adtech company in a fast-moving, data-intensive market. Teams needed answers faster than engineering could deliver. The typical pattern: file a ticket, wait weeks, get a partial solution, build a workaround in spreadsheets. Most operational work happened outside the actual systems.
Reusable components: standardized data connectors, shared UI patterns, common auth layers, and pre-built templates for dashboards, workflow tools, data entry forms, and approval flows. The second tool takes 30% of the time the first did. The tenth takes 10%.
A lightweight CI/CD pipeline for internal apps. Not the heavyweight customer-facing process, but not cowboy deployments either. Automated testing, staged rollouts, easy rollback. Deploy in hours, not weeks.
Structured autonomy: teams configure and deploy using standardized blocks within security guardrails. They own the "what" and "when." Engineering owns the "how" and "where."
Result: Teams deploy internal tools in days instead of months. Operational bottlenecks become self-service. Data locked in systems becomes accessible. Spreadsheet processes become automated workflows. Each new tool reduces load on the next team.
The principle: The bottleneck isn't engineering talent - it's the absence of infrastructure that lets non-engineering teams move at engineering speed. A reusable internal tooling layer turns every team from a consumer of engineering capacity into a producer of operational solutions.
The path from "PM has an idea" to "code is live" is messy. Requirements written in one format, interpreted differently by developers, built in a way that doesn't match intent, tested against wrong criteria. No traceable flow where every handoff is explicit and every rejection path defined.
PM articulates the idea with full context: problem, audience, business case, expected impact. Gate: PM self-review. If not worth pursuing - killed before any engineering time is spent.
PM writes a user story with specific, testable acceptance criteria - the contract between product and engineering. Gate: developer reviews for feasibility. Can reject with a reason, alternative, and complexity estimate.
Implementation based on agreed spec. Gate: code review by a peer for quality, security, performance, and architecture adherence.
Automated testing: unit, integration, regression. Gate: all tests pass. No manual overrides, no "fix it next sprint."
PM validates that what was built matches what was specified. Gate: PM approval with structured, actionable feedback if rejected - not ambiguous "doesn't feel right."
Production deployment with post-deploy monitoring, alerts, and logging.
Cost of rejection increases at every stage. A rejected idea at Stage 1 costs nothing. A rejected deployment at Stage 5 costs a full dev cycle. The workflow pushes rejections as early as possible - where they're cheap.
Result: Less rework, less frustration, code that matches business intent the first time. Every handoff explicit, every rejection with a reason and a path forward. PM knows when to engage. Developer knows what "done" means.
The principle: The gap between product and engineering isn't a people problem - it's a process problem. When the path from user story to production is explicit, traceable, and has defined rejection paths at every stage, both sides know what to expect.
Let's talk about what's slowing your organization down and how to fix it.