Community Office Hours

Community office hours for engineering, product, and strategy discussions across tech, teams, and execution.

I run community office hours for people working through hard engineering, product, and strategy decisions.

You can reach out with challenges related to technology, product direction, execution, team dynamics, or cross-functional tradeoffs.

These sessions are intentionally small and practical. The best use of the time is a decision that feels stuck: a platform choice with competing tradeoffs, a delivery pattern that keeps creating rework, a team boundary that no longer matches the product, or an AI adoption question where the tooling is moving faster than the operating model.

What Office Hours Are For

  • Tech strategy decisions with real constraints
  • Architecture tradeoffs and platform direction
  • Product strategy and prioritization tradeoffs
  • Delivery bottlenecks and execution reliability
  • Team design and ownership clarity
  • Leadership and communication decisions across functions

Good Questions To Bring

Good office-hours questions are specific enough that we can reason about constraints together. For example:

  • "Should we split this service now, or fix ownership first?"
  • "Our roadmap is moving, but incidents are rising. What should we inspect?"
  • "Where should humans stay in the loop for this AI workflow?"
  • "How do we help senior engineers make better cross-team decisions?"
  • "Which delivery metric is hiding the real bottleneck?"

If the question is still fuzzy, that is fine. Bring the symptoms, recent examples, and the decision you are under pressure to make.

Format

  • 4 slots per month
  • 45 minutes per session
  • Focused on one problem per session
  • Practical next steps, not generic advice

What Usually Happens In A Session

We first name the system we are really discussing: technical architecture, delivery flow, team ownership, product prioritization, or leadership behavior. Then we separate facts from interpretations. After that, we sketch two or three paths with the likely cost of each path.

The output is usually a short decision frame: what to try, what not to optimize yet, what evidence to collect, and which risk deserves explicit communication before the team commits.

How To Prepare

You do not need a polished document. A few bullets are enough:

  1. What changed recently?
  2. What decision is blocked?
  3. Which constraints are fixed for now?
  4. What has already been tried?
  5. What would a useful next step look like?

The more concrete the example, the better the discussion. A real incident, missed deadline, tense roadmap decision, or confusing architecture tradeoff is more useful than a broad prompt like "how do we improve engineering?"

Possible Outcomes

A good session usually ends with one of these:

  • a sharper problem statement
  • a decision matrix for two or three options
  • a small experiment to run with the team
  • a communication plan for a risky tradeoff
  • a list of evidence to collect before committing

Sometimes the useful outcome is deciding what not to do yet. That can save a team from turning uncertainty into premature process or architecture.

What This Is Not

This is not a pitch call, generic career advice, or an open-ended consulting session. It works best when you want a sharper way to think through one hard problem and leave with a concrete next step.

Request a Slot

Email me at tm@whatworked.io with the subject:

Office Hours

In your email, include:

  • your role and team context
  • the specific problem you want to discuss (engineering, product, team, or strategy)
  • what decision you are trying to make
  • timeline and constraints

If there is a fit, I will reply with available slots and a structure for the session.

If your question is closer to an ongoing engagement, read Ways I Help. If it is specifically about AI systems or engineering judgment, the AI & Systems Notes page shows the style of problem breakdown I usually find useful.

Related Pages