← All Steps

Communication & Conventions

We’re spread across client projects and internal work. We default to async, and it only works if people write things down.

Async First

Write it down instead of scheduling a call. A Slack message or GitHub comment beats a meeting almost every time. People are across timezones, on different client projects, or heads-down on something. Don’t expect instant replies, give it a few hours.

When you do write, include enough context that someone can actually respond. Links, screenshots, error messages, what you’ve tried. “It’s broken” is not a message. “The API returns 403 when I hit /users with this token, here’s the request” is.

Use threads. Nobody wants to scroll past 40 unthreaded messages to find the thing they need to reply to.

Save calls for things that aren’t working in text. If you’ve gone back and forth three times and you’re still not aligned, jump on a huddle and sort it out.

How We Work

Most of the team is on client projects at any given time. Some work on internal stuff like our open source tools and infrastructure. Same rules either way.

Client Projects

  • You’ll be embedded in a client’s team or working on their infrastructure
  • Follow the client’s processes in addition to ours (their Jira, their Slack, their deploy process)
  • Keep your Gremlin team lead in the loop on progress and blockers
  • Client credentials and data stay isolated, never mix across projects

Internal Projects

  • We use GitHub Issues and Projects for tracking
  • PRs go through the standard review process
  • Deploy when ready, no gatekeeping, but use common sense

Communication Channels

Day-to-day

Slack or Teams for async stuff. GitHub PRs for code discussion (keep it in the PR, not in chat). Calls when text isn’t cutting it.

Escalation

If something is urgent:

  1. Message your team lead directly
  2. If they’re unavailable, post in the engineering channel with context
  3. For production incidents, follow the client’s incident process

When to speak up

Let the team know when you pick something up, when you’re blocked, and when a PR is ready for review. If you’re stuck, say so early rather than sitting on it until end of day. If you’re going to be away, give your team lead and any client contacts a heads up.

Documentation

If you spent time figuring something out, write it down. A runbook, an ADR, a README update, whatever fits. Don’t assume the next person has your context, because they won’t.

Project-specific docs go in the repo (docs/ folder or README). Cross-project stuff goes on this site. Client-specific docs stay with the client.

Meetings

Standups

Async by default. Post in the team channel:

  1. What did I do yesterday?
  2. What am I doing today?
  3. Am I blocked on anything?

Some client projects run sync standups. Show up on time, keep it under 2 minutes, take discussions offline.

Retrospectives

We run retros at the end of sprints or project milestones:

  • What went well?
  • What could be better?
  • What will we change?

Be honest. Retros only work if people speak up.

Code Conventions

Naming

  • Branches - feature/, bugfix/, hotfix/ prefix (see Git Configuration)
  • Commits - conventional commits (see Conventional Commits guide)
  • Variables - descriptive, no abbreviations unless universally understood (db is fine, cstmrSvc is not)

Code Style

  • Use the project’s linter and formatter. Don’t fight it.
  • Format on save. No style debates in PRs.
  • Follow the existing patterns in the codebase. Consistency beats personal preference.

Pull Requests

  • Keep them small and focused
  • Write a description that explains why, not just what
  • Respond to review feedback within a working day
  • Don’t let PRs sit open for more than 2-3 days

Working hours

Flexible. Be around roughly 10am-4pm UK so there’s overlap for the async stuff to actually flow. If you’re working with a client in a different timezone, agree on overlap hours with them. Don’t burn yourself out doing heroic sprints. Sustainable pace is the point.

Next Steps

Continue to Learning Resources for curated links to deepen your knowledge.