Strongly Held Beliefs
These are a few strongly held beliefs that guide how I work.
Find pain, not flaws
A request is evidence of a problem, not a build specification. Look for the underlying pain, the recurring pattern, and the outcome people are actually trying to reach.
Build to learn, then cut to clarify
A prototype tests an idea; it is not a commitment to the final system. Software often expands while you learn, then contracts as you remove what no longer earns its place.
Spend complexity where it matters
Pragmatism is not choosing the least sophisticated tool. It is resisting the urge to rebuild what already works, and writing custom logic only where it creates real leverage.
A manager’s job is to reduce chaos
Good management creates clarity: what matters, what can wait, who owns what, and how the team makes decisions. The goal is to make it easier for people to do good work.
Follow the signal
Cut through requests, requirements, and noise to find the recurring pain. Focus on the work where solving it creates the most leverage.