How I work
How I think about product and engineering.
Framing the problem
Before building anything, I want a one-pager that says who the user is, what's hard about their life right now, and what it looks like after our software exists.
When the framing is clear, people make good decisions on their own. Engineers, designers, support, sales. Everyone can look at the one-pager and figure out their part.
Engineering and delivery
Deadlines matter and we meet ours. We just don't get there through estimation. Estimates are always wrong, and the real damage starts when someone turns rough sizing into a timeline and now you have a gantt chart. So we pick a date, commit to an outcome, and cut scope until it fits.
Every merged PR has to be deployable. Green build, tested, secure. Anything not ready for customers goes behind a flag, so we can ship any time.
Working with agents
When software gets cheaper to produce, you don't get less engineering. You get more software. Same thing that happens when you build more motorways and get more traffic. What that means for the shape of engineering teams, I honestly don't know yet.
Day to day, we're building the harness: parallel worktrees, specs that agents can follow, sandboxed permissions. The goal is agents that can work fast without someone reading every line.
Influences
Lean Enterprise by Humble, Molesky, and O'Reilly is probably the book I recommend most. It's about lean applied to large organisations, drawing from Toyota, 3M, NATO, the US DoD. It convinced me lean isn't a startup thing.
Also: Working Backwards for Amazon's press-release-first product approach. Jobs to Be Done (Christensen) for figuring out what job the customer is actually hiring the software to do. Opportunity Solution Trees (Torres) for mapping the space between a problem and its possible solutions.
I write about specific decisions in more detail on the writing page. phil@pghale.com