- ❤️ Working at Red Hat on the Open Data Hub AI Dashboards as an engineering manager.
- 💬 Ask me about breaking into technology as a diverse person, and check out my network if I can help make intros.
- 👨🏻💻 Professional TLDR;
Lifelong technologist patiently evolving into a full stack generalist, looking to use my skills to improve the human condition. - Fun Fact: First fell in love with tech in middle school when my 10mb shared hosting space allowed me to create at home, and share it with classmates. Bought www.bobscomputers.com shortly therafter!
- ☕️🤙 Message me on LinkedIn if you'd like to grab coffee in the Boston area, and I am in NYC a few times a year.
- 🎮 Lifetime playcount by hours: Factorio, Space Engineers, Diablo, Dyson Sphere Program, Fallout
- 🛠️ Hobbies include pets, DIY/home improvement, and 🐠🐡 Saltwater Reefkeeping
- 📇 Contact info: LinkedIn.
I optimize for systems over heroes.
My responsibility is to design operating models that scale beyond any one individual — including me and my team leads.
Core principles:
- Clear ownership at every layer
- Visible work and documented decisions
- Public context by default
- Distributed authority
- Sustainable 24×7 execution maturity
If something depends on one person, it is fragile. If it scales across time zones and absence, it is durable.
I have led and operated in environments requiring:
- Multi-time-zone collaboration
- Async-first execution
- Clear handoffs across regions
- Public decision logs
- Incident clarity under pressure
- Reduced single-point human dependencies
Mature systems:
- Function while leaders are offline.
- Allow team leads to decide without escalation.
- Make work and risk visible without private backchannels.
- Balance psychological safety with accountability.
My goal is not to be central. It is to make the system resilient.
To prevent bottlenecks and support distributed leadership:
My work hours are not your work hours.
I may respond outside traditional windows. There is no expectation of immediacy or after-hours reciprocity.
The same applies to my team leads.
Public channels first.
If a question, decision, or clarification benefits more than one person, post it publicly.
This:
- Protects team leads from private escalation gravity
- Builds shared context
- Strengthens distributed authority
Avoid bypassing leads via DM when the topic is operational.
DMs are appropriate for:
- Sensitive personnel matters
- Psychological safety concerns
- Active policy breaches
- Explicitly private topics
DM SLA: 24 business hours.
This applies to me. It also applies to respecting my team leads' focus.
If urgent, include:
- Impact
- Deadline
- Decision required
Use email for:
- Cross-org coordination
- Director+ visibility
- External stakeholders
- Formal communication trails
Response expectation: 24–48 business hours.
Jira is the source of truth for:
- Work tracking
- Status
- Dependencies
- Risk visibility
If it isn't in Jira, it doesn't scale. Team leads own execution clarity within this system.
GitHub is the source of truth for:
- Code review discussion
- Architecture rationale
- Tradeoffs
- Change history
Prefer PR comments over Slack summaries.
- Engineer → Team Lead
- Public thread with context
- Escalate if necessary
Escalation should clarify ownership, not replace it.
If I do not respond immediately, assume I am preserving distributed authority intentionally.
Clarity scales. Centralization does not.
Evidence over claims.
Patterns visible across my repositories:
- Service scaffolding with container-first design
- Infrastructure-as-code experiments (Ansible, Docker Compose)
- Public architecture decision records
- Tooling and CLI abstractions
- OSS contribution history focused on documentation, structure, and maintainability
- Multi-agent and automation experimentation
The throughline is consistent:
Build systems that:
- Reduce implicit knowledge
- Prefer automation over repetition
- Survive contributor turnover
- Improve with documentation
If it cannot be cloned, versioned, or reasoned about asynchronously, it does not scale.