Building Engineering Leaders

Management as a Craft

I came to management the way most engineers do — by being good at engineering. I didn't plan to manage. I grew into it organically, and then encountered the question I'd never been prepared for: what does a manager actually do?

The insight that changed my trajectory: engineering is a discipline you can study. You learn data structures, design patterns, system architecture. Management is also a discipline — but almost no one treats it that way. Most engineers who become managers just improvise, drawing on intuition and the managers they've had. Some get lucky. Most repeat the dysfunctions they experienced.

I decided to treat management the same way I'd treated software engineering: as a field with real theories, research-backed practices, and accumulated wisdom worth learning deliberately. I "sent myself to college" for management — reading Jurgen Appelo's Management 3.0, studying team dynamics, change management, psychological safety, and motivation theory.

That intentional learning journey — started at eMortgage Logic over a decade ago — is the origin of everything in this page.

The Management Training Program

Shortly after joining Porch Group, I launched a formal engineering management training program. The premise: most managers are never taught the craft they're supposed to practice.

The curriculum philosophy: The point isn't a fixed syllabus. It's to establish that learning management is an intentional endeavor. The program covers management principles, tools, and practices — what it means to be a manager, what enables teams to do great work, and how to think about the role as a craft rather than a title.

Topics covered across sessions:

Management 3.0 — motivation models, organizational complexity, team empowerment
Team topologies and organizational design
Psychological safety — creating environments where people take risks and speak honestly
Change management — bringing people with you rather than dragging them
Motivation theory — what actually drives people
The maker vs. manager mindset — the hardest transition new managers face
AI's impact on the manager role — the last five sessions shifted to this focus

The growth: The program started for my own manager team. By mid-2025, ~36 total sessions delivered, ~12 in 2025 alone. It grew beyond my direct reports — leaders from across the organization started participating.

The program is one of my clearest expressions of a belief: the best thing a senior leader can do is make the leaders around them better.

1:1 Philosophy: Their Time, Not Yours

My 1:1 approach starts from a simple premise: it's their time.

Most managers use 1:1s to get status updates or work through their own agenda. I use them differently:

Their agenda first. The 1:1 belongs to the direct report. They decide what to bring. I'm there as a thought partner, sounding board, and when needed, a place to vent. My job is to be useful to them — not to extract information for myself.

Feedback delivered consistently. The 1:1 is the primary vehicle for giving feedback. Not the annual review. Not the mid-year check-in. If someone is surprised by something in their annual review, it means they haven't been getting enough feedback throughout the year. The annual review should be a summary of conversations that have already happened — not news.

Custom, not formulaic. Some 1:1s are structured; some follow the report's lead. What's not negotiable: the meeting exists, it recurs, and it's treated as a priority — especially in remote work where you won't cross paths in the hallway.

Beyond direct reports. I hold informal 1:1s with skip-level team members — engineers who have strong situational awareness, who surface what's actually happening on the ground. And I maintain 1:1s with peers, stakeholders, and leaders in adjacent business units — because in a remote world, relationship building has to be intentional. You don't want the first conversation with someone to be about a problem.

Developing People

The BA Who Became a Product Owner

One of the most tangible coaching stories: a business analyst at Brinks who transformed into a senior product owner/manager.

She was technically excellent — knew the business, was organized, was trustworthy. But her mental model of the job was "collect requirements from stakeholders and hand them to engineering." That's a reasonable BA role — but a failure mode for a product owner.

The key coaching move: I pushed her outside her comfort zone, deliberately and consistently. Asked her to make decisions, not just document them. Reframed her job: not "what did they ask for?" but "what are they trying to accomplish, and how would we get there?" Made it clear she had permission to take ownership — to bring ideas, to propose directions, to evaluate trade-offs.

The safety net: I made it safe to fail. I didn't push her into a void — I was explicit that her decisions weren't irreversible, that experimentation was encouraged. The combination of encouragement and safety is what let her grow without freezing.

She earned the product owner role, continued to develop, and is now a senior product owner/manager. Her career arc is some of the strongest evidence I have that this coaching approach works.

The Engineer → Manager Transition

I've coached multiple engineers through the transition to management. What they consistently fail to anticipate:

The maker vs. manager shift. Engineers solve problems by doing. If something needs to get done, you stay late and do it. You personally ensure quality. You personally deliver.

Managers can't do that. When you move to management, you can no longer personally ensure anything is done — you have to enable and rely on the team. For engineers used to trusting their own hands, that's deeply uncomfortable.

The hardest part: letting go. Letting go of the execution. Letting go of the satisfaction of building. Learning that your leverage is now through other people — through the clarity you give them, the environment you create, the obstacles you remove.

What I teach new managers:

Team structure and why it matters — who works with whom affects how information flows
Communication patterns — ceremonies, visibility, making work legible to the organization
Motivation — what actually drives people, and how to create conditions where they want to do great work
Guardrails vs. micromanagement — how to set boundaries without controlling execution
Agile principles and why — not just the practices, but the reasoning, so managers can make judgment calls when the playbook doesn't fit

The Gardeners

One of my first structural interventions at Porch Group: naming my managers as a team.

The managers hadn't been operating as a cohesive unit — each tending their own team without much cross-pollination. I brought them together as "the Gardeners," facilitating regular conversation and shared problem-solving. The effect: ideas, practices, and context flow laterally across the organization rather than staying siloed within individual teams.

This is a pattern I've used across every company. At Brinks it was the Ziglar Tribe leadership team. The mechanism is the same: make the managers a team. Managers who talk to each other, solve problems together, and share what's working compound their individual impact into organizational capability.

Building a Global Organization

Porch Group's engineering organization spans the US, Latin America, and India. Key learnings:

Time zone reality. Latin America works well — effectively the same time zone as the US. India is different. The overlap window for synchronous collaboration is narrow, which creates meeting congestion and forces hard choices about which conversations require real-time participation. The principle: push toward greater India independence over time, but deliberately rather than prematurely.

The India hiring lesson. We moved too fast. The decision to hire a complete team in India rather than embedding individuals into existing teams created a ramp-up challenge — new engineers dependent on US colleagues for context, domain knowledge, and answers, but separated by a 10+ hour time zone gap. Cycle times suffered. Questions took 24-48 hours to resolve.

The fix: slow down intentionally. US engineers now invest time in thorough code reviews and in-depth context conversations. Cycle times are slower in the short term, but the investment builds the domain understanding India engineers need to eventually run independently.

The blueprint. The 2025 India team onboarding was ultimately successful and created a repeatable blueprint for future launches. The lesson from the earlier misstep is baked into the process.

Engineering Excellence Philosophy

Engineering excellence isn't a checklist. It's a state of engagement. A team with engineering excellence feels accountable — not just for delivering features, but for the quality, reliability, and maintainability of what they build. They think about architecture. They care about security and compliance without being told to. They instrument their systems, create alerts, and want to be the first to know when something is wrong — not the customer.

The opposite is a feature factory: a team that ships tickets but doesn't think beyond the next sprint. I've spent my career working against that model.

Russell's Button

At Brinks, I conceived a testing philosophy I called "Russell's Button" — a single button I could push and be 80% confident that everything was working correctly in production.

The button was symbolic. The discipline was real: production synthetic testing — automated tests running against live production systems, verifying that mission-critical workflows are actually functioning.

We built it from scratch. Worked with the finance team to establish test users in production whose transactions wouldn't affect real financials. Built automated synthetic tests covering critical user flows. Created a test runner UI that anyone at Brinks could use to trigger regression tests.

The value was visible. Other teams built their own synthetic tests. The practice spread across IT and — as far as I know — is still in use today. A cultural shift: from discovering problems reactively (when customers called) to detecting them proactively (before anyone else noticed).

Security Shift-Left

At Porch Group, I led a cross-functional effort to advance application security posture:

Enabled static code analysis (SAST) across all repositories — automated vulnerability scanning on every commit
Enabled secret scanning and dependency scanning
Integrated CodeRabbit AI code review — security issues surfaced live in pull requests, before code merges
Built processes with the security team for how engineering responds when vulnerabilities are identified

Security moved from a gate at the end of development to a continuous signal embedded in the development workflow.

DORA Metrics

Introduced DORA metrics as a framework for measuring engineering performance — deployment frequency, lead time for changes, change failure rate, time to restore. Part of the broader push to track meaningful engineering KPIs beyond feature throughput.

Earlier Career Foundations

eMortgage Logic / Assurant (2007–2016): Where the management philosophy was born. Started as a software engineer, grew into team lead and manager. Drove Agile/Scrum/Kanban adoption. Began studying management theory — Management 3.0, Agile leadership models — and started asking the question that shaped my career: what does a manager actually do in an Agile team? Facilitated GTD (Getting Things Done) workshops to build team productivity practices.

Wolters Kluwer (2016–2018): Led blameless postmortems — separating system problems from individuals to build psychological safety around failure. Continued GTD workshops. Individual development planning treated as seriously as delivery planning. Hired 6 people in 4 months while coaching Scrum ceremonies through a major cloud migration.

The Through-Line

Across every company and every team, the approach starts the same way: build relationships first — on the team and across teams. Teams left in isolation calcify. Cross-pollination is what keeps them growing.

Everything else — the frameworks, the org structures, the cultural change — flows from that foundation.

→ Back to Resume