DeAndre Harris

← Back

Current Role

From individual cases to support systems

My role began with complicated customer cases involving CI behavior, monorepos, Storybook extraction, resource loading, account access, and build limits. As the same kinds of problems kept coming back, I started working on the systems around the cases: how requests enter the queue, what context follows them, which operations are safe to delegate, and how a useful answer becomes shared knowledge.

That shift’s taken my role well past individual casework. I have authored 300+ merged pull requests across product fixes, documentation, infrastructure, tooling, automation, and migration work.

Owning the support platform

I proposed moving from Intercom to Plain after seeing gaps in our omnichannel support, particularly for Slack-based customer work. I completed the organization-wide migration, including authentication, data imports, cutover, and post-launch monitoring. Plain is now fully live, and I remain its point person and administrator.

Published Plain workflow with connected branches for filtering requests, assigning teams and users, applying account and priority labels, and routing work by region
Plain's primary workflow encodes the routing, assignment, labeling, and regional rules behind the support operation.

Making day-to-day administration safer

I built a Go administration system that runs as both a CLI and an MCP server. Support & Solutions Engineering use it for day-to-day administration without changing every task into an engineering request or relying on cumbersome raw GraphQL operations. It redacts PII by default and requires confirmation before destructive actions. The system posts weekly anonymous telemetry summaries to Linear, so I can find and fix failures like GraphQL schema drift, and internal users rarely have to encounter and report them.

Chroma CLI preview of a user deletion with redacted name and email, a list of affected accounts and apps, and a confirmation prompt before permanent deletion
Chroma previews the full impact of a destructive operation, redacts PII, and waits for explicit confirmation before proceeding.

Turning repeated work into shared knowledge

Support snippets live in version control, sync to Plain, and can be proposed through Slack with review gates.

Snippetsss is a Slack app for creating reviewable, repo-backed changes to Plain snippets: compose and preview a snippet, open a pull request, then automatically sync the change to Plain after merge.

I packaged our reusable support workflows as an agent plugin with one maintained source and generated packages for OpenAI, Claude, and Cursor. I migrated 18 canonical workflows covering triage, reproduction, escalation, QA, reporting, documentation, and safe handling. The plugin surfaces 19 skills alongside five MCP servers, including a documentation MCP with full-text search across product docs.

Support Engineering displayed as a Codex plugin with five MCP servers and 19 skills
Support Engineering packages shared support workflows and their connectors as an installable agent plugin.

One of those workflows uses resolved support cases to find gaps in customer-facing documentation, support snippets, and the internal knowledge base, then recommends and drafts the missing material for human review. Together, these systems make the knowledge from one case easier to find and reuse in the next.

Making incident communication more reliable

During incidents, customer impact and engineering context were scattered across Slack and Plain threads, slowing status-page updates and increasing the risk of overclaiming. I built a skill that separates confirmed facts from working theories and drafts stage-appropriate updates for human review. Across four test scenarios, it met every assertion, compared with 75% without the skill.

Using operational data to improve routing

When thread assignment felt uneven, I analyzed 30 days of routing data rather than treating the anecdote as the conclusion. The data showed that one engineer’s two-week absence had temporarily concentrated assignments on another teammate. It also exposed an opportunity to improve distribution through regional routing. I ran a 30-day pilot measured against assignment distribution, unassigned duration, response time, SLA breaches, and capacity pressure. It met the success criteria, and regional routing is now the permanent model.

Proposal slide showing a regional-first routing flow: prioritize the EU or Americas team according to business hours, skip people who are offline or at capacity, then fall back to the broader support team
The proposal deck translated the routing analysis into a regional-first model with broad-team overflow.
Senior Support Engineer
2024–
  • Built a Go tool that Support & Solutions Engineering uses for day-to-day administration. It runs as both a CLI and MCP server, redacts PII by default, and requires confirmation before destructive actions. Used its anonymous telemetry to find and repair GraphQL schema drift.
  • Authored 300+ merged pull requests across product fixes, documentation, infrastructure, tooling, automation, and migration work.
  • Shipped an agent plugin and cross-client package for OpenAI, Claude, and Cursor, migrating 18 canonical Support Engineer workflows and generating five shared MCP definitions from one maintained source.
  • Led and completed the move from Intercom to Plain across Support, Product Engineering, GTM, BizOps, Solutions Engineering, and Marketing. Owned authentication, routing, imports, customer context, cutover planning, and post-launch monitoring; continue as Plain’s point person and de facto administrator.
  • Built repo-backed support snippet tooling with automated Plain sync, review gates, and Slack-based authoring.
  • Analyzed 30 days of routing data to identify the cause of an assignment spike and found an opportunity to improve assignment distribution, response times, and SLA adherence. Based on those findings, proposed and ran a 30-day regional-routing pilot that met its success criteria and became the permanent model.