Communication
Plane is our source of truth. Slack is where we talk. Between the two, that is how work happens here.
Where work lives
Plane.
We use our own product to plan, track, document, and ship everything. Roadmaps, releases, RFCs, customer issues, decisions, retros: all of it. There is no parallel doc, no shadow tracker, no "the real plan is in this Notion." If it matters, it is in Plane.
This is non-negotiable for two reasons. One, it forces our product to be good enough to run a serious company on. Two, it means anyone at Plane can find anything they need without having to ask first.
Where conversation happens
Slack.
We have a deep Slack-Plane integration: updates from Plane flow into the right Slack channels, and conversations in Slack thread back to issues in Plane. The two surfaces work as one. Our customers use it the same way, and the feedback loop between how we use it and how they use it is one of the reasons it keeps getting sharper.
A few defaults:
- Default to public channels. DMs are for personal things. Everything else belongs in a channel where the people who need to know can find it.
- Default to writing. A Slack message that captures a decision is a doc once you cross-post it into the right Plane issue.
- Assume good intent. Especially when feedback is direct, and it will be.
- Be specific. Vague requests get vague answers.
Our cadence
We do not run sprints. We run releases.
Every two weeks, we cut a release. What goes in is decided by the product team's rolling roadmap, reviewed with leadership, broken down by team managers, and turned into concrete scope for each release cycle.
The flow:
- Product team maintains the roadmap.
- Leadership reviews and aligns on direction.
- Managers plan their team's scope for the next release.
- Engineers, designers, and PMs execute.
This applies across every product we ship. Each has its own release line, all coordinated through Plane.
When things change
They will.
A customer-critical issue lands. An assumption proves wrong. A feature in flight turns out to be the wrong solution. When that happens, the manager owning the team's scope decides how to reallocate. We do not freeze a release plan and force the team to ship a worse version of yesterday's decision. We shift, we communicate the shift, and we keep moving.