How I think

Leadership

The hardest thing to build is the system around the software: the leadership, culture, delivery discipline, and decision-making model that keeps an organization aligned while everything about the business is changing.

Most delivery problems are system problems wearing a technology costume. When work stalls, when quality slips, when good engineers burn out, the instinct is to look harder at the technology or the people. The cause is almost always the system they work inside: how decisions get made, how priorities move, and how much clarity actually reaches the people doing the work.

What follows is how I think about that system: how decisions should be made and tracked, how teams grow, what pressure does to organizations, and what technology investment owes the business. Software delivery becomes a strategic advantage in organizations where work moves, people grow, and investment produces measurable outcomes. Building those organizations is the work of leadership.

Evidence first

On decisions and evidence

Most organizations are better at making decisions than at finding out whether they were right. Goals get set, work gets funded, software ships, and the loop never closes. I hold post-decision accountability as seriously as pre-approval rigor, because a decision well-made and poorly tracked is still a decision poorly managed.

Closing that loop starts with making work visible. Flow gets work into production quickly and predictably. Realization proves it created measurable business value. Flow metrics, value stream visibility, and aging-of-work analysis show where work stalls and what a decision actually changed. The discipline goes beyond setting goals: connect the work to those goals before delivery, then follow through afterward to determine whether the expected outcome was realized.

Evidence has limits, and judgment fills the gap. Transformations stall in predictable places, and watching change succeed and fail through growth, modernization, and acquisition has taught me the pattern that matters most: operations, culture, and alignment to outcomes have to improve together, not in sequence. Fixing one while ignoring the others just moves the bottleneck.

The best input rarely comes from the top of the organization chart. The people closest to the work see problems before any dashboard does: engineering leads, architects, QA leaders, platform and SRE leads, data engineers, and Agile leaders. They should operate as active advisors within their domains. The executive’s job is to set direction, make the why behind decisions unmistakable, create the conditions for honest input, and integrate that expertise into decisions the whole team understands and can execute with confidence. Safety is not the absence of challenge. High-performing teams debate, disagree, and hold one another accountable, and the conflict stays on the problem, not the person.

On teams and the people in them

Organizations structure delivery in different ways: some around functional silos, others around cross-functional, autonomous, accountable teams. For those that choose the cross-functional path, success depends on the operating model around the teams. Autonomy scales only when the system is designed for it: clarity about what matters, trust that runs in both directions, discipline in how work flows, visibility into where it stands, and leaders willing to improve the system instead of only asking teams to move faster.

Past a baseline of technical skill, the better hiring decision usually comes down to attitude, curiosity, and team fit. Skills can be developed; curiosity is much harder to teach. And once people are on board, growth should not be left to chance: a clear, supportive career path makes development visible, intentional, and real. Leadership means more than extracting output: expanding capability, increasing confidence, and helping people leave stronger than they arrived. The best leaders are career accelerators for the people around them, and that is the standard worth holding.

Sometimes that investment means building what the broader organization cannot provide. When HR support for engineering careers was limited, we designed our own inside technology: a career path with clear expectations at every level, a performance assessment tied to those expectations, and a promotion assessment that clarified what advancement requires and gave managers a consistent, evidence-based way to support promotion cases. People knew what growth required, and promotions rested on demonstrated capability.

The same care belongs at the front door. I designed, developed, and continually improved our engineering hiring practices: the interview structure, the workflow, and the assessments candidates work through. Candidates judge an organization by the quality of its interviews, and the interview is the first experience of the culture they are joining. Feedback from candidates and new hires remained highly positive about both the experience and the quality of each interview, and that reputation compounds: good engineers refer other good engineers.

On innovation

Innovation needs protected time, and protected time is an investment decision. I sponsored and grew a standing innovation practice much like Google’s 20% time: we started slowly with half-day Fridays, expanded to full-day Fridays, and called them Innovation Fridays. Most of the work went toward improving our products, and we made room for learning and growth efforts as well.

The practice itself got the same treatment as any other investment: watch what actually happens, then improve it. Over the years we noticed that only developers participated, so we renamed the practice 50 Fridays and made it explicit that QA, production engineering, data engineering, and Agile leaders belonged in it alongside developers. An innovation practice that reaches one discipline improves one discipline; widening who felt invited widened what came out of it.

On autonomy and accountability

Trust is not granted by title. Leaders have to build it, earn it, and protect it. Teams want clarity on the problem they are solving and why it matters. Then they want the autonomy to solve it, with accountability for outcomes and learning.

Accountability only works when measurement serves the team instead of watching it. Metrics improve the system, they do not surveil the individual: teams use them to understand their own work, leaders use them to remove constraints. The moment a metric becomes a performance weapon, it stops telling the truth.

When it gets hard

On pressure

Urgency flows downhill unless a leader absorbs and translates it. Investors and boards have legitimate return expectations and defined timelines, and a PE investment thesis carries a natural urgency that will pass straight through an organization if nothing slows it down. The less visible part of the executive job is managing that pressure well: being honest with leadership about what is and isn’t realistic while protecting teams from the anxiety and instability that unfiltered urgency creates. Engineers do their best work when they have clarity and trust. Maintaining that environment under pressure is a leadership responsibility, not a nice-to-have.

The hardest version of that responsibility is a workforce reduction. Those are the hardest days in the role, balancing real empathy for people whose livelihoods are affected with the business realities that made the decision necessary. Those moments are never purely financial events. How a leader handles them determines whether the trust and culture of the remaining team survives intact. Shield teams from noise while staying honest about reality. Both halves of that sentence matter.

On partnership

Strategy, investment priorities, and operating expectations belong to the executive. Technical execution belongs to the leaders closest to the system: architecture, platform and production operations, QA, and data leadership operate as advisors and owners within their domains, and Product and Engineering co-own outcomes and constraints. Decisions made close to the work are better decisions, and making them there builds the leaders the organization will need next.

The same principle applies upward. The CFO’s terms are COGS and OPEX structures, ROI frameworks, and opportunity cost. A technology leader who cannot reason in those terms forfeits the budget conversation before it starts. Finance fluency shapes how technology budgets are set, defended, and spent, and it turns the technology seat at the executive table into a full partnership.

The value center lens

On investment

Engineering is a value center, not a cost center. Every investment decision is an opportunity cost decision: what we choose to fund defines what we choose not to do, and that tradeoff deserves transparency, not convenience.

In practice that means build/buy/partner decisions made with weighted evidence, budget governance as an ongoing operating discipline rather than a once-a-year planning exercise, annual vendor rationalization reviews, a platform-as-a-service model so delivery teams consume infrastructure instead of managing it, and AI investment measured by whether it improves the system end-to-end.

Nothing tests that discipline like a capital event. Acquisitions and funding rounds compress time, raise stakes, and expose every weakness in how an organization makes decisions, which is exactly where the value-center lens matters most. The career-level record, including the Instructure integration, is on the experience page.

Thinking in practice: when the evidence contradicts the instinct

Sunk cost is the hardest bias to argue with, because protecting an existing investment feels like discipline. We had already invested in building a Value Stream Management solution internally, and the instinct to protect that investment was real. I worked through the evidence before recommending a change in direction: the true cost of the homegrown solution including maintenance and opportunity cost, a weighted vendor scorecard across candidate enterprise platforms, and a business case showing where the crossover point was. The structure of the evidence and deal framing enabled favorable multi-year contract terms.

I presented the full journey, the build experience, the evaluation process, the decision criteria, and the outcomes, at the Flowtopia conference hosted by the Value Stream Management Consortium. The learning: a well-structured buy decision, grounded in evidence and negotiation discipline, can outperform the perceived control of a homegrown solution.

Thinking in practice: adding capacity without breaking the team

Capacity pressure tempts organizations to trade team integrity for headcount. When two high-priority integration and refactoring initiatives required delivery capacity beyond existing team bandwidth, the critical decision was how to augment. Rather than adding individual engineers to existing teams, which would dilute team identity, create onboarding drag, and fragment accountability, I chose to partner with a provider that could deliver complete, agile-ready delivery teams. I assigned an Agile Leader and Enterprise Architect from our organization to each team for delivery governance and architectural guardrails, and managed vendor performance actively throughout.

The most significant underestimate was onboarding time: even experienced teams needed longer to reach full productivity in an unfamiliar codebase than planned. In hindsight, committing a senior engineer, product owner, or engineering manager to each team would have accelerated onboarding and raised the quality ceiling earlier. The model is viable and worth repeating, with a more intentional embedding commitment from the start.

Beyond the org chart

On mentorship

The hardest transition in an engineering career is the first one into management: the skills that earned the promotion are suddenly the wrong ones for the job. I developed first-time manager communities so new line-level managers could learn that transition together instead of alone, and I mentored many of them directly through it.

Some of those relationships outlasted the org chart. After leaving Parchment and Instructure, I still meet with a few of those leaders on a monthly or biweekly cadence. It is a small commitment of personal time, a few hours a month, and it continues because their growth did not end when the reporting line did.

Third-party validation

From people I’ve worked alongside

Phil’s leadership approach began with people and talent development. He then motivated and optimized his teams through continuous improvement of our software engineering processes.

His executive sponsorship in my work has been incredibly impactful, and his ability to work cross-functionally with technology, product, and every other team makes Phil unique.

I sincerely appreciate the generosity with which he shares his expertise and experiences—he makes me a better leader.

Read all endorsements → · See the executive experience →