How I Mentor and Contribute

Overview

I work with two teams at Vanguard FAS: the team behind the AXS design system and the team behind Expert Insights. Mentoring and contribution are continuous and overlapping for me, I write code alongside the engineers I work with, and the mentoring shows up as much in PR reviews and pairing sessions as in 1:1s. This is how I think about both.

The through-line under everything below: I’d rather build the system that teaches the pattern than have the same conversation twice.

Part I, How I mentor

How I calibrate

How I work with each engineer depends on where they are in their career arc, not on a generic template. The voice I use changes; the structure of the feedback doesn’t.

With newer engineers, my opening move is genuine recognition with specificity, “you’re technically strong, you show up in discussions”, followed by a behavioral gap statement (not a character assessment), then a close with expressed belief: “the talent is there; I need the discipline to match it.” No cruelty, no hedging. The hard thing is said directly, once, clearly.

With mid-level engineers, the most useful thing I can do is invite them into the actual problem-solving rather than receive the problem from them. The ask I tend to make is explicit: “help me think through how we staff this, how we prioritize, where we can create leverage, don’t just flag the problem.” I pair the invitation with scaffolding, named collaboration, protected time, direct coaching on confidence where needed.

With senior engineers and tech leads, the conversation turns outward. The patterns and architectural guidance they’ve developed have broader value than the team they sit on; the growth move is to make those patterns visible, reusable frameworks, demos, architectural notes for other teams. “You don’t need to wait for a formal venue; start creating them.”

With peer leaders, the framing is honest diagnosis as an equal. I’ll name systemic patterns, breadth diluting impact, speed without architectural grounding, narrative updates where decisions should be forced, and name the structural fix without softening it.

The shape of the feedback

Every piece of substantive feedback I write follows the same underlying structure:

1. Genuine, specific recognition of what is working.
2. The growth edge, stated as a behavioral or strategic gap, not a judgment.
3. A concrete path forward with expressed belief that it’s achievable.

Acknowledgment and challenge are always paired. The pairing is deliberate: “I set a high bar intentionally because I believe in the team.”

Teaching through infrastructure

This is the most distinctive part of how I work. I don’t rely on repeated conversations to enforce standards. I build the infrastructure that makes the correct pattern the default path.

On AXS, migrating a V0 component to V1 means reading the architecture docs, consulting accessibility patterns, applying composable APIs correctly, and following a slot-over-props philosophy, a multi-step discipline that’s easy to skip under deadline pressure. So I encoded the entire workflow as a structured Claude Code skill (/build-v1) that mandates reading the architecture and a11y docs before any code is written. The standard is no longer carried in a person’s head or enforced in code review after the fact. It runs before the first line of code.

Same idea on documentation quality. Rather than “we should write better docs,” the team has a /test-docs skill that simulates a fresh agent session, follows the exact discovery path, and produces a Pass/Partial/Fail checklist with a percentage. Doc quality stopped being a gut feel and started being a tracked metric.

Mentoring at scale, for me, is this: build the system that teaches the pattern, then we all use it.

Part II, How I contribute code

Platform-first, reusability-first

I evaluate technical work through the lens of compounding value. A contribution that works once is table stakes. A contribution that works for the next three teams is what I name out loud when I see it:

Your data-visualization content-fragment architecture dramatically reduced hard-coded content and created a reusable data pipeline that’s the foundation for all future content-fragment implementations. That’s the kind of forward-thinking architecture I want more of.

When I review my own work, the standard is the same: I push for designs that support progressive phases without requiring a rewrite at each stage. Future-proofing isn’t speculative scope, it’s how I think about whether a design will still be useful three years from now.

Clean baselines before evolution

I don’t ship new capabilities on top of technical debt when I can avoid it. On AXS, the V0-to-V1 conversion backlog was executed as a disciplined prerequisite to the V3 architectural work, the right call to prevent adoption fragmentation and long-term friction for consumers.

The pattern: establish a clean baseline, then build forward. Not because debt cleanup is interesting, but because it’s what makes the next thing survivable.

AI-native by design, not by addition

My clearest technical conviction is that AI integration is a first-class architectural concern, not a layer applied after the fact. The benchmark I hold myself to: “‘understand and apply AI tools’ sets a low bar. The intent should be workflow-level change, not tool familiarity.”

This shows up in the actual contribution work. The AXS design system:

• Generates machine-readable component metadata (axs.web-types.json, axs.html-data.json) at every build, so every developer’s editor understands the component API automatically.
• Ships an MCP server (axs-mcp) exposing 9 tools across components, design tokens, and recipes, making the entire design system queryable by any AI assistant without fine-tuning or RAG.
• Uses Claude Code skills to enforce architecture patterns through agentic workflows, not code review.

The framing I use for the IDE metadata layer: “Before any AI agent enters the picture, the authoritative component API needs to be machine-readable and editor-discoverable. That’s the foundation every other layer depends on.”

The closed loop: the design system generates its own AI-readable documentation at build time, which feeds both external AI assistants and internal agentic workflows, and documentation quality is measured by an automated AI audit. The system continuously improves its own AI-readiness. See AXS + AI: The Three-Layer Architecture for the full technical breakdown.

Documentation as an engineering deliverable

I treat documentation quality as a first-class engineering metric, not a nice-to-have. The /test-docs audit skill exists because we needed a way to answer a specific question: are our docs actually sufficient to guide an AI agent through building a component correctly?

The answer is now measurable, trackable, and improvable, percentage score, structured checklist, rather than a gut feel. The underlying principle extends beyond AI tooling: documentation that can guide a capable agent can guide any new engineer. The bar is the same.

Part III, The through-line

How I mentor and how I contribute are the same instincts applied at different scales.

In both cases: encode the standard in the system rather than carrying it in your head. Make the right path the default path. Measure quality explicitly so improvement is visible. Calibrate the work to where someone (or something) actually is, not to a generic template.

What I want from the work:

• Patterns I’ve worked out should be usable across the org, not just inside my team, migration kits, templates, education sessions, the things that travel.
• An experimentation-driven culture using GenAI tools as workflow change, not just chat assistants.
• A team that doesn’t need me in the room for the architecture to stay coherent.

The AXS MCP server is a working prototype of that posture. The V1 migration skills are a working prototype. The documentation quality audit is a working prototype. The case study is the pattern, already running.

Phrases that recur

These are mine, and they capture how I think:

• “Workflow-level change, not tool familiarity.”
• “You don’t need to wait for a formal venue; start creating them.”
• “The talent is there. I need the discipline to match it.”
• “Solutions-focused, don’t just flag problems, always pair with ‘so here’s what we’re thinking.’”
• “I set a high bar intentionally because I believe in the team.”
• Compounding value, the measure I apply to both architecture decisions and engineering growth.