High-touch engagement builds trust faster than any documentation. Written docs answer questions developers know they have. Office hours and hackathons surface questions developers didn't know to ask — and reveal platform problems that would otherwise stay hidden until they cause a production incident.
1. Office Hours: The Help Desk That Scales
Office Hours are scheduled, recurring blocks of time — typically 60 to 90 minutes, once or twice a week — where any developer can drop in to ask questions, troubleshoot a problem, or brainstorm an approach with platform experts. The format is deliberately informal: no agenda, no ticket required, no judgment for "basic" questions.
Why they work: Most developers won't file a support ticket for a question they think is too simple. They'll either struggle silently, ask a colleague who may give them wrong information, or give up and use a workaround. Office Hours lower the barrier to asking for help to near zero.
Public Solving: When a developer asks a question during Office Hours, the answer should immediately become a public artifact. Post the solution to a dedicated Slack channel (e.g., #platform-office-hours-log), add it to the FAQ in your documentation, or record a short screen capture. This transforms a one-to-one interaction into a one-to-many resource. If the same question appears three times in Office Hours, that's a signal that your documentation or UX has a gap that needs fixing — not that developers need to read more carefully.
Tracking patterns: Keep a simple log of every question asked. After four to six weeks, cluster the questions by theme. The clusters reveal your platform's most significant usability problems. This data is more actionable than any survey because it reflects what developers actually struggle with, not what they remember struggling with when filling out a form.
2. Internal Hackathons: The Innovation Lab
Hackathons are 24 to 48 hour events where developers are encouraged to build something new using the platform's tools, with minimal constraints and no production pressure. Teams self-organize, pick a problem they care about, and build.
The dual purpose: On the surface, hackathons produce prototypes and generate excitement. Below the surface, they are the most effective stress test your platform will ever have. In a single day, you get dozens of teams — with varying levels of platform familiarity — attempting to use your tools in ways you didn't anticipate. Every place they get stuck is a real usability problem.
Observation as a method: Platform engineers should actively roam during a hackathon, not just watch from a table. Sit with teams. Watch where they pause, where they open a second browser tab to search for something, where they ask each other "wait, how do you do X?" If ten different teams struggle with the same API endpoint or the same CLI flag, you've found a critical usability bug — one that exists in production right now, silently slowing down every team that hits it.
Post-hackathon retrospective: Within 48 hours of the hackathon ending, publish a "What We Learned" document that lists every friction point observed, ranked by frequency, with a committed timeline for fixing each one. This document serves two purposes: it shows developers that their struggle was seen and will be addressed, and it gives the platform team a prioritized backlog derived from real usage data.