Servant Leadership
Servant leadership is not a philosophy I subscribe to. It's the operating system that runs beneath every team I build, every initiative I lead, and every decision I make. At Successware, the org grew 80% in 9 months while retention materially improved - autonomy with accountability is what scaled the platform, not headcount budget.
Being a servant leader means intentionally listening more than I speak. It means creating psychological safety so engineers can propose bold ideas, respectfully challenge the status quo, and recover from failure without fear. I prioritize one-on-ones, not as status updates, but as spaces for mentorship, coaching, and career growth. I view my success through the lens of team success--velocity, code quality, innovation, and, most importantly, the well-being of the people writing the code.
Over the years, I've consistently seen that when engineers feel heard, trusted, and supported, performance soars. It's how I transformed underperforming teams into high-functioning units that take pride in delivering world-class software. I empower through context, not control--providing the 'why' behind every decision so that teams can own the 'how.' This approach doesn't just yield better software; it creates more invested, resilient, and motivated people. And at the end of the day, people build platforms--not the other way around.
Manager vs. Leader
This explains the difference between operational management and product leadership.
The Restaurant Owner vs. The Head Chef
Expert in the kitchen (the codebase)
Responsible for quality of every dish (feature)
Manages line cooks (engineers) directly
Ensures immediate execution is flawless
Focuses on the "what" and "how" of the current sprint
Handles daily operations and task assignments
Measures success by delivery speed and quality
Solves immediate problems and removes blockers
The Restaurant Owner (Leader)
Thinks about the entire business and is concerned with:
The Menu: Product roadmap and customer needs
The Ambiance: Team culture and developer experience
The Supply Chain: Technical debt and tooling investment
The Customers: Solving the right problems for users
The Staff: Team happiness, growth, and effectiveness
What Makes a Great Engineering Leader
A great engineering leader connects the team's day-to-day work to the larger business context. They ensure the team isn't just "cooking" efficiently but is cooking the right food for the right customers in a sustainable way. They balance tactical execution with strategic vision, ensuring both immediate delivery and long-term success.
AI-Native Engineering Organization
At hc1, I built an AI-native engineering organization from the ground up - not by bolting AI onto existing workflows, but by rethinking how software gets built, tested, and shipped. GitHub Actions, Claude Code, Copilot, and AWS Kiro now drive code generation, test synthesis, cloud architecture scaffolding, and documentation as first-class CI/CD pipeline stages.
The toolchain is deliberate and multi-model by design - Kiro, Claude, Copilot, Gemini, and Snowflake Cortex - so teams develop fluency across platforms with no single-vendor dependency. Each tool has a purpose: Copilot for inline assistance, Claude Code for architecture and complex refactoring, Kiro for cloud-native workflows, Gemini Gems for non-technical productivity. Prompt throughput is tracked as a leading indicator alongside delivery and quality metrics.
The shift was deliberate, not opportunistic - rolled out in waves: engineering and data first, then DevOps, Integrations, Professional Services, Product, and HR. To stress-test the toolkit on real problems, I organized hc1's first AI Hackathon as a Q2 organizational rock - explicit permission for engineers to step off the sprint and attack a problem that mattered. Rolling Show & Tell sessions converted individual experiments into shared playbooks.
Partnering with the CPO on greenfield agentic AI. Source IQ is an agentic supply chain intelligence platform combining contract performance with utilization analytics on Python FastAPI and vLLM (Qwen3.6-27B), consolidated late-stage from a hybrid Java + Python stack. Clinical IQ is a clinical intelligence SaaS with direct Epic EMR integration via HL7/FHIR on HIPAA-compliant AWS, surfacing AI-detected patterns and lab/test recommendations to close care gaps and support earlier intervention. This includes MCP (Model Context Protocol) for production AI integration, A2A Protocol for multi-agent communication, and context-as-infrastructure methodology using AGENTS.md and CLAUDE.md files.
AI governance is not optional. Agent SLOs, audit trails, and responsible adoption with proper safeguards. The results: 5x deploy frequency, 23% PR throughput gain, code coverage from under 10% to 40%, and a 70% reduction in new-engineer onboarding time. Quality ownership is shared across Engineering, Product, and Services - no dedicated QA team - with Playwright smoke + regression and SonarQube quality gates enforced in CI/CD.
My focus is improving Developer Experience and reducing flow friction. Whether accelerating MVP development, using AI for smarter testing, or auto-generating documentation, the goal is the same: ship smarter, not just faster. Read more about my AI Philosophy at RJL.ai.
Private Equity & High-Growth Leadership
I have led technology organizations within PE-backed companies where speed, efficiency, and measurable value creation are non-negotiable. My experience includes post-acquisition technology assessments using 30-60 day evaluation frameworks, building value creation roadmaps tied to EBITDA impact, and delivering board-ready reporting that connects engineering investment to business outcomes. I understand the PE playbook: reduce cost, increase velocity, de-risk the platform, and position the technology org as a value driver--not a cost center. From M&A due diligence to exit readiness, I bring the strategic and operational rigor that PE-backed environments demand.
Product Management Partnership
I don't just partner with product management - I challenge and elevate it. Too often engineering is treated as a delivery mechanism, handed a list of features and told to execute. I reject that model. When I sit down with product leaders, I don't ask, "What do you need built?" I ask, "What problem are we solving, for whom, and why now?" That question resets the dynamic.
Through this model, we prioritize with purpose - vetting ideas through business value, technical feasibility, and user impact. Engineering moves upstream into product discovery; product joins sprint reviews. Shared accountability. We make space for experimentation, rapid prototyping, and feedback loops to validate hypotheses before committing engineering resources.
Strategic Insight
Vision tied to outcomes. At Successware, I presented architecture and investment cases directly to PE advisors and the C-suite; secured approval and offshore investment for a React Native mobile platform delivered on schedule and within budget.
Distributed by design. The last 13+ years leading geographically distributed teams - onshore, nearshore, and offshore - under a single delivery model that cut hand-off friction and unified mobile, data, and backend telemetry. At Successware, MTTR dropped 30% under unified Datadog/Splunk standards.
Quality and reliability as non-negotiables. Every initiative measured against SLA. Successware ran at sub-second response for 10k concurrent users at 99.95% SLA; hc1 went from reactive firefighting to executive-visible CloudWatch + PagerDuty + Grafana dashboards delivering uptime and platform health metrics for the first time.
Player-Coach
I refuse to step entirely away from the keyboard. I still spin up local dev servers, write vanilla JavaScript, build my own utilities, and prototype solutions alongside my teams. This is not nostalgia - it is how I maintain the technical credibility that earns respect from senior engineers and architects. Leaders who collaborate directly with developers are better equipped to anticipate risks, bottlenecks, and quality concerns before they escalate. I can review a complex pull request in the morning and present a budget proposal to the board in the afternoon.
Player-coach for me means PR review, architectural review, platform modernization, and process design - not 50% feature delivery. I will code up to 30% when the work calls for it. I am past the career stage where coding tests are useful screening signal.
Deep Technical Expertise
Even when my title says Director or VP, my function often mirrors a Chief Architect. I possess the broad technical vocabulary required to design an entire ecosystem - conceptualizing how a modern frontend, a legacy backend, and a new AI prompt library will communicate, then guiding the specialists who write the bulk of the code. My expertise spans cloud-native architectures, distributed systems, data security, and full-stack SaaS development. At hc1 I'm leading the AWS-partnership build for the Epic EMR integration and serving as an early-adopter design partner for AWS Kiro pre-GA - bringing external partner muscle and pre-GA tooling into the platform roadmap.
Pragmatic Technologist
13 years as an IC and 20+ years of leadership across HealthTech, EdTech, and regulated B2B SaaS - long enough to have survived enough hype cycles to know that the right tool for the job is the only sustainable approach. I am language-agnostic by necessity and by conviction. I care about the business outcome, the system architecture, and the deployment strategy far more than being dogmatic about a specific programming language or framework. When you combine this philosophy with executive responsibilities and a deep focus on artificial intelligence, you get someone who does not just manage teams--I understand how to orchestrate AI tools, evaluate emerging platforms, and make pragmatic build-versus-buy decisions that stand up to scrutiny. Every technology choice I make is grounded in what ships, what scales, and what the business actually needs.
Summary
Professional Experience
Leadership Profile
Key Capabilities
Measuring the Success of Engineering Teams
What I'm Built For