// WORKING STYLE
How I Work
How I move through unclear work, help people get aligned, and leave behind something useful after the initial push.
// CORE APPROACH
The Short Version
I am a technical product and program leader who builds systems. Most of my work has been about taking confusing, cross-functional situations and making them easier for people to understand, run, and improve.
Whether I am planning a military task, running a community event, coordinating a software roadmap, or building an automation workflow, I start by learning how the pieces interact. Then I look for the simplest useful system that makes the next pass easier.
// WHAT TEAMS CAN EXPECT
What Working With Me Feels Like
I am not trying to make the room louder. I am trying to make the work easier to see, easier to move, and easier to keep improving.
Clarity before speed
I like teams to know what problem we are solving, who owns what, and where decisions need to happen before everyone starts sprinting.
No surprise blockers
I try to surface tradeoffs, risks, and stuck points early, while there is still time to do something useful about them.
Things people can keep running
The best result is not just that something ships. It is that the workflow, notes, and rhythm are clear enough for other people to keep using.
A better next pass
Reviews only matter if they change what happens next. I care about honest debriefs, small fixes, and actually carrying lessons forward.
// WORK HABITS
The Habits I Come Back To
These are the patterns I lean on when the work is unclear, cross-functional, or moving faster than the process around it.
Understand before fixing
I try not to rush into a solution just because one is available. I want to know what is actually getting in the way, what people have already tried, and where the pain is really coming from.
Turn needs into delivery artifacts
A good idea still needs a usable path to delivery. I translate research, support friction, stakeholder needs, and operational constraints into PRDs, one-pagers, user stories, acceptance criteria, OKRs, roadmaps, and release plans.
Get the people part right
Tools can help, but they usually amplify whatever is already happening. Before I automate anything, I want the ownership, handoffs, and communication habits to make sense.
Make the unclear parts visible
Unclear work is normal. I help by naming the open questions, spelling out tradeoffs, documenting decisions, and making sure people know what is settled and what still needs attention.
Deliver in working increments
I use Scrum, Kanban, sprint planning, standups, backlog grooming, cross-functional estimation, QA coordination, and release planning as practical tools, not ceremony. The point is to make work visible, sequence it honestly, and keep teams moving.
Build for real people
A system only works if real people can use it when they are tired, busy, distracted, or under pressure. I try to build for the actual humans in the loop, not the perfect version of them.
// WORKING STYLE
How I Like To Work
A quick look at how I communicate, plan, lead, and build once the work is moving.
◈ How I communicate
- Direct, without being blunt. I say what I mean.
- Written-first - I think clearly in structured writing.
- I document decisions and the reasoning behind them.
- Async by default, synchronous when it actually requires synchrony.
- I give candid feedback and expect it in return.
⬡ How I plan
- Start with outcomes, not activities.
- Work backward from the deadline with explicit milestones.
- Build contingency into the plan before it is needed.
- Track health, not just status - are we actually going to make it?
- Regular review cadences to catch drift early.
◉ How I lead teams
- Clear mission and commander intent - then let people execute.
- Make ownership unambiguous. No unclear handoffs.
- Run lightweight, high-value retrospectives after every major event.
- Shield the team from noise; escalate blockers fast.
- Invest in capability building, not just task completion.
▣ How I build and deliver
- Simplest working solution first, then optimize.
- Document as I go - future me and future operators need this.
- Build for observability - you cannot operate what you cannot see.
- Automate the repeatable; keep humans in judgment roles.
- Nothing is done until it is documented and someone else can run it.
⊕ How I deliver with technical teams
- Write PRDs, one-pagers, user stories, and acceptance criteria that engineering, design, QA, and support can use.
- Use Jira, GitHub Projects, Confluence, and Miro to keep plans visible and decisions traceable.
- Gather estimates with the people doing the work, then sequence delivery around real constraints.
- Coordinate QA and release readiness so shipped work can be supported after launch.
- Stay close enough to technical workflows to manage GitHub Actions, Perforce, and delivery tooling without presenting myself as a pure software engineer.
// TOOLS & FRAMEWORKS
Tools I Reach For
Tools matter when they make the work clearer or lighter. They are helpful, but they are not the whole strategy.
Planning and Documentation
Community and Communications
Automation and Integration
AI and Workflow
Infrastructure
Development
// LEARNING LOOP
How I Debrief After The Work
One habit I kept from military service is taking time to debrief after meaningful work. After a project, event, or tough cycle, I like to ask:
What was supposed to happen?
The plan, the intent, the expected outcome.
What actually happened?
Honest, factual account - no spin, no blame.
Why was there a difference?
What was underneath it, not just what showed up on the surface.
What do we sustain?
What worked? What should become standard practice?
What do we improve?
Specific, actionable changes to make the next one better.